Main Script Setup

[00:00:00]
>> Now coming back here, most of the time what we want is to work with the patient, okay? We need to work with the page and actually, because this is going to be executed after the parsing has finished. I could directly do things like getElementByID, or getElementsByName or query selector.

[00:00:28]
So I could do this in a defer script, okay? So I can go and grab my nav, okay? Some things like that, I can do that. However, it's not a good practice, why? Because some browsers, I mean, it's not really happening in the real world, but in theory, it might happen that some browsers are still working in the creation of the DOM.

[00:00:58]
So the parsing has finished, but for some reason that DOM structure in memory is not finished yet. So that's why the window object has an event that we can listen to that specifies that the DOM is ready for manipulation, and that happens always after defer, after my code is executed.

[00:01:25]
So the event is known as DOM content loaded. And here we are going to see that they were not, I mean the W3C spec is not completely following the same naming guideline as for the rest of the events. This is kind of an exception I will get into that later but anyway.

[00:01:51]
So actually I'm going to execute something there, for example that code. And for now, let's say console.log, my nav. So, meaning that to work with the DOM, it's better, To wait for the event. Before that event, the DOM objects that you wanna manipulate might not be ready, might not be in memory, and they may be in like weird state.

[00:02:26]
So that's why most of the time, we're going to use them content loader. If you have ever played with JavaScript like 10 years ago, 15 years ago, you probably have heard about the load event. That was the common scenario, like in the IE era, Netscape and IE era, the load event is still there.

[00:02:49]
Does anyone know the difference between the load event and the DOMContentLoader? I know the difference, so I will explain that. [LAUGH] The load waits for everything in the page to be loaded. That means style sheets are loaded and parsed, images are loaded, web fonts are loaded, videos are loaded when everything is ready.

[00:03:16]
If you wait for that, you're missing the opportunity to manipulate the DOM earlier. And maybe the user is I mean, if you have a video for example, maybe the video is still loading But the user is trying to use the app, and it's not working because you didn't execute the JavaScript yet.

[00:03:33]
You didn't initialize the app because you're waiting for the video to finish, which doesn't make any sense. So that's why we typically initialize our app in DOM content loaded, that means as soon as possible. If the browser, after executing my code, is still downloading videos, fonts, images, it's fine.

[00:03:53]
In fact, that doesn't mean that when DOM content loaded is fired, that doesn't mean that the user has actually seen the page. In fact, I'm pretty sure it's not seen the page. This event happens before rendering, but it means that the domain memory is ready for us to manipulation.

[00:04:13]
Manipulation means out some things, or even handlers understanding what's going on, adding a button hooking an event to the button, so when it appears on the screen and the user clicks on the button, he will work, okay? Makes sense? So everything that you do for initialization, you do that in DOM content loaded as an event.

[00:04:37]
It's like what we typically use as our initializer for the whole app. And by the way, there are more events, I mean, in the life cycle of the page load, there are more events that you can hook into, but they are not part of the DOM API. They're part of a performance navigation API that is used for performance.

[00:05:01]
So we are not going to cover that today, but there are a lot of events in terms of the timeline. When we are working with performance, you can know when the rendering appear, for example, for when the user is seeing a pixel on the screen. When the user seeing that's called first paint.

[00:05:17]
You can know when the user has it's actually seen the most important part of the page that can be an image or a title, its first contentful paint, the largest contentful paint. So there are a lot of events that are not part of the DOM API. They're part of other APIs that browsers might implement or not.

[00:05:39]
Like typically Chrome implements all of them, Firefox, and Safari, it depends. So, here, we are covering the DOM API, that is an API that works everywhere, even in an old BlackBerry, things like that, okay? So far nothing is on the screen yet, but actually, I could take my nav for example, and I can change its inner HTML.

[00:06:04]
This is just for playing a little bit I'm not going to use this. So I'm going to write a back tick here, and I'm going to show you that I can write my own HTML, like hello DOM like that, and you can see that on the screen I can write HTML within a JavaScript string.

[00:06:30]
You can see it's a string. When I'm saving this. This web server has live reload, so every time I save. It works here. I mean, you if I let's let's try to analyze the DOM now. Anyway, this is not the code that I want for my app. But now if I inspect my code, my nav originally have links and a span, okay?

[00:06:57]
Can you see that in my original HTML, but they're not here anymore? My nav only has an H2 and a paragraph, why? Because I changed the DOM dynamically with JavaScript. When the DOM was ready, the original DOM was ready, I replaced it completely, and now I have an H2 and a paragraph, and that's because I'm using this code here.

[00:07:24]
Okay, makes sense? By the way, I'm using the backtick just for making a template string that can be multi line, so it's easier to write HTML, okay? But it can be just a normal HTML as well.