Check out a free preview of the full Vanilla JS: You Might Not Need a Framework course

The "The DOM API" Lesson is part of the full, Vanilla JS: You Might Not Need a Framework course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses the DOM API, where it's available, and walks through parts of a simple DOM example. Referencing DOM elements and actions that can be performed on elements are also discussed in this segment.


Transcript from the "The DOM API" Lesson

>> So I want you to emphasize that warning, okay? That this is not a common situations, that we are going to mix different techniques at the same time. I mean, we can, it will work, but you will see, for example, on doing reactive programming with the DOM. We will see two or three techniques.

Yeah, probably you pick one and stick with that one for the whole project, but we will mix all of them, okay? So before seeing some code, but now we will see code, but before working with our project, let me go over some essentials, talking about the DOM API, okay?

So let's start defining the DOM. The DOM is the Document Object Model. And actually it's a representation of the structure of a document in memory that will let us connect to web pages, the HTML to JavaScript. It's actually a memory representation of your HTML. Is that the API?

No, that's the DOM. So the DOM isn't a structure in memory. That browsers are creating when they are rendering a page, okay? That's the DOM. And the API, it's an API, so a list of functions, properties available under different objects that a browser is exposing to us so we can manipulate, that's a structure.

From an scripting language that today is JavaScript. So we can change the structure in memory, okay? We can change a property, we can add an element to that structure in memory. And that will trigger an update in the rendering HTML that you see on the screen. So talking, this is actually quick and dirty, but it's like changing your HTML, okay?

From JavaScript. Actually, we are not changing the HTML, we are changing the DOM, but the browser is representing that change in the UI and it looks like we are changing the HTML file. I mean the string, the HTML, we are not changing that, okay? We are changing memory representation, but it looks like we are changing the HTML.

So the DOM API is available in many options. And we're not going to cover 100% of the DOM API, because it's really large, and there are many things that I've never used. So there are many parts of the DOM API that are very specific for some specific situations that typically you don't use.

So I'm not going to focus on like being verbose on the all the DOM API. You have MDN and other places where you can see everything in the DOM API. So I'm going to show you what's most important. So we have for example, the window global object. The window global object is, in JavaScript the current global context, when you're running your scripts unless we are talking about the worker, a web worker, a service worker or other kind of workers that we have today.

Unless we're talking about workers those are threads. Every script that you have have access to the global variable, and JavaScript goes to the window global object. And most of the functions that we will see later today are attached to that global option. The window represents the window. The problem is that the window is not a clear concept this day.

So what's a window? This comes from the 90s where you have a window for one. So one page was loaded in one window, if you wanna open two pages, you need to create a new browser window. We didn't have tabs at the time, okay? So we don't have that, we didn't have tabs.

So every page was actually on a window, and one window, one page. This is not the case anymore. So it's an unclear concept these days, okay?. But let's say that roughly it's like a navigation, like a main navigation, but it's not still there because we have iframes as well.

When we have iframes like iframe is a like HTML document or the within another document, well, it gets more complicated, okay? But that's the window. Then we have the Document Object. That is more clear, a document is a DOM, so a structure. Typically since the 90s, we used to have only one document per window.

So one HTML we are loading one HTML if you have a link to another HTML, that's another document. So the only exception here were iframes or even framesets originally, where in that case, we could load more HTMLs at the same time, okay? But these days, and we will see that later with web components, we can have more than one document in the same page navigation even without iframes.

And the document object represents the current DOM, the Document Object Model, that memory structure. Okay, that's the structure in memory. And then we have the domain API available on every object in the DOM. So we will have one object per HTML element. So every HTML element in your web app will have an object.

And that object, will have the DOM API. Or one part of the DOM API is sitting there. So we can change things, we can add, children, we can remove elements from there. And I'm saying there, other nodes, we won't get too deep in that part, but actually, when you have text nodes, we have comments in HTML.

Also, those elements that they don't feel like objects, when you see the HTML, they're also objects, and they have also an API. I mean, we don't typically want to deal today at least with comments. I mean, if you have comments in your HTML, why do you wanna manipulate that from JavaScript?

It was a thing years ago to do some hacks, okay? But not today. Anyway quick sample basic, this is very basic I know, but some of you, maybe the first time you're seeing this. Let's say we have that HTML, that's an HTML file index.html file, we'll load that in the browser.

With this file, each element will be represented by an object of an interface. Let's say a class with a name HTML element. That's the class name in JavaScript, okay? Originally, it was known as an interface. But if you're coming from TypeScript or other languages, you will get better in the term class.

So there is an HTML element, okay? And also, we have other elements inheriting from that one. For example, we can have an HTML image element that is the class or the interface when you have an AMG tag, okay? These objects or these elements, we have properties, instance properties and methods to work with them.

Changes in those properties will trigger updating the user interface. And this is important, when you're released the thread. So sometimes I hear from React developers that they like the virtual DOM, okay? That's a concept that doesn't exist a vanilla.js, a virtual DOM, so what's a virtual DOM? So virtual DOM in the case of React, every library is different.

It's actually like a clone of the DOM, the real DOM, but managed completely by the JavaScript library. It's just like an array, it's a collection in memory. It has no direct relationship with the real DOM. That's the virtual DOM. And some people think that, well, it's better to work with the virtual DOM because then React will update the real DOM.

I mean, for example if you are making ten changes at once, React will receive that only in the virtual DOM and it will update the real DOM once. So it's more performant than vanilla.js. And my first reaction to that is that's false, because if you're making ten changes in the real DOM, okay?

It won't trigger any updates until you release the thread. So it will be kind of similar in that case. You will release the thread, and the layout changes. We will trigger when you release a thread because you're competing, we have only one main thread, and our child script is competing with the browser to use that thread.

