This is just Google trying to reinforce their everything-in-the-cloud-as-web-app model, which they are in a position to do considering they make one of the leading browsers, especially amongst developers.
It's shoehorning everything into ancient technology ill-suited for any of these applications, which is not exclusively Google's fault of course. First HTML was augmented with Javascript, which was augmented with XHTTPRequest, which led to an increased usage of Javascript (Here's where Google comes in), which led to a lot of manpower being invested in optimizing the Javascript engines (trying to run a quirky dynamic language as fast as possible) and then augmenting the browser with "native" OS features like:
* Full-screen mode
* Clipboard control
* Native notifications, with background workers, etc.
* WebMIDI
* OpenGL
* etc.
Which is basically like building a second operating system on top of the already existing architectures. Google tried to further push people this way by coming up with Chromebooks, which in reality actually serve to reinforce my point, since most (not all!) users find them just not sufficient enough.
Which didn't surprise seasoned OpenGL developers at all, because it happens to us all the time, that we see old memory contents in uninitialized buffer objects.
I wish to be able to browse websites, which contain (a) text, (b) associated images, (c) low forms of interactivity, say, comments, or interactive graphics.
This is pretty much the web 2012, or most of German-language web today still.
For browsergames, let’s just use the same paradigm as with apps instead: Bundle them via node+webkit, and integrate a "run locally" API into browsers that automatically downloads a program and runs it locally in a sandbox, but seperately.
In the long term, for games we’ll need to develop a different concept anyway.
But there’s a good reason why no one develops 3D games in PDF, despite PDF supporting 3D objects, scripting, and modification of the document via scripts.
No, WebRTC cannot make normal TCP connections so it can't be used to connect to a classic client. In theory all bittorrent software could implement WebRTC connections though
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.
You know that you can't connect to normal bittorrent clients from webtorrent in browser right? Which means that you do not have almost any sources of seeders, which means that webrtc adoption dosen't matter.
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).
> All it takes for someone to seed a file is to open a web page. Think about it.
That's a pretty big hurdle considering most regular torrent users don't even realize WebTorrent exists, and these users contribute the vast majority of the content available on BitTorrent.
Of course in the ideal world where WebTorrent has significant market share, this wouldn't be nearly as much of a problem. But I agree with lossolo that without interop with libtorrent at the very least (if not uTorrent as well), that ideal world is probably never going to come into existence.
"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.
Yes, WebTorrent enables plenty of really great, novel use cases for BitTorrent technology, but it will remain a second-rate BitTorrent client in the eyes of most existing BitTorrent users without great interop. Although I personally do like these new WebTorrent-based web services, there's no guarantee that any of them will ever reach critical mass in terms of adoption, whereas BitTorrent itself has long since reached critical mass. 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.
> 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.
If this what you wrote was true then you would see big adoption of webtorrent which is not the case. As i said before and i am saying for almost 2 years now. I love webtorrent but it NEEDS support from libtorrent and utorrent. Look at biggest bittorrent sites and on private trackers, i have seen private data on clients usage and i can tell you that adoption is almost non-existent comparing to big 5, which still means that webrtc dosen't matter in this case..
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.
Agreed, but in this context "knowing how to code" is not the same as "being able to code".
I know how to code. I understand it, and can hack at basic programs written by other people. That doesn't mean I can code. That would require years of practice and, like the author, it's just not my thing. I'm better at other stuff.
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.