Hacker News new | past | comments | ask | show | jobs | submit login

Not really. The assumption is that modifying the dom directly is the expensive part.

Doesn’t seem like a good bet for the long term. There’s no practical reason why modifying the DOM couldn’t be practically free. Especially if we can hint to the layout engine that we’re working in a well behaved subset. (Or the layout engine can detect such)

Hi, I work on a browser, layout and styling are expensive.

Browsers already to tons of work to avoid recomputing too much of this stuff whenever the DOM changes, and it's still inadvisable to poke the DOM too much. I don't see this changing anytime soon. There are various new features that allow for some level of hinting, but it's not going to obviate this. Browsers need to have incremental layout/styling prepare for any kind of potential change, whereas if you have a reactive UI framework you know what kinds of changes can happen, and can optimize diffing based on that.

There's a reason why a lot of JS UI frameworks use a virtual DOM. It sounds expensive to maintain, but directly operating on the DOM is more expensive.

That’s why I mentioned subsets! (like ASM.js)

Also, syncing can theoretically get to the minimum possible DOM calls, but with good tools I believe I can get close to n*log(n) of that with a procedural model. Which makes your point somewhat moot.

At some point the JS->C++ FFI was just slow in most browsers, but I guess this has seen improvements lately?

I don't think that's too slow. It can be, but it's not the main bottleneck in my experience.

That said there are various tricks that browsers use to avoid introducing these boundaries.

Right. All this treating the DOM with kid gloves seems to be due to its pre-existing weaknesses. Why not just fix those?

Browser vendors have spent the past several decades trying to fix those weaknesses and haven't, it seems like a very strong indication that it is not exactly an easy thing to do.

This might be just because most web apps never had a bottleneck on JS->DOM changes.

This is blatantly false, as the DOM has always been a bottleneck for web apps.

Because you can't "just" fix them. It's a complex problem with no easy solutions. Don't you think it'd already be "fixed" if it was easy?

> There’s no practical reason why modifying the DOM couldn’t be practically free.

Oh yeah, modifying the DOM is practically free. Which is why React and the like do that in their mirror DOM.

Actually applying the resulting changes, on the other hand...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact