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.

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

well, it could definitely be designed better.

Starting from not only single-threaded but memory-limited target was... weird decision

What does NaCl (seems to be some random crypto library?) have to do with this?

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.

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

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.

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.

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.

Oh, even worse than I thought.

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?

Wasm can do 64-bit integers, SIMD and statically typed GC classes.

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.

WASM can even do 32-bit integers, which JavaScript can't, so uses floats instead.

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.

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.

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

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

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/

Js is not always faster, but in a good chunk of cases it is.

It is easy to make benchmarks where JS is faster. JS inlines at runtime, while wasm typically does not, so if you have code where the wasm toolchain makes a poor inlining decision at compile time, then JS can easily win.

But that is really only common in small computational kernels. If you take a large, complex application like Adobe Photoshop or a Unity game, wasm will be far closer to native speed, because its compilation and optimization approach is much closer to native builds (types known ahead of time, no heavy dependency on tiering and recompilation, etc.).

I would take these benchmarks with a pinch of salt. Within a single function, it's very easy to optimize JS because you know every way a single variable will be defined. When you have to call a function, the data type of the argument can be anything the caller passes to the function, which makes optimization far more complex.

In practice, WASM codebases won't be simply running a single pure function in WASM from JS but instead will have several data structures being passed around from one WASM function to another, and that's going to be faster than doing the same in JS.

By the way, if I remember correctly V8 can optimize function calls heuristically if every call always passes the same argument types, but because this is an implementation detail it's difficult to know what scenarios are actually optimized and which are not.

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.

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.

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.

I think youre referring to PNaCl(as opposed to Native Client), which did away with the arch-specific assembly, and I think they shipped the code as LLVM IR. These are 2 completely separate things, I am referring to the former.

I don't see an issue with shipping uArch specific assembly, nowadays you only have 2 really in heavy use today, and I think managing that level of complexity is tenable, considering the monster the current Wasm implementation became, which is still lacking in key ways.

As for out of process sandboxing, I think for a lot of things it's fine - if you want to run a full-fat desktop-app or game, you can cram it into an iframe, and the tab(renderer) process is isolated, so Chrome's approach was quite tenable from an IRL perspective.

But if seamless interaction with Web APIs is needed, that could be achieved as well, and I think quite similarly to how Wasm does it - you designate a 'slab' of native memory and make sure no pointer access goes outside by using base-relative addressing and masking the addresses.

For access to outside APIs, you permit jumps to validated entry points which can point to browser APIs. I also don't see why you couldn't interleave stack frames, by making a few safety and sanity checks, like making sure the asm code never accesses anything outside the current stack frame.

Personally I thought that WebAssembly was what it's name suggested - an architecture independent assembly language, that was heavily optimized, and only the register allocation passes and the machine instruction translation was missing - which is at the end of the compiler pipeline, and can be done fairly fast, compared to a whole compile.

But it seems to me Wasm engines are more like LLVM, an entire compiler consuming IR, and doing fancy optimization for it - if we view it in this context, I think sticking to raw assembly would've been preferable.

Sorry, yes, I meant PNaCl.

> I don't see an issue with shipping uArch specific assembly, nowadays you only have 2 really in heavy use today,

That is true today, but it would prevent other architectures from getting a fair shot. Or, if another architecture exploded in popularity despite this, it would mean fragmentation.

This is why the Portable version of NaCl was the final iteration, and the only one even Google considered shippable, back then.

I agree the other stuff is fixable - APIs etc. It's really portability that was the sticking point. No browser vendor was willing to give that up.

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.

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.

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.

They tried their best: https://deterministic.js.org/

No, WASM is deterministic, JS is fundamentally not. Your dislike of all things blockchain makes you say silly things.

But WASM already exists and has many languages that are able to compile to it, why reinvent the wheel?

JS isn't deterministic in its performance