Hacker News Reader

Comment by beders | Hacker News Reader

It is simply mind-boggling how much effort the JS community has put into working around the performance properties of a document layout engine to make it 'interactive' and 'responsive'.

With only 3 major rendering engines left standing, where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines?

Back to Svelte vs. React vs. Reagent vs. Vue.JS vs. Angular vs. (insert framework-of-the-month-here)

One common theme seems to be: Run code to manipulate a tree-like data structure (DOM) efficiently. This obviously needs to become: Submit data to the rendering engine to manipulate the tree-like structure. (and in a way .innerHtml is doing that for a sub-tree, but is not suitable for general-purpose tree manipulation)

View on HN

> where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines

The DOM is fast enough for desktop apps @60 or even 90 frames per second, especially of you follow best practices (no framework required)

If it is fast enough, why is everyone optimizing?

I hope you read the original article, that clearly lays out the (non) optimizations being done in VDOM.

In any compute environment, doing more than necessary spins CPU cycles wastefully. I believe the optimizations you speak of try to limit this work to the least possible, by telling on the framework's Dev world. But this is surprisingly easy to achieve without frameworks, see [1] and [2]

[1]: https://github.com/wilsonpage/fastdom

[2]: https://youtu.be/sFMpS2_GqQc

For an individual developer it is not obvious how you should structure your usage of the DOM API to avoid the performance potholes and other problems. Even a team of experts in the DOM will sometimes take shortcuts or one expert's technique doesn't play nicely with another's.

Some parts of the DOM are extremely slow if the API is used naturally, and obvious usage of the API has other side-effect penalties (e.g. stored state, difficult component destruction, or reference loops causing memory blowouts).

So the vast majority of developers use the native DOM in such a way that the page is slow and buggy.

React et al provide a clean API that avoids the worst performance problems, while providing a framework that steers a team towards good practices, so the average developer can be productive.

The framework has a bunch of extra overhead, but the overhead is far less than the average overhead of not using the framework.

This is why I find the flutter approach interesting: it has its own rendering engine. I would guess it is optimized for this sort of thing (dynamically rendering UI elements) without depending on an external entity (DOM).

Maybe there is a future where flutter style renderers become standard, have a container like a browser (to avoid the entire runtime baggage when it's deployed), and people target it instead of the DOM? This gives best of both worlds--write apps in a declarative way, without the need of any external "optimizing" framework.

Does Flutter bridge accessibility APIs?

Reply on news.ycombinator.com