What is a DOM? What does it eat?
The DOM (Document Object Model) is the base of web pages and developing them. It's a programming interface for HTML and XML documents, representing the structure of a document in a tree-like object. With branches and leaves. Each element, attribute, and piece of text in the document becomes a node in this tree. It allows JavaScript to interact with HTML elements, modify them or add new elements. This is a rough digest of what every person experiences on the web, interaction, mutability, dynamic visual cues and elements. When you click a button or a shiny menu, your brain expects something to happen. To a sentence to change, to a new be page to be loaded or to a popup with a green check mark telling us that our online order was paid successfully.
Manipulating the DOM too fast, every second, is a big no-no for user retention or even basic interaction from the user. Even with all the dynamic behavior we can create and expand the user experience, the over usage of DOM manipulations can be very frustrating. And the final saying is always from the user. If you have crucial operations happening in the background of your page, like data fetching, but the performance just tanks and becomes worse by the minute after the user interacts with it, it can be very hard and daunting to pinpoint the choke points.
A example of simple way of using the basic way of doing things and doing it faster, is using textContent from vanilla js. Yes, I know. Most of the time we need a complex cycle of life for components that are so dynamic and mutable that we need to use state management and such. But that is not always the case. If you are only changing some text or updating a cookie once per session, do you really need to use such a complex logic and resource hungry option?
The textContent function is the fastest in js for manipulating text when compared with similar functionality options, for example, the more popular innerHtml method. See these timed tests for reference.
Why?
You can save up the user's machine memory for other way more impactful operations. Sometimes being accessible and reasonably fast in really old android or apple devices, for example, is a must. Or maybe your API call returns a JSON so big that you need a couple of seconds for parsing and proper manipulation. So every second that the user gets no feedback or is stuck watching a CSS animation on screen, counts.
I learned a lot recently was by coding in JavaScript with no dependencies, as a challenge and learning experience. Like fetching data and creating a to do app with just HTML, CSS and JavaScript. No npm, no libraries. And I found out a bunch of Web API's method and objects I never heard of before, like the DocumentFragment object. It creates a empty 'fragment' of a DOM structure and let's you manipulate it and populate it before actually changing the page's DOM. So you load up a object with your list of menus or your super fancy AI powered tool's titles, and after you are done with the appending operations and nesting tags, you patch it to the DOM once. In such way that the parsing only happens once, in one go, instead of doing a for loop with many identical calls, and requiring a new parsing of the tree at the end of every call.
So lets say I click a button really fast, because my use case requires rendering really fast, more than 1 time a second. Using your favorite state management library can create some sort of barrier in this case, because after every click there was new event fired, so it must go off before starting the second instance of the event in the stack, by default. Depending on the complexity or the need of a async operation, that can take more than a second. In this use case, is a deal breaker. So, choosing the right tool can be simpler, shorter and even faster. Nowadays there are options that popular libraries offer to solve this issue, like breaking execution of a re-render when a new identical event fired recently. But my point here is, not to just pursue a pretty and modern looking web application. But to make your own life easier by making maintenance the easiest you can and not shoot yourself on the foot by blindly trusting chunks of code that someone wrote and says that is the best option.
If you are already installing these packages and libraries to fire up your project, why not investigate why errors and exceptions spit out unknown function calls or cryptic messages on the console?
Conclusion and some extra rambling
Getting a service up and running on the cloud or in a very common service for free, can be a really fast and so easy nowadays. Using a boiler plate like starting point can be very helpful and will save you time not worrying about very basic and recurrent tasks. Just type a single command in your terminal and there you have it, base routing and a hello world page running on a local server.
Nobody, nowhere in the internet will always know what a determined library or an entire framework does under the hood, but the more you know how things work, more often you will be able to take more informed decisions and work efficiently.
Most popular framework's for web development do quite a great job to actually optimize re-rendering and manipulate the DOM using resources like a virtual DOM's or implement some sort of persistence for very demanding operations that retrieve data.
The web developer tools from your web browser of choice is your best friend here. Newer versions of these tools can give you telemetry and even show which part of your code or which calls are the possible choke point of your performance.
By knowing how the JavaScript language works or how it implements its way of doing things, you can easily identify situations where a ready to use function from your favorite library might force you create a more bloated code base and not focus on solving the problem. It might just steal your attention to replicating some piece of code that you wrote hundreds of times. And even with AI to boost your productivity, you might fall for the trap of using a solution suggested by you artificial companion, and actually just making things harder to maintain in the future.
Don't worry, we sometimes just don't know better. Like I said, no one can know everything at all times.
Experimenting and making mistakes in more forgiving moments will help you a lot and give you the tools you need to do better. The next time you come across doing something as simple as deploying a static file server or coding some really complex logic to a very niche use case, knowing the basics will get you really far and give you more clarity when facing new issues in your career.
I strongly recommend checking out the Web API's docs. As well as taking a look around in online blog's, social media or resource focused in web development.
If I made any miskates, wich is likely, please let me know in the comments. I all ears to criticism and new ideas, so please, share them if you want to!
Top comments (0)