6 ms·

>I don't understand this. WASM is not JavaScript: [...] So I think your analogy fails. WASM is not a JS IL, it's a separate IL Yes, that's what it looks like

by jasode 3y ago

>I don't understand this. WASM is not JavaScript: [...] So I think your analogy fails. WASM is not a JS IL, it's a separate IL Yes, that's what it looks like now. To explain the Javascript-to-WASM evolution, we use the concept of the "Overton Window" shifting the industry by almost imperceptible degrees : https://en.wikipedia.org/wiki/Overton_window https://en.wikipedia.org/wiki/Overton_window - phase 1: 1995 Javascript the "toy language" but no IL. The industry doesn't need to be "afraid" of a toy scripting language because it's just there to make the monkey dance.[1] - phase 2: 2000s Javascript is being extended XMLHttpRequest() to create "serious" apps like drag & drop email and Google Maps - phase 3: 2013 extensive use of Javascript everywhere motivates a performance hack by creating subset in "asm.js" : https://en.wikipedia.org/wiki/Asm.js https://en.wikipedia.org/wiki/Asm.js - phase 4: 2017 instead of "asm.js" (and also using some Google NaCl ideas), the industry finally collaborates to create WASM to further optimize away the inefficient "asm.js" Since WASM today looks a lot like what JVM/CLR hoped to accomplish, why couldn't we have skipped the whole circuitous route of Javascript-then-WASM instead of just having "WASM in 1995" in the first place?!? Because of the Overton Window. If WASM was there from the beginning, it would have been too "threatening" in 1990s and corporate firewall admins would want to block all http/html that had it. ("Let's prevent WASM viruses") Javascript on the other hand is just for animating monkeys so there's no need to block it. That's how you eventually get universal distribution across clients including smartphones. With Javascript code already entrenched everywhere, it's easier to slide the Overton Window over to WASM. WASM didn't get created in a vacuum. It's existence is directly tied back to Javascript's usage and growth. [1] https://softwareengineering.stackexchange.com/questions/221615/why-do-dynamic-languages-make-it-more-difficult-to-maintain-large-codebases#:~:text=The%20by%2Ddesign%20purpose%20of%20JavaScript%20was%20to%20make%20the%20monkey%20dance%20when%20you%20moused%20over%20it.%20Scripts%20were%20often%20a%20single%20line https://softwareengineering.stackexchange.com/questions/2216....

zozbot234 3y ago
> Since WASM today looks a lot like what JVM/CLR hoped to accomplish WASM is actually much lower-level than JVM or CLR, there's basically no comparison. The main feature in both CLR and JVM (accounting for the bulk of their complexity) is their object model which has no equivalent in WASM-GC, the closest thing (while quite different nonetheless) is probably the WASM components proposal which is still vaporware. (Could WASM-GC have shipped in the mid-1990s? Quite unlikely, the FLOSS community was in its infancy back then and JVM applets were seen as state of the art. Even the Cyclone language was only created in the mid-2000s, and having full type- and memory-safety with C-like performance and no need for pervasive GC was unthinkable prior to that. The plan9 folks had Limbo and Dis which were somewhat simpler, but there was zero broader interest in using something like that over the JVM.)
jchw 3y ago
Not to mention, JavaScript engines were essentially extended into supporting WebAssembly much like they were extended to optimize Asm.js. Browsers generally don't have entirely separate WebAssembly engines, parts of their existing JS engine are shared for WebAssembly. I think that makes the case pretty well!
- lolinder 3y ago
  That doesn't really make the case—JIT compiler backends are all pretty similar, so of course the browsers are going to reuse parts of their JavaScript JIT for WASM, but that doesn't make WASM "JavaScript, but fast". The only resemblance WASM has to JavaScript is it lives in the browser.
  - jchw 3y ago
    To be fair, as far as I can tell you are the first person to use the phrase "JavaScript, but fast" in this thread. Wasm's design isn't based on JS, obviously. It is, however, strongly inspired by ideas like asm.js and the existence of C -> JS compilers (among other things.) You can find more evidence of this than just HN commenters. Here's Google: https://web.dev/articles/what-is-webassembly https://web.dev/articles/what-is-webassembly Heck, the same toolchain (Emscripten) that targeted asm.js became one of the defacto Wasm toolchains. They're not the same thing, but the path from which things evolved is not really open for much debate.
    - lolinder 3y ago
      This is what I'm replying to from OP: > Now the industry says: "Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make it fast by creating an IL runtime!!!" If they'd said that we have a universal platform in the browser, make it fast, that would be different. It's the idea that the JavaScript runtime is going to be made faster by WASM that I'm objecting to.
      - jchw 3y ago
