3 ms·

WebAssembly already exists. It's easier for certain use cases, but not most. It gives good performance, but worse than native software outside the browser.

wewxjfq 3y ago
WebAssembly only gives better performance for things that shouldn't be done in the UI main-thread. As long as you don't do number crunching in the mouse move event handler, I doubt WebAssembly can beat vanilla JavaScript for reactive UIs.
- flohofwoe 3y ago
  Once you work with the DOM, the (small) overhead of calling from WASM into a JS shim or any performance difference between WASM and JS doesn't matter. The internal DOM implementation will dominate the performance profile unless you do really dumb things.
pjmlp 3y ago
And after a decade the tooling still sucks, comparing with the development experience of native code.
- flohofwoe 3y ago
  That's why you develop and debug a native target, and then just flip a build system option to compile to WASM, it's really not much different from regular cross-compiling. (DWARF debugging in VSCode is now actually possible via https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod..., but the native debugging workflow still makes more sense, unless you need to debug the WASM-specific parts of the code)
  - pjmlp 3y ago
    Like I say, the tooling sucks. I am well aware of that workflow. We can walk with a cane, doesn't mean walking without it isn't much better.
    - flohofwoe 3y ago
      The single parts are all there (but only since very recently), now they just need to be connected through a VSCode extension. I cobbled such a workflow together myself [1] with a couple of python scripts and existing VSCode extensions which is good enough for me. In the end it's up to IDE vendors to provide a similar workflow. [1] https://floooh.github.io/2023/11/11/emscripten-ide.html https://floooh.github.io/2023/11/11/emscripten-ide.html
      - pjmlp 3y ago
        Yeah, it only covers C and C++, solves your specific use case, and still doesn't change the fact the tooling sucks for everyone else, with exception of something like Blazor or Unity.
flohofwoe 3y ago
> worse than native software outside the browser ...for typical portable C code the performance difference is surprisingly small though (within 20% or so). The main advantage of native compilation targets is that you have more "manual optimization potential" via non-standard language extensions like builtins and intrinsics (usually at the cost of portability and compiler compatibility).

wewxjfq 3y ago

WebAssembly only gives better performance for things that shouldn't be done in the UI main-thread. As long as you don't do number crunching in the mouse move event handler, I doubt WebAssembly can beat vanilla JavaScript for reactive UIs.

flohofwoe 3y ago
Once you work with the DOM, the (small) overhead of calling from WASM into a JS shim or any performance difference between WASM and JS doesn't matter. The internal DOM implementation will dominate the performance profile unless you do really dumb things.

pjmlp 3y ago

And after a decade the tooling still sucks, comparing with the development experience of native code.

flohofwoe 3y ago
That's why you develop and debug a native target, and then just flip a build system option to compile to WASM, it's really not much different from regular cross-compiling. (DWARF debugging in VSCode is now actually possible via https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod..., but the native debugging workflow still makes more sense, unless you need to debug the WASM-specific parts of the code)
- pjmlp 3y ago
  Like I say, the tooling sucks. I am well aware of that workflow. We can walk with a cane, doesn't mean walking without it isn't much better.
  - flohofwoe 3y ago
    The single parts are all there (but only since very recently), now they just need to be connected through a VSCode extension. I cobbled such a workflow together myself [1] with a couple of python scripts and existing VSCode extensions which is good enough for me. In the end it's up to IDE vendors to provide a similar workflow. [1] https://floooh.github.io/2023/11/11/emscripten-ide.html https://floooh.github.io/2023/11/11/emscripten-ide.html
    - pjmlp 3y ago
      Yeah, it only covers C and C++, solves your specific use case, and still doesn't change the fact the tooling sucks for everyone else, with exception of something like Blazor or Unity.

flohofwoe 3y ago

> worse than native software outside the browser ...for typical portable C code the performance difference is surprisingly small though (within 20% or so). The main advantage of native compilation targets is that you have more "manual optimization potential" via non-standard language extensions like builtins and intrinsics (usually at the cost of portability and compiler compatibility).