Vanilla JS: You Might Not Need a Framework

Adding Scripts async & defer

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Vanilla JS: You Might Not Need a Framework

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

The "Adding Scripts async & defer" 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 adding scripts with the async or defer attributes to the course project. The defer attribute will defer the script execution until the parsing is finished while the async attribute will execute the script in tandem with the parsing operation.


Transcript from the "Adding Scripts async & defer" Lesson

>> Well, as I mentioned before, I said that this project has no JavaScript so far, so I'm going to start working with that. So I will keep my Chrome there, so we can have both at the same time, okay, my code on my browser, so I'm not jumping between both options.

The first thing that we need to add is a JavaScript file. So if you have ever played with Vanilla JavaScript few years ago, one of the scary parts is that you need to have hundreds of scripts, one script declaration per file that you need, okay? That was the problem, yeah, it was a problem.

That's why one of the reasons of JavaScript bundling was that, not the most important reason, was more for performance. But anyway, we were using tools to bundle all my JavaScript files in one file, because we didn't have context per file before. But today, we are using modern JavaScript.

It's difficult to say modern JavaScript, because what's modern? But anyway, today it's like post, let's say, ES 2017. That is that we are using ECMAScript modules, we are using async await, we are using class declarations. So that's what we deal today with modern JavaScript. Later today, I'm going to use also one thing that is from ES 2019 and 2020, but that is, anyway, compatible with all the browsers these days.

But despite that particular part, the rest is actually today compatible with all the browsers, but no, IE 9, okay? Yeah, it's not going to be compatible with IE9, but we shouldn't care too much about that. So today, we don't need to create one script tag per file, and we can still organize our code in different files with ES modules, okay?

So we're going to do that. So they're going to start, and by the way, this is actually a pretty common pattern on libraries as well. You have an entry point. So the entry point is actually one file that sometimes it's even called 'app,' okay? So I'm going to create an app.js file, okay?

So the app.js file is going to be our entry point. So, that entry point, Which is just the only JavaScript that we are gonna inject or we are going to reference in our HTML. So we are not going to add more scripts, just app.js. And maybe we're thinking, isn't it a good idea to create a scripts folder and then add our scripts there?

Well, I could argue that that's for the past. I'm not sure if it's a good idea for this case. You will see why in a second. I mean, it was common before to have the styles folder, the scripts folder, and the image folder, or images folder. Well, today, we can think this differently, more similar to what you are used to with a library.

So how many scripts, root scripts, will we have one app.js? Well, let's put it in the root, it's only one file. The rest of the JavaScript file, I'm not saying that we will write everything in one file, but the rest of the files will be organized by kind of files.

We are going to create components, we are going to create services. And then we can have folder for those ideas instead of the scripts folder that maybe it's a little bit outdated, but again, this is just one solution. As I mentioned there, you can make your own decision here.

But I wanna emphasize that maybe that decision of using a script folder, it's kind of from a different era, okay, so it's not really what we're used to use these days. So anyway, now, I'm going to create the file that is empty right now. And my script tag, by the way, is not finished yet.

And so I wanna first because we are doing Vanilla JS from scratch. And you might not know about this, but do you know what happens in terms of performance with our script as it is right now, like in a script with a source and that's all? So when the browser is parsing the HTML line by line, let's say, I'm simplifying, but when it finds a script tag like that, it will stop parsing the rest of the HTML at that point.

It will download the JavaScript file, it will execute the JavaScript file, and when it's done with that, it will continue the rest, okay? That's why an completely deprecated best practice today, so it's deprecated, but a lot of people, I mean in college or in some trainings, they're still saying this, that you should put your scripts at the bottom of the body.

Have you ever seen that? Well, that's deprecated, you shouldn't be doing that. But why? The reason was to render the HTML, and then the JavaScript file, because the browser was halting the parsing at that point. So then you were seeing an effect of a white page. You go to a URL and you see white or blank for a lot of time before seeing even the text of the page.

Well, today, we have some attributes that we can apply, such as defer or async, that the code that you are doing from React or Vue or Svelte, it's actually doing this, okay? So quickly, what's the difference? This is more for a performance workshop, but let me give you the insights.

Let's say that if you're not sure which one to use, defer or async, you should use defer, okay? So let's stay with defer as default. Defer, it's a Boolean attribute, so I don't need to specify a value. Defer will actually do this. When the browser finds, it's parsing the HTML, when it finds the script, it says, it says defer.

Okay, because it's defer, I will download the file in parallel, but I'm not going to wait, I will continue parsing the rest of the HTML, okay? So it's not halting the parsing. When the whole parse operation finishes, at that moment, it will execute the JavaScript file. So it will defer the execution of that file for later, okay?

So it's a good idea to have defer. When to use async, it's one or the other, not both, it's one or the other. Async, today, is more suitable for small scripts that really need to be executed as soon as possible, for example, analytics, things that you need to send to your server, things like that.

Async will not halt the parsing, it will download the file in parallel, but once the file is ready, it will halt the parsing and execute the script at that point. So it's kind of in the middle between the original script loading and defer. But by default, let's say we defer.

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