3 ms·

I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete. It already has a slim advantage of being 2x faster. And Javasc

I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete. It already has a slim advantage of being 2x faster. And Javascript has so many advantages in terms of handling. No compilation step needed at all. And since it has modules widely supported now, it is a joy to code in native Javascript without any libraries like React&Co. Just look at how beautifully you can dynamically load code when it is needed in modern Javascript: let calendar = await import('/modules/calendar.js'); calendar.askUserForDay("Checkin Date");

rocqua 7y ago
You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation. I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.
- FreeHugs 7y ago
  If you want to use a different language, why would you care about the compile target? Compiling is done by the compiler. So to the developer it is the same. No matter if it comiles to Javascript or Webassembly. In the end, I don't think writing code for the web in languages other then Javascript will take off. Simply because Javascript will always evolve to fit this specific environment. And therefore will always be the best choice. While other languages will evolve to be the best fit for their niche.
  - rocqua 7y ago
    Cross compilation always comes at a performance cost. Moreover, it is another compilation target your compiler needs to support. When that compilation target is a high-level language, supporting it is harder. This means java-script as a compilation target is less likely to be added.
  - pjmlp 7y ago
    Because usually it ends up with debugging generated JavaScript at some point.
- z3t4 7y ago
  The use case for wasm is basically doing cpu/memory intencive work in a worker process. In order to use wasm for UI you need lots of glue and ducttape, and the end result will be something using 2d canvas.
thegeomaster 7y ago
WebAssembly will never become obsolete (in a technical sense, who knows what will happen in practice) as long as there are use-cases that require predictable and consistent performance. I predict these will become plentiful as more and more companies build web apps for increasingly performance-sensitive niches. I'm not talking so much about raw speed, it's more about latency. Things such as realtime audio in the browser, non-CSS-driven animation, 3D (or any kind of realtime graphics, really), tight UIs where feedback must be very fast to be useful, etc. In lower-level languages, you must sometimes go as far as to avoid all memory allocations in one critical path. It's very hard to do so in JavaScript, especially when you take into account the prevalent coding style and functional nature of the language. As long as you have GC and a dynamic type system which requires JIT heuristics to achieve that 2x speedup, you will always have cases of pathological latency which degrade the experience. When you measure raw speed in benchmarks, you amortize all of the jitter. Now, whether the market is such that it will be satisfied by apps with this behavior is another story.
- pjmlp 7y ago
  And then you have cases like Android where there was a FloatMath class, implementated in native code due to the dog slowness from Dalvik with floating point math. After ART came into play, and its JIT started getting serious optimizations, doing regular Java math was faster than going over the JNI wall and FloatMath is now deprecated.

rocqua 7y ago

You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation. I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.

FreeHugs 7y ago
If you want to use a different language, why would you care about the compile target? Compiling is done by the compiler. So to the developer it is the same. No matter if it comiles to Javascript or Webassembly. In the end, I don't think writing code for the web in languages other then Javascript will take off. Simply because Javascript will always evolve to fit this specific environment. And therefore will always be the best choice. While other languages will evolve to be the best fit for their niche.
- rocqua 7y ago
  Cross compilation always comes at a performance cost. Moreover, it is another compilation target your compiler needs to support. When that compilation target is a high-level language, supporting it is harder. This means java-script as a compilation target is less likely to be added.
- pjmlp 7y ago
  Because usually it ends up with debugging generated JavaScript at some point.
z3t4 7y ago
The use case for wasm is basically doing cpu/memory intencive work in a worker process. In order to use wasm for UI you need lots of glue and ducttape, and the end result will be something using 2d canvas.

thegeomaster 7y ago

WebAssembly will never become obsolete (in a technical sense, who knows what will happen in practice) as long as there are use-cases that require predictable and consistent performance. I predict these will become plentiful as more and more companies build web apps for increasingly performance-sensitive niches. I'm not talking so much about raw speed, it's more about latency. Things such as realtime audio in the browser, non-CSS-driven animation, 3D (or any kind of realtime graphics, really), tight UIs where feedback must be very fast to be useful, etc. In lower-level languages, you must sometimes go as far as to avoid all memory allocations in one critical path. It's very hard to do so in JavaScript, especially when you take into account the prevalent coding style and functional nature of the language. As long as you have GC and a dynamic type system which requires JIT heuristics to achieve that 2x speedup, you will always have cases of pathological latency which degrade the experience. When you measure raw speed in benchmarks, you amortize all of the jitter. Now, whether the market is such that it will be satisfied by apps with this behavior is another story.

pjmlp 7y ago
And then you have cases like Android where there was a FloatMath class, implementated in native code due to the dog slowness from Dalvik with floating point math. After ART came into play, and its JIT started getting serious optimizations, doing regular Java math was faster than going over the JNI wall and FloatMath is now deprecated.