4 ms·

HTML was originally envisioned as something extremely user-friendly to let people and companies customize their online presence. Nowadays multiple professional

by a1371 5y ago

HTML was originally envisioned as something extremely user-friendly to let people and companies customize their online presence. Nowadays multiple professional roles and software stacks are between the content and its HTML representation. It tells us something, but also regularly what's easy looks hard. I have organized some hackathons and coding events for students. Some start with create-react-app for showing an image. They are very hesitant to do things the "manual" way when I suggest it. I think it's awesome that vanilla gets to have a community like this.

austincheney 5y ago
Then they invented the DOM. I love the DOM but most developers would rather jump off a bridge than write some logic to walk a DOM. I have never understood why there is so much fear about the DOM, why that fear is so astonishingly prevalent, or the extremes people will go to in order to sidestep this phobia. So curious because this is a subject that takes about 2 hours to learn after which your career takes a different trajectory.
- jerf 5y ago
  The DOM has double impedance mismatch written into its most basic foundations. It's an object oriented API to something that functional programming is much better for (functional programming loves manipulating trees recursively). And then, you're using Javascript to program it, a dynamic scripting language, but the DOM spec is heavily biased towards static C++ or Java, thus it simultaneously fails to take good advantage of the opportunities a dynamic language offers while also importing the verbosity and hoop jumping of 1990s statically-typed programming... and statically-typed programming has come a long way since then! You can see this most clearly in DOM 1.0: https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-on... Look particularly at the "IDL specifications". That's Java, not Javascript! Later versions have improved various elements of this, but the fundamental architecture is still there and still not looking much like what I would write down if I wanted to write out a similar system natively for Javascript, assuming this was still the 1990s and that meant I could also modify JS itself a bit. When you learn how to work around these impedance mismatches you can do some good work, but the resulting code may not make much sense to your coworker. Fortunately, even in native JS nowadays, .querySelector and similar APIs make it unnecessary to have to "walk" the DOM much anymore. I'd even argue you could cite the existence of a triple mismatch, in that the original DOM level 0, supported in Netscape 2.0, entirely precedes the idea of a writable DOM. (It wasn't until Netscape 4 that we got "layers", which were useless, and it was IE 4 that finally gave us manipulable DOMs as we know them today. [1]) So the standard that was originally written with the concept of introspection and largely read-only access (you could only write things that the browser could guarantee wouldn't require a reflow, and not necessarily all of those) got a lot of write access bodge onto it later. Historically, it's a huge mess. [1]: They didn't necessarily work the way we expect today for much longer than that, I crashed IE 4 a lot with stuff we'd consider trivial today, but it was the first browser to at least try presenting everything in the DOM as editable.
  - austincheney 5y ago
    It sounds like you are looking at anything you can find, grasping at straws, to rationalize insanity. So much of what you described is absent in the Level 2 and Level 3 specifications. This is clear when your reasoning only makes sense using a 23 year old expired snapshot for an evolving technology that remains the backbone of frontend technology today. * https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ * https://www.w3.org/TR/DOM-Level-3-Core/ https://www.w3.org/TR/DOM-Level-3-Core/ The DOM is a language agnostic API written without any particular programming languages in mind and written to simultaneously and universally support both HTML and XML Schema. These are stylistic and organizational concerns still not enough to qualify the irrational behaviors favoring jumping off a bridge. This is concerning considering learning to use the concepts takes substantially less time than learning the APIs of modern JavaScript frameworks developers favor. There remains far more to this that is psychologically focused regardless of any technology.
    - jerf 5y ago
      Technologies maintaining reverse compatibility always contain echos of their beginnings. History matters. We still live with those wrong foundations chosen at the beginning. But if you just want to blame almost all developers everywhere across several decades for mysteriously being unwilling to engage with a simple and wonderful technology that has no flaws, feel free. It's easy, but it leads to no further understanding or wisdom.
      - austincheney 5y ago
        Blaming the technology is not sufficient to explain the behavior. Ignoring that and putting your head in the sand isn’t an indicator of wisdom. http://www.fallacyfiles.org/bandwagn.html http://www.fallacyfiles.org/bandwagn.html
- graderjs 5y ago
  No stress document.createTreeWalker() is your steadfast friend
- robertlagrant 5y ago
  Walking the DOM is a problem because if (or when) its structure changes, everything breaks. Also, "astonishingly prevalent"? Come on!
  - austincheney 5y ago
    Then your code is too tightly coupled to an instance without you writing error handling or any kind of fallback. That kind of fragility is not limited to the DOM and can occur in any programming.
    - robertlagrant 5y ago
      This is not a problem that can be fixed by error handling. It's just best avoided if an application developer is altering the DOM at will. The DOM is not a good, stable API.
      - austincheney 5y ago
        Yes, it’s tight coupling and it can be fixed by writing better code. The DOM API has maintained full backwards compatibility for its 25 year history of massive evolution so it’s extremely stable. That stability is completely orthogonal to the incompetence of the developer using it though. My daughter doesn’t like driving my manual transmission car and cannot figure it out. That doesn’t mean my car has an unstable API. She does mention the same sort of bullshit about blaming the technology for her own incompetence though.
        robertlagrant 5y ago
        I'm not talking about the DOM API. I'm talking about writing code that relies on a certain DOM structure - i.e. misusing that structure as an API format when it wasn't intended for that, and any changes made to it would not bear that in mind.
