5 ms·

So you still need JS to load/compile wasm or do anything useful(i.e DOM)...what a disappointment!

by thefounder 9y ago

hackcasual 9y ago
The alternative is that it's a bloated piece of tech that ends up the way of Flash/Applets.
- username223 9y ago
  I.e. disabled and eventually removed? I could live with that.
- thefounder 9y ago
  I believe flash and java applets were something else than WASM.
  - hackcasual 9y ago
    Right, they were their own separate VMs, with a lot of duplicated functionality. WASM is just a way to get native, non memory managed languages executing efficiently in a JavaScript environment.
banhfun 9y ago
Now that makes me wonder what the point of WASM is because we could have always transpiled code to JS
- bastawhiz 9y ago
  Performance. WebAssembly has no JIT stage, it gets AOT compiled straight to machine code. Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.
  - kllrnohj 9y ago
    > Plus, it gives (or will give) much lower-level access to features like threads and memory allocation. There's no reason JavaScript couldn't just have those features. It already has some amount of memory allocation control via ArrayBuffer & DataView.
    - imtringued 9y ago
      You're describing asm.js which had significant issues as a compilation target. The generated javascript code was massive and it took several seconds just to parse it.
      - caseymarquis 9y ago
        Related is a mozilla post on streaming wasm for big performance gains: https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
      - kllrnohj 9y ago
        asm.js never added threads, which is a far bigger performance issue than fine-grained manual memory allocation is.
  - amaranth 9y ago
    Thanks to Spectre I don't think we'll be seeing threads anytime soon. Well, not threads with shared memory anyway which removes a lot of the point of them. Same reason JavaScript just lost SharedArrayBuffer, too easy to make a high precision timer out of it.
- malcolmwhite 9y ago
  Right now, some of the biggest users are applications where JavaScript's garbage collection pauses are show-stoppers, like games and audio recording software.
- themihai 9y ago
  Transpilation to JS always sucks. JS was not designed as a compiler target. The point of WASM is exactly that: Compile any language on the web without getting into the JS limitation.
Ono-Sendai 9y ago
Is that just the current state of affairs, or will it always be like that?
- undecidabot 9y ago
  Just for now, it seems. It's tied together with the GC support: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079. I wouldn't expect it anytime soon though.
  - steveklabnik 9y ago
    It is not tied together with GC support; that used to be the case, but https://github.com/WebAssembly/host-bindings/ https://github.com/WebAssembly/host-bindings/ is the way forward.

So you still need JS to load/compile wasm or do anything useful(i.e DOM)...what a disappointment!

hackcasual 9y ago

The alternative is that it's a bloated piece of tech that ends up the way of Flash/Applets.

username223 9y ago
I.e. disabled and eventually removed? I could live with that.
thefounder 9y ago
I believe flash and java applets were something else than WASM.
- hackcasual 9y ago
  Right, they were their own separate VMs, with a lot of duplicated functionality. WASM is just a way to get native, non memory managed languages executing efficiently in a JavaScript environment.

banhfun 9y ago

Now that makes me wonder what the point of WASM is because we could have always transpiled code to JS

bastawhiz 9y ago
Performance. WebAssembly has no JIT stage, it gets AOT compiled straight to machine code. Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.
- kllrnohj 9y ago
  > Plus, it gives (or will give) much lower-level access to features like threads and memory allocation. There's no reason JavaScript couldn't just have those features. It already has some amount of memory allocation control via ArrayBuffer & DataView.
  - imtringued 9y ago
    You're describing asm.js which had significant issues as a compilation target. The generated javascript code was massive and it took several seconds just to parse it.
    - caseymarquis 9y ago
      Related is a mozilla post on streaming wasm for big performance gains: https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
    - kllrnohj 9y ago
      asm.js never added threads, which is a far bigger performance issue than fine-grained manual memory allocation is.
- amaranth 9y ago
  Thanks to Spectre I don't think we'll be seeing threads anytime soon. Well, not threads with shared memory anyway which removes a lot of the point of them. Same reason JavaScript just lost SharedArrayBuffer, too easy to make a high precision timer out of it.
malcolmwhite 9y ago
Right now, some of the biggest users are applications where JavaScript's garbage collection pauses are show-stoppers, like games and audio recording software.
themihai 9y ago
Transpilation to JS always sucks. JS was not designed as a compiler target. The point of WASM is exactly that: Compile any language on the web without getting into the JS limitation.

Ono-Sendai 9y ago

Is that just the current state of affairs, or will it always be like that?

undecidabot 9y ago
Just for now, it seems. It's tied together with the GC support: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079. I wouldn't expect it anytime soon though.
- steveklabnik 9y ago
  It is not tied together with GC support; that used to be the case, but https://github.com/WebAssembly/host-bindings/ https://github.com/WebAssembly/host-bindings/ is the way forward.