Not sure who this is for? It looks like something made for casual users, but I'm not sure that they need a web UI for remote control or CLI.

More advanced users are very unlikely to use something with such UI. I can't imagine that it will be fun to use while having 10 torrents, let alone 250+.

Even Fragments[1], the GNOME Circle app for BitTorrent that targets casuals can fit more downloads in a single view.

And what's the point of the search bar? All it does is open a new tab and search "torrent <keyword>" in either Google or DDG. I can do it myself. It's neither helping newbies nor advanced users.

Also the 1.7M package-lock.json[2] scares me, but so do most JavaScript projects. Do we really need that many JS libraries for a UI for a BitTorrent client?

In comparison, Transmission's web UI has a package-lock.json that uses 354K[3].

1: https://apps.gnome.org/en-GB/app/de.haeckerfelix.Fragments/

2: https://github.com/G-Ray/pikatorrent/blob/main/package-lock....

3: https://github.com/transmission/transmission/blob/main/web/p...

Thank you for your valuable opinion.

As an advanced user myself, remote control is important to me, but I also want to introduce more people to BitTorrent through a simple UI. Based on the comments, it seems I have missed the target for advanced users with these large cards, this is something I would like to improve.

What would you suggest? Should I offer two view modes, one with cards and one with a list? I could find a way to reduce the vertical height of the cards anyway.

In the near future, I plan to utilize the horizontal space to add filter and label management options, allowing users to quickly find specific torrents. I think displaying hundreds of torrents simultaneously isn't practical as I can't process them all. Instead, I believe a search bar and filters would greatly enhance the user experience. It seems people here would prefer a table view instead, like qbittorrent, what are your thoughts on this?

The search bar allows you to quickly search using the selected search engine. Google is just an example preconfigured in the settings, but you can configure any search engine of your choice. For example, you can add archive.org with the URL "https://archive.org/search?query=". While I may consider integrating a search feature with plugins in the future, I currently find the existing search bar to be a simple & time-saving shortcut for finding torrents online.

Regarding the package-lock.json, I understand your point. However, please keep in mind that PikaTorrent is a monorepo. It includes the website, app (web & mobile), desktop (electron), and CLI. There are numerous development dependencies that are not bundled into the final app.

> What would you suggest? Should I offer two view modes, one with cards and one with a list? I could find a way to reduce the vertical height of the cards anyway.

I'm personally not a fan of the card view in BitTorrent clients, but I'm not necessarily against having one, but it has to be more compact than what it is now. If you want to attract more advanced users, having a list view would be pretty important if you ask me. Having both could be an option.

But keep in mind that you don't have to satisfy everyone, because that's not even possible.

> In the near future, I plan to utilize the horizontal space to add filter and label management options, allowing users to quickly find specific torrents. I think displaying hundreds of torrents simultaneously isn't practical as I can't process them all. Instead, I believe a search bar and filters would greatly enhance the user experience. It seems people here would prefer a table view instead, like qbittorrent, what are your thoughts on this?

I personally use Transmission and the default view is compact enough for me. Search for the torrents loaded into the client is a must for me, but I personally don't really care about labels. But that's just me.

> Regarding the package-lock.json, I understand your point. However, please keep in mind that PikaTorrent is a monorepo. It includes the website, app (web & mobile), desktop (electron), and CLI. There are numerous development dependencies that are not bundled into the final app.

That's fair I guess… but homepage alone seems to have 1202 dependencies (180 of them need funding and one is deprecated), seems a lot for 2 static pages. I'm not the one that will have to maintain it, but at some point something will break… Also the performance of the homepage seems to impacted by the frameworks used[1].

1: https://pagespeed.web.dev/analysis/https-www-pikatorrent-com...

I prefer the “rather old interface” over whatever this is. Whats the point of so much whitespace? On the desktop screenshot, only two downloads are visible in the window. In any decent client you would see at least 10 times as many. Stop this obsession with wasting the user’s screen real estate, I do nit want to buy an even bigger display

Funny and sad I successfully guess it's JavaScript and bullshit look given the "modern" label.

Defaults to bright mode. Well, I say defaults - is there a dark mode? Why don't all sites support a switch, defaulting to dark in case you don't want to blind yourself?

