4 ms·

I start to think that's why there is still no DOM for the WASM and we have to pingping over JS > Also the dirty secret of WebAssembly is that it's not really f

I start to think that's why there is still no DOM for the WASM and we have to pingping over JS > Also the dirty secret of WebAssembly is that it's not really faster than JS. That is near purely due to amount of work it took to make that shitty language run fast. Naive webassembly implementation will beat interpreted JS many times over but modern JIT implementations are wonder.

moralestapia 10mo ago
I don't dislike JS but the reason why it's fast is because billions were poured into making that happen. V8 is a modern engineering marvel.
- rob74 10mo ago
  Yeah, and like many engineering marvels, it was instantly misused for purposes its creators didn't intend and became a scourge on humanity (looking at you NodeJS & co).
- Findecanor 10mo ago
  And WASM hasn't been around for as long, so WASM implementations are not as mature. There is no reason why WASM couldn't be as fast, or faster than JS, especially now with WASM 3.0. Before, every programs in a managed language had to be shipped with its own GC and exception handling framework in WASM which was probably crippled by size constraints.
  - pjmlp 10mo ago
    They still need to, because WASM GC is a MVP that only covers a subset. Any language with advanced GC algorithms, or interior pointers, will run poorly with current WASM GC. It works as long as their GC model overlaps with JS GC requirements.
    - WorldMaker 10mo ago
      It's also currently only a subset of JS GC requirements at that. It's the bare minimum to share references between JS and WASM to byte arrays like Int32Array. It's like basic OS-level memory page sharing only for now. Some of the real GC tests will be strings support (because immutability/interning) and higher-level composite objects, which is all still in various draft/proposal states.
      - pjmlp 10mo ago
        Oh, even worse than I thought.
gritzko 10mo ago
Yep. These things have been solved by massive investments. The question is, can WASM as a language (not an implementation) do something JavaScript can't?
- moralestapia 10mo ago
  The answer to that is no. But innovating at the language level was never a goal for WASM; quite the opposite, as simple as possible so it can be compiled and run anywhere.
- CryZe 10mo ago
  Wasm can do 64-bit integers, SIMD and statically typed GC classes.
  - DonHopkins 10mo ago
    WASM can even do 32-bit integers, which JavaScript can't, so uses floats instead.
    - WorldMaker 10mo ago
      JS has had byte arrays like Int32Array for a while. The JS engines will try to optimize math done into them/with them as integer math rather than float math, but yeah you still can't use an integer directly outside of array math.
  - davidmurdoch 10mo ago
    JS could have had support for SIMD and 64 bit it's by now, and progress was actually being made (mostly just through the asm.js experiments), but it was deprioritized specifically to work on WASM.
torginus 10mo ago
For WASM, the performance target isn't Javascript - but native code and NaCl. Considering WASM has had tremendously more time and effort invested into it, and still underperforms NaCl (and JS) signals to me that this is not the right approach. The WASM runtime ended up from something that ingests pseudo-assembly,validates it and turns it into machine code, into a full-fledged multi-tiered JIT, like what JS has, with crazy engineering complexity per browser, and similar startup performance woes (which was one of the major goals of Nacl/Wasm to alleviate the load time issues with huge applications).
- 201984 10mo ago
  What does NaCl (seems to be some random crypto library?) have to do with this?
  - torginus 10mo ago
    https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client
- PunchyHamster 10mo ago
  well, it could definitely be designed better. Starting from not only single-threaded but memory-limited target was... weird decision
WorldMaker 10mo ago
> I start to think that's why there is still no DOM for the WASM and we have to pingping over JS I don't think you need conspiracy theories for that. DOM involves complex JS objects and you have to have an entirely working multi-language garbage collection model if you are expecting other languages to work with DOM objects otherwise you run the risk of memory leaking some of the most expensive objects in a browser. That path to that is long and slow, especially with the various committees' general interest being in not requiring non-JS languages to entirely conform to JS GC (either implementing themselves on top of JS GC alone or having to implement their own complex subset of JS GC to interop correctly), so the focus has been on very low level tools over complex GC patterns. The first basics have only just been standardized. The next step (sharing strings) seems close but probably still has months to go. The steps after that (sharing simple structs) seem pretty complex with a lot of heated debate still to happen, and DOM objects are still some further complexity step past that (as they involve complex reference cycles and other such things).

