4 ms·

This might be a fact, but it certainly isn’t fun or interesting. Anybody who is framing WebAssembly into some sort of competition with javascript is completely

This might be a fact, but it certainly isn’t fun or interesting. Anybody who is framing WebAssembly into some sort of competition with javascript is completely missing the point of it’s existence. The major problem with WebAssembly right now is the major point of it’s existence is mirky. It will take time and effort from everyone using it for figure out it’s true calling, but I am hopeful and optimistic this gets discovered. In the meantime it doesn’t help to pit it against javascript.

smegsicle 4y ago
what should it be compared against if not javascript?
- zamadatix 4y ago
  Any general purpose VM is fine, including the VMs behind JavaScript, but just double check that's actually what's being compared instead of inter JavaScript and VM performance. How many times per second you can call 1-5 line functions from a webpage's execution context is comparing the latter and as the article notes at the end: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming. WASM functions aren't meant to replace small JS functions on your standard website. It's meant to be a general purpose VM you can target large amounts of non-webpage code to.
- enos_feedler 4y ago
  Its a new thing not trying to supplant anything else.
EGreg 4y ago
If you can use emscripten to compile all stuff to Javascript, then what’s the point of WASM? Smaller instruction set? It’s a serious question. All the JS has the same properties, it seems, as WebAssembly. The runtime implementers can reason about it better?
- RodgerTheGreat 4y ago
  In a nutshell, WASM is slightly more efficient than Empscripten + Asm.js because it has a binary format and circumvents the need to parse a blob of JS. That's about it, really. Whereas Asm.js had (has?) perfect backwards-compatibility with unsupported browsers and JS interpreters, WASM requires users to remain on the bleeding edge of new browser features as it continues to evolve, and introduces a whole host of fantastic new bottlenecks as the designers puzzle over how to interface WASM modules with the rest of the facilities JS can already access. The whole thing is a hilarious boondoggle- an insane amount of effort and complexity for mild bandwidth and page-load time savings- made all the more hilarious for the fact that a remarkable number of people seem unaware that Asm.js ever existed in the first place.
- jsheard 4y ago
  https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... WASM has continued to evolve past what's possible in JS/asmjs since that article as well, with things like SIMD support
  - davidmurdoch 4y ago
    So it is about performance over JavaScript.
    - zamadatix 4y ago
      Performance against JavaScript for specific use cases (i.e. being a general purpose VM for traditional application code) is a factor. Performance against JavaScript in general (e.g. calling the same simple function in a loop) is not a factor. E.g. if you had only done rendering on a CPU and someone came by and said "we can do all sorts of stuff we couldn't do before with this GPU check it out!" it'd be easy to say "I could do all that on a CPU" and you could even show the exact same benchmarks presented here and then say "see, the CPU even runs the single threaded factorial function many more times per second than this new GPU". Everything you said would be absolutely correct in the most literal form yet it'd still be completely missing the point of why the GPU was made and how to assess if it fits that purpose better. Then someone shows you the GPU doing rendering it was designed to do well better than the CPU and the reply is "So it is about the GPU being faster than the CPU?". Yes. No. It depends what context you're asking from. Traditional use cases no, what it was designed to do well yes. The original article which talked about WASM being slower itself specifically notes this relation of purpose, functionality, and performance it's just tucked away in the conclusion: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming.
torginus 4y ago
Aren't they though? Is it not possible, that in the future web pages will be scripted in literally every programming language, from python to rust, and javascript will be just one of many ways to write a webapp?
thrashh 4y ago
It’s not like we haven’t been down a similar path Java introduced a language and library… but the real innovation was that it introduced a cross platform VM that was supported by some organization WebAssembly is now doing the same thing… but just the cross-platform VM part Now you can run Python and JS on the JVM these days but these are not de-facto implementations and so their adoption is pretty low. I wonder if the same issue will apply to these alternate WASM implementations of existing languages.

smegsicle 4y ago

what should it be compared against if not javascript?

zamadatix 4y ago
Any general purpose VM is fine, including the VMs behind JavaScript, but just double check that's actually what's being compared instead of inter JavaScript and VM performance. How many times per second you can call 1-5 line functions from a webpage's execution context is comparing the latter and as the article notes at the end: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming. WASM functions aren't meant to replace small JS functions on your standard website. It's meant to be a general purpose VM you can target large amounts of non-webpage code to.
enos_feedler 4y ago
Its a new thing not trying to supplant anything else.

EGreg 4y ago

If you can use emscripten to compile all stuff to Javascript, then what’s the point of WASM? Smaller instruction set? It’s a serious question. All the JS has the same properties, it seems, as WebAssembly. The runtime implementers can reason about it better?

RodgerTheGreat 4y ago
In a nutshell, WASM is slightly more efficient than Empscripten + Asm.js because it has a binary format and circumvents the need to parse a blob of JS. That's about it, really. Whereas Asm.js had (has?) perfect backwards-compatibility with unsupported browsers and JS interpreters, WASM requires users to remain on the bleeding edge of new browser features as it continues to evolve, and introduces a whole host of fantastic new bottlenecks as the designers puzzle over how to interface WASM modules with the rest of the facilities JS can already access. The whole thing is a hilarious boondoggle- an insane amount of effort and complexity for mild bandwidth and page-load time savings- made all the more hilarious for the fact that a remarkable number of people seem unaware that Asm.js ever existed in the first place.
jsheard 4y ago
https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... WASM has continued to evolve past what's possible in JS/asmjs since that article as well, with things like SIMD support
- davidmurdoch 4y ago
  So it is about performance over JavaScript.
  - zamadatix 4y ago
    Performance against JavaScript for specific use cases (i.e. being a general purpose VM for traditional application code) is a factor. Performance against JavaScript in general (e.g. calling the same simple function in a loop) is not a factor. E.g. if you had only done rendering on a CPU and someone came by and said "we can do all sorts of stuff we couldn't do before with this GPU check it out!" it'd be easy to say "I could do all that on a CPU" and you could even show the exact same benchmarks presented here and then say "see, the CPU even runs the single threaded factorial function many more times per second than this new GPU". Everything you said would be absolutely correct in the most literal form yet it'd still be completely missing the point of why the GPU was made and how to assess if it fits that purpose better. Then someone shows you the GPU doing rendering it was designed to do well better than the CPU and the reply is "So it is about the GPU being faster than the CPU?". Yes. No. It depends what context you're asking from. Traditional use cases no, what it was designed to do well yes. The original article which talked about WASM being slower itself specifically notes this relation of purpose, functionality, and performance it's just tucked away in the conclusion: > definitely don’t go converting all your websites’ JavaScript to WebAssembly! However, that’s not really the aim of WebAssembly. Its aim is to enable richer experiences on the web that require higher performance, for example machine learning, virtual reality, or gaming.

torginus 4y ago

Aren't they though? Is it not possible, that in the future web pages will be scripted in literally every programming language, from python to rust, and javascript will be just one of many ways to write a webapp?

thrashh 4y ago

It’s not like we haven’t been down a similar path Java introduced a language and library… but the real innovation was that it introduced a cross platform VM that was supported by some organization WebAssembly is now doing the same thing… but just the cross-platform VM part Now you can run Python and JS on the JVM these days but these are not de-facto implementations and so their adoption is pretty low. I wonder if the same issue will apply to these alternate WASM implementations of existing languages.