7 ms·

WebAssembly is nice and all, but I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. Meanwhile they a

by Touche 9y ago

WebAssembly is nice and all, but I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web. Safari and Edge have leapfrogged Firefox in providing the important things to web developers.

dagw 9y ago
I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. What follow is speculation: At guess they feel burnt after they lost the whole closed source DRM in the w3c spec battle. They realize that something like WebAssembly will become a thing in the next few years and that if they don't push super hard for a completely open solution from day 1 then they're afraid that Google, Microsoft and Apple will get together in a room and make a deal without them. At the end of the day Mozilla don't only care about delivering a browser, they care about delivering a completely open browser, and they don't want their ability to deliver that to become more threatened in the future.
jahnu 9y ago
> useable by 0.01% of applications. I think you will be surprised how many apps will use WASM in the future. I'm a C++ dev and working with WASM (and asm.js as a fallback) full time. It's going to be absolutely huge.
- Touche 9y ago
  Even if it causes Photoshop and CAD software and such to be ported to the web (which would be a huge business model change, so don't hold your breath) we're still talking about a tiny percentage of apps. There's no reason why Slack would rewrite in C++.
  - jahnu 9y ago
    Not talking about re-writing. But there is an enormous amount of code out there in c, c++ and other langs that people would love to use in web apps. In our case we use the same library code on iOS, Android, Windows and in the browser to do computationally expensive operations. Also, to dismiss productivity apps such as PS and CAD as unimportant is kind of crazy. Huge business model change? They are still an enormous part of the software industry and the browser a great platform for distribution for many cases. Performance and code secrecy being two barriers that WASM solves for them.
  - fixermark 9y ago
    The question of interest is "In a world where webassembly exists and is well-supported, would Slack have been written in JavaScript (or a JS-targeting language like TypeScript), or was there some other language the developers knew better that they could have worked faster in but the JavaScript tax prevented that option?"
  - sqeaky 9y ago
    Rewrites have never been where its at, there are so many new possiblilities web assembly opens. Imagine if every AAA game had a web demo? Imagine real support for Peer to Peer video that worked in several browsers and platforms? What could editors in browsers be? Not just text, but any kind of office suite that exists on the local Anything requiring a 3d canvas that was limited by javascript's speed.
  - Noseshine 9y ago
    > which would be a huge business model change, Is it? Since Adobe switched to the subscription model and the "Adobe Creative Cloud" I'd say they would be quite happy if that infrastructure would be good enough to run their very big application suite(s). Not to mention the savings of not having to support two major platforms (and several OS versions for each) - even realizing them only partially would be big. Of course, given the size of their product I'd say there is little use in talking about this at this point, the web platform would have to mature a lot more first.
- livingparadox 9y ago
  Could you elaborate on how you're using WASM in your full-time job?
calcifer 9y ago
> Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web Do tell...
- Touche 9y ago
  Too many to name, really. <link rel=preload> is one that immediately comes to mind.
  - db48x 9y ago
    Use <link rel=prefetch> instead. This has existed for the entire lifetime of Firefox, all the way back to the first release when it was called Phoenix.
    - Touche 9y ago
      Prefetch is a different thing, and it doesn't give priority to fetch the resource. Preloading, for example, a script is exactly equivalent to adding the script tag minus the execution part.
  - cpeterso 9y ago
    A Firefox patch to implement <link rel=preload> is being reviewed right now: https://bugzilla.mozilla.org/show_bug.cgi?id=1222633 https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
  - bzbarsky 9y ago
    You mean the thing that is not actually supported in any browser other than Chrome, because Google just came up with it a few months ago to replace <link rel="prefetch">, which worked in most brosers? (Yes, I know Safari technical preview has support, but shipping Safari does not. We'll see whether Firefox ends up shipping support before Safari or not; the patches to implement <link rel="preload"> in Firefox got posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1222633 https://bugzilla.mozilla.org/show_bug.cgi?id=1222633 earlier today.)
  - acdha 9y ago
maxsilver 9y ago
> this feature that will be useable by 0.01% of applications If they do this right, I suspect it will be much more heavily used than that. I can already see a world where every major webapp is using this (indirectly, using a language that compiles down to this) for the performance and user experience improvements it could provide.
flavio81 9y ago
As pointed out, this will be HUGE. For starters, this will enable client (browser) software development in a language other than Javascript/ES6. With, probably, a plethora of compilers to choose from, some of them giving better optiimizations than others. I think this will make an explosion of more browser-hosted applications, with much more power than before. And will make many more programmers go into serious frontend app development. Also, as a personal wish of mine, this enables the possibility of being able to program on the language of your choice, both in the browser side and on your server side. For example Haskell/Haskell, Common Lisp/Common Lisp, Clojure/Clojure, Racket/Racket Python/Python, etc. And i mean using in the browser the FULLY FEATURED version of the language, not a subset or a limited version like ClojureScript, PyJS, Transcrypt, etc, but a full version of the language supporting the full libraries available for it. This also gives us a little step forward in liberating ourselves from being tied to the mainstream operating systems: Windows, Apple X, Linux, BSD, because more and more apps will target the browser environment, not the operating system directly. Roll your own operating system and still keep compatibility with most apps!!
- ccozan 9y ago
  >full version of the language supporting the full libraries available for it. Does this mean, simply said, that I can take any arbitrary windows desktop app written in C++, for example, and run it in browser on every other OS?
  - ebiester 9y ago
    http://www.quakejs.com/ http://www.quakejs.com/ It required 3 days of porting from what I remember hearing.
  - pc2g4d 9y ago
    I think there are still limitations around threading, but basically that's the goal. I think of it as the promise of Java (write once, run anywhere) re-implemented with buy-in from all the major vendors. (So no MS/IBM/Sun fragmentation).
- ooqr 9y ago
technion 9y ago
I'm expecting that a lot of people that don't plan on using it still will. Front-end JavaScript developers using something like SJCL have a much more positive future with those crypto primitives done in something other than JavaScript, even if they themselves are just calling them from a JavaScript binding. Graphing and graphics libraries may turn to web assembly for performance. etc etc.

by Touche 9y ago

dagw 9y ago

I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. What follow is speculation: At guess they feel burnt after they lost the whole closed source DRM in the w3c spec battle. They realize that something like WebAssembly will become a thing in the next few years and that if they don't push super hard for a completely open solution from day 1 then they're afraid that Google, Microsoft and Apple will get together in a room and make a deal without them. At the end of the day Mozilla don't only care about delivering a browser, they care about delivering a completely open browser, and they don't want their ability to deliver that to become more threatened in the future.

jahnu 9y ago

> useable by 0.01% of applications. I think you will be surprised how many apps will use WASM in the future. I'm a C++ dev and working with WASM (and asm.js as a fallback) full time. It's going to be absolutely huge.

Touche 9y ago
Even if it causes Photoshop and CAD software and such to be ported to the web (which would be a huge business model change, so don't hold your breath) we're still talking about a tiny percentage of apps. There's no reason why Slack would rewrite in C++.
- jahnu 9y ago
  Not talking about re-writing. But there is an enormous amount of code out there in c, c++ and other langs that people would love to use in web apps. In our case we use the same library code on iOS, Android, Windows and in the browser to do computationally expensive operations. Also, to dismiss productivity apps such as PS and CAD as unimportant is kind of crazy. Huge business model change? They are still an enormous part of the software industry and the browser a great platform for distribution for many cases. Performance and code secrecy being two barriers that WASM solves for them.
- fixermark 9y ago
  The question of interest is "In a world where webassembly exists and is well-supported, would Slack have been written in JavaScript (or a JS-targeting language like TypeScript), or was there some other language the developers knew better that they could have worked faster in but the JavaScript tax prevented that option?"
- sqeaky 9y ago
  Rewrites have never been where its at, there are so many new possiblilities web assembly opens. Imagine if every AAA game had a web demo? Imagine real support for Peer to Peer video that worked in several browsers and platforms? What could editors in browsers be? Not just text, but any kind of office suite that exists on the local Anything requiring a 3d canvas that was limited by javascript's speed.
- Noseshine 9y ago
  > which would be a huge business model change, Is it? Since Adobe switched to the subscription model and the "Adobe Creative Cloud" I'd say they would be quite happy if that infrastructure would be good enough to run their very big application suite(s). Not to mention the savings of not having to support two major platforms (and several OS versions for each) - even realizing them only partially would be big. Of course, given the size of their product I'd say there is little use in talking about this at this point, the web platform would have to mature a lot more first.
livingparadox 9y ago
Could you elaborate on how you're using WASM in your full-time job?

calcifer 9y ago

> Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web Do tell...

Touche 9y ago
Too many to name, really. <link rel=preload> is one that immediately comes to mind.
- db48x 9y ago
  Use <link rel=prefetch> instead. This has existed for the entire lifetime of Firefox, all the way back to the first release when it was called Phoenix.
  - Touche 9y ago
    Prefetch is a different thing, and it doesn't give priority to fetch the resource. Preloading, for example, a script is exactly equivalent to adding the script tag minus the execution part.
- cpeterso 9y ago
  A Firefox patch to implement <link rel=preload> is being reviewed right now: https://bugzilla.mozilla.org/show_bug.cgi?id=1222633 https://bugzilla.mozilla.org/show_bug.cgi?id=1222633
- bzbarsky 9y ago
  You mean the thing that is not actually supported in any browser other than Chrome, because Google just came up with it a few months ago to replace <link rel="prefetch">, which worked in most brosers? (Yes, I know Safari technical preview has support, but shipping Safari does not. We'll see whether Firefox ends up shipping support before Safari or not; the patches to implement <link rel="preload"> in Firefox got posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1222633 https://bugzilla.mozilla.org/show_bug.cgi?id=1222633 earlier today.)
- acdha 9y ago

maxsilver 9y ago

> this feature that will be useable by 0.01% of applications If they do this right, I suspect it will be much more heavily used than that. I can already see a world where every major webapp is using this (indirectly, using a language that compiles down to this) for the performance and user experience improvements it could provide.

flavio81 9y ago

As pointed out, this will be HUGE. For starters, this will enable client (browser) software development in a language other than Javascript/ES6. With, probably, a plethora of compilers to choose from, some of them giving better optiimizations than others. I think this will make an explosion of more browser-hosted applications, with much more power than before. And will make many more programmers go into serious frontend app development. Also, as a personal wish of mine, this enables the possibility of being able to program on the language of your choice, both in the browser side and on your server side. For example Haskell/Haskell, Common Lisp/Common Lisp, Clojure/Clojure, Racket/Racket Python/Python, etc. And i mean using in the browser the FULLY FEATURED version of the language, not a subset or a limited version like ClojureScript, PyJS, Transcrypt, etc, but a full version of the language supporting the full libraries available for it. This also gives us a little step forward in liberating ourselves from being tied to the mainstream operating systems: Windows, Apple X, Linux, BSD, because more and more apps will target the browser environment, not the operating system directly. Roll your own operating system and still keep compatibility with most apps!!

ccozan 9y ago
>full version of the language supporting the full libraries available for it. Does this mean, simply said, that I can take any arbitrary windows desktop app written in C++, for example, and run it in browser on every other OS?
- ebiester 9y ago
  http://www.quakejs.com/ http://www.quakejs.com/ It required 3 days of porting from what I remember hearing.
- pc2g4d 9y ago
  I think there are still limitations around threading, but basically that's the goal. I think of it as the promise of Java (write once, run anywhere) re-implemented with buy-in from all the major vendors. (So no MS/IBM/Sun fragmentation).
ooqr 9y ago

technion 9y ago

I'm expecting that a lot of people that don't plan on using it still will. Front-end JavaScript developers using something like SJCL have a much more positive future with those crypto primitives done in something other than JavaScript, even if they themselves are just calling them from a JavaScript binding. Graphing and graphics libraries may turn to web assembly for performance. etc etc.