7 ms·

Where should I begin. I've been building for web for 10 years and the horrors I've seen... specifics... Well, before I go criticizing, I want to say that the we

by maga 10y ago

Where should I begin. I've been building for web for 10 years and the horrors I've seen... specifics... Well, before I go criticizing, I want to say that the web is in a far better place today than it was 10 or even 5 years ago, and nowadays I'm an ardent VanillaJS user that doesn't use jQuery or React/Angular (I do use a minimalistic in-house MVC with Incremental DOM though). Back to the question: Traversal: Historically we had 4 methods to get an element: by its id, name, tag, and class; yet there was no general method to get an element by value of its attributes until Selectors API brought querySelector. IMO it was one the most important things that pushed the community towards jQuery back in the day. Manipulation: Up until recently one couldn't remove an element without referencing its parent, that is, you have to use removeChildNode, or replace, or innerHTML, or other methods of the parent. Now they added .remove() that is only supported in the evergreen browsers. Replacing or inserting nodes operates on the same principles and is a hell of its own that makes people opt for re-generating nodes instead of shuffling the existing ones. Generation: For years now we have been relying on non-standard innerHTML for element generation because the only way DOM allows to do it is to create each element with createElement and then set attributes one by one. It's a ridiculously low level api considering our use cases. Hence, we got the whole templates/jsx movement today. Modularity: Ain't there. In order to truly "componentize" our apps we have to wait for something like Shadow DOM because there is no way to guaranty that one part of the page won't affect the other in today's DOM. All in all, DOM wasn't meant for what we are trying to use it today and for a long time it has been playing catch with browsers implementing ad-hoc solutions to new problems.

