WASM isn't based on LLVM. WASM is a compiler target, but compilers other than LLVM can target WASM.
And WASM is now the defacto portable Bitcode. Just as JS took over the world, so will WASM. In six months, WASM will have had more program launches than the totality of .Net and the JVM. We have yet to fathom how far reaching WASM will be. Did I say WASM enough times? I end with only this. WASM.
JS didn't take over the world, web did. And if we don't talk plugins, then there wasn't much choice in the matter if you wanted to do things clientside.
By all means, keep on asserting things without demonstrating them and ignoring arguments and examples to the contrary. It doesn't actually convince, but I'm sure it makes you feel better.
I can tell you're young.
Oh, tell me more, anonymous coward! Your perception knows no bounds.
I agree. I dont know where Mozilla is spending their money, but they are years behind in regards to security enhancements in comparison with Chrome, Edge, and IE11. Around IE7 nivea. Still waiting for 64 bit Firefox with Sandbox and per-tab-process and CFI.
I hope they never go with process-per-tab in Firefox. It's one of the things I dislike about Chrome.
I thought that's what Electrolysis was. We've switched to an ESR release with e10s disabled because of an incompatible add-on listed as compatible. Annoying, because the idea is if an add-on doesn't work with e10s, e10s will be automatically disabled. And of course in this case it doesn't since the add-on works "great" with it!
Too many to name, really. is one that immediately comes to mind.
... a chrome only feature, pushed by Google, that isn't considered a standard? 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.
Sorry, it's not Chrome-only. I don't particular care whose idea it originally was. It's a good feature and other browsers are implementing it.
Too many to name, really. is one that immediately comes to mind.
Use instead. This has existed for the entire lifetime of Firefox, all the way back to the first release when it was called Phoenix.
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.
Too many to name, really. is one that immediately comes to mind.
As people have pointed out, that's Chrome-only at the moment but that's also a big moving of the goal-posts. Your original comment was “far behind in a variety of features that are useful to a much bigger % of the web” — precisely how much user-visible benefit do you think comes from a feature which may accelerate the first load slightly? If that was that critical, it'd be easy to point to e.g. webpagetest.org traces…
Moving goal post? Preloading is useful on every single web page that, for example, loads a script. Not just 3D games, but any web page with scripting.
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.
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 front…
People have been writing client software in those languages for almost 10 years now. Object J came out in 2008! Not saying WebAssembly won't make this better, maybe even a lot better, but this is not opening new capabilities the way that, for example, shipping modules would.
As people have pointed out, that's Chrome-only at the moment but that's also a big moving of the goal-posts. Your original comment was “far behind in a variety of features that are useful to a much bigger % of the web” — precisely how much user-visible benefit do you think comes from a feature which may accelerate the first load slightly? If that was that critical, it'd be easy to point to e.g. webpagetest.org traces…
Moving goal post? Preloading is useful on every single web page that, for example, loads a script. Not just 3D games, but any web page with scripting.
Keep reading the entire comment: the point wasn't that rel=preload isn't useful but rather questioning the assertion that it's this huge game-changing feature which is causing ordinary people to switch browsers.
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.
... a chrome only feature, pushed by Google, that isn't considered a standard? 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.
Sorry, it's not Chrome-only. I don't particular care whose idea it originally was. It's a good feature and other browsers are implementing it.