6 ms·

It is a reasonable big deal in the niche of computation intensive applications. It would be an huge deal or revolution if it could perform faster on plain DOM

It is a reasonable big deal in the niche of computation intensive applications. It would be an huge deal or revolution if it could perform faster on plain DOM manipulation. By now, plain Javascript is faster than WASM [0]. That's because all WASM's DOM manipulation must go through the Javascript engine and many browsers do JIT compilation on Javascript. Edit: be aware that the article has a more interesting discussion on WASM on the server side, as a replacement of technologies such as Docker/containers, Java Virtual Machine and .Net. [0] https://krausest.github.io/js-framework-benchmark/2023/table_chrome_116.0.5845.82.html https://krausest.github.io/js-framework-benchmark/2023/table...

dclowd9901 3y ago
A WASM-powered virtual DOM with painting privileges seems all but ascertained given the general direction Mozilla and other interested parties are taking the environment. Include the bubble/capture phases and you’re completely there.
- satvikpendem 3y ago
  Indeed, I posted this in a sibling comment but this is exactly the future that will arrive: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 The browser will be the unified runtime for WASM apps, native level performance with the linkability and other advantages of the browser.
satvikpendem 3y ago
Unless you don't use the DOM at all for UI for web apps: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 It would enable any language to simply render their own UI and handle things like accessibility with their own accessibility based DOM that just handles the accessibility parts rather than the entire logic of the app. I believe this is what Flutter does.
- pavlov 3y ago
  This means shipping an entire UI framework as part of the web app onto a computer that already is running multiple UI frameworks. For example on macOS with Chrome, you’ll have Flutter running on Chromium running on AppKit. All of these provide text layout engines, compositors, 2D and 3D graphics, widget hierarchies, scripting languages… Hundreds of megabytes of redundant stuff loaded in memory to run some typically basic Flutter app. I know, we can’t magically have native binaries delivered on the web (that was ActiveX and it was bad). But it somehow boggles the mind that this is what we ended up with.
  - satvikpendem 3y ago
    Well, people like web apps but not desktop apps, but then also complain that web apps are slow (see Electron), so what can we do otherwise?
- troupo 3y ago
  > simply render their own UI simply is doing a lot of heavy lifting here. > and handle things like accessibility with their own accessibility based DOM that just handles the accessibility just is doing as much heavy lifting as simply before it. > I believe this is what Flutter does. Flutter "just" "simply" have a trillion-dollar company sponsoring their project that came out of internal power struggles. And they have "just" "simply" been working on it for 6 years, and currently has 11 thousand issues in their repository.
  - satvikpendem 3y ago
    Well, that's why I use Flutter rather than some other community-led project in another language, like I see in Rust like Slint, because it's quite a big task to redo a lot of this work for WASM.
    - troupo 3y ago
      Yes, see how "simply" and "just" quickly became "I will only use code from a trillian-dollar corporation because it's neither 'simple' nor 'just' to build a proper UI framework"
alexvitkov 3y ago
Just days ago I was rewriting some matrix math operations for our game from C to WASM SIMD, only for most of them to barely tie the original performance (where for reference a crappy x86 SIMD routine gives me 3x to 5x). That's not something you'd use for "computationally intensive" applications. Frankly this shit has been around for years and the major implementations still suck. As for servers, it's insane to pretend you don't know what your server's CPU is and run your crap in what's essentially a handicapped JVM. Made up solutions for made up problems.
- pjmlp 3y ago
  The experience is worse than Java, .NET and BEAM application servers, while pretenting to have invented something new.
