Check out a free preview of the full JavaScript: From First Steps to Professional course:
The "Modules Q&A" 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 answers student questions regarding if only utility functions are imported, importing modules on the internet compared to locally, and recommendations for where to start breaking a webpage into modules. Resources to look into after this course are also provided in this segment.

Get Unlimited Access Now

Transcript from the "Modules Q&A" Lesson

>> Do we generally only import utility functions?
>> Do we generally only import utility functions? Good question, so utility functions are a very handy thing to import. But, no, we might be importing, for example, some data from a module. Maybe some module is actually going through and going to generate or load some data for us like a JSON object, let's say, for our big long name of dog breeds.

[00:00:28] We could even put that in a separate module. We could put our big, big, big, long array of all of these dog breeds in a module that exposes that as a constant, breeds. And we could say import breeds from breeds.js or what have you. So, essentially, we can import values.

[00:00:49] It's sort of like any kind of property that could be pointing at something in JavaScript. A function could be pointed at by a property. A literal value, a string, or a Boolean, that's probably less likely that we'd want to import. But any kind of data, maybe a complex object, maybe some adjacent object with lots of different properties and nested objects within it, we could import that, too.

[00:01:17] So, basically, we can import whatever we want. We just have to make sure that it is exported by the module that we want to load it from, yeah?
>> There's a question around importing modules on the Internet versus locally.
>> Mm-hm, yeah, so as I mentioned, importing modules when the files are hosted somewhere on the Internet like on, let's say, will work.

[00:01:42] Because of the way the browser decides whether the thing that the page is trying to do is loading something appropriate. So the fact that we're loading two scripts that are both hosted on matters to the browser. This is due to something called CORS, C-O-R-S, Cross Origin Request Scripting.

[00:02:09] And it's a whole big complex topic that you could look up and read more about. But, essentially, when you're loading things locally with those file URLs as opposed to an HTTPs URL, the browser can't be sure about that security of whether you're loading something from somewhere that's trusted or not trusted, or whether it's actually coming from the same, what's called origin.

[00:02:33] So the same sort of URL. And so this is something that just doesn't work. So if you wanted to work with modules locally, and the reason that we didn't do this in our Doggo Fetch project is because there's just a little bit extra work you have to do.

[00:02:46] What you have to do is, essentially, run a local server that pretends to be a website. That's not a website that's out there on a public URL that anybody can get to, but is what we call a local host website. So if you've seen projects, maybe, where they ask you to start a server, and then load a page from local host, that is what's going on there.

[00:03:13] So if we wanna work with a JavaScript project that uses modules, usually what we're gonna be doing is not opening a file in our browser from a file URL, we're going to be using some small little program on our local computer. For example, Node has a tool called Express, that can run a web server locally on our computer.

[00:03:42] Or there are a bunch of other services or toolkits that do this for us, too. For example, next, if folks have run into that before. Anyway, there's a lot of different ways that we can run a program locally on our computer which pretends to be a website. Runs a, what's called local server that's serving up both of those module files or however many module files we have from the same URL.

[00:04:08] So that we're not loading them from file URLs, we're loading them from an HTTP URL that happens to just be pointed at a local website. So this is a whole can of worms that we can explore. And if you read up about modules, for example, on MDN and their guide about modules, you will see this mentioned.

[00:04:27] That this is due to course security policies that browsers have. So good question.
>> Yeah, I just wanna add to that, she was asking also about React modules and how it's loaded. And generally your NPM installing a bunch of modules to your local node modules folder, and that's where they're actually coming from when you hit import a library.

[00:04:53] That's how that's working.
>> Yes, exactly, so we haven't really touched on Node, which is a whole big topic. And I'm sure there are entire courses that you can take to really dig into Node, which is, essentially, server-side JavaScript. But usually what's happening is, we have, as Mark points out, a whole bunch of different modules.

[00:05:14] Some of which we wrote, and maybe some of which other people wrote that we want to reuse other people's code that's open source. That we want to take advantage of in our programs, so that we don't have to reinvent the wheel all the time. And we can actually import all kinds of different modules.

[00:05:28] Modules that we wrote in files that we have, modules that are being loaded from somewhere else on the Internet, modules that were installed as kind of dependencies of our project. So it gets very very complex, and there's a lot more to be said about it. But, yes, when we're working with really complex sites or frameworks like React, or kind of Meta frameworks like Next, let's say, we end up working with a ton of different modules.

[00:05:57] And we have tools like NPM, which is a way of downloading, and installing, and essentially including those modules in our project so that we can import from them, even if we don't have them kind of as a file that we've written next to our main program file, yeah?

>> So if I have a HTML page and I wanna split it into modules and generate parts of the webpage, what would you recommend to get started?
>> So if you're working locally, you're saying you want to kind of develop a site and split up the code across multiple modules, like we just saw in the module or Doggo Fetch example.

