Why are front-end JS dev's so afraid of the DOM? It's not like she's got a whip!

Jokes aside, I'm not sure "afraid" is entirely right; though it does reek of that same paranoid fear of objects we see with long-time PHP developers who still refuse to use PDO or choose the pointless mysqli_ function wrappers. Perhaps just outright ignorance is more appropriate? I'm really asking because with a certain client I just dealt with a major XSS hole that was screwing them entirely because they were using jQuery's html() to slop markup -- including user defined values -- into the page.

As such whilst this is a legitimate question on my part, there's a good deal of venting thrown in.

Either way, I see very few developers out there who ACTUALLY use the DOM. When people talk about things like jQuery providing DOM manipulation tools I genuinely have ZERO HUFFING CLUE what they're talking about! Using a bloated wrapper for Element.queryAll to grab nodes or nodelists and then screwing around using (the outdated outmoded possibly insecure) innerHTML methodology to slop stuff into the page is NOT working with the DOM, and it sure as shine-ola isn't good practice. Same goes for the idiocy that is React when used client-side you see the same half-witted methodology only further pissing on the page by using string processed templates and exchanging full markup from server-side for AJAX style operations -- either passing more data over the connection than needed or making the client-side scripting five times larger and ten times slower than necessary.

... and it's not like jQuery doesn't provide append(), prepend(), before(), after() -- even text() -- but it seems like nobody ever uses them and instead insists on writing markup as strings and shoving them in with html() regardless of the middle finger to performance, battery life, or security!

What is it about document.createElement, Document.createTextNode , and walking the DOM that people find so intimidating? Is it "wah wah, eyes dun wants two haz two typez alls tat oot" laziness? Just plain ignorance?

Going directly to the DOM avoids so many headaches, is faster and uses less memory since it bypasses the parser, and is inherently more secure since if you are plugging in user data with createTextNode it is impossible to create a XSS exploit... so why don't people do that and instead insist on screwing around making massive nodelists for EVERYTHING, slop content in with innerHTML (or innerHTML-style 'markup in the scripting').

It's even more confusing when that approach just means shoving as much if not more data around than a bloody page-load would have if their markup wasn't bloated crap. I mean I know a lot of people have bought into the "pageloads are evil" LIE brought about by using 60-100k of markup to do 8-16k's job, 256-512k of CSS to do 12-32k of CSS' job, and the mind-numbingly idiotic megabytes of scripting where 90% of it likely doesn't even belong on a website in the first damned place and the rest has no business breaking 64k before minification... but really folks what the blazes is going on?!? Blind copypasta from bad books or worse online tutorials? "Wah wah, I dunz wanna learns?" Is there some mental block involved in how/what the DOM is much less how to use it PROPERLY?

I mean I know most people dive for jQuery or React (or vue or any of these other halfwitted frameworks) before they know enough about HTML/CSS or even JavaScript to have any clue what utter shit those systems are, but whiskey tango foxtrot people?!? Walking the DOM instead of nodelists isn't rocket science and is just so much faster in most usage scenarios than trying to treat a nodelist like an array.

... and remember, in Soviet Russia, the DOM walks you.

Write your answer…

10 answers

What?? :-\ It sounds lot like you know a lot, but then it also sounds like you haven't touched a new framework in years.

There certainly are disadvantages to manipulating the DOM directly with native methods, namely tight coupling of application logic to the presentation/rendering system. JavaScript logic is not easily unit-testable when it directly manipulates the DOM. You also cannot swap out DOM rendering for another rendering system, such as how a framework like NativeScript does so that it can render native GUIs on Android and iOS. You can't do server-side pre-rendering such as how Angular Universal does.

I honestly don't understand what your gripe is about. Do you really need to squeeze a small, negligible amount of performance out of your JavaScript code? Forgive me if I'm mistaken, but if you've maintained a JavaScript codebase with 10,000 LOCs, the cognitive overhead (and time!) that another layer of abstraction saves me is well worth it. Besides a framework like Angular with its ahead-of-time (AOT) compilation can preprocess the HTML for your components at build time to generate optimized JavaScript that will do direct DOM manipulation under the hood.

Show all replies

