> I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes.
This statement betrays the commenter's lack of understanding understanding of both limitations of the Web model and the freedom afforded by almost every single one of UI libs and frameworks.
> I don't even understand what he tries to say with "draw the control directly".
Aaand here it is: "I don't understand".
In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. A framework/library doesn't provide a control you need? You just draw it yourself.
So, instead of re-inventing, poorly, a virtual list, or a calendar, or a customisable drop-down with a few thousand divs, z-index issues and layout thrashing, you can (relatively) easily implement those controls yourself. At easy 60 or 120 fps.
> I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform.
Name a few, please. And when you look into those "performant UIs", you'll see on or more of:
- skipping the DOM entirely and building everything on top of canvas or webgl
- going through great pains to: avoid mutating DOM, avoid repaint/reflow (which can happen by simply querying the DOM [1]), reducing the already laughably small amount of updates even further to prevent DOM updates, layout thrashing, JS GC pauses etc. etc.
And this will still not come even close to, lets say, displaying a million objects on screen at 120fps (any modern game engine), or any significantly complex UI layout (any professional app).
[1] https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a