> Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance.
What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
The point of WASM is a universal compile target that executes a sandbox. That is all.
The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.
I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++.
Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.
Modern JS executes at about the same speed as Java or about 25% C language speed. A JavaScript application is often faster to initialize into memory than a C language application, largely because less overhead is required for application initialization, but otherwise slower because JS is garbage collected.
These distinctions are crucial when hardware performance really matters, like gaming or scientific data analysis. Otherwise these performance differences just aren’t noticeable to a common user.
Before WASM was a thing 3D gaming engines were ported into Emscripten demos to show case the potential. The output was too slow to play heavy 3D games in a portable browser container but far beyond what you could get away with using JS alone. All that misses the point that you could now run this giant game engine in a web page without installing anything.
And that’s why it’s ten years old and just getting traction now. Until it has DOM access nobody working on the front end will be particularly enthused about its utility.
They’ve made a solution looking for a problem while the problem is staring them right in the face. It is a frankly ridiculous situation.
> And that’s why it’s ten years old and just getting traction now.
There’s not any particularly meaningful change in its traction. It has specialised situations where it’s very desirable, and it has been used in those specialised situations extensively for quite a few years; and for more general use, it’s trudging along as it ever has been, because it’s not compelling.
> Until it has DOM access nobody working on the front end will be particularly enthused about its utility.
This is also false. Shipping WebAssembly or shipping Web Workers each add complexity, compared with just using main-thread JavaScript, and most people simply can’t justify that—that’s why they’re not interested. But as for DOM access transforming things, I’ll say that Rust is one of the main languages used for targeting WebAssembly (because most languages aren’t suitable), and native DOM bindings is going to change approximately nothing. It will allow/require a slight change in the build process, and slightly change the way you write your own bindings, but that’s all.
I don’t entirely understand why people keep on thinking giving WASM direct access to DOM objects will be transformative. In truth, it’s very minor.
What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.