3 ms·

It's absolutely a possibility but the problem is one of speed. DOM interop is one of the things that slows down JS so much and requires a lot of flexibility. A

It's absolutely a possibility but the problem is one of speed. DOM interop is one of the things that slows down JS so much and requires a lot of flexibility. Adding it to WASM will not be the amazing experience many think it will be.

hinkley 9y ago
I don't know about others but I'm not expecting it to be an amazing experience. It's more that I expect not having DOM interop to be an amazingly boring experience. Maybe Rust could be good for Web Workers but it'll be far more interesting when I can use it for interactions. The overhead problem you mention reminds me a little of the false intuition that people have about databases. I've worked on a couple projects where people were surprised that as the data set grew (either more customers, or accumulated customer activity), operations like INSERT and UPDATE got slower and slower, even without new functionality getting in the way. Everyone expects SELECT to get slower, but INSERTs seem to catch them off guard. Every INSERT or UPDATE has to update the indexes. And when you quadruple the data, the update time for each index doubles. At first the cost of the insert is in the noise floor. It's swamped by the communication and transaction overhead. But after a handful of doublings it becomes detectable. A few more and it becomes noticeable. After a few more it becomes a problem, and if you haven't already changed your product roadmap, you do now. To make a web page fast, you have to correlate the DOM with the CSS and the viewport. Adding more data isn't free.
- abritinthebay 9y ago
  Good illustration of that issue. I don’t know if I agree it’ll be less interesting- but it will have narrower applications. They’ll be more self contained - data and processing related - rather than driving the UI... but I don’t know if I’d call that not interesting. I mean... imagine a WASM game engine where the modules/plugins can be any language as long as the compile target is WASM and they follow the right API... with JS/DOM just doing the DOM part (canvas or webgl I guess). Sounds pretty powerful and fun.

hinkley 9y ago

I don't know about others but I'm not expecting it to be an amazing experience. It's more that I expect not having DOM interop to be an amazingly boring experience. Maybe Rust could be good for Web Workers but it'll be far more interesting when I can use it for interactions. The overhead problem you mention reminds me a little of the false intuition that people have about databases. I've worked on a couple projects where people were surprised that as the data set grew (either more customers, or accumulated customer activity), operations like INSERT and UPDATE got slower and slower, even without new functionality getting in the way. Everyone expects SELECT to get slower, but INSERTs seem to catch them off guard. Every INSERT or UPDATE has to update the indexes. And when you quadruple the data, the update time for each index doubles. At first the cost of the insert is in the noise floor. It's swamped by the communication and transaction overhead. But after a handful of doublings it becomes detectable. A few more and it becomes noticeable. After a few more it becomes a problem, and if you haven't already changed your product roadmap, you do now. To make a web page fast, you have to correlate the DOM with the CSS and the viewport. Adding more data isn't free.

abritinthebay 9y ago
Good illustration of that issue. I don’t know if I agree it’ll be less interesting- but it will have narrower applications. They’ll be more self contained - data and processing related - rather than driving the UI... but I don’t know if I’d call that not interesting. I mean... imagine a WASM game engine where the modules/plugins can be any language as long as the compile target is WASM and they follow the right API... with JS/DOM just doing the DOM part (canvas or webgl I guess). Sounds pretty powerful and fun.