Check out a free preview of the full JavaScript: From First Steps to Professional course

The "Modules" Lesson is part of the full, JavaScript: From First Steps to Professional course featured in this preview video. Here's what you'd learn in this lesson:

Anjana discusses a concept commonly used in real-life JavaScript code of splitting large codebases into multiple smaller files using modules. The differences between JavaScript and module JavaScript, including await, scope, import, and export, are also covered in this segment.


Transcript from the "Modules" Lesson

>> Hi everybody we are back with a bonus round of some JavaScript first steps or perhaps these are even indications for the next steps that we wanna take into our JavaScript journey. So, so far in the course we have built few different projects, we've been working with JavaScript, we've been looking at all of its different ways of interacting with the webpage.

We've been talking about different types of syntax and different types of values and how different parts of the language work. But of course as you go out and, venture into the wilderness of the web, we will be running into some other considerations around JavaScript that we haven't really had too much time to talk about yet.

So that's what I'd like to do now with you all is talk about some things we're gonna run into when we encounter JavaScript in the wild, or as Morpheus says in the real world. So there is, of course, a ton more we could say about JavaScript than we have been able to say in this course.

And for that you have so many other awesome courses on FrontEnd Masters and all of the documentation on MDN and the whole rest of the web community to help you get your feet wet with all kinds of, other things about JavaScript. But there were a few concepts that I did wanna just mention so that we can talk about a little bit here today, and that's because they are gonna be relevant to how you're gonna be using JavaScript in real life as a web developer.

One cause have we discovered a little bit of a hint act earlier when we're working on our doggo fetch project, is the concept of modules. So let's take a minute and talk about it. So modules are a relatively new development in JavaScript that essentially let us take a big, big long program and split it up across multiple files.

So we have maybe started to get to the point in our doggo fetch project where we have a lot of things going on. We have a lot of different functionality, the code file is starting to get pretty long. And the more and more complex your JavaScript projects become and as we said JavaScript started out being a language intended to just write a few lines of scripting code to add a little bit of interactivity to a simple web page.

And now, decades later, we have hugely complex JavaScript project being written with huge teams split up into different places in the world. And we all have to kind of work together on these really massive JavaScript projects. So modules lets us take a big, big, big JavaScript codebase like that and split it up into multiple files so that it becomes a little bit easier to work with.

So there are some differences between module style JavaScript and the regular JavaScript that we had sort of been looking at initially and one of those differences is await. So do you remember how when we tried to run await at one point earlier, we ran into an error message that JavaScript said wait, wait, wait, wait, wait, you can't just run await in any function, you have to run await in an async function.

So similarly to that, JavaScript also complains if we try to use await outside of a function, that's usually not possible. And so in our doggo quiz, we actually have an await here that is outside of a function. It is just hanging out outside of any function, it is what's called at the top level of this program in this script.

And usually, this would be a problem for JavaScript. So, if we take a closer look at our .doggo fetch file, we actually find that in our script tag, we're not just working with a regular script tag or <script type="text/javascript">, we have <script type=''module''>. If we check this out here.

We scroll up, we can double check for ourselves in our code, there it is. So in our script tag, we had this special designation that this is a module script. Now if we didn't have that. Usually, we would have just kind of a script tag or maybe you've seen also script equals, and then the string text slash JavaScript.

So, if we try that, if we take out our module designation, and we go back to our local JavaScript file, we see this syntax error, await is only valid in async functions. We ran into that earlier, async generators and modules. So unless I designate and tell JavaScript with that type equals module here, that this is not just a regular Java script, but a JavaScript module.

Unless I do that, JavaScript is not going to allow me to await my loadQuizData function. So if I put that back in here now that I make it a module again and save and reload, well, something else is going wrong, but we'll talk about that in a moment.

Okay, so one of the differences between modules and regular JavaScript scripts is await, top level of await, but another difference is scope. So we said that there's a few different cases in JavaScript where we create a new scope. For example, functions were one of those that we ran into.

And another time that JavaScript will create a new scope for us is when we have a module. So, earlier we tried to access the BREEDS constant variable that we had assigned to this long list of dog breeds, in our earlier programs like the quiz.js for example. We had some things like option buttons, right?

Which when we went and we loaded our local JavaScript quiz program here, I could still access option buttons which was a variable that we had declared in this script. But notice, that's because this is not a module, this is just a regular JavaScript script. And so I'm able to see into this script, and all of those variables that I declare here, they are not in a different scope, they are still accessible to me in my global scope here.

But in doggo fetch, since we have this module, I'm not able to access any of these variables that I declare in here, they are local to the scope of the module. So again it's kind of like that module is like this limo with tinted windows that Bart Simpson can't see into.