- paulgb 3y ago
  The problem with just moving hot routines over to Wasm is that you pay overhead every time you cross the Wasm boundary. The success stories I’ve heard with Wasm typically involve writing the entire computational core and renderer in Wasm, to minimize the amount that the boundary is crossed. Here’s an example of an architecture that seems to work well: https://x.com/paulgb/status/1688919428740816896?s=46 https://x.com/paulgb/status/1688919428740816896?s=46
  - alexvitkov 3y ago
    We don't jump a WASM/JS boundry, the entire game is written in C/C++ - we only jump to JS once at the end of each game frame when it comes time to render, so we do all WebGL calls from JS at once. What I did was rewrite a chunk of our matrix math library, previously written in C, directly into WASM with the shiny new SIMD operations. Rewriting a naive 4x4 matrix multiplication with SIMD gains you 3x to 4x on on x86 (with the algorithm from the answer in [1]), and a direct translation of that using the WASM SIMD instructions gains you nothing on Chrome. On Firefox the WASM SIMD is 20-30% faster than naive multiplication, which is not much, but it's something. The issue is that on Chrome the WASM version is dead even with the scalar implementation, and to be honest I care a lot more about performance on Chrome than on Firefox. [1] https://codereview.stackexchange.com/questions/101144/simd-matrix-multiplication https://codereview.stackexchange.com/questions/101144/simd-m...
jwr 3y ago
I agree with your first sentence, although I believe that niche is really small, so I am entirely unconvinced as to the benefits of WASM. I am an author of a large ClojureScript app, which sometimes does need to do intensive computation. In my experience, the performance of compiled ClojureScript (it uses the Google Closure compiler in "advanced" mode, so the code is really optimized) is not a problem at all. What is a major issue is DOM manipulation: any time you touch the DOM, you run into slowdowns of two orders of magnitude. And that can't be magically waved away by WASM. In my case, if I had a ClojureScript->WASM compiler, it would likely provide me with an overall perceptible app performance gain in the 5%-10% range, while introducing a whole range of interesting bugs and issues. Not something I'd like to use.
troupo 3y ago
> It is a reasonable big deal in the niche of computation intensive applications. For a very narrow definition of "computation intensive applications" where definition is "speeding up some parts of some workloads in some situations on web pages"
tcfhgj 3y ago
Well, plain JS is faster than JS Frameworks as well. And in comparison with them WASM (e.g. Dioxus or Leptos) aren't that much slower, if at all. Solid is at 1.09 Dioxus 1.14 - wasm Leptos 1.18 - wasm Angular 1.62 React 1.64 Now, that's just DOM manipulation. Any real app, especially ones where performance matters will have a huge shift towards computation that's not DOM related, even if the app is not computationally extensive.

dclowd9901 3y ago

A WASM-powered virtual DOM with painting privileges seems all but ascertained given the general direction Mozilla and other interested parties are taking the environment. Include the bubble/capture phases and you’re completely there.

satvikpendem 3y ago
Indeed, I posted this in a sibling comment but this is exactly the future that will arrive: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 The browser will be the unified runtime for WASM apps, native level performance with the linkability and other advantages of the browser.

satvikpendem 3y ago

Unless you don't use the DOM at all for UI for web apps: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 It would enable any language to simply render their own UI and handle things like accessibility with their own accessibility based DOM that just handles the accessibility parts rather than the entire logic of the app. I believe this is what Flutter does.

pavlov 3y ago
This means shipping an entire UI framework as part of the web app onto a computer that already is running multiple UI frameworks. For example on macOS with Chrome, you’ll have Flutter running on Chromium running on AppKit. All of these provide text layout engines, compositors, 2D and 3D graphics, widget hierarchies, scripting languages… Hundreds of megabytes of redundant stuff loaded in memory to run some typically basic Flutter app. I know, we can’t magically have native binaries delivered on the web (that was ActiveX and it was bad). But it somehow boggles the mind that this is what we ended up with.
- satvikpendem 3y ago
  Well, people like web apps but not desktop apps, but then also complain that web apps are slow (see Electron), so what can we do otherwise?
