5 ms·

Why fast? In our experience, the cost of boundary-crossing between wasm and js make it slower than js implementation for everything dom-related.

scottgpaulin 3y ago
I guess it's best for stuff that isn't dom related There are a few wasm libraries like finos/perspective and duckdb-wasm that are really useful in the client even though they don't interact with the dom
- throwme_123 3y ago
  Thanks for the pointer to duckdb-wasm, didn't know about it! > These micro benchmarks show that there is also no such thing as free lunch in the browser. We are paying for the increased processing efficiency in WebAssembly with a sightly less efficient evaluation on very small input. Our recommendation is therefore to use DuckDB-Wasm if you need SQL, the features or the raw speed on medium to large data sizes. Stick to existing frameworks if your dataset is very small or if your queries only contain simple scans and filters.
chriscbr 3y ago
Author here. Yeah, in fairness this post doesn't go into benchmarking (that would be interesting as a follow up). Though I would argue even for libraries that aren't numerically intensive (like the one I used in this blog post), I'd imagine the speeds are probably comparable to the JavaScript runtime if you don't have to boundary cross very often. In this case, the main thing that was "fast" was that I didn't have to rewrite a nontrivial string formatting library in a new language (I literally couldn't find any other JavaScript libraries that had this kind of error-formatting functionality, so that would have been my only other option). :-)
- danenania 3y ago
  Cool post! I'm curious how big your wasm file ended up being? For node, it would be interesting to compare performance, weight, and gotchas of the wasm approach vs. building a shared library with Rust and then pulling it in through node-gyp. Loading wasm is certainly a lot simpler, but multithreading support seems shaky and I imagine there may be some other drawbacks compared compiling into node directly, despite the added complexity.
foota 3y ago
That's surprising to me, there was a Mozilla post a few years ago saying js to wasm allows 100 million calls per second for the slowest category, which seems speedy enough? See: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%f0%9f%8e%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
- chrisco255 3y ago
  I think main issue is when it comes to DOM manipulation, the DOM is generally the bottleneck, not JavaScript. And since the DOM manipulations must be executed by JS anyways, you are often adding overhead by embedding your UI lib into wasm which then needs to message pass with JS to execute the DOM changes anyways. See: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
  - davidatbu 3y ago
    To me, the benchmarks you linked show that the fastest WASM web frameworks I know (leptos, dioxus, sycamore) are competitive with, or faster than, the JS frameworks most famously associated with speed, like SolidJS and Svelte; and that they are way faster than React. That doesn't support your statement here, so I was wondering what takeaway you meant to direct our attention to when providing that link.
    - chrisco255 3y ago
      The most mature React-like library written in Rust, Yew, is slower than React, as the chart shows. Meanwhile the fastest frameworks are minimal JS / vanilla JS, including the fastest framework, mikado. Either way it's clear that even a compile time language with no garbage collection can't get faster than the DOM itself allows, which is the crux of my point. In theory a compiled language should run at least twice as fast as JS, but it's not the case in the browser.
      - davidatbu 3y ago
davidatbu 3y ago
I'd love to hear more about your experience, because it contradicts what the JS Framework Benchmarks[0] suggests. Leptos and Dioxus, Rust/WASM frameworks, are competitive with SolidJS, and right out destroy React, when it comes to manipulating the DOM! So I'd love to hear, if possible, about when was it that you evaluated your WASM based solution, what language and framework you used, etc. [0] https://krausest.github.io/js-framework-benchmark/2023/table_chrome_114.0.5735.90.html https://krausest.github.io/js-framework-benchmark/2023/table...
- throwme_123 3y ago
  We built a prototype using wasm-bindgen where we computed data values (displayed in a large table). Benchmarks were slower than native js. This was last year though, maybe things got better now, so thanks for the pointers, will do another attempt!
  - davidatbu 3y ago
    Thanks for providing your data point! If you're having another go, I'd recommend checking out sledge-hammer[0], a wasm-bindgen alternative that the folks behind Dioxus have been working on. It's a faster, but more limited version. Best of luck! [0] https://github.com/Demonthos/sledgehammer_bindgen https://github.com/Demonthos/sledgehammer_bindgen
    - throwme_123 3y ago
      Thanks! Indeed, string decoding may have been our bottleneck as explained in [0]. Will definitely have a look. PS: Evan from https://github.com/Demonthos https://github.com/Demonthos, if you ever stumble upon this there is typo in the Dioxus link from your bio :)