[00:06:45] But we wanna work, we wanna develop on our computer before we put it out on the Internet for the whole world to see. There are a few different options. For example, if you're used to working with another programming language that runs on the backend like Python, for example, you can run a simple Python script that starts up a server that serves all of the files in a certain directory on your local computer, just locally for you.

[00:07:10] And that will satisfy the browser's security worries. But if you're working in just a JavaScript universe, you're probably going to be using Node and some kind of program that you're downloading from NPM that has an ability to launch a server. So, for example, Express is a framework, I guess you could say, for running websites with JavaScript on the backend.

[00:07:44] So Node can let you use Express to run a server locally. And then there are other frameworks and things like, basically, tooling that allow you to use something like NPM. You might for example be following some tutorial, they'll have instructions on how to install the project. You'll download, maybe, a zip file, or maybe you'll clone a git repository onto your local computer.

[00:08:16] And then it'll give you some kind of command you might run something like a start command, which launches off a bunch of functionality that that developer has already written for you that starts a server locally so that you can develop and tweak the project. So it really depends on different projects.

[00:08:33] There's lots of different ways of doing it. But if you want to get started with that kind of local server running, you're probably gonna wanna look into Node, next, yeah?
>> Yeah, I would probably say that something like 11ty would be a great project to start with. Cuz, essentially, what they're looking for is a CMS, right?

[00:08:57] And being able to load pieces of HTML into the header or whatever. So 11ty is a great place to start cuz it's a static site builder.
>> Yeah, so, for example, yeah, this is a very popular, simple site builder, 11ty, that you could use to, let's say make a blog or something like that.

[00:09:19] And it has a pretty simple workflow for running it. So you can read, it's,, you can read about it there. There are some other ones that you might run into out there, like one that is starting to get more attention in the web communities, Astro, for example, but that's a little bit more complex.

[00:09:44] And then you might find that if you are working with a framework like React, or what have you, you have some tooling like Create React App is a little starter kit for React that can also do this kind of local site running. And then, another really, once you're getting into much more complex sites, you might find a Next.js comes up.

[00:10:11] So these are a few great things to be aware of. I second Mark's recommendation, 11ty would be a fun thing to try if you'd like to start building a site locally with JavaScript. So you can read up about that, and I'm sure it's also mentioned in some other courses on Frontend Masters.

>> Another option would be Gatsby, and we have a Gatsby course.
>> Uh-huh.
>> That's another good option. But, yeah, there's lots of these kind of.
>> Yeah, so Gatsby.js is another kind of system for running this. And I think there's some courses on Frontend Masters about, and there's also, yeah, more generally kind of a Next.js is-

>> We also have [INAUDIBLE].
>> Yeah, exactly, there's something very, this is something that you see a lot in professional settings. A lot of professional teams are working with tools like React and Next.js. They kind of go hand-in-hand. So as you go deeper into your journey, you'll encounter more of these kind of systems.

[00:11:21] And the other kind of things that you'll notice is, if you start, if let's say you join a team that's working with JavaScript, they might be working with a particular framework like React. They might have their own way that they build and serve their sites. So they might have their own instructions for how to be doing that locally.

[00:11:43] So essentially each different project that you work on, or that you work with, might have a different approach for doing this, and for working with modules, and for structuring modules, and for organizing modules in a huge complex code base. Yeah?
>> The final note I just wanted to mention because I ran into it when I started using JavaScript Modules, is the fact that the browser caches these modules.

[00:12:13] And so you might change some code and then you try to load your browser and the code doesn't change. And so you have to hold the Shift key and hit Refresh-
>> Mm-hm.
>> For hard Refresh.
>> Yeah, so remember we said the two hardest problems in computer science are cache and validation, naming things, and off-by-one errors.

[00:12:31] [LAUGH] So caching is a really complex topic that what the browser's trying to do is it's trying to load your site as fast as possible. And so it's going to say, that utilities script, that utilities module, excuse me, that you loaded that one time, I've already seen it before.

[00:12:48] So I'm just gonna remember what happened when I loaded that before. And I'm going to use those functions that it exported to give to you whenever you reload your page. But if then you go in and you edit your utilities file, and change one of the functions, the browser says, well, I already remember the old ones, so you have to manually tell it, hey, hey, hey, don't use the cached version with the Shift+Cmd+R instead of just Cmd+R or Ctrl+R.

[00:13:17] So, yeah, that's a great point, Mark, thanks for mentioning. But suffice it to say, modules do get very, there's a lot to be said. There's a lot of complexity and there's a lot of history here, of how the JavaScript and the web community, I would say we're even still in the progress of moving to a modular existence.

[00:13:37] Because, again, JavaScript was created back in '95 for just running a few lines of script code to edit or add a little bit of interactive flair to an HTML page. And now we're building hugely complex projects with it. So this is part of the fact we said, JavaScript is a moving target, JavaScript is a living, breathing ecosystem, and modules are a relatively new concept to that ecosystem.

[00:14:12] So if you find this interesting, you can dig way deeper and you can take some of the other courses that go into more details about working with modular and JavaScript code.