6 ms·

> The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I

by chucky 6y ago

> The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.” 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. I don't even understand what he tries to say with "draw the control directly". In component-based library, this is exactly how you would work. Put your component where it needs to be, and boom, you're finished (just like in all frameworks this is a lie, you probably still need to tweak). 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.

iovrthoughtthis 6y ago
Yeah, the whole of the bottom of the post strikes me as off base. I think the author is trying to get to a wonderful future but their heading in totally the wrong direction.
dmitriid 6y ago
> 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 https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a
- iovrthoughtthis 6y ago
  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.
  - dmitriid 6y ago
    > 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.
  - lasagnaphil 6y ago
    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)
- fctorial 6y ago
  > In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. HTML5 canvas?
  - 6y ago
simion314 6y ago
Let me give you an example, the DOM is missing a decent dropdown component. Some will say that they can make a cool dropdown in 2 minutes with 20 divs and some js and css, the issue is this 2 minutes components have lot of bugs and missing features (accessibility, keyboard supports, missing events) and then if you need the same dropdown in other section but you need to add 1 small thing you duplicate it again. For comparison in GUI toolkits you use the existing feature complete dropdown. And if you need more customization you extend the dropdown and override it's render/paint function and you can painted as you want. What I liked about this powerfull GUI toolits is that most of the time you used the built in stuff so all application look consistent and only special apps would create custom stuff. I wish browser makers would focus on improving the existing DOM elements and adding a few more so we could use native ones instead of having to implement custom shit because the designer wants the component to look in a specific way but you can't CSS the native element to get the result.
- ta34545734 6y ago
  > Some will say that they can make a cool dropdown in 2 minutes with 20 divs and some js and css Isn't there already JS libraries to do that? If so, doesn't it boil down to the same issue as traditional OO UI toolkit, where the abstraction must be extremely precise to allow for any sort of customization? > For comparison in GUI toolkits you use the existing feature complete dropdown. Aren't you making the assumption here that GUI toolkits necessarily bundle a perfect implementation of this widget? Why would that be only possible for native GUI and not for Web UI?
  - simion314 6y ago
    The problem with existing libraries that give you a dropdown is that you have not one but many such libraries and some will not be compatible with what your project uses, some are missing the feature you need, some are bugged. As an example the Search input in YouTube has a dropdown with suggestion, that dropdown got stuck on for me a few times , clicking outside it did not make it hidden, I had to reload the page. So google developers are incapable of creating a basic dropdown that has the feature where you can type and shows you some options. If there was a built in powerful enough dropdown then YouTube could have used that and not invent it's own broken version. My point is give us native components as powerful as Qt,Flex,WPF , React, Agnular and others could use those or if they want can use DIVs or canvas , I don't want to remove you the option to use React or whatever. The existing toolkits are not as limited as you think because you can most of the time override them and do whatever change you want , most of the time though you have enough built in customization that you don't need to do advanced overrides (I do not mean only visual customization, for example a dropdown can give you the option on how many items would be visible on the dropdown at once, a DataGrid can give you option about what columns are resizable, sortable and you can specify if you want a sort function for a column. And about DataGridView components, the native ones are implemented smart and can hold a million rows and have no performance hit because are smart enough not to create million GUI elements. >Aren't you making the assumption here that GUI toolkits necessarily bundle a perfect implementation of this widget? Why would that be only possible for native GUI and not for Web UI? Desktop toolkits are not perfect so if your designer asks you for super extra fancy stuff you can either extend and existing one or you can create it from scratch but for visual stuff just changing the paint/render function would be enough. For WebUI, let's say I need a good dropdown, calendar, and DataGrid where do I go and get this components? If you say bootstrap those are too basic, if you say some React stuff maybe I am not suing react, if you link me to some Angular version N stuff maybe I am using N-1 version etc. I think if you ask 3 developers to go and find me an X component for my framework Y I would get back at least 3 different results. Other issue with non native components is that if you do not read the code you might not notice bad quality, components that do not clean after themselves or that run code each time you move your mouse around the page.
