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!!
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?
It required 3 days of porting from what I remember hearing.
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.
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.
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.
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.
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.
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.
Do tell...
(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 earlier today.)
If that was that critical, it'd be easy to point to e.g. webpagetest.org traces showing Chrome loading a site significantly faster. And, yes, you can find differences in microbenchmarks but it's pretty rare to find something where rel=preload is a game-changer.
Do a quick text search of this Hacker News thread for people talking about Firefox "feeling" slower than Chrome.
Preload is a big underlying "why" of that experience.
I've read many comments where people mention performance in ways suggesting they have issues with UI performance, launch time, extensions, etc. Optimizing cold-cache performance the first time someone visits a site won't help with that at all.
If you actually run benchmarks, it's nice but hardly a game-changer, especially in the post-HTTP/2 world. If you're concerned about cold page load times most sites will see significantly greater benefit from using fewer blocking resources.
Same for modules, or Intersection Observer or many other features that FF is not shipping. Stop trying to prove me wrong and understand my point. Firefox is slow on stuff that makes regular old web developers lives easier, because they're chasing 3d games.
> Stop trying to prove me wrong and understand my point.
I think you should focus on making your point more clearly rather than defending what was clearly a. For example, you cite modules as something which is apparently a big deal for web developers but not shipped by Firefox. Sounds like Mozilla needs to get cracking … unless you know that only Safari has shipped it and the Chrome, Firefox, and Edge teams all have it available but behind a feature flag for testing:
https://www.chromestatus.com/feature/5365692190687232
That doesn't support your narrative that the Firefox team is ignoring this or that they're behind the market — and since anyone who isn't targeting only the latest version of Safari is either polyfilling or continuing to use their existing strategy, so there's an upper bound on how bad that can be, too.
Similarly, with Intersection Observer you can see that it was enabled in FF50 but had stability issues which lead to it being disabled and is likely to be re-enabled in FF54 based on testing. Unless you have some evidence that the developers who were working on that were pulled off to work on WebAssembly it doesn't seem like an especially compelling argument.
Again, I'm not saying that any of these things are useless — only that the narrative you're insisting on where Mozilla is ignoring web developers doesn't seem to be well supported by the evidence. At least for the projects I work on, I'd level that criticism at Safari or Edge first and in the much fewer cases where either Chrome or Firefox has a bug or limitation I need to work around it's about as likely to be Chrome as Firefox requiring extra work.
This type of thinking and behavior is going to make Chrome today what Internet Explorer was in the 90's: a toxic, dangerous platform that ignores standards.