So if you're changing the same property, in the real DOM ten times in the same execution, the real DOM will just take the last one. So we will see on the page the last one. I'm simplifying this a little bit, I'm not saying that this is the same as the virtual DOM in terms of performance, but we have some things here in mind.

Also, this might lead to some issues, and I have these issues in my web apps a lot. And there was a trick before that is a set timeout 0, I'm not sure if you have heard about that. Because you change something in the DOM, and then you wanna use it immediately in the same execution, and you can't.

Because it's not yet, we didn't leave enough time for the browser to actually make that change. So the trick was to create the set timeout 0, and there is to defer an execution after the browser was making the changes, okay? Anyway, we don't need to do it anymore.

But just to let you know that happened. And we can listen to events happening in that element and reacting consequences. Probably you have heard about these you have seen this, the famous today add event listener, okay? So for example for this particular code that you see there, we have the document.

I'm simplifying this a little bit, but we have the document the document will have the body and there is an HTML body element, inheriting from HTML element. Then we have the header element inside, okay? It's a child of the body, the header. Inside the header we have the h1, the interface for the h1 is called HTML heading.

So we don't have an HTML h1 heading. It's just a heading that will be the interface for h1 to h6. We have the paragraph and we have an image. And that's the DOM, that those are objects in memory in JavaScript of one specific class, each object having methods and properties.

To work with those elements from JavaScript, we can pick them from the current DOM. So I'm in JavaScript, so I can pick one element from the DOM or we can create them from JavaScript, and then inject them in the DOM. So if I wanna play with an image like every five seconds I wanna change the source of the image.

If I wanna change the photo, like a photo gallery or something like that, how can I change the image? Well, I need a reference to that DOM element for the for the img tag. So I can pick them from the DOM, or I can create it on the fly with JavaScript creating a new object, for example, or we will see different ways to do that.

And then put it into the DOM. But we need a reference in JavaScript to do that, okay? To have a reference and we can read its contents. So when we have a reference, we can read the content, change the content, remove it from the DOM. So I can take a reference to an img tag and then remove it or I can add new elements to it.

So for example, back in our example, if I get the reference to the HTML heading element, the h1 from JavaScript, I can then delete that, I can remove that object from the DOM. And if I remove that object from the DOM, it will trigger an update after we release the thread.

It will release an update and it will remove the h1, so you won't see the h1 in the browser anymore. It's like going to the DevTools, inspecting the HTML and deleting the h1 manually, okay? If I take the img tag, you can see the img tag right now has a hidden property set.

Well, I can go when I get the reference to that attribute for that img element, I can change the hidden attribute. So if I change the hidden attribute, I'm updating the contents of that HTML element it will trigger a change in the URL. And also it's not just playing with the current DOM.

I can create a new HTML image element, but we'll see how later. And then I can attach that new element to the header, for example, and that will trigger a new img element in your HTML. So that's the idea of how we manipulate the content with vanilla.js. So if you're coming from React, it's not like we have a state.

It's not like we have a render method. No, we are talking directly to that DOM structure. Yeah, question? What do you mean release the main thread? Release the thread, you can release the thread in different ways in JavaScript, but the simplest way to understand that is that your function ends.

So you're executing some code, because of some reason. Most of the time, it's because you have an event listener. For example, you click on a button, you are listening for that click event and you have a function. Well, at one point that function ends. When that function ends, you're releasing the thread because there is no more code to execute.

So the JavaScript engine says, or actually the Just-In-Time compiler thinks, there is no more code to execute, so we are releasing the thread. And in that point, there is a set of operations in order. And the browser will say, okay, JavaScript, you finished. Okay, it's my turn now, and now I will do relay out, re-render there, repaying, there are a couple of processes there until it checks again if there are more JavaScript to execute.

So talking this or saying this in the quick and dirty way is when your event handler finishes. When you have a function, so if you have a while true in JavaScript, you're not releasing the thread. And most of the browser's today after a couple of say, I think Firefox, I think it's two seconds.

They will show you a message saying, hey, this website is not responding anymore. Should we kill the child's grip or something like that? Because if you don't release the thread, and there is only one thread, the browser cannot render anything on the screen. And when you are with your phone and you are scrolling a website, and you feel that it's not scrolling, that it's kind of shanky.

That's because most of the time there is a JavaScript code there, there is not releasing the thread. And because it's not releasing the thread, the browser has no enough time to detect that you are scrolling and to relay out the contents of the screen. So the thread is a big performance issue, or understanding the thread is a big performance issues that you need to understand.

When you have things that will take a lot of CPU time, you should move that into a new thread that in JavaScript is known as a web worker, okay? And that's for a different day. If we find delete a node and then try to retrieve it in the next line, where do we find it?

If you're using the DOM API to retrieve it won't be there because you'll remove it from the DOM structure, but the user is still seeing that on the screen, that's the problem. So when you wanna show, I mean, you wanna show a timer or something that is changing on the page, you need to release the thread because if not, the user will see the last state only.

I think that probably will clarify that. So when you're working with the DOM API without releasing the thread, you're working with the memory structure. So if you remove something from the memory structure, and then you go through a structure and see if it's there, it's not. Because you remove that from the structure, but the user is still seeing that while you are doing that.

Okay, so the difference is that when you're released the thread the browser will see. Now, if the what you see on the screen matches the current DOM. It's like the diff that React is doing between the vDOM and the virtual DOM and the real DOM. I'm simplifying, but it's kind of similar idea.

And then you will realize that there were changes, and it will do a real layout and repaint on the screen. So in this case, I'm not talking about the JavaScript, but I'm talking about the the UI, what the user says. The user will not see the change until you release the thread.

And releasing the thread means that stop executing code, just let the event handler finish it, that's kind of idea.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now