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

10Responses

Write your response…

This answer has received 1 appreciation.

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.

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.

Write a reply...

This answer has received 1 appreciation.

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...

Write a reply...

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!

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>
    </button>

    <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é!

Write a reply...

/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.

Write a reply...

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 :)

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 ;)

Write a reply...

Load more responses

Join a friendly and inclusive Q&A network for coders

  • 🖥Pick the technologies you like & read great content through your feed.
  • 💬Ask a question when you want to learn more about anything.
  • 🚀Share what you know & build your portfolio.
Sign up nowLearn more

loading ...