So one of the other differences, other than top level await between modules and scripts is scope. Now, I said earlier that the whole reason modules exist is so that we can split our code up into multiple files. But if we can't see into the scope of a module, how can we use code from another file in our file?

And that is where import and export statements come in. So you might run into these as you're reading other people's JavaScript code around the web, because these are becoming more and more useful that folks are splitting up code into different modules. And so you'll see things like export statements.

So export from a module is sort of like exposing a variable or a value, whatever it may be. It may be a constant value, might be a function that you want people to be able to use, might be data, it might be all kinds of stuff. So export what it does is it says, hey, from this module, I wanna pop some values up the roof of the limo here so that other people can see them if they need to.

And once we have a module with some code where we've exported something, we can in another module, import something that the first module has exported. So that's how we can sort of take advantage of code that is written in some other module. And we use our curly braces this looks very much like the kind of destructuring syntax that we saw before.

Because when we export something, we're going to name certain value, certain variables essentially. Essentially what we're doing is creating an object of exports that has some properties on it. In this case, it has a property veryUsefulFunction that points at a function that doesn't do a ton, but is there.

And when we import, we sort of do a kind of destructuring on that, and we say which variables, which properties, or which exported things from the other module we would like to pull in to this module that I meant. So what we end up with, is a way to kind of talk between modules via this import and export statement, sort of opening up the sunroof of our tinted windows limo and our scope here.

So we allow certain values to be exposed but certain values but certain other values might still be local to the module scope if they're not exported. So I've got here on our on our course, materials page, so this is again You'll notice a new option in our Doggo Fetch here, a modular version.

So let's take a look at this. Even in our local Doggo Fetch that we were working in, we had one big module. That's how we were able to use top level await. But in this version, if I inspect what's going on here, I'll notice that now in this version, I have two script tags.

Let's take a look at the codes. So I'm going to save this as modular, and go over to my editor and open it up. So we can take a better look here. Okay, so this is the same program, it's doing the same thing, I still have my functionality that I had before.

But if we scroll down we notice that there's something a little bit different. So now I have two script tags in my file here. And one is the same that we had before, but this time I don't have any of my kind of little helper functions there that were pulling in random elements from an array or shuffling an array.

They're no longer in the module that's written in my DoggoFetch.html file, what I'm doing is I'm actually importing them. What I'm doing is actually importing them from another module. In this case, it's called 3-utilities.js. And I'm getting that involved here via this other script tag that's saying, hey, there's another module that I care about for this program.

So that is loading, another file that you can find here, this utilities file, on the course materials page, which if we look at that, this is just a JavaScript file, it ends in .js instead of .html. And this has essentially the functions that we wrote earlier, that we had the helper function, some of them were already written in a JavaScript file.

And what we're doing is exporting the things that we want people to be able to use from this other utilities file, just because we don't want them to have to be cluttering up our main program. These are utilities, they're not super important, we just wanna be able to use their functionality.

We don't want to have so much code in our one module. So what we're doing is we're exporting three of these functions, getRandomElement, shuffleArray and getMultipleChoices from this utilities module. And then in my main Duggo Fetch module, I am importing those using that destructuring kind of syntax and this special import statement.

And so now I'm able to call those functions like getRandomElement for example. Or shuffleArray or getMultipleChoices I'm able to call those functions from within my module so the whole thing still works. So this is how you might see code split up in different places. So now there's a few more things we could say about modules, for example, the reason that I'm showing you these files hosted on here, is that if we were to try to do this in a local file, the browser won't allow it.

And this is because of some browser security policies around how one file of code is able to load in information from another file. So if I were to try to do this in my local file, in my DoggoFetch.html that I'm just opening at a file URL in my browser, loading another module wouldn't work.

It only works, if we're hosting them both from the same place on the interwebs, let's say. So this is another difference between modules and scripts. And there are a lot of other things that we could say about modules, and of course, MDN has a whole bunch more information about them.

So if you want to dig in, you can read a bit more about how they work. About some of the restrictions or some of the differences between a regular JavaScript script and a JavaScript module. So the suffice it to say that modules are kind of part of the the modern professional web developer workflow.

Because our programs are now so complex that it would be completely impractical to have them all in one file. So you will see these import and export statements more and more around the JavaScript that you're reading and starting to work with as you get into a professional level of JavaScript.

And there's a lot more that we could say about that modules in JavaScript as a whole. Could be a whole course in, and of itself and so, there are some other courses on Frontend masters that go into this in more detail that you can go ahead and explore next.

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