By whitespace I was referring to empty space. The colour of that empty space is irrelevant here

Usually you can just tell the user's preference via css..? Its builtin.

That UI may make some sense on mobile where a finger, which is bigger than a mouse pointer, must operate bigger controls comfortably; but on desktop? Nope, old interfaces win over "modern" ones any day. For example, down that page there's a Transmission remote GUI screenshot (I use it as Transmission here is a daemon on my headless XigmaNAS server).

https://github.com/transmission-remote-gui/transgui

What would be wrong with it or anything similar? Every information is just there, no need to swipe left and right to read information that has been either hidden elsewhere or, worse, taken away. The same applies to many "old" clients such as QBittorrent and others.

I understand that design is important, but it should never ever win over functionality.

Thank you for your comment, it seems that many users here would prefer a table view. It's true that when the cards are collapsed, some (configurable and orderable) information gets hidden, which is not ideal. However, in the meantime, I'm trying to maintain parity between the mobile and desktop versions.

When I mentioned the "old" interface, what I meant was that it may not be as attractive to newcomers. I understand that a UI can be old but perfectly functional.

Why the hell would you ever use this over qbitorrent. Holy, that screenshot is terrible

When looking at the comments [1] for Tabby, people pointed out that “modern” nowadays tends to mean web technologies. Seems like that hasn’t changed.

[1] https://news.ycombinator.com/item?id=29553767

I chose web technologies for PikaTorrent because I wanted the ability to remotely control my instances on the web, which you can access at https://app.pikatorrent.com. Additionally, Expo allows me to target both web and native mobile platforms using React Native. It's a significant time-saver to maintain a single codebase that can target the web, desktop (via Electron), and native mobile platforms.

However, in the context of a terminal like Tabby or Hyper, it may make less sense to choose web technologies over cross-platform native libraries. I suppose the goal here was to create an easily "hackable" terminal experience.

Solution in the search of a problem? Made by someone who doesn't uses BT often:

Not only there is too much whitespace so you can't see more than two torrents, but..

Why there is a search bar? Pointed to Google?[0]

Why anyone need a gigantic Start/Pause and Remove buttons on a separate line?

Why the Remove button is so easily accessible, especially on a touch enabled device?

Why is there Status status if there is already a button?

Why there is a file counter? Did anyone care about how many files in a particular torrent?

Why there is no way see the actual torrent name on a touch device in the portrait mode?

Why anyone would need to see ETA and Download rate and Progress for a seeding torrent?

[0] bonus points if you are accessing it in a web browser

I invite you to read https://news.ycombinator.com/item?id=36745751, where I explain how the search bar can be configured with custom search engines.

I strive to maintain parity between the mobile and desktop UIs, and I understand that some tweaks are needed to reduce the used space.

The file counter is a button that displays the downloaded files. In the near future, users will be able to directly open files from this view. For example, this will enable playing media files directly from PikaTorrent.

The displayed information and ordering can be customized from the settings. If you prefer not to see ETA or other information. The default settings might changed based on feedback received, such as yours.

Why bake libtransmission into the app instead of just using the transmission daemon's RPC?

What you've done actually makes it harder to use, because in order to configure any of transmission's settings (ports, connection/torrent connection limits, bandwith limits, etc) the user needs to dig around to find the transmission config folder and then manually edit JSON with a text editor - because your client doesn't expose any of transmissions numerous settings [1] to the user except for choosing the download folder.

I'm not sure why anyone would want to use this instead of Flood [2] or even old Transmission Web Control [3]

1: https://github.com/transmission/transmission/blob/main/docs/...

1: https://github.com/jesec/flood

2: https://github.com/ronggang/transmission-web-control

This is a very good question.

I preferred to bundle libtransmission to offer a plug'n play experience across all platforms.

Regarding all the criticism here, I believe PikaTorrent should primarily focus on new or average torrent users. Advanced users might either modify the settings file manually for now (though guessing the path is not ideal), or perhaps PikaTorrent should expose a textarea to edit transmission settings (though this approach might be risky for average users).

In the meantime, I plan to expose a lot more Transmission settings in the UI. Even for me, PikaTorrent is not mature enough to fulfill all my needs. However, with more features to come and potential feature requests from users on GitHub, it might become a suitable BitTorrent client for advanced users and server usages.

