[Cthulhu_]

That's exactly the kind of thing I think WASM is good at - small, computationally expensive libraries that are easy to just plug in.

I'm more of a web developer and every time I think "hmm, could I use this to build a webapp?", but quickly shrug it off because it would create a big headache and the JS execution is rarely the bottleneck (and if it is, it's likely developer error and inefficiencies than the language / interpreter).

[throwaway894345]

It's very similar to the Python/C distinction. Python will often drop into C for the use-cases you're describing. However, unlike WASM, Python/C is the wild west:

- The whole CPython interpreter is the "C-extension interface" which means that the CPython interpreter can hardly change or be optimized or else it will break something in the ecosystem (and for the same compatibility reason it's virtually impossible for alternative optimized interpreters to make headway), and because the interpreter is so poorly optimized the ecosystem depends on C extensions for performance. WASM presumably won't have this distinction.

- Without the abysmal build ecosystem that C and C++ projects tend to bring with them, building and deploying WASM applications will likely be pleasant and easy after a few years. Of course, if your WASM is generated from C/C++ then that's a real bummer, but fortunately this should be a much smaller fraction of the ecosystem than it is with C/Python.

[NohatCoder]

Yeah, and most of the time if "JavaScript is slow" it is because of DOM manipulation or network latency, WASM can't even do those things.

[zozbot234]

Network roundtrips are unavoidable, but WASM could be used to parse a server response and generate custom HTML to use in replacing some portion of the DOM. It would likely be a lot faster than trying to do the same in pure JS, and it would obviate the use of over-complicated hacks like virtual DOM and the like.

[NohatCoder]

No, parsing the response is usually way too fast to make a difference. Generating an HTML string is also usually pretty fast. The slowness happens when you ask the browser to parse that HTML string and generate the appropriate DOM, WASM is not going to get you out of that.

[zozbot234]

> The slowness happens when you ask the browser to parse that HTML string and generate the appropriate DOM

If you do it right, that step only has to happen once for each user interaction. You can entirely dispense with the need to do multiple edits to the DOM via pure JS.

[baybal2]

Multiple edits on the HTML are by far not anywhere near as performance devastating as they were a decade ago.

At the moment, the "virtual DOM" approach is actually going against performance optimization.

JS frameworks like react, vue, angualr etc effectively replicates a big portion of browser's internal logic for nothing.

[acdha]

It’s not “at the moment” but “continuously from the creation of the virtual DOM concept” - often slower by multiple orders of magnitude.

The misrepresentation of a virtual DOM as a performance improvement came from two things: people who were comparing virtual DOM code to sloppy unoptimized code which was regenerating the DOM on every change and React fans not wanting to believe their new favorite was a regression in any way (not to be confused with the actual React team who certainly knew how to do real benchmarks and were quite open about limitations).

There’s a line of argument that the extra overhead is worth it if the average developer writes more efficient code than they did with other approaches but I think that’s leaving a lot of room for alternatives which don’t have that much inefficiency baked into the design.

[abacadaba]

Na, the slowness comes from asking the browser to do that 1000's of times in a loop every click :)

[scsilver]

Frankly that just seems more difficult and handles an issue I havent run into in 5 years that couldn't be solved with js performance optimizations.

Does WASM really make sense for something that isnt constantly doing high performance calculations? Do I gain anything from using it in most SPA's?

[underwater]

Forcing the browser to continually parse HTML and generate a new DOM tree, recalculate layout, etc. shouldn't be faster than updating specific nodes than need changes.

[dahfizz]

The first roundtrip is unavoidable. Making another handful of roundtrips every time the user scrolls the page is definitely avoidable.

[miohtama]

What would it take to make DOM manipulation faster?

[onion2k]

DOM manipulation

Browser vendors have done a lot of work on that over the past decade or so. It's nowhere near as slow as it was in the early days.

[danShumway]

Absolutely, it's been kind of incredible progress. But it's still going to be a bottleneck more often than JS execution (in my experience at least).

Not always; I have definitely run into applications where parsing large amounts of data in code is a bottleneck, especially when building large charts. But often.

[__s]

Where in my case "small, computationally expensive library" is a card game engine & its AI search

[Black101]

I think WASM is also good at hiding the source code? which is the main reason why I don't like it...