lolinder 3y ago
> 2013 extensive use of Javascript everywhere motivates a performance hack by creating subset in "asm.js" : ASM.js was an attempt to make JavaScript a useable compilation target, not a performance hack for JavaScript programs. That effort did lead to people deciding that a new bytecode format was a better option, but the desire to compile to JavaScript was never about JavaScript itself, it was about trying to bring other languages to the frontend web. At the time the only way to do that was to compile to JavaScript. I don't think you're wrong about the Overton window, but it's a lot more complicated than "JavaScript shifted the overton window". The actual history is one of people wanting to do more and more with web browsers in general until JavaScript became non-viable. WASM is far more a younger sibling of JavaScript than it is a descendant of it—both were born from the growth of the web.

by jasode 3y ago

zozbot234 3y ago

> Since WASM today looks a lot like what JVM/CLR hoped to accomplish WASM is actually much lower-level than JVM or CLR, there's basically no comparison. The main feature in both CLR and JVM (accounting for the bulk of their complexity) is their object model which has no equivalent in WASM-GC, the closest thing (while quite different nonetheless) is probably the WASM components proposal which is still vaporware. (Could WASM-GC have shipped in the mid-1990s? Quite unlikely, the FLOSS community was in its infancy back then and JVM applets were seen as state of the art. Even the Cyclone language was only created in the mid-2000s, and having full type- and memory-safety with C-like performance and no need for pervasive GC was unthinkable prior to that. The plan9 folks had Limbo and Dis which were somewhat simpler, but there was zero broader interest in using something like that over the JVM.)

jchw 3y ago

Not to mention, JavaScript engines were essentially extended into supporting WebAssembly much like they were extended to optimize Asm.js. Browsers generally don't have entirely separate WebAssembly engines, parts of their existing JS engine are shared for WebAssembly. I think that makes the case pretty well!

lolinder 3y ago
That doesn't really make the case—JIT compiler backends are all pretty similar, so of course the browsers are going to reuse parts of their JavaScript JIT for WASM, but that doesn't make WASM "JavaScript, but fast". The only resemblance WASM has to JavaScript is it lives in the browser.
- jchw 3y ago
  To be fair, as far as I can tell you are the first person to use the phrase "JavaScript, but fast" in this thread. Wasm's design isn't based on JS, obviously. It is, however, strongly inspired by ideas like asm.js and the existence of C -> JS compilers (among other things.) You can find more evidence of this than just HN commenters. Here's Google: https://web.dev/articles/what-is-webassembly https://web.dev/articles/what-is-webassembly Heck, the same toolchain (Emscripten) that targeted asm.js became one of the defacto Wasm toolchains. They're not the same thing, but the path from which things evolved is not really open for much debate.
  - lolinder 3y ago
    This is what I'm replying to from OP: > Now the industry says: "Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make it fast by creating an IL runtime!!!" If they'd said that we have a universal platform in the browser, make it fast, that would be different. It's the idea that the JavaScript runtime is going to be made faster by WASM that I'm objecting to.
    - jchw 3y ago

lolinder 3y ago

> 2013 extensive use of Javascript everywhere motivates a performance hack by creating subset in "asm.js" : ASM.js was an attempt to make JavaScript a useable compilation target, not a performance hack for JavaScript programs. That effort did lead to people deciding that a new bytecode format was a better option, but the desire to compile to JavaScript was never about JavaScript itself, it was about trying to bring other languages to the frontend web. At the time the only way to do that was to compile to JavaScript. I don't think you're wrong about the Overton window, but it's a lot more complicated than "JavaScript shifted the overton window". The actual history is one of people wanting to do more and more with web browsers in general until JavaScript became non-viable. WASM is far more a younger sibling of JavaScript than it is a descendant of it—both were born from the growth of the web.