Dude, are you trolling us? If you need to be stubborn and sanctimonious to get along, that's your perogative. You claimed you were asking for a genuine answer; but I guess you only wanted to broadcast your diatribe.

I think I'll stick with opinions about development practices from the company who has actually written a browser. Feel free to curmudgeonly handicap yourself with your archaic development practices.

And by the way, that "obtuse syntax and pointless gibberish [and] all that describe and assert bullshit" is what you call an automated unit test. It's what professional software engineers use to ensure high quality code free of errors and regressions.

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

Because I don't want to spend lot of time at low level instead of implementing the actual business logic. If I would go deep and start playing with the DOM itself I'm really sure I would create my own 'framework' after a while.

Because I always tend to create reusable code blocks. At the beginning I would encapsulate couple of code lines into reusable functions. After I have lot of functions I would try to organize them somehow into larger blocks. At this point I would just reach the package/module step of the progress. Later on I would have many modules so finally I would look for a fancy name and finally have my own framework.

Because I want to work on my real projects instead of my own framework I pick one from outside.

That doesn't actually answer the question, nor does it even seem relevant... since as much as I just hated on jQuery it DOES provide some methods for at least SOME of it -- append, prepend, before, after, text, the ENTIRE "tree traversal" method set -- it's just it feels like nobody uses them and instead defaults to using the most convoluted and insecure methodology possible.

... and at the HTML/JS level this isn't "low level" ANYTHING! Unless by that you mean the minimum basics that should be followed if you care about accessibility, usability, speed, efficiency, and actually working smarter instead of harder.

Since to be brutally frank, 99% of the time I bump heads with this it's because of an XSS exploit or the entire website it is on flipping the bird at accessibility which is why the client ends up being fined or facing civil lawsuits over the failings! aka what I specialize in helping clients out of.

It just feels like the whole mess is either outright ignorance, or willful negligence...

More so when the result is people crapping together megabytes of JavaScript on websites that shouldn't even HAVE scripting on them in the first bloody place -- at least not for what they are actually doing with it.

It literally ends up feeling like people are saying that starting out with more code to write more code of their own resulting in 100 times the code actually needed to do the job is "simpler". That's some special kool-aid being handed out there...

Reply to this…

/grab popcorn

P.S. I can understand aliases window.$ = (selector, node = document) => node.querySelector(selector);

Meanwhilst to me that is aggravatingly cryptic gibberish nonsense. Which seems odd since I still write x86 Machine language.

But to be fair I started out in machine language and Wirth family languages, then spent a decade writing ADA... So for me even C is aggravatingly annoyingly and needlessly cryptic seemingly designed to perpetuate the idea that programming is difficult. As I've often joked I'd sooner hand-assemble 8k of RCA 1802 machine language than try to debug 100 lines of C code.

So much of this stuff just feels like intentionally trying to take something simple and to make it harder... or less useful to the end user... or insecure.

Willfully so in some cases, much akin to the mouth-breathing halfwits who spent most of the '00's ignoring Strict and vomiting up HTML 3.2 with the 4 tranny DOCTYPE atop it, and now just barf up the same ineptly developed dumbass bloated broken presentational markup with 5 lip-service wrapped around it -- back-slapping each-other over how "modern" they are as they undo the two decades of progress HTML 4 Strict actually gave us... with groups like the WhatWG and dipshit "frameworks" like bootcrap and w3.css pissing on the very INTENT of why HTML even exists!

We see the same level of outright willful negligence and stupidity on the scripting side of things... and honestly I tire of being "witness for the prosecution" when it comes to dealing with weighing negligence vs. incompetence.

Reply to this…

I definitely work with the DOM, but even still I'm not sure if the ways I work with it would set off your alarms or not :D

(Luckily) I don't think jQuery has a lot of traction anymore—even the creator of jQuery has put it down in favor of using React for a few years now—so if anything, I think a more relevant question might be something like:

"Why do developers insist on trying to innovate on top of the DOM we already have with things like virtual DOM?"

Surely some of these frameworks and libraries are reimplementing things we already have, (and sometimes much more poorly), but at the same time I think some of the ways people are experimenting with building can lead to new ideas that will someday get built into the DOM like how some of the handiest helpers from jQuery, and syntax ideas from CoffeeScript have inspired JavaScript features that came later.