moralestapia 10mo ago

I don't dislike JS but the reason why it's fast is because billions were poured into making that happen. V8 is a modern engineering marvel.

rob74 10mo ago
Yeah, and like many engineering marvels, it was instantly misused for purposes its creators didn't intend and became a scourge on humanity (looking at you NodeJS & co).
Findecanor 10mo ago
And WASM hasn't been around for as long, so WASM implementations are not as mature. There is no reason why WASM couldn't be as fast, or faster than JS, especially now with WASM 3.0. Before, every programs in a managed language had to be shipped with its own GC and exception handling framework in WASM which was probably crippled by size constraints.
- pjmlp 10mo ago
  They still need to, because WASM GC is a MVP that only covers a subset. Any language with advanced GC algorithms, or interior pointers, will run poorly with current WASM GC. It works as long as their GC model overlaps with JS GC requirements.
  - WorldMaker 10mo ago
    It's also currently only a subset of JS GC requirements at that. It's the bare minimum to share references between JS and WASM to byte arrays like Int32Array. It's like basic OS-level memory page sharing only for now. Some of the real GC tests will be strings support (because immutability/interning) and higher-level composite objects, which is all still in various draft/proposal states.
    - pjmlp 10mo ago
      Oh, even worse than I thought.

gritzko 10mo ago

Yep. These things have been solved by massive investments. The question is, can WASM as a language (not an implementation) do something JavaScript can't?

moralestapia 10mo ago
The answer to that is no. But innovating at the language level was never a goal for WASM; quite the opposite, as simple as possible so it can be compiled and run anywhere.
CryZe 10mo ago
Wasm can do 64-bit integers, SIMD and statically typed GC classes.
- DonHopkins 10mo ago
  WASM can even do 32-bit integers, which JavaScript can't, so uses floats instead.
  - WorldMaker 10mo ago
    JS has had byte arrays like Int32Array for a while. The JS engines will try to optimize math done into them/with them as integer math rather than float math, but yeah you still can't use an integer directly outside of array math.
- davidmurdoch 10mo ago
  JS could have had support for SIMD and 64 bit it's by now, and progress was actually being made (mostly just through the asm.js experiments), but it was deprioritized specifically to work on WASM.

torginus 10mo ago

For WASM, the performance target isn't Javascript - but native code and NaCl. Considering WASM has had tremendously more time and effort invested into it, and still underperforms NaCl (and JS) signals to me that this is not the right approach. The WASM runtime ended up from something that ingests pseudo-assembly,validates it and turns it into machine code, into a full-fledged multi-tiered JIT, like what JS has, with crazy engineering complexity per browser, and similar startup performance woes (which was one of the major goals of Nacl/Wasm to alleviate the load time issues with huge applications).

201984 10mo ago
What does NaCl (seems to be some random crypto library?) have to do with this?
- torginus 10mo ago
  https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client
PunchyHamster 10mo ago
well, it could definitely be designed better. Starting from not only single-threaded but memory-limited target was... weird decision

WorldMaker 10mo ago

> I start to think that's why there is still no DOM for the WASM and we have to pingping over JS I don't think you need conspiracy theories for that. DOM involves complex JS objects and you have to have an entirely working multi-language garbage collection model if you are expecting other languages to work with DOM objects otherwise you run the risk of memory leaking some of the most expensive objects in a browser. That path to that is long and slow, especially with the various committees' general interest being in not requiring non-JS languages to entirely conform to JS GC (either implementing themselves on top of JS GC alone or having to implement their own complex subset of JS GC to interop correctly), so the focus has been on very low level tools over complex GC patterns. The first basics have only just been standardized. The next step (sharing strings) seems close but probably still has months to go. The steps after that (sharing simple structs) seem pretty complex with a lot of heated debate still to happen, and DOM objects are still some further complexity step past that (as they involve complex reference cycles and other such things).