- mediumdeviation 5y ago
  Other than the historic messiness the other comment raised, the DOM API is just... not good. I don't think it's surprising developers don't want to bother with fun stuff such as - The only way to remove a node is node.parentNode.removeChild(node), until you get past IE11 then you can use Element.remove() https://developer.mozilla.org/en-US/docs/Web/API/Element/remove https://developer.mozilla.org/en-US/docs/Web/API/Element/rem... - Text node normalization - because there are separate representation of the exact same HTML https://developer.mozilla.org/en-US/docs/Web/API/Node/normalize https://developer.mozilla.org/en-US/docs/Web/API/Node/normal... - NodeLists are almost but not quite arrays. They could also be live or static but you can't inspect it directly to tell which is which https://developer.mozilla.org/en-US/docs/Web/API/NodeList https://developer.mozilla.org/en-US/docs/Web/API/NodeList. Similar almost-array nonsense with HTMLCollection. - Historically IE and Netscape/Firefox supported two completely different set of API and it was a horrible mess. You can still see remnants of that API war in functions that does almost but not quite the same things such as textContent vs. innerText https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent#differences_from_innertext https://developer.mozilla.org/en-US/docs/Web/API/Node/textCo...,
  - austincheney 5y ago
    Maybe arguments of IE insanity were once vaguely qualified because it took an extra step of testing and learning, a straw that breaks a camels back. IE is dead now, years past sunset and about to be eliminated in June 2022, so these arguments no longer apply. The fear and insanity remain nonetheless.
    - Zababa 5y ago
      Years past sunset? At work we have customers that use IE every day. These arguments certainly still apply, especially since IE isn't even EOL yet.
      - austincheney 5y ago
        MS sunset IE in November of 2018. Security maintenance ends in June at which point IE will become a security threat and remains a core OS component (according to MS). At any point after MS can forcefully remove IE with a patch.
tannhaeuser 5y ago
Then they invented CSS ;) When SGML, on which HTML is based, has all the customizing, organization, vocabulary extension, and authoring comfort features you could ever want, even stylesheets. Think about it - you have a content model grammar with type-checked item-value pairs (attributes); then CSS comes along with a completely separate, not type-checked item-value syntax and value space that make even seasoned graphic professionals run away.

by a1371 5y ago

austincheney 5y ago

Then they invented the DOM. I love the DOM but most developers would rather jump off a bridge than write some logic to walk a DOM. I have never understood why there is so much fear about the DOM, why that fear is so astonishingly prevalent, or the extremes people will go to in order to sidestep this phobia. So curious because this is a subject that takes about 2 hours to learn after which your career takes a different trajectory.

jerf 5y ago
The DOM has double impedance mismatch written into its most basic foundations. It's an object oriented API to something that functional programming is much better for (functional programming loves manipulating trees recursively). And then, you're using Javascript to program it, a dynamic scripting language, but the DOM spec is heavily biased towards static C++ or Java, thus it simultaneously fails to take good advantage of the opportunities a dynamic language offers while also importing the verbosity and hoop jumping of 1990s statically-typed programming... and statically-typed programming has come a long way since then! You can see this most clearly in DOM 1.0: https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-on... Look particularly at the "IDL specifications". That's Java, not Javascript! Later versions have improved various elements of this, but the fundamental architecture is still there and still not looking much like what I would write down if I wanted to write out a similar system natively for Javascript, assuming this was still the 1990s and that meant I could also modify JS itself a bit. When you learn how to work around these impedance mismatches you can do some good work, but the resulting code may not make much sense to your coworker. Fortunately, even in native JS nowadays, .querySelector and similar APIs make it unnecessary to have to "walk" the DOM much anymore. I'd even argue you could cite the existence of a triple mismatch, in that the original DOM level 0, supported in Netscape 2.0, entirely precedes the idea of a writable DOM. (It wasn't until Netscape 4 that we got "layers", which were useless, and it was IE 4 that finally gave us manipulable DOMs as we know them today. [1]) So the standard that was originally written with the concept of introspection and largely read-only access (you could only write things that the browser could guarantee wouldn't require a reflow, and not necessarily all of those) got a lot of write access bodge onto it later. Historically, it's a huge mess. [1]: They didn't necessarily work the way we expect today for much longer than that, I crashed IE 4 a lot with stuff we'd consider trivial today, but it was the first browser to at least try presenting everything in the DOM as editable.
- austincheney 5y ago
  It sounds like you are looking at anything you can find, grasping at straws, to rationalize insanity. So much of what you described is absent in the Level 2 and Level 3 specifications. This is clear when your reasoning only makes sense using a 23 year old expired snapshot for an evolving technology that remains the backbone of frontend technology today. * https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ * https://www.w3.org/TR/DOM-Level-3-Core/ https://www.w3.org/TR/DOM-Level-3-Core/ The DOM is a language agnostic API written without any particular programming languages in mind and written to simultaneously and universally support both HTML and XML Schema. These are stylistic and organizational concerns still not enough to qualify the irrational behaviors favoring jumping off a bridge. This is concerning considering learning to use the concepts takes substantially less time than learning the APIs of modern JavaScript frameworks developers favor. There remains far more to this that is psychologically focused regardless of any technology.
  - jerf 5y ago
    Technologies maintaining reverse compatibility always contain echos of their beginnings. History matters. We still live with those wrong foundations chosen at the beginning. But if you just want to blame almost all developers everywhere across several decades for mysteriously being unwilling to engage with a simple and wonderful technology that has no flaws, feel free. It's easy, but it leads to no further understanding or wisdom.
    - austincheney 5y ago
      Blaming the technology is not sufficient to explain the behavior. Ignoring that and putting your head in the sand isn’t an indicator of wisdom. http://www.fallacyfiles.org/bandwagn.html http://www.fallacyfiles.org/bandwagn.html
graderjs 5y ago
No stress document.createTreeWalker() is your steadfast friend
robertlagrant 5y ago
Walking the DOM is a problem because if (or when) its structure changes, everything breaks. Also, "astonishingly prevalent"? Come on!
- austincheney 5y ago
  Then your code is too tightly coupled to an instance without you writing error handling or any kind of fallback. That kind of fragility is not limited to the DOM and can occur in any programming.
  - robertlagrant 5y ago
    This is not a problem that can be fixed by error handling. It's just best avoided if an application developer is altering the DOM at will. The DOM is not a good, stable API.
    - austincheney 5y ago
      Yes, it’s tight coupling and it can be fixed by writing better code. The DOM API has maintained full backwards compatibility for its 25 year history of massive evolution so it’s extremely stable. That stability is completely orthogonal to the incompetence of the developer using it though. My daughter doesn’t like driving my manual transmission car and cannot figure it out. That doesn’t mean my car has an unstable API. She does mention the same sort of bullshit about blaming the technology for her own incompetence though.
      - robertlagrant 5y ago
        I'm not talking about the DOM API. I'm talking about writing code that relies on a certain DOM structure - i.e. misusing that structure as an API format when it wasn't intended for that, and any changes made to it would not bear that in mind.
mediumdeviation 5y ago
Other than the historic messiness the other comment raised, the DOM API is just... not good. I don't think it's surprising developers don't want to bother with fun stuff such as - The only way to remove a node is node.parentNode.removeChild(node), until you get past IE11 then you can use Element.remove() https://developer.mozilla.org/en-US/docs/Web/API/Element/remove https://developer.mozilla.org/en-US/docs/Web/API/Element/rem... - Text node normalization - because there are separate representation of the exact same HTML https://developer.mozilla.org/en-US/docs/Web/API/Node/normalize https://developer.mozilla.org/en-US/docs/Web/API/Node/normal... - NodeLists are almost but not quite arrays. They could also be live or static but you can't inspect it directly to tell which is which https://developer.mozilla.org/en-US/docs/Web/API/NodeList https://developer.mozilla.org/en-US/docs/Web/API/NodeList. Similar almost-array nonsense with HTMLCollection. - Historically IE and Netscape/Firefox supported two completely different set of API and it was a horrible mess. You can still see remnants of that API war in functions that does almost but not quite the same things such as textContent vs. innerText https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent#differences_from_innertext https://developer.mozilla.org/en-US/docs/Web/API/Node/textCo...,
- austincheney 5y ago
  Maybe arguments of IE insanity were once vaguely qualified because it took an extra step of testing and learning, a straw that breaks a camels back. IE is dead now, years past sunset and about to be eliminated in June 2022, so these arguments no longer apply. The fear and insanity remain nonetheless.
  - Zababa 5y ago
    Years past sunset? At work we have customers that use IE every day. These arguments certainly still apply, especially since IE isn't even EOL yet.
    - austincheney 5y ago
      MS sunset IE in November of 2018. Security maintenance ends in June at which point IE will become a security threat and remains a core OS component (according to MS). At any point after MS can forcefully remove IE with a patch.

tannhaeuser 5y ago

Then they invented CSS ;) When SGML, on which HTML is based, has all the customizing, organization, vocabulary extension, and authoring comfort features you could ever want, even stylesheets. Think about it - you have a content model grammar with type-checked item-value pairs (attributes); then CSS comes along with a completely separate, not type-checked item-value syntax and value space that make even seasoned graphic professionals run away.