6 ms·

Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. Theory and pr

by torginus 10mo ago

Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. Theory and practice doesn't match in this case, and many people have remarked that companies that sit on the WhatWG board have vested interest in making sure their lucrative app stores are not threatened by a platform that can run any app just as well. I remember when Native Client came to the scene and allowed people to compile complex native apps to the web that run at like 95% of native speed. While it was in many ways an inelegant solution, it worked better than WebAssembly does today. Another one of WebAssembly's killer features was supposed to be native web integration. How JS engines work is that you have an IDL that describes the interface of JS classes which is then used to generate code to bind to underlying C++ implementations. You could probably bind those to Webassembly just as well. I don't think a cross-platform as in cross CPU arch matters that much, if you meant 'runs on everything' then I concur. Also the dirty secret of WebAssembly is that it's not really faster than JS.

PunchyHamster 10mo ago
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).
avadodin 10mo ago
As someone with no intersection with the web, it is disconcerting to attend the burial of wasm when she was still getting her first compiler backends.
EGreg 10mo ago
Actually the great secret of wasm (that will piss off a lot of people on HN I am sure) is that it is deterministic and can be used to build decentralized smart contracts and Byzantine Fault Tolerant distributed systems :) Some joker who built Solana actually thought Berkeley Packet Filter language would be better than WASM for their runtime. But besides that dude, everyone is discovering how great WASM can be to run deterministic code right in people’s browsers!
- torginus 10mo ago
  I don't think you need WASM for that, I'm sure you can write a language that transpiles to JS and is still deterministic.
  - circuit10 10mo ago
    But WASM already exists and has many languages that are able to compile to it, why reinvent the wheel?
  - undeveloper 10mo ago
    JS isn't deterministic in its performance
  - EGreg 10mo ago
    They tried their best: https://deterministic.js.org/ https://deterministic.js.org/ No, WASM is deterministic, JS is fundamentally not. Your dislike of all things blockchain makes you say silly things.
z3t4 10mo ago
Also WebAssembly is meant to be a compiler target with the biggest advantage being it's sandboxed. The problem is that the JS engines can do that too. Just like JS engines, WebAssembly can run outside browsers. I think in theory Wasm is better then JS in those areas, but not better enough.
CuriouslyC 10mo ago
WASM is way way way faster if you need explicit memory management. It's only 100% a wash if you're doing DOM stuff.
- torginus 10mo ago
  Not necessarily. I found a benchmark that you can run yourself, that's doing pretty much just raw compute (JS vs C/C++ in Wasm): https://takahirox.github.io/WebAssembly-benchmark/ https://takahirox.github.io/WebAssembly-benchmark/ Js is not always faster, but in a good chunk of cases it is.
  - CuriouslyC 10mo ago
    Things might be getting better for JS, but just looking over those briefly, they don't look memory constrained, which is the main place where I've seen significant speedups. Also, simpler code makes JIT optimizations look better, but that level of performance won't be consistent in real world code.
    - torginus 10mo ago
      You might be right in your use case, but still, JS is not the benchmark to beat. Native Client was already almost as fast as native code, started up almost instantly, and didn't get a decade of engineering with who knows how much money behind it invested into it. Webassembly that was supposed to replace it needs to be at least as good, that was the promise. We're a decade in, and still Wasm is nowhere near while it has accumulated an insane amount of engineering complexity in its compiler, and its ability to run native apps without tons of constraints and modifications is still meh as is the performance.
      - azakai 10mo ago
        To be fair, Native Client achieved much of its speed by reusing LLVM and the decades of work put into that excellent codebase. Also, Native Client started up so fast because it shipped native binaries, which was not portable. To fix that, Portable Native Client shipped a bytecode, like wasm, which meant slower startup times - in fact, the last version of PNaCl had a fast baseline compiler to help there, just like wasm engines do today, so they are very similar. And, a key issue with Native Client is that it was designed for out-of-process sandboxing. That is fine for some things, but not when you need synchronous access to Web APIs, which many applications do (NaCl avoided this problem by adding an entirely new set of APIs to the web, PPAPI, which most vendors were unhappy about). Avoiding this problem was a major principle behind wasm's design, by making it able to coexist with JS code (even interleaving stack frames) on the main thread.
