7 ms·

I would really like to know specifics on your criticism of DOM. I've seen a lot of people complain about DOM over the years, but I've never heard anything speci

I would really like to know specifics on your criticism of DOM. I've seen a lot of people complain about DOM over the years, but I've never heard anything specific.

mememachine 10y ago
I think having it be entirely separated from JS was a mistake. A lot of the web is Apps not documents and the separation is often much more of a hindrance than a help. Obviously it can be nice for organization, but that should really fall more on the individual to decide than the spec.
- moron4hire 10y ago
  In what way do you consider DOM separate from JS such that it causes difficulty for application development?
  - mememachine 10y ago
    Take the entire usecase for ReactJS as my example
    - moron4hire 10y ago
      Seeing as I don't see the need to use React, I also don't see your point.
      - mememachine 10y ago
        Do you see the need for the C language? They both make life significantly easier
        moron4hire 10y ago
        To draw a comparison between JS and assembly is to seriously misunderstand both.
        mememachine 10y ago
        i think you are certainly taking my comparison in some way i did not mean, because i see no misunderstanding...
    - SadWebDeveloper 10y ago
      Not everyone is developing SPA's nor working with the same constrains that facebook has (optimized incremental changes to UI). This new trend of making everything in JS for JS by JS Developers is crippling the web ability to display the dynamic information as a document and forced the creation of standards (AMP) to preserve the real legacy of the web.
      - mememachine 10y ago
        The DOM is a subset of React
        SadWebDeveloper 10y ago
        The DOM is _abstracted_ by React not a subset of React. If you can't see the difference between subset and abstract you are either new on the web development scene or just another die-hard fan of JS development.
        mememachine 10y ago
        You can write any and all DOM in react, that is the definition of subset. your ad hominem is pathetic, and i hope the moderators take action on my report.
kruhft 10y ago
The DOM is nice, it's the CSS I could do without.
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.
deleted 10y ago
[deleted]

I would really like to know specifics on your criticism of DOM. I've seen a lot of people complain about DOM over the years, but I've never heard anything specific.

mememachine 10y ago

I think having it be entirely separated from JS was a mistake. A lot of the web is Apps not documents and the separation is often much more of a hindrance than a help. Obviously it can be nice for organization, but that should really fall more on the individual to decide than the spec.

moron4hire 10y ago
In what way do you consider DOM separate from JS such that it causes difficulty for application development?
- mememachine 10y ago
  Take the entire usecase for ReactJS as my example
  - moron4hire 10y ago
    Seeing as I don't see the need to use React, I also don't see your point.
    - mememachine 10y ago
      Do you see the need for the C language? They both make life significantly easier
      - moron4hire 10y ago
        To draw a comparison between JS and assembly is to seriously misunderstand both.
        mememachine 10y ago
        i think you are certainly taking my comparison in some way i did not mean, because i see no misunderstanding...
  - SadWebDeveloper 10y ago
    Not everyone is developing SPA's nor working with the same constrains that facebook has (optimized incremental changes to UI). This new trend of making everything in JS for JS by JS Developers is crippling the web ability to display the dynamic information as a document and forced the creation of standards (AMP) to preserve the real legacy of the web.
    - mememachine 10y ago
      The DOM is a subset of React
      - SadWebDeveloper 10y ago
        The DOM is _abstracted_ by React not a subset of React. If you can't see the difference between subset and abstract you are either new on the web development scene or just another die-hard fan of JS development.
        mememachine 10y ago
        You can write any and all DOM in react, that is the definition of subset. your ad hominem is pathetic, and i hope the moderators take action on my report.

kruhft 10y ago

The DOM is nice, it's the CSS I could do without.

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.

deleted 10y ago

[deleted]