moron4hire 10y ago
A lot of what you're saying is about the history of DOM. You even admit that some of your complaints don't hold anymore, so I don't understand what is the point of holding on to them. And I don't think it follows that just because SGML wasn't designed for SPAs in 1986 that the browser infrastructure we have today is not good for applications. Von Neumann architecture computers weren't designed for playing MP3s, but somehow they manage to do it pretty well. Because I look at all the GUI toolkits out there (and in the last twenty years I've used a LOT of different ones), and none of them are idealistically "good". I don't see anything particularly special about other toolkits that makes DOM look particular bad. In fact, I tend to think of DOM as being pretty good in comparison, if only for the fact that it works on everything. "createElement and then set attributes one by one" is no different than any other toolkit. They pretty much all have a simple, static editor syntax for doing bulk element creation and attribute setting, and then a verbose API for dynamic element creation. It's low level because your use case is not the only use case it needs to support. I've seen--and built--a bunch of systems that have tried to simplify it and it always loses something in translation. So maybe you're complaint isn't with DOM. Maybe you just don't like user interface programming in general.
- maga 10y ago
  > A lot of what you're saying is about the history of DOM. That's because my whole point was to elaborate on the statement I made in the first comment: >The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM, People who were complaining about web dev and JS over the years were mostly doing it because of the browser APIs and DOM, hence my recollection of recent history. And of course I do point out what was fixed, and I said from the start that it's far better now than it was before. I'm rooting for VanillaJS after all. I cannot comment on other GUI toolkits since I don't work with them. You may be right that they too are low level, and I wholeheartedly you're right about DOM being better, because I hope DOM with Web Platform replaces them all one day. That doesn't exempt DOM from criticism though. Technically DOM still doesn't have API for bulk element creation since innerHTML/insertAjacent comes as a separate API which is still a working draft. But that's just details. There is another problem somewhat related to DOM being low level. Although it has to do with the browser implementations rather than the standard, it's still a problem for the end user, and the user is going to blame it on the web/JS being bad in general. That is performance. As it was mentioned here, DOM is separated from JS engine in browsers. Calls to DOM from JS are a lot more expensive than calls inside the engine. This gave rise to the whole Virtual DOM movement we see taking over the web dev. It's not just the verbosity of low level DOM that pushes people towards React and such, but the fact that at the end of the day their approach of mimicking DOM in the engine and limiting the DOM calls turns out to be more performant that the low level manipulations we do directly on the DOM.
  - moron4hire 10y ago
    That is incorrect. React is faster than destroying the document and rebuilding it from scratch on every day's change. It is slower than making your own stateful edits.
    - maga 10y ago
      True, but the culprit is still DOM calls being expensive. Virtual DOM minimizes those calls through various optimizations, including not destroying elements unnecessarily as you said, but it's not limited to it. Consider the following scenario. You have two handlers on an event that both change the DOM and may result in cancelling each other. With the "raw" DOM you'll end up calling DOM at least twice (and changing it twice if no debouncing is used), whereas Virtual DOM both times calls to, well, its "virtual" DOM (which is a lot cheaper) and by the time it gets to its next cycle of updating the "real" DOM it may not need to change anything or do it once. These optimizations are hard to implement without resorting to a virtual DOM of one sort or another.
the_duke 10y ago
> Up until recently one couldn't remove an element without referencing its parent Every node has a reference to it's parent. What's the problem with node.parentElement.removeChild(node)?
- maga 10y ago
  > What's the problem with node.parentElement.removeChild(node)? Being counter-intuitive and verbose. It's but one example of such peculiarities that makes DOM hard to grasp for beginners.
- bzbarsky 10y ago
  > What's the problem with node.parentElement.removeChild(node)? It's node.parentNode.removeChild(node). And the fact that this is even a mistake that can be made, and is made by people all the timem is part of the problem! "node.remove()" is a lot harder to screw up.

by maga 10y ago

moron4hire 10y ago

A lot of what you're saying is about the history of DOM. You even admit that some of your complaints don't hold anymore, so I don't understand what is the point of holding on to them. And I don't think it follows that just because SGML wasn't designed for SPAs in 1986 that the browser infrastructure we have today is not good for applications. Von Neumann architecture computers weren't designed for playing MP3s, but somehow they manage to do it pretty well. Because I look at all the GUI toolkits out there (and in the last twenty years I've used a LOT of different ones), and none of them are idealistically "good". I don't see anything particularly special about other toolkits that makes DOM look particular bad. In fact, I tend to think of DOM as being pretty good in comparison, if only for the fact that it works on everything. "createElement and then set attributes one by one" is no different than any other toolkit. They pretty much all have a simple, static editor syntax for doing bulk element creation and attribute setting, and then a verbose API for dynamic element creation. It's low level because your use case is not the only use case it needs to support. I've seen--and built--a bunch of systems that have tried to simplify it and it always loses something in translation. So maybe you're complaint isn't with DOM. Maybe you just don't like user interface programming in general.

maga 10y ago
> A lot of what you're saying is about the history of DOM. That's because my whole point was to elaborate on the statement I made in the first comment: >The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM, People who were complaining about web dev and JS over the years were mostly doing it because of the browser APIs and DOM, hence my recollection of recent history. And of course I do point out what was fixed, and I said from the start that it's far better now than it was before. I'm rooting for VanillaJS after all. I cannot comment on other GUI toolkits since I don't work with them. You may be right that they too are low level, and I wholeheartedly you're right about DOM being better, because I hope DOM with Web Platform replaces them all one day. That doesn't exempt DOM from criticism though. Technically DOM still doesn't have API for bulk element creation since innerHTML/insertAjacent comes as a separate API which is still a working draft. But that's just details. There is another problem somewhat related to DOM being low level. Although it has to do with the browser implementations rather than the standard, it's still a problem for the end user, and the user is going to blame it on the web/JS being bad in general. That is performance. As it was mentioned here, DOM is separated from JS engine in browsers. Calls to DOM from JS are a lot more expensive than calls inside the engine. This gave rise to the whole Virtual DOM movement we see taking over the web dev. It's not just the verbosity of low level DOM that pushes people towards React and such, but the fact that at the end of the day their approach of mimicking DOM in the engine and limiting the DOM calls turns out to be more performant that the low level manipulations we do directly on the DOM.
- moron4hire 10y ago
  That is incorrect. React is faster than destroying the document and rebuilding it from scratch on every day's change. It is slower than making your own stateful edits.
  - maga 10y ago
    True, but the culprit is still DOM calls being expensive. Virtual DOM minimizes those calls through various optimizations, including not destroying elements unnecessarily as you said, but it's not limited to it. Consider the following scenario. You have two handlers on an event that both change the DOM and may result in cancelling each other. With the "raw" DOM you'll end up calling DOM at least twice (and changing it twice if no debouncing is used), whereas Virtual DOM both times calls to, well, its "virtual" DOM (which is a lot cheaper) and by the time it gets to its next cycle of updating the "real" DOM it may not need to change anything or do it once. These optimizations are hard to implement without resorting to a virtual DOM of one sort or another.

the_duke 10y ago

> Up until recently one couldn't remove an element without referencing its parent Every node has a reference to it's parent. What's the problem with node.parentElement.removeChild(node)?

maga 10y ago
> What's the problem with node.parentElement.removeChild(node)? Being counter-intuitive and verbose. It's but one example of such peculiarities that makes DOM hard to grasp for beginners.
bzbarsky 10y ago
> What's the problem with node.parentElement.removeChild(node)? It's node.parentNode.removeChild(node). And the fact that this is even a mistake that can be made, and is made by people all the timem is part of the problem! "node.remove()" is a lot harder to screw up.