throwaway314155 10mo ago
> Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. This is an entirely unnecessary jab. There’s a whole generation dealing with stuff like this because of economic and other forces outside their control.
- axus 10mo ago
  WASM not taking over the world is probably also due to forces outside its control; I guess that's only relevant if money was being spent to accomplish that goal.

PunchyHamster 10mo ago

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).

avadodin 10mo ago

As someone with no intersection with the web, it is disconcerting to attend the burial of wasm when she was still getting her first compiler backends.

EGreg 10mo ago

Actually the great secret of wasm (that will piss off a lot of people on HN I am sure) is that it is deterministic and can be used to build decentralized smart contracts and Byzantine Fault Tolerant distributed systems :) Some joker who built Solana actually thought Berkeley Packet Filter language would be better than WASM for their runtime. But besides that dude, everyone is discovering how great WASM can be to run deterministic code right in people’s browsers!

torginus 10mo ago
I don't think you need WASM for that, I'm sure you can write a language that transpiles to JS and is still deterministic.
- circuit10 10mo ago
  But WASM already exists and has many languages that are able to compile to it, why reinvent the wheel?
- undeveloper 10mo ago
  JS isn't deterministic in its performance
- EGreg 10mo ago
  They tried their best: https://deterministic.js.org/ https://deterministic.js.org/ No, WASM is deterministic, JS is fundamentally not. Your dislike of all things blockchain makes you say silly things.

z3t4 10mo ago

Also WebAssembly is meant to be a compiler target with the biggest advantage being it's sandboxed. The problem is that the JS engines can do that too. Just like JS engines, WebAssembly can run outside browsers. I think in theory Wasm is better then JS in those areas, but not better enough.

CuriouslyC 10mo ago

WASM is way way way faster if you need explicit memory management. It's only 100% a wash if you're doing DOM stuff.

torginus 10mo ago
Not necessarily. I found a benchmark that you can run yourself, that's doing pretty much just raw compute (JS vs C/C++ in Wasm): https://takahirox.github.io/WebAssembly-benchmark/ https://takahirox.github.io/WebAssembly-benchmark/ Js is not always faster, but in a good chunk of cases it is.
- CuriouslyC 10mo ago
  Things might be getting better for JS, but just looking over those briefly, they don't look memory constrained, which is the main place where I've seen significant speedups. Also, simpler code makes JIT optimizations look better, but that level of performance won't be consistent in real world code.
  - torginus 10mo ago
    You might be right in your use case, but still, JS is not the benchmark to beat. Native Client was already almost as fast as native code, started up almost instantly, and didn't get a decade of engineering with who knows how much money behind it invested into it. Webassembly that was supposed to replace it needs to be at least as good, that was the promise. We're a decade in, and still Wasm is nowhere near while it has accumulated an insane amount of engineering complexity in its compiler, and its ability to run native apps without tons of constraints and modifications is still meh as is the performance.
    - azakai 10mo ago
      To be fair, Native Client achieved much of its speed by reusing LLVM and the decades of work put into that excellent codebase. Also, Native Client started up so fast because it shipped native binaries, which was not portable. To fix that, Portable Native Client shipped a bytecode, like wasm, which meant slower startup times - in fact, the last version of PNaCl had a fast baseline compiler to help there, just like wasm engines do today, so they are very similar. And, a key issue with Native Client is that it was designed for out-of-process sandboxing. That is fine for some things, but not when you need synchronous access to Web APIs, which many applications do (NaCl avoided this problem by adding an entirely new set of APIs to the web, PPAPI, which most vendors were unhappy about). Avoiding this problem was a major principle behind wasm's design, by making it able to coexist with JS code (even interleaving stack frames) on the main thread.

throwaway314155 10mo ago

> Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. This is an entirely unnecessary jab. There’s a whole generation dealing with stuff like this because of economic and other forces outside their control.

axus 10mo ago
WASM not taking over the world is probably also due to forces outside its control; I guess that's only relevant if money was being spent to accomplish that goal.