4 ms·
I think the developer base still remains to be seen. As long as WebAssembly doesn't provide significant speedups over tuned JS, it seems likely we'll continue t
by fulafel 6y ago
I think the developer base still remains to be seen. As long as WebAssembly doesn't provide significant speedups over tuned JS, it seems likely we'll continue to mostly see it used for porting code from platforms and languages that don't natively target the web.
- maxgraey 6y agoWebAssembly still not reaching their full potential in browsers. For example: https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=component%3AWebAssembly&can=2 https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=comp... On Firefix and Safari we have the same missing optimizations. Basically wasm in all browsers reuse the same codegen from JS. But this will improved in the future. Also, don't forget about SIMD, multi-threading with stared buffers and atomics and multi-values, a lot of special instructions like popcnt, ctz, clz, rotl/rotr and etc which not supported by JS and usually emulate not in the best way that complicates or make impossible to optimize this by the JS compiler. In some points JS is really fast, so much that it is not inferior, for example, to the C language with the LLVM compiler without vectorization (-O2). Obviously WebAssembly can't outperform JS in such cases.
- maxgraey 6y agoHere a great example of how SIMD brings WebAssembly closer to native speed: https://medium.com/@robaboukhalil/webassembly-and-simd-7a7daa4f2ecd https://medium.com/@robaboukhalil/webassembly-and-simd-7a7da...