jcelerier 6y ago
> Lots of great and performant UIs have been built on the web platform. still waiting to see them, at least for performance levels comparable to 2007 desktop apps
deleted 6y ago
[deleted]
oblio 6y ago
With the DOM, can you extend the default text input component while keeping the default behaviors, like when inheriting/subclassing a component for normal GUI toolkits? For example accessibility. Also, does the DOM have a ListView/TreeView?
AnIdiotOnTheNet 6y ago
> Lots of great and performant UIs have been built on the web platform. This must be some strange usage of the word 'performant' I wasn't previously aware of.
millerm 6y ago
I will just say I agree in my own words "the DOM sucks for user interface development". I don't know why people are always so quick to defend it, or insist on being ardent apologists for it. It's a crap foundation for what we've been building on it for decades. It was never intended for this. Yes, I am forced to use is, as we all are. But, I tell you, I miss Swing and actual GUI component libraries that were designed, and implemented, from the ground up to be used as GUI. I could rant until the end of my career for this mistake of a path we all took in the 90s. HTML/Hypertext was a game changer. But, bastardizing this implementation into what we have to deal with today was a total and utter mistake.
- mtrovo 6y ago
  Could you give some examples of what are the problems with DOM and how do alternatives look like? It's been some years that I don't do anything web so I'm not sure if I'm familiar with its problems.
- dathinab 6y ago
  I wouldn't say it's a crap foundation but it's the wrong foundation. DOM, CSS and the way they interact with JS where designed for mostly immutable "documents" with mostly but to complex design. Then it was bend and extended to somewhat extend somewhat more complex designs and more interaction. That step was repeated again and again until now where is used for application graphical user interface instead of just displaying documents with some forms in them. The foundation is fundamentally unsuited for the task it's used for by now. CSS might seem simple but has crazy amounts of hidden complexity and until recently lacked trivial/simple ways to do some layouts common for GUIs but unnecessary (and bad) for displaying documents. In recent years thinks have gotten better, e.g. CSS grid makes GUI layouts SO much simpler, but still the foundation is broken. As consequence many of the promises the foundation gives are in practice often broken, too (like accessibility, like free resizing and zooming which often doesn't work correct, like cross platform as web apps are often designed for chrome relying accidentally on chrome specific behavior especially wrt. CORS, ...)
MaxBarraclough 6y ago
> Lots of great and performant UIs have been built on the web platform. At the risk of simply mirroring dmitriid's comment, and without wishing to come across as snarky: which ones? I don't think I've ever seen an Electron app that couldn't have been implemented in C++ to run appreciably faster and use at most a quarter of the memory.
deleted 6y ago
[deleted]

by chucky 6y ago

iovrthoughtthis 6y ago

Yeah, the whole of the bottom of the post strikes me as off base. I think the author is trying to get to a wonderful future but their heading in totally the wrong direction.

dmitriid 6y ago

> 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 https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a

iovrthoughtthis 6y ago
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.
- dmitriid 6y ago
  > 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.
- lasagnaphil 6y ago
  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)
fctorial 6y ago
> In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. HTML5 canvas?
- 6y ago

simion314 6y ago

Let me give you an example, the DOM is missing a decent dropdown component. Some will say that they can make a cool dropdown in 2 minutes with 20 divs and some js and css, the issue is this 2 minutes components have lot of bugs and missing features (accessibility, keyboard supports, missing events) and then if you need the same dropdown in other section but you need to add 1 small thing you duplicate it again. For comparison in GUI toolkits you use the existing feature complete dropdown. And if you need more customization you extend the dropdown and override it's render/paint function and you can painted as you want. What I liked about this powerfull GUI toolits is that most of the time you used the built in stuff so all application look consistent and only special apps would create custom stuff. I wish browser makers would focus on improving the existing DOM elements and adding a few more so we could use native ones instead of having to implement custom shit because the designer wants the component to look in a specific way but you can't CSS the native element to get the result.