scottgpaulin 3y ago

I guess it's best for stuff that isn't dom related There are a few wasm libraries like finos/perspective and duckdb-wasm that are really useful in the client even though they don't interact with the dom

throwme_123 3y ago
Thanks for the pointer to duckdb-wasm, didn't know about it! > These micro benchmarks show that there is also no such thing as free lunch in the browser. We are paying for the increased processing efficiency in WebAssembly with a sightly less efficient evaluation on very small input. Our recommendation is therefore to use DuckDB-Wasm if you need SQL, the features or the raw speed on medium to large data sizes. Stick to existing frameworks if your dataset is very small or if your queries only contain simple scans and filters.

chriscbr 3y ago

Author here. Yeah, in fairness this post doesn't go into benchmarking (that would be interesting as a follow up). Though I would argue even for libraries that aren't numerically intensive (like the one I used in this blog post), I'd imagine the speeds are probably comparable to the JavaScript runtime if you don't have to boundary cross very often. In this case, the main thing that was "fast" was that I didn't have to rewrite a nontrivial string formatting library in a new language (I literally couldn't find any other JavaScript libraries that had this kind of error-formatting functionality, so that would have been my only other option). :-)

danenania 3y ago
Cool post! I'm curious how big your wasm file ended up being? For node, it would be interesting to compare performance, weight, and gotchas of the wasm approach vs. building a shared library with Rust and then pulling it in through node-gyp. Loading wasm is certainly a lot simpler, but multithreading support seems shaky and I imagine there may be some other drawbacks compared compiling into node directly, despite the added complexity.

foota 3y ago

That's surprising to me, there was a Mozilla post a few years ago saying js to wasm allows 100 million calls per second for the slowest category, which seems speedy enough? See: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%f0%9f%8e%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

chrisco255 3y ago
I think main issue is when it comes to DOM manipulation, the DOM is generally the bottleneck, not JavaScript. And since the DOM manipulations must be executed by JS anyways, you are often adding overhead by embedding your UI lib into wasm which then needs to message pass with JS to execute the DOM changes anyways. See: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- davidatbu 3y ago
  To me, the benchmarks you linked show that the fastest WASM web frameworks I know (leptos, dioxus, sycamore) are competitive with, or faster than, the JS frameworks most famously associated with speed, like SolidJS and Svelte; and that they are way faster than React. That doesn't support your statement here, so I was wondering what takeaway you meant to direct our attention to when providing that link.
  - chrisco255 3y ago
    The most mature React-like library written in Rust, Yew, is slower than React, as the chart shows. Meanwhile the fastest frameworks are minimal JS / vanilla JS, including the fastest framework, mikado. Either way it's clear that even a compile time language with no garbage collection can't get faster than the DOM itself allows, which is the crux of my point. In theory a compiled language should run at least twice as fast as JS, but it's not the case in the browser.
    - davidatbu 3y ago

davidatbu 3y ago

I'd love to hear more about your experience, because it contradicts what the JS Framework Benchmarks[0] suggests. Leptos and Dioxus, Rust/WASM frameworks, are competitive with SolidJS, and right out destroy React, when it comes to manipulating the DOM! So I'd love to hear, if possible, about when was it that you evaluated your WASM based solution, what language and framework you used, etc. [0] https://krausest.github.io/js-framework-benchmark/2023/table_chrome_114.0.5735.90.html https://krausest.github.io/js-framework-benchmark/2023/table...

throwme_123 3y ago
We built a prototype using wasm-bindgen where we computed data values (displayed in a large table). Benchmarks were slower than native js. This was last year though, maybe things got better now, so thanks for the pointers, will do another attempt!
- davidatbu 3y ago
  Thanks for providing your data point! If you're having another go, I'd recommend checking out sledge-hammer[0], a wasm-bindgen alternative that the folks behind Dioxus have been working on. It's a faster, but more limited version. Best of luck! [0] https://github.com/Demonthos/sledgehammer_bindgen https://github.com/Demonthos/sledgehammer_bindgen
  - throwme_123 3y ago
    Thanks! Indeed, string decoding may have been our bottleneck as explained in [0]. Will definitely have a look. PS: Evan from https://github.com/Demonthos https://github.com/Demonthos, if you ever stumble upon this there is typo in the Dioxus link from your bio :)