Can you speak to the target user? Remotely managing torrents makes me think "seedbox user", but your ui makes me think "person who deletes torrents as soon as they finish downloading".

This is ugly as hell and works worse than Qbittorrent, which is already cross platform and 'modern'.

qbittorrent is rock solid, performant (libtorrent puts libtransmission to shame), light on resources, has a great webui (if you don't want to run in desktop mode) and is programmable and featureful. I don't see this as coming close plus it's node.js (a major minus).

I would be interested if you have some serious benchmarks between libtorrent & libtransmission?

Transmission's main maintainer published this in 2010: https://gist.github.com/ckerr/89882362c65b819614051935364b9e.... This comparison was done between clients, so there is overhead involved due to the GUI, but still.

I use qBitTorrent and I disagree that any of those things are hard.

Same here, it's super easy to set qbittorrent on a server. I did put it behind an nginx server but that's just common sense when exposing anything on the web.

The web UI does the job, no complaints.

Well, I believe that setting up a web server should not be a requirement for remote software control. In the case of torrents, it would be great to have the ability to manage downloads on a desktop from a mobile device, no matter where we are.

I understand that Hacker News users are generally power users. If qbittorrent fulfills your needs and you have the skills to setup and secure a webserver, there is no need to switch to another client. Additionally, it's worth noting that PikaTorrent may not implement all the features of qbittorrent anyway.

what's the point putting it behind an NGINX proxy as opposed to exposing it directly? Rate-limiting or fail2ban or something?

Qbittorent in particular has had several webui exploits in the past. The most recent was a few months ago and it was pretty bad: https://github.com/qbittorrent/qBittorrent/issues/18618

Putting nginx in front with http basic auth would prevent all of them.

Not the parent, but:

Hosting multiple services behind one ip:443 and having a valid LE certificate is surely a nice thing. You can even add a simple URI knocking if you wish.

I just released a new version. I mainly reworked design for the torrent cards, utilizing a lot less vertical space.

Thank you for the few valuable feedback. I will continue to iterate and improve pikatorrent. Please don't hesitate to share your thoughts and feature requests on GitHub/Discord.

Why is there so much space. I can only view a few torrents at once in this app. I guess I will stay with qbittorrent.

I think the UI likes sleek, seems like it would be perfect for users with a handful of torrents. Nice work OP!

I don't disagree that the space could be used more efficiently, but I definitely agree that the current torrenting apps have really old UIs. I think the target users for this app might be younger than the audience here on HN. I do foresee a tradeoff occurring though where a nice UI hides some information.

When all information is shown, like in qBittorrent, you can simply ignore the info you dont care about.

This has worked for everyone so far, it cant be that hard.

Old UI doesnt mean bad UI. It means time tested, reliable, proven. Bad UI is UI which isnt being used because its so bad.

> you can simply ignore the info you dont care about.

This still has a cognitive load though.

I think so, too. It seems people here would prefer a table view. However, I'm uncertain about the value added by including all this information in a table. Personally, I find myself ignoring them 99% of the time.

When dealing with hundreds of torrents, I believe filtering options and a simple text filter would be more useful in quickly finding specific torrents. What are your thoughts on this?

That being said, based on the feedback, it seems necessary to reduce some vertical space in these cards.

The first time, yeah, but its incredibly easy to filter after IMO

Why not use transmission headless with the web interface? ( Ok, Transmission's web interface is a bit shit and you have to use the command line for some options.)

There's nothing wrong with using Transmission. I find the new web UI rather nice, but IMHO, still not be ideal for newcomers. With PikaTorrent, my goal is to provide a simple, cross-platform client that can be controlled remotely without requiring any technical knowledge.

It's tough because this kind of person probably doesn't exist in any significant quantity.

Have you tried new v4 web interface?

Doesn't like like v4 is in the Raspberry Pi repo. I'll try it as soon as it shows up.

I can't wait till someone launches an OS written in Javascript so I can finally off myself.

https://www.os-js.org Sorry.

How many torrents can PikaTorrent serve simultaniously?

In theory, PikaTorrent could handle as many torrents as Transmission since it uses the same library. However, we need to conduct further testing on PikaTorrent UI with a larger number of torrents in order to observe the performance of its virtualized list.