5 ms·

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 'inter

by beders 7y ago

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)

writepub 7y ago
> 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)
- beders 7y ago
  If it is fast enough, why is everyone optimizing?
  - writepub 7y ago
    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 https://github.com/wilsonpage/fastdom [2]: https://youtu.be/sFMpS2_GqQc https://youtu.be/sFMpS2_GqQc
  - robocat 7y ago
    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.
vaibhavkul 7y ago
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.
- ozten 7y ago
  Does Flutter bridge accessibility APIs?

by beders 7y ago

writepub 7y ago

> 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)

beders 7y ago
If it is fast enough, why is everyone optimizing?
- writepub 7y ago
  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 https://github.com/wilsonpage/fastdom [2]: https://youtu.be/sFMpS2_GqQc https://youtu.be/sFMpS2_GqQc
- robocat 7y ago
  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.

vaibhavkul 7y ago

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.

ozten 7y ago
Does Flutter bridge accessibility APIs?