> 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).
I don't think you're wrong just that the discussion warrant more nuance and less ego. On the the comment...
> You just draw it yourself.
This is disingenuous. It might be ok in Games not to have decent interop with the OS but for productivity tools, it is a requirement.
Which means you need to implement OS native interop (for multiple DE's in linux perhaps), accessibility for screen readers and you need to be smart with your rendering because having a function called 60+ times a second is a surprisingly big foot gun. All this across 2-3 very different (and currently diverging) operating systems.
> Which means you need to implement OS native interop (for multiple DE's in linux perhaps), accessibility for screen readers and you need to be smart with your rendering because having a function called 60+ times a second is a surprisingly big foot gun. All this across 2-3 very different (and currently diverging) operating systems.
Yes, you have to do all of that, and I never said it was an easy task. That is, it's relatively easy compared to the web. This task is close to impossible on the web, especially if you want decent performance.
Rendering something natively in OpenGL (or using a lightly-wrapped framework around it) is usually much more performant than fiddling with canvas elements or CSS, so I don’t think it’s a footgun. (And OpenGL is quite cross-platform if you stick with older versions.) And since browsers these days also have all sorts of incompatibility issues, the merit of “write JS once” seems to be dwindling a bit... (although that’s becoming less of a problem when Chrome is becoming the de-facto browser)
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