3 ms·

I thought WASM was considered slower than JavaScript only for the use cases where heavy usage of DOM is necessary. Since that's not available through WASM it ne

by dudus 5y ago

I thought WASM was considered slower than JavaScript only for the use cases where heavy usage of DOM is necessary. Since that's not available through WASM it needs to make a call to a JS function to perform the DOM manipulation and that incurs extra overhead. I think these cases will just never be good for WASM. DOM manipulation heavy Apps (which is a good chunk of JS code out there) may continue to be in JS and only the CPU intensive tasks would be computed in WASM. Isn't that the best practice for WASM?

meetups323 5y ago
Browsers are good enough that if you're careful about it you can just use a WebWorker and write standard JS, no need to worry with the build/compilation/compatibility headaches adding a whole new language to your ecosystem entails. Nice part with this is you can even have a fallback routine that runs the WebWorker code in the main thread to support really old browsers. I wouldn't recommend dropping to WASM until you've ironed out the ideal data structures/algorithms to use, and have spent some time in the devtools profiler. Hacking on ideas in JS is (IME) much faster than doing the same in a compiled language, and the built in profiling in browsers works far better for JS than any WASM (again IME). Only after you have an optimized algorithm, data structure, and implementation, and still find perf isn't where you want it would I recommend rewriting in a compiled language -- even then I'd wager having the optimized reference implementation around will make this much easier and faster than if you tried to start from 0 in the compiled language. Bonus points if you can reuse tests and/or have a debug mode that runs both implementations in parallel and throws on any differences in output.
- OtomotO 5y ago
  But I prefer to write other languages, so a compilation target is perfect. So it's either wasm or something like scala.js or fengari.io (lua on the web) (Worry not, I am paid to write JS and TS these days... But my rate increased due to the pain it causes ;))
dgb23 5y ago
This issue is being worked on: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...
janpaul123 5y ago
The overhead of going to JS from Wasm these days is very small, and the DOM is relatively slow. So doing DOM operations from Wasm is not much different than from JS; the vast majority of the time is spent in the actual DOM API calls.
- marcosdumay 5y ago
  Add to that the fact that complexity tends to exist in an exponential curve, and even though the DOM is relatively slow, it is still very fast. So the number of projects where there is enough DOM interaction that WASM will be slow, but not enough that JS is still usable is very small.
jkelleyrtp 5y ago
In http://dioxuslabs.com http://dioxuslabs.com we share our strings (interned) across the JS/Rust boundary and only send primitives back and forth. All diffing stays in Rust with bump memory allocators managing allocations. The JS side is only there to do DOM manipulation. [1] It's about 3-4x faster than React. I'd say a lot of the ergonomics are there, but not every pattern has been translated cleanly from React into Rust yet. [1] https://github.com/DioxusLabs/dioxus/blob/master/packages/interpreter/src/interpreter.js https://github.com/DioxusLabs/dioxus/blob/master/packages/in...
deleted 5y ago
[deleted]

by dudus 5y ago

meetups323 5y ago

Browsers are good enough that if you're careful about it you can just use a WebWorker and write standard JS, no need to worry with the build/compilation/compatibility headaches adding a whole new language to your ecosystem entails. Nice part with this is you can even have a fallback routine that runs the WebWorker code in the main thread to support really old browsers. I wouldn't recommend dropping to WASM until you've ironed out the ideal data structures/algorithms to use, and have spent some time in the devtools profiler. Hacking on ideas in JS is (IME) much faster than doing the same in a compiled language, and the built in profiling in browsers works far better for JS than any WASM (again IME). Only after you have an optimized algorithm, data structure, and implementation, and still find perf isn't where you want it would I recommend rewriting in a compiled language -- even then I'd wager having the optimized reference implementation around will make this much easier and faster than if you tried to start from 0 in the compiled language. Bonus points if you can reuse tests and/or have a debug mode that runs both implementations in parallel and throws on any differences in output.

OtomotO 5y ago
But I prefer to write other languages, so a compilation target is perfect. So it's either wasm or something like scala.js or fengari.io (lua on the web) (Worry not, I am paid to write JS and TS these days... But my rate increased due to the pain it causes ;))

dgb23 5y ago

This issue is being worked on: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...

janpaul123 5y ago

The overhead of going to JS from Wasm these days is very small, and the DOM is relatively slow. So doing DOM operations from Wasm is not much different than from JS; the vast majority of the time is spent in the actual DOM API calls.

marcosdumay 5y ago
Add to that the fact that complexity tends to exist in an exponential curve, and even though the DOM is relatively slow, it is still very fast. So the number of projects where there is enough DOM interaction that WASM will be slow, but not enough that JS is still usable is very small.

jkelleyrtp 5y ago

In http://dioxuslabs.com http://dioxuslabs.com we share our strings (interned) across the JS/Rust boundary and only send primitives back and forth. All diffing stays in Rust with bump memory allocators managing allocations. The JS side is only there to do DOM manipulation. [1] It's about 3-4x faster than React. I'd say a lot of the ergonomics are there, but not every pattern has been translated cleanly from React into Rust yet. [1] https://github.com/DioxusLabs/dioxus/blob/master/packages/interpreter/src/interpreter.js https://github.com/DioxusLabs/dioxus/blob/master/packages/in...

deleted 5y ago

[deleted]