troupo 3y ago
> simply render their own UI simply is doing a lot of heavy lifting here. > and handle things like accessibility with their own accessibility based DOM that just handles the accessibility just is doing as much heavy lifting as simply before it. > I believe this is what Flutter does. Flutter "just" "simply" have a trillion-dollar company sponsoring their project that came out of internal power struggles. And they have "just" "simply" been working on it for 6 years, and currently has 11 thousand issues in their repository.
- satvikpendem 3y ago
  Well, that's why I use Flutter rather than some other community-led project in another language, like I see in Rust like Slint, because it's quite a big task to redo a lot of this work for WASM.
  - troupo 3y ago
    Yes, see how "simply" and "just" quickly became "I will only use code from a trillian-dollar corporation because it's neither 'simple' nor 'just' to build a proper UI framework"

alexvitkov 3y ago

Just days ago I was rewriting some matrix math operations for our game from C to WASM SIMD, only for most of them to barely tie the original performance (where for reference a crappy x86 SIMD routine gives me 3x to 5x). That's not something you'd use for "computationally intensive" applications. Frankly this shit has been around for years and the major implementations still suck. As for servers, it's insane to pretend you don't know what your server's CPU is and run your crap in what's essentially a handicapped JVM. Made up solutions for made up problems.

pjmlp 3y ago
The experience is worse than Java, .NET and BEAM application servers, while pretenting to have invented something new.
paulgb 3y ago
The problem with just moving hot routines over to Wasm is that you pay overhead every time you cross the Wasm boundary. The success stories I’ve heard with Wasm typically involve writing the entire computational core and renderer in Wasm, to minimize the amount that the boundary is crossed. Here’s an example of an architecture that seems to work well: https://x.com/paulgb/status/1688919428740816896?s=46 https://x.com/paulgb/status/1688919428740816896?s=46
- alexvitkov 3y ago
  We don't jump a WASM/JS boundry, the entire game is written in C/C++ - we only jump to JS once at the end of each game frame when it comes time to render, so we do all WebGL calls from JS at once. What I did was rewrite a chunk of our matrix math library, previously written in C, directly into WASM with the shiny new SIMD operations. Rewriting a naive 4x4 matrix multiplication with SIMD gains you 3x to 4x on on x86 (with the algorithm from the answer in [1]), and a direct translation of that using the WASM SIMD instructions gains you nothing on Chrome. On Firefox the WASM SIMD is 20-30% faster than naive multiplication, which is not much, but it's something. The issue is that on Chrome the WASM version is dead even with the scalar implementation, and to be honest I care a lot more about performance on Chrome than on Firefox. [1] https://codereview.stackexchange.com/questions/101144/simd-matrix-multiplication https://codereview.stackexchange.com/questions/101144/simd-m...

jwr 3y ago

I agree with your first sentence, although I believe that niche is really small, so I am entirely unconvinced as to the benefits of WASM. I am an author of a large ClojureScript app, which sometimes does need to do intensive computation. In my experience, the performance of compiled ClojureScript (it uses the Google Closure compiler in "advanced" mode, so the code is really optimized) is not a problem at all. What is a major issue is DOM manipulation: any time you touch the DOM, you run into slowdowns of two orders of magnitude. And that can't be magically waved away by WASM. In my case, if I had a ClojureScript->WASM compiler, it would likely provide me with an overall perceptible app performance gain in the 5%-10% range, while introducing a whole range of interesting bugs and issues. Not something I'd like to use.

troupo 3y ago

> It is a reasonable big deal in the niche of computation intensive applications. For a very narrow definition of "computation intensive applications" where definition is "speeding up some parts of some workloads in some situations on web pages"

tcfhgj 3y ago

Well, plain JS is faster than JS Frameworks as well. And in comparison with them WASM (e.g. Dioxus or Leptos) aren't that much slower, if at all. Solid is at 1.09 Dioxus 1.14 - wasm Leptos 1.18 - wasm Angular 1.62 React 1.64 Now, that's just DOM manipulation. Any real app, especially ones where performance matters will have a huge shift towards computation that's not DOM related, even if the app is not computationally extensive.