3 ms·

"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, w

by CmonDev 12y ago

"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).

ddalex 12y ago
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.
- CmonDev 12y ago
  Dev: "I made this nice game - try it!" User: "Cool! What do I need to run it?" Dev: "Just install {X}!" User: "Wait, it's not available for {Y} yet." 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.
  - nawitus 12y ago
    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.
  - coldtea 12y ago
    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).
azakai 12y ago
Well, every new web feature will only work on new enough browsers. That was true for HTML5 video, for new HTML5 input tags, ES5 stuff in JS, etc. The difference though compared to plugins, is that 1. Plugins must be installed by the user. 2. Plugins are binary and usually do not exist for all OSes/browsers (e.g., no more Flash for linux, Silverlight never worked on linux, etc.) 3. Plugins are nonstandard, created and controlled by a single corporation, typically not open source, etc.
- _random_ 12y ago
  "new enough browsers" - will work automatically in mobile Safari? Cool! Unless we are talking about _specific_ browsers rather than just new ones. 1. Browsers are installed by the user. 2. Browsers are binary too. It seems Mozilla prefers C++/Rust to build them rather than JavaScript. 3. New web tech is mostly developed by Mozilla, who is de-facto paid by Google.
  - azakai 12y ago
    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.
    - CmonDev 12y ago
      "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.
      - azakai 12y ago
        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.
ahoge 12y ago
> 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.

by CmonDev 12y ago

"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).

ddalex 12y ago

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.

CmonDev 12y ago
Dev: "I made this nice game - try it!" User: "Cool! What do I need to run it?" Dev: "Just install {X}!" User: "Wait, it's not available for {Y} yet." 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.
- nawitus 12y ago
  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.
- coldtea 12y ago
  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).

azakai 12y ago

Well, every new web feature will only work on new enough browsers. That was true for HTML5 video, for new HTML5 input tags, ES5 stuff in JS, etc. The difference though compared to plugins, is that 1. Plugins must be installed by the user. 2. Plugins are binary and usually do not exist for all OSes/browsers (e.g., no more Flash for linux, Silverlight never worked on linux, etc.) 3. Plugins are nonstandard, created and controlled by a single corporation, typically not open source, etc.

_random_ 12y ago
"new enough browsers" - will work automatically in mobile Safari? Cool! Unless we are talking about _specific_ browsers rather than just new ones. 1. Browsers are installed by the user. 2. Browsers are binary too. It seems Mozilla prefers C++/Rust to build them rather than JavaScript. 3. New web tech is mostly developed by Mozilla, who is de-facto paid by Google.
- azakai 12y ago
  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.
  - CmonDev 12y ago
    "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.
    - azakai 12y ago
      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.

ahoge 12y ago

> 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.