Hacker News new | ask | show | jobs
by eqrion 97 days ago
I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.

And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.
1 comments
azakai 97 days ago
> DOM performance is a big deal and bottleneck for a lot of applications

What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production.

> But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

If the toolchain does it for them, they don't need to be experts, no more than people need to be DWARF experts to debug native applications.

I agree tools could be a lot better here! But as I think you know, my position is that we can move faster and get better results on the tools side.

link
jitl 97 days ago
> What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production.

any application you use today that is written in JavaScript rendering to the DOM, is much harder to write in not-JavaScript

Slack, Teams, Outlook, Word, OpenAI, Anthropic, Github, Twitter, Instagram (web), Notion, Google Docs, ...

link
azakai 96 days ago
Sorry, I'll ask my question in a better way: what applications written in wasm that exist today would benefit from this?

Now, maybe there aren't many because of performance - maybe they haven't used wasm because it was too slow. But I would appreciate seeing data on that - an application that tried wasm and gave up after seeing the overhead, at the least. But I would also expect to see apps that use wasm even despite some DOM overhead, because of the speedup on non-DOM code - and I'd like to see data on how much DOM overhead they are currently suffering.

I am asking because I'm familiar with a lot of apps ported to wasm, and they don't do this. That may just be because I am seeing one particular slice of the ecosystem! So I am very curious to learn about other parts.

link