>They both seem like perfectly good places to write a BitTorrent client.
Except they aren't. Web APIs don't provide the facilities necessary for a complete bittorrent stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant). Additional facilities like mmaped files, epoll-based socket IO and inotify make for more efficient implementations.
A good bittorrent client on a gigabit connection can push a lot of data around, hashcheck it and so on.
Some torrents also have thousands of files open simultaneously, this can push the number of filehandles the browser process has to keep, possibly conflicting with other files the browser also wants to open, e.g. its cached files.
You also need to talk to local network devices (UPnP routers), enumerate network interfaces to bind ports to the correct one so you can tell other clients your alternative addresses (this is part of ipv4/ipv6 compatbility) and a whole bunch of other sort of low-level stuff.
Browsers simply do not provide the same access to system APIs. They are not a libc-replacement.
>Web APIs don't provide the facilities necessary for a complete bittorrent stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant).
While it's only available to privileged and certified apps, Mozilla's TCPSocket Web API[0] gives you (unsurprisingly, given the name) raw TCP sockets.
The W3C also has a TCP and UDP Socket API[1] under development.
Obviously, exposing raw TCP/UDP sockets to the open web is a Bad Idea but Web Apps are more than that.
Sounds like a whole lot more bellyaching. Why so serious? Dial down your zeal friend.
BitTorrent is extensible: I see you agree with that premise since you listed UDP sockets, formalized by BEP-0029. The objections you level against WebRTC DataChannels make it sound like the particular transports you mention are somehow blessed, that it's not and won't ever be bittorrent unless it's TCP or UDP (and even if it was a hard/fast requirement, one could still benefit from WebTorrent via Firefox extensions and Chrome apps).
Who cares if you're using mmap, epoll, or inotify? Are you intimate with the performance limitations of IndexedDB in all browsers? How versed are you on the performance hit taken by File API? When do these limits become problems? Why would a browser need to keep open a filehandle for every "every" in the first place? That's certainly not at all how https://github.com/js-platform/filer works, on either it's IndexedDB or it's WebSQL backend.
As for your networking dilemmas, I recommend you check out: The network discovery api (which can enumerate UPnP and DNS-SD), WebRTC's TURN/Stun for correctly choosing from available addresses, and a whole bunch of other web stuff that you obviously don't know anything about but think is explicitly the domain of Real Serious Programming With Real Applications.
Not everyone needs to be operating at the fantastical extremes you are concocting, not all use cases are gigantic seedboxes on fat pipes. It's ok to deliver capabilities that someone else might already have, and maybe not even have some quirks or possible points of poor comparison.
You're throwing a whole bunch of technical minutia at the problem you want to have. You're picking a false fight (and one that the web has plenty of good repostes you didn't know/omitted to retort with). The web might not be the best choice for using a gigabit ethernet connection (or maybe it actually does it fine in some conditions!): the act of finding these particular points to dive deep deep into as an excuse to ignore, shun, and spit upon the expansion of human technical capabilities is a close-minded injustice. It's bigotry, simpleminded technical bigotry showing off your inability to open your mind to possibilities, unwilling to open your arms to new improved things becoming available to people who want them and will benefit from their use, it's your own intransigence in the face of the ongoing adaption and mutation going on in the world. You're in for a bumpy ride if you are going to cling so tightly to your notion of what things are for and how they ought be.
Except they aren't. Web APIs don't provide the facilities necessary for a complete bittorrent stack. TCP and UDP sockets are essential (this thing uses webrtc, so it's not even bittorrent-compliant). Additional facilities like mmaped files, epoll-based socket IO and inotify make for more efficient implementations. A good bittorrent client on a gigabit connection can push a lot of data around, hashcheck it and so on.
Some torrents also have thousands of files open simultaneously, this can push the number of filehandles the browser process has to keep, possibly conflicting with other files the browser also wants to open, e.g. its cached files.
You also need to talk to local network devices (UPnP routers), enumerate network interfaces to bind ports to the correct one so you can tell other clients your alternative addresses (this is part of ipv4/ipv6 compatbility) and a whole bunch of other sort of low-level stuff.
Browsers simply do not provide the same access to system APIs. They are not a libc-replacement.