3 ms·

Shipping an entire Java/ruby/python/whatever VM with your code doesn't make much sense (not to mention, wasm doesn't have a good GC story). Then there's the DOM

by hajile 9y ago

Shipping an entire Java/ruby/python/whatever VM with your code doesn't make much sense (not to mention, wasm doesn't have a good GC story). Then there's the DOM API issue. If you aren't making games or crunching big numbers, wasm isn't for you yet. Even so, let's assume wasm added all those features today. History shows it would still be a decade before you could ship to all your users. That may not matter for fancy startup X, but it certainly matters for the biggest and most important businesses. I love the potential of wasm, but I think it's way too soon to be preaching about it being the end-all be-all of the web.

pjmlp 9y ago
I don't remeber ARM, MIPS, x86 or x64 having a good GC history either. If WebAssembly is good enough as C and C++ target, it is good enough as any of those processors. As for the potencial of WebAssembly, there are already ongoing efforts to port .NET and Java runtimes to it, and I am looking forward to Adobe porting Flash to it as well. So it will come, WebAssembly + Canvas + WebGL is already quite usable.
- kibwen 9y ago
  > I don't remeber ARM, MIPS, x86 or x64 having a good GC history either. Typical client programs intended to run on nascent versions of those architectures were not intended to be delivered and installed very often. In contrast, web pages might get changes deployed to production multiple times a day. Needing to deliver a compiled runtime solely in order to run your client side code is going to be a nonstarter for the overwhelming majority of developers. Now, at best, we can hope that many developers will collaborate to make caching easier by agreeing to only use one specific version of each runtime, delivered from a single well-known source (though experience with e.g. jQuery means that we shouldn't hold our breath). In the meantime, extending WASM to obviate the need for delivered runtimes will even the field between Javascript and every other managed language.
  - pjmlp 9y ago
    Runtimes are already being delivered by the majority of languages that compile to JavaScript. A GC runtime for a language with like Oberon semantics is just a few hundred KB, way less than sonething like minified jQuery.
- hajile 9y ago
  Those ISAs are much lower-level than wasm. If you want to keep things secure, you have to restrict things. For example, wasm is going to optimize a lot of things and isn't necessarily going to treat your pointers the way you expect. Good garbage collectors need pretty fine-grained control. LLVM has been the bane of GC creators for the same kinds of reasons.
  - pjmlp 9y ago
    Only from those that want to rely on LLVM for their compiler backends. Using LLVM to target WebAssembly is not a requirement. Also the point isn't implementing the best GC algorithm, rather a good enough one.

by hajile 9y ago

pjmlp 9y ago

I don't remeber ARM, MIPS, x86 or x64 having a good GC history either. If WebAssembly is good enough as C and C++ target, it is good enough as any of those processors. As for the potencial of WebAssembly, there are already ongoing efforts to port .NET and Java runtimes to it, and I am looking forward to Adobe porting Flash to it as well. So it will come, WebAssembly + Canvas + WebGL is already quite usable.

kibwen 9y ago
> I don't remeber ARM, MIPS, x86 or x64 having a good GC history either. Typical client programs intended to run on nascent versions of those architectures were not intended to be delivered and installed very often. In contrast, web pages might get changes deployed to production multiple times a day. Needing to deliver a compiled runtime solely in order to run your client side code is going to be a nonstarter for the overwhelming majority of developers. Now, at best, we can hope that many developers will collaborate to make caching easier by agreeing to only use one specific version of each runtime, delivered from a single well-known source (though experience with e.g. jQuery means that we shouldn't hold our breath). In the meantime, extending WASM to obviate the need for delivered runtimes will even the field between Javascript and every other managed language.
- pjmlp 9y ago
  Runtimes are already being delivered by the majority of languages that compile to JavaScript. A GC runtime for a language with like Oberon semantics is just a few hundred KB, way less than sonething like minified jQuery.
hajile 9y ago
Those ISAs are much lower-level than wasm. If you want to keep things secure, you have to restrict things. For example, wasm is going to optimize a lot of things and isn't necessarily going to treat your pointers the way you expect. Good garbage collectors need pretty fine-grained control. LLVM has been the bane of GC creators for the same kinds of reasons.
- pjmlp 9y ago
  Only from those that want to rely on LLVM for their compiler backends. Using LLVM to target WebAssembly is not a requirement. Also the point isn't implementing the best GC algorithm, rather a good enough one.