"without the need to rely on any native plugins" - if I need a specific version of specific browsers (which it is), than it's no different (though sand-boxed, which plugins could be as well).
1. Browsers are often preinstalled for the user (especially but not only, on mobile Oses). Also, many browsers auto-update, so the new features will be automatically available eventually, without the user installing anything
2. The point is that while browsers are binary, they can then run a huge set of portable apps. As opposed to all those apps not being portable.
3. Everything Mozilla does is open source, and not just Mozilla but also most browsers today are open source - Chromium and WebKit in particular. This is a very open space.
"This is a very open space" - then why is it locked to one legacy scripting language of some sort of crappy transpilation they themselves don't use? It is effectively closed for new languages.
First, adding more options takes work. People need to volunteer to do that work, and prove that adding more VMs to the web can be effective (there are many technical challenges, like cross-VM garbage collection, sandboxing issues, etc.). People simply haven't shown this is practical yet.
But, people have meanwhile shown that cross-compiling to JS is practical, from things like CoffeeScript to C++. This is opening up the space to new languages, but it takes time and effort as well - again, the speed depends on how many people volunteer to help out.
if you use CSS, you need specific browser versions - it's not gonna run ok on ancient browsers - of the video/audio tags, or anything new
this is just exposing a yet another platform API in the browser - once all browsers are updated in the field, you can reliably deploy your new code; or you can do it even before, but with a performance penalty; I'm not seeing anything wrong with that.
Dev: "Shame... Let's just wait n years until it gets released."
X = Chrome or Unity plug-in
Y = e.g. Safari for iOS.
PS: the whole idea of API-mega-mutant browsers sounds like shipping Node.js/Angular with all the packages instead of just letting them be installed in a flexible way via NPM/Bower/whatever.
Only the newer Chrome/Safari/Firefox/IE get to billions of users with auto-updates and such. Whether they want to run your nice game or not, they'll get to those new browsers, sooner or later. And any "nice game" will be able to take advantage of that.
Whereas a third party plugin just used to run "a nice game" will never get the same adoption, and users wont be bothered.
So your example can be rendered as:
Dev: "I made this nice game - try it!"
User: "Cool! What do I need to run it?"
Dev: "Just install a browser version released after 2015!"
User: "Nice, my browser is already updated"
In the vast majority of the cases. And for those who haven't yet updated, either they're not your target audience (they have some ancient IE6 they use mandated by their company policy) or they can just go ahead an update their browser.
They should update their browsers regularly anyway, and getting the latest Chrome/FF/etc is not like being forced to installed some unknown plugin from some unknown developer just to run a single app.
Is it really just difficult to understand?
>PS: the whole idea of API-mega-mutant browsers sounds like shipping Node.js/Angular with all the packages instead of just letting them be installed in a flexible way via NPM/Bower/whatever.
Also called as "batteries included". But unlike in your example, those packages are one for each kind (e.g not 100 competing templating engines, or 100 MVC frameworks, like in NPM).
You need to ship the "the whole API" with the browser for security reasons. If the API could be installed in a modular fashion in realtime while browsing, it couldn't be made secure in practise.
> if I need a specific version of specific browsers (which it is)
No, you don't need a specific browser. You can polyfill it. (The reference implementation is a polyfill.)
If you want the performance benefits, you'll need to update your browser. But that's true for JavaScript in general. IE8's engine is very slow, for example. Only the most recent browsers can offer the best performance.
