4 ms·

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 ?

gavinray 4y ago
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)
klohto 4y ago
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-manipulation https://sudonull.com/post/62869-WebAssembly-and-DOM-manipula...
- torginus 4y ago
  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.
  - dmitriid 4y ago
    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.
nikki93 4y ago
For DOM you can get pretty far binding http://google.github.io/incremental-dom/ 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.
flohofwoe 4y ago
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.

gavinray 4y ago

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)

klohto 4y ago

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-manipulation https://sudonull.com/post/62869-WebAssembly-and-DOM-manipula...

torginus 4y ago
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.
- dmitriid 4y ago
  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.

nikki93 4y ago

For DOM you can get pretty far binding http://google.github.io/incremental-dom/ 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.

flohofwoe 4y ago

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.