> To say that "normal clients don't really matter" simply because WebTorrent can enable new use cases for BitTorrent (that haven't shown any significant traction) really seems like you're missing the proverbial forest for the trees.
"there's no guarantee that any of them will ever reach critical mass in terms of adoption"
When you give away tool with a widespread guaranteed userbase like this, someone is bound to build something that people will use.
Not to say WebTorrent will be this big, but that's how the internet came to be.
And this is a completely decentralized upload and download library for the web, someone's going to build something popular with it I'm sure and it's not even at version 1.0 yet.
"That's a pretty big hurdle considering most regular torrent users don't even realize WebTorrent exists"
They don't need to. That's the point.
If I send a user to https://file.pizza/ to transfer a file to them. Not once to I have to mention that it uses WebTorrent.
IMO that's the killer feature.
I know you can't connect to normal clients. My point is normal clients don't really matter.
"Which means that you do not have almost any sources of seeders"
All it takes for someone to seed a file is to open a web page. Think about it.
At any point if I wanted to promote a song via WebTorrent, I could build WebTorrent into an audio player and encourage my user base to click a checkbox and seed the track (toss in IndexedDB support for storing it offline and it's even better).
Complete serverless resharing with almost every benefit of BitTorrent to boot.
The only thing WebTorrent needs the existing BitTorrent install base for is the existing torrents, which don't matter as much as you might think they do (most torrents are pirated content anyways).
I'm pretty sure the install base of WebRTC data channels is far higher than BitTorrent (Chrome, Firefox, Opera and soon Edge and Safari), so existing Torrent clients providing support only helps out the existing torrents out there.
Down the line I'm willing to bet that WebTorrent grows to be more widely used than BitTorrent, just off of the lack of friction to get started for both users and developers.
The "Safari is the new IE" article was about them being slow to adopt APIs and the yearly release cycle attached to OS updates.
This is about visuals and UI based APIs that can be polyfilled.
They matter but not as much as stuff like WebRTC and Service Workers IMO.
Google can fix these problems with updates and polyfills.
Apple can't do that. Some iOS and Mac OS users will at some point be left out.
Nothing in this article matter that much "position:sticky, no backdrop-filter, no scroll-snap-type, gradients" they're useful, but not critical.
Doubt we'll see apps that aren't possible without these.
They just make the experience nicer, they don't make products happen though.
Meanwhile on the Chrome end we've got web apps like Emojoy (https://jakearchibald-gcm.appspot.com/), Offline Wikipedia (https://wiki-offline.jakearchibald.com/), Instant.io (https://instant.io/), PeerCloud (https://peercloud.io/) and even Facebook (http://Facebook.com/) all providing features and services in Chrome (WebRTC, Service Workers, Background Sync) that can't be polyfilled or will have to provide a far lesser experience in Safari because it lacks even a way to polyfill these features (only things I can think of are AppCache and WebSockets which don't get the job done for these services).
Chrome Packaged Apps allow developers to build alternative browsers using Native Client.
Just no one has bothered to do so because it wouldn't make much of an impact, plus alternate browsers wouldn't be able to set themselves as the default browser.
But it's not in certain contexts.
Like in areas where a basic understanding of technology apply like on a tech blog or high profile position in politics or company where you make decisions that steer the tech sector, you'll do best with some basic programming knowledge.
Nothing serious is needed either, just a few weeks of learning Python and just read up on the rest of the programming world and you should at least have some understanding on how everything works.
Because I see more and more people in areas where programming knowledge can apply say "It's okay to not learn how to code" and people where it doesn't apply never go out of their way to say that.
Knowing how to code isn't always about getting a great job, sometimes it's just about making yourself better at your existing one.
It's a road. It normally doesn't generate energy anyway.
Anything here is a plus, especially when it comes to research.
They just have to take what they've learned from this and apply it to the next attempt.
And from the sounds of it, the only thing they have to really focus on is ensure the next one lasts long enough to pay for its own construction.
Solar sidewalks might be a better idea.