ta34545734 6y ago
> Some will say that they can make a cool dropdown in 2 minutes with 20 divs and some js and css Isn't there already JS libraries to do that? If so, doesn't it boil down to the same issue as traditional OO UI toolkit, where the abstraction must be extremely precise to allow for any sort of customization? > For comparison in GUI toolkits you use the existing feature complete dropdown. Aren't you making the assumption here that GUI toolkits necessarily bundle a perfect implementation of this widget? Why would that be only possible for native GUI and not for Web UI?
- simion314 6y ago
  The problem with existing libraries that give you a dropdown is that you have not one but many such libraries and some will not be compatible with what your project uses, some are missing the feature you need, some are bugged. As an example the Search input in YouTube has a dropdown with suggestion, that dropdown got stuck on for me a few times , clicking outside it did not make it hidden, I had to reload the page. So google developers are incapable of creating a basic dropdown that has the feature where you can type and shows you some options. If there was a built in powerful enough dropdown then YouTube could have used that and not invent it's own broken version. My point is give us native components as powerful as Qt,Flex,WPF , React, Agnular and others could use those or if they want can use DIVs or canvas , I don't want to remove you the option to use React or whatever. The existing toolkits are not as limited as you think because you can most of the time override them and do whatever change you want , most of the time though you have enough built in customization that you don't need to do advanced overrides (I do not mean only visual customization, for example a dropdown can give you the option on how many items would be visible on the dropdown at once, a DataGrid can give you option about what columns are resizable, sortable and you can specify if you want a sort function for a column. And about DataGridView components, the native ones are implemented smart and can hold a million rows and have no performance hit because are smart enough not to create million GUI elements. >Aren't you making the assumption here that GUI toolkits necessarily bundle a perfect implementation of this widget? Why would that be only possible for native GUI and not for Web UI? Desktop toolkits are not perfect so if your designer asks you for super extra fancy stuff you can either extend and existing one or you can create it from scratch but for visual stuff just changing the paint/render function would be enough. For WebUI, let's say I need a good dropdown, calendar, and DataGrid where do I go and get this components? If you say bootstrap those are too basic, if you say some React stuff maybe I am not suing react, if you link me to some Angular version N stuff maybe I am using N-1 version etc. I think if you ask 3 developers to go and find me an X component for my framework Y I would get back at least 3 different results. Other issue with non native components is that if you do not read the code you might not notice bad quality, components that do not clean after themselves or that run code each time you move your mouse around the page.

jcelerier 6y ago

> Lots of great and performant UIs have been built on the web platform. still waiting to see them, at least for performance levels comparable to 2007 desktop apps

deleted 6y ago

[deleted]

oblio 6y ago

With the DOM, can you extend the default text input component while keeping the default behaviors, like when inheriting/subclassing a component for normal GUI toolkits? For example accessibility. Also, does the DOM have a ListView/TreeView?

AnIdiotOnTheNet 6y ago

> Lots of great and performant UIs have been built on the web platform. This must be some strange usage of the word 'performant' I wasn't previously aware of.

millerm 6y ago

I will just say I agree in my own words "the DOM sucks for user interface development". I don't know why people are always so quick to defend it, or insist on being ardent apologists for it. It's a crap foundation for what we've been building on it for decades. It was never intended for this. Yes, I am forced to use is, as we all are. But, I tell you, I miss Swing and actual GUI component libraries that were designed, and implemented, from the ground up to be used as GUI. I could rant until the end of my career for this mistake of a path we all took in the 90s. HTML/Hypertext was a game changer. But, bastardizing this implementation into what we have to deal with today was a total and utter mistake.

mtrovo 6y ago
Could you give some examples of what are the problems with DOM and how do alternatives look like? It's been some years that I don't do anything web so I'm not sure if I'm familiar with its problems.
dathinab 6y ago
I wouldn't say it's a crap foundation but it's the wrong foundation. DOM, CSS and the way they interact with JS where designed for mostly immutable "documents" with mostly but to complex design. Then it was bend and extended to somewhat extend somewhat more complex designs and more interaction. That step was repeated again and again until now where is used for application graphical user interface instead of just displaying documents with some forms in them. The foundation is fundamentally unsuited for the task it's used for by now. CSS might seem simple but has crazy amounts of hidden complexity and until recently lacked trivial/simple ways to do some layouts common for GUIs but unnecessary (and bad) for displaying documents. In recent years thinks have gotten better, e.g. CSS grid makes GUI layouts SO much simpler, but still the foundation is broken. As consequence many of the promises the foundation gives are in practice often broken, too (like accessibility, like free resizing and zooming which often doesn't work correct, like cross platform as web apps are often designed for chrome relying accidentally on chrome specific behavior especially wrt. CORS, ...)

MaxBarraclough 6y ago

> Lots of great and performant UIs have been built on the web platform. At the risk of simply mirroring dmitriid's comment, and without wishing to come across as snarky: which ones? I don't think I've ever seen an Electron app that couldn't have been implemented in C++ to run appreciably faster and use at most a quarter of the memory.

deleted 6y ago

[deleted]