Hacker News Reader

Your logic is circular though. You are saying that there won't be much speedup for the sort of things people already do in WASM - but the reason they're doing them in WASM is because they're not slowed down too much.

What you don't get much is people doing standard SPA DOM manipulation apps in WASM (e.g. the TodoMVC that they benchmarked) because the slowdown is large. By fixing that performance issue you enable new usecases.

View on HN

IMHO the bang-for-the-buck proportion isn't right. The core problem is slow string marshalling in the JS shim (because it needs to create a JS string object from an ArrayBuffer slice - where the array buffer is the WASM heap).

Integrating the component model into browsers just for faster string marshalling is 'using cannons to shoot sparrows' as the German saying goes.

If there would be a general fast-path for creating short-lived string objects from ArrayBuffer slices, the entire web ecosystem would benefit, not just WASM code.

Reply on news.ycombinator.com