Here is a summary of the standard DOM for mere mortals:
https://prettydiff.com/2/guide/unrelated_dom.xhtml
> What GP is advising against is doing direct manipulations on the DOM outside of an application's normal control flow.
I have been doing this work long enough to see all manners of excuses and justifications. It is amazing how they change over time, but at any given time they are wonderfully uniform centering on the most popular understanding of the technology at the time. They are all unoriginal clichés that people mindlessly echo.
The excuses that stuck with me over the years:
* Its too hard. You cant do it without jQuery.
* It has to be further abstracted. Without the necessary abstractions you are essentially working in assembly code. (JavaScript is never close to assembly).
* You are reinventing the wheel (never mind that frameworks do that frameworks reinvent the wheel)
* You have to maintain state and you cannot do that without a framework. (unit test your code)
* If you don't use a framework you will end up writing a framework anyways.
---
In the end all the stupidity comes down to behavior. Developers don't trust the technology, don't trust their management, and especially don't trust each other or themselves to get it right. This behavior is called invented here syndrome and it isn't limited to the dom, the web, or even software. I frequently speak with lawyers and medical professionals who are frequently forced to mitigate this very same set of stupidity.
The cure for this foolishness is:
* Don't hire incompetent people, which are people lacking the proper desire and potential.
* Train your people. This technology isn't hard.
* Have the proper test automation in place.
* Have strong leadership in place. It is only a matter of time before people get frustrated or desperate and differ to really bad decisions. Bad decisions aren't limited to stupid people. Strong leaders are capable of withstanding the tired pleadings and big tears. Bad decisions are almost universally motivated by a perception of convenience without regard for risks or future expense, the easy versus simple paradigm.
Of course most organizations aren't willing to invest in any of this and would rather push the debt out to be a future failure for somebody else.
What GP is advising against is doing direct manipulations on the DOM outside of an application's normal control flow. That has nothing to do with being afraid of the DOM, it has to do with grouping your update logic into one place so that you can avoid spaghetti code, state-dependent updates, and XSS attacks. When people talk about direct DOM access, this is often what they're referring to -- developers who think, "I need to change the color of this button. I know, I'll just set it directly in this random method so it only works in this very narrow code path."
I haven't used JQuery on a single personal project in at least 3 or 4 years, possibly longer. But even though I'm usually using the JS APIs directly, I'm still pushing all of my logic through a single render function instead of willy-nilly updating input labels in 5 different functions. Forcing rendering to go through an optimized chokepoint is just good architecture -- I'd use the same pattern even if I was working with Windows Forms or OpenGL.
My advice would be that if you're surrounded by people who are frightened of working with the DOM without JQuery, then find better developers to hang out with. Because in my experience that's not typical, and I very rarely run into developers with that perspective. Certainly I don't think it's the consensus on HN.