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.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?
... and remember, in Soviet Russia, the DOM walks you.
What?? :-\ It sounds lot like you know a lot, but then it also sounds like you haven't touched a new framework in years.
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!
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.
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?"
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!
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 :)