While I definitely don't go out of my way to use jQuery or CoffeeScript, I can't deny their influence on the native JS features I learn and use today.

While you definitely won't go out of your way to use things like Vue or React today, I hope you won't deny the impact they will have on the native DOM features of the future!

Show all replies

Tommy Hodgins wrote:

Building websites doesn't have to be nearly as complicated as most people make it.

THANK YOU! That's basically what I'm really saying... but at the same time the woeful ignorance of the most basic of accessibility norms or even what semantic markup IS or how to leverage selectors is outright terrifying.

Made all the worse by outright mentally enfeebled derpitude like:

<nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
    <a class="navbar-brand" href="#">Site Title</a>
    <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarsExampleDefault" aria-controls="navbarsExampleDefault" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>

    <div class="collapse navbar-collapse" id="navbarsExampleDefault">
        <ul class="navbar-nav mr-auto">
            <li class="nav-item active">
                <a class="nav-link" href="#">Home <span class="sr-only">(current)</span></a>

Where as I'm always saying if you don't know what's wrong with that, do the world a favor, back the hell away from the keyboard, and go take up something a bit less detail oriented like macramé!

Reply to this…

What is the problem with the DOM? One of the most reasonable thing's I've heard is that the DOM does have side-effects. That's not really relevant outside of a functional approach but react insist on being functional so

A to A' obviously seams important the idea was to have no sideffects and a predictable mutation pattern. There is ofc some BS involved but luckily most devs are "users".

So in most cases I personally would stay declarative (HTML) with minimalistic CSS. because I don't need a rocket engine behind everything.

But as soon as my layout uses non synchronous update cycles so for example I have a component in the layout that should update on a dropdown change. The app-state to render-state issue is slowly starting to arise.

This is where react for example could come handy. I personally think it's still to bloated for such a simple task but the reasoning is more sensible. As soon as the page is not contained into 1 single Request and Response people tend to get confused.

The question of when a framework makes sense is like everywhere 1st usecase. It's always the question what we're trading. Do we need to know all cycles of updates? do we need to understand how an event really bubbles?

In my opinion based on my observations a lot of the modern JS-devs are framework users, they have to deliver and deliver and deliver so they try to push the thinking to their tools. that's what Gabor for example said "focus on the business-logic".

In my opinion, if you don't have a page that needs to be highly interactive .... you have to be an unexperienced programmer or you have way to much time, to add anything complex to your frontend as a complete framework.

But as soon as interactive asynchronous state changes / reactive state changes are necessary you probably have to much time or you are a classic old dog to not at least consider using a modern frontend solution for that.

I hope I am not to much off topic with my answer :)

Show all replies

Jason Knight

I understand :D but FP is old it got put down for a long time because memory was expensive and other classic religious fights between rivaling approaches of "how to control global state"

OOP took the "we control who change what" aka "messaging (private, protected, friend, public ....) and FP the "we just don't use the global state, everything is a copy" aka no "no global state inside a function" approach.

The lack of "memory / cpu" based thinking based on the "lets push this to the client" attitude as well as the newer compilers with better GCs and Heuristics for branch optimizations as well as the container based hybrid apps for mobile phones pushed a lot of it to. I think you observed this too.

A lot of solutions are just throwing a nuke onto something where a firecracker would've done the job.

I totally agree with you about those things ;D I use no-script as a default and just allow certain pages and scripts to run and it annoys me.

Still I will follow every trend to understand it because it does not matter if I like something, I need to understand it ... that's a requirement to myself. If it's good .... that I don't know ... it's just how I approach information, I need to dissect and understand it.

And yes some devs just use FP without knowing what the core principle of FP architecture- and memory-wise ... they probably don't understand OOP either ... a lot of BS all around.

Anyhow ... I'm rambling ;)

Reply to this…

Load more responses
Jason Knight's photo

Jason Knight


The less code you use, the less there is to break




Keene, NH

Joined on

Dec 29, 2015

Welcome to Hashnode
the dev community

The programming forum to discuss topics broader than bugs and issues, write and share knowledge and connect with the best developers.