5 ms·

>I hate DOM manipulations in the browser What exactly is so difficult about DOM manipulation? I honestly don't get why people see it as a problem that warrants

>I hate DOM manipulations in the browser What exactly is so difficult about DOM manipulation? I honestly don't get why people see it as a problem that warrants zillion badly written frameworks, while other critical language issues are pretty much ignored.

thrower123 8y ago
I think it's a hangover from ten years ago when it actually was a huge pain in the ass to do DOM stuff without jQuery.
IggleSniggle 8y ago
What’s difficult isn’t the DOM itself, it’s that you thread in and out of the DOM with a changing DOM state and with multiple people writing application code. Many of the frameworks / packagers exist to help tame the context switching, since in frontend land you might have business logic that is dependent on a CSS class that may or may not be present at any given moment and might be modified by some other piece of logic. Everything in the DOM is basically a global variable, and any part of the app might manipulate any part of the DOM. Example: Someone wrote CSS that is coupled to a child element (which seemed the clearest way to write it at the time) and someone else comes along to edit the content of the HTML which adds a layer and now your logic is broken even if the CSS still looks right. The frameworks make it easier to avoid that kind of fragile coupling / enforce a consistent way to manage the interaction of JS, CSS, and HTML. All that said, web applications really are an entirely different beast than websites, even if they exist on a spectrum.
- lostcolony 8y ago
  Yep. In any shared development context (or even solo but trying to ensure proper containment of component structure, logic, and design rather than just one ugly hodgepodge), there is no good solution without a framework. And because literally everyone runs into that problem, everyone has created their own framework, which is why there's so many of them. But none of that is an issue on the backend, where there's no DOM considerations. No HTML or CSS either. Just Javascript. And there it's straightforward, succinct, and usually easily understood (usual caveat of bad developers, but compare average Node codebases with average Java codebases).

thrower123 8y ago

I think it's a hangover from ten years ago when it actually was a huge pain in the ass to do DOM stuff without jQuery.

IggleSniggle 8y ago

What’s difficult isn’t the DOM itself, it’s that you thread in and out of the DOM with a changing DOM state and with multiple people writing application code. Many of the frameworks / packagers exist to help tame the context switching, since in frontend land you might have business logic that is dependent on a CSS class that may or may not be present at any given moment and might be modified by some other piece of logic. Everything in the DOM is basically a global variable, and any part of the app might manipulate any part of the DOM. Example: Someone wrote CSS that is coupled to a child element (which seemed the clearest way to write it at the time) and someone else comes along to edit the content of the HTML which adds a layer and now your logic is broken even if the CSS still looks right. The frameworks make it easier to avoid that kind of fragile coupling / enforce a consistent way to manage the interaction of JS, CSS, and HTML. All that said, web applications really are an entirely different beast than websites, even if they exist on a spectrum.

lostcolony 8y ago
Yep. In any shared development context (or even solo but trying to ensure proper containment of component structure, logic, and design rather than just one ugly hodgepodge), there is no good solution without a framework. And because literally everyone runs into that problem, everyone has created their own framework, which is why there's so many of them. But none of that is an issue on the backend, where there's no DOM considerations. No HTML or CSS either. Just Javascript. And there it's straightforward, succinct, and usually easily understood (usual caveat of bad developers, but compare average Node codebases with average Java codebases).