Hacker News Reader

Comment by cassepipe | Hacker News Reader

I am curious. I barely know any webdev and only program C and C++. Are there things that one still need JS for even though using webassembly ?

View on HN

Simply put, missing DOM manipulation. Here [0] is quite a good summary with plenty of links to currently open proposals/issues on WA's GitHub that would allow it to do that.

[0]https://sudonull.com/post/62869-WebAssembly-and-DOM-manipula...

Hmm, wouldn't it suffice just to export a createHandle() function to WASM, which could then use said handle to reference the underlying C++ object of the HTML element. V8's involvement isn't even necessary.

The DOM element then would be collected, when there are no JS references to it, its handle is disposed of by the WASM code, or the WASM runtime itself is destroyed.

Seems like a very similar problem to how game engines integrate scripting languages like Lua - with very similar solutions.

Game engines are aware of the scripting languages embedded in them. Browsers are largely unaware of anything but Javascript.

On top of that a lot of DOM manipulation is smoke and mirrors. While the exposed DOM APIs may provide you with some object, internally it's likely to be a collection of weird things in a trench coat due to all the optimisations that browser engines are doing.

And no one in their right mind will give you raw access to the underlying C++ object for many reasons, security being number one. And 30 years of assumptions that browsers have about these objects being number two.

For DOM you can get pretty far binding http://google.github.io/incremental-dom/ to C (it's all just procedure calls).

But other than that there are OpenGL bindings (eg. in emscripten) and things for audio like SoLoud etc. You can usually put off writing JS for a while.

WASM on the browser runs inside the Javascript engine 'context', so you will always need to deal with some Javascript (for instance to load and start the WASM blob, but also for calling out into web APIs). Emscripten hides most of that from the programmer (depending what web APIs you need to talk to), but there's still plenty of Javascript running under the hood.

So, to clarify, "WEBassembly" was a terrible name in retrospect -- the majority of WASM use (that I have encountered) is serverside, not clientside.

The super tl;dr of WASM is that it's a universal bytecode format, an idea sort of like the JVM or the CLR. There are a few major benefits to this:

  1. Languages can pick WASM as a compile target, and then run anywhere that WASM is supported. This includes the browser, the server, embedded devices, wherever.

  2. WASM acts as a "Lingua Franca" for interop between languages, sort of like a C ABI. Any language that supports importing WASM bundles immediately gains support for calling code from any language that supports compiling to WASM.

It's trivial to write a program that calls functions from IE. Rust, Go, Zig, and C# in the span of 10 lines, because of WASM.

On the clientside, you still need JS because WASM needs to interact with the browser's DOM API's. I'm not convinced of the benefits of WASM for writing web apps.

(One exception is maybe Blazor for .NET, which is exceptionally well-done)

Reply on news.ycombinator.com