When I first started learning JavaScript modules and that topic was the most confusing thing ever for
me, I had a really tough time getting a grasp of the concept.
It took me a year to actually get it, but I've created a mental image in my head to understand a better.
And as we do in this course, we first start with the problem, then go to the solution that we have
now to see where we where and where we are now.
This is the mental model that I've created and I call it climbing the mountain of modules.
Let me explain.
When we first started writing JavaScript and creating websites with JavaScript.
Well.
We had an e-mail file.
And the very first time people are using JavaScript.
You used a script tag and what we called an inline script.
And in-line script is exactly that we just in line all of our JavaScript within the HTML file.
Now, there's problems that I see with this, imagine this getting massive, a massive JavaScript file,
hundreds and thousands of lines of code.
One is the lack of code reusability, and you'll hear this term a lot.
If we need to add another page, maybe in about 30 page, well, we have to copy this code and put it
into the other e-mail file.
And the second was the pollution of the global namespace.
And that is.
Once I use up a as a variable in this case in the window object, well, I can never use a again and
maybe hundreds of lines down by mistake.
I assign a variable A and erase my A function.
Well, that's a huge problem and that's a big problem in general.
You want to make sure that you don't pollute the global namespace.
That is the window object with all these names, because then you have collisions, you have different
team members working on different pieces of the code and all of a sudden we both come up with the same
name.
It's a big problem.
The next attempt was script X, and this is something we've been familiar with instead of having in
line.
We had.
Script X.
And we played around with Bootstrap and Jorquera, this is what we did, we had our Jaquie file Voda
first, then our JavaScript file load a second.
And as you can see, we can have one script filed in the second one, then the third one, then the
fourth one.
This way you have.
Everything outside of the e-mail solves the problem, right?
Well, the problem with script tax, as far as I can see, are three things.
If we need to add another page, like an about page, well, we still have to copy and paste this script
ex.
And again, we don't really want to do that.
The second one is the lack of dependency resolution, and that is you're responsible to make sure that
the scripts are added in proper order.
For example, if this script accesses a function from the number four Dodgiest Followill, it's going
to fail because the number for JS file hasn't loaded yet.
So that's lack of dependency resolution.
And finally, a third, this doesn't really solve the global namespace problem, right?
It's polluting the global namespace.
All the functions and variables that are declared in each of these files will be on the window object.
OK, so what about the third attempt, the ISP that stands for immediately invoked function execution?
I know that's a mouthful, but it looks something like this.
And if he is, it actually wraps a function in brackets so that JavaScript reads this and says, oh,
I have to evaluate this and execute this.
And then.
These brackets at the end says run the function, so after you evaluate this, run this function.
And it was a confusing way to make sure of one thing, and that is by using this method, you don't
pollute the global namespace.
Now, if in the first file you have variable Myalup, they'll be on the window object.
But everything else that's inside a function, as we know, creates a new scope.
So all the files, because they're wrapped in this, if he had their own scope and if you wanted to
add to my app, you just added everything as a property or method.
So awesome that reduced our global namespace to just one, I mean, it's not zero, but the one that's
that's a lot better, right?
But there is still one issue with this.
The order of the files are still important, and I've worked on apps before where we're using so many
scripts that this was close to one hundred skeptic's.
And every time you added a file, you had to make sure that you add it in the right place because that
file might be dependent on another file loading before it.
So as we know, that's lack of dependency resolution.
And frankly, this doesn't look very pretty.
So then we had.
Browser filed this nice looking logo.
Now, what did browser, if I do it, actually used something called Common G.S..
So I'm going to comment that if you out and show you what browser if I did.
It use common gas, which allowed us to use a certain syntax, and it looks something like this, if
I wanted to have on my first JavaScript file a function and I can say module exports, and now in the
second JavaScript file, I could require the.
Add this, fix the strings here and now.
I can add add function into my JavaScript to file.
Browser, if I use this common syntax.
But it's actually a module bundler.
And what does that mean?
Well.
It runs before you put the website online, what that means is it read through all the JavaScript files,
read through all the syntax.
And it bundles everything into a single file.
Once you run all the files through browser PHY and again is just a simple tool that allowed us to just
dump all our secret files, all of these.
And to Bruce, Safai.
And as long as we use the common syntax like this.
It will know what to do and automatically.
Create.
One file.
Usually called something like Mondal Dogs, so all our scripts will just be on one massive file and
yeah, that might be bad when we're actually developing, but when it's out on the Internet in real
world, we don't really care how it looks because we're just doing this to send it somewhere to a server
so that the web can be viewed by users.
This is not what it's actually going to look when developers are working on it, when developers are
working on it.
We just have our own separate files.
We just run it through browser.
Right before we deploy, that is put it out to the public, all right, so.
That was pretty cool, and we're getting closer to the top of the mountain here.
Now, all of these problems here, it was all because JavaScript didn't have what we call a module system
built into the language.
And think of module's as building blocks, as different pieces of code, so instead of having one giant
thing, you have module's each piece is really, really good at doing one thing.
And because JavaScript didn't have this module system, it's the reason we have so many different ways
of importing and exporting modules and there's actually quite a few more that I didn't show because,
well, frankly, it'll just be too much.
But things have recently changed with the introduction of ESX.
We can now.
Do something a lot nicer.
And it looks something like this.
With Essex, we have two new things, export and import, for example, in JavaScript, one file, I
can have a function and you can see them using our functions here, an ADD function, and I simply export
it.
Or I can even do export default.
In the second file, if I wanted to use the add function, all I say is import and then we see here
the structuring.
You might remember this from the S5 S6 video.
And we're simply just grabbing at.
Or if the export was default, which means with this, you can export multiple functions in the same
file versus here you can only export one thing.
So the file only exports one thing.
Well, in that case, we don't need the little brackets.
We can just to add from Adva.
Very cool.
So that's nice.
That reads pretty nicely.
We just put the imports at the top so each fall we know exactly what each file needs and everything
is clean, everything's works, and we don't have to worry about any of this stuff.
Right?
Well, yeah.
Kind of as you know by now, and I feel like a broken record, browsers aren't supporting everything
yet because it's a new feature.
Again, we're still waiting on browsers to implement them.
But this is what this blue thing is for.
It's called the -- and --.
Just like Bruce Safai is a module bundler.
That is a bundles modules, which is bundles, JavaScript files.
And just like Bresser five, it traverses the dependancy tree, which is these export and import tags
into a single file, or it can even have multiple files based on your needs.
And with Webb back, we can actually use S6 in all browsers.
Isn't that awesome?
This is where we are now with climb the mountain of modules and we have a really, really good system
right now in JavaScript.
It was really hard getting there, but we're in a good place right now.
So this is what we're going to be using and this is what the industry is using.
Get used to the syntax.
I'll leave a link at the end of this video so you can check out more.
But when we get to react, we're going to be using this a lot and it's going to be a ton of fun.
It's going to make things really nice and clean for us.
One thing I wanted to show you, you might think, hey, this -- thing seems like it's kind of
hard, like how does it do it?
It's very simple.
It just has a config file just like this.
As you can see, we just have an output that is bundle jobs and we don't need to worry too much about
it.
Usually when somebody is starting a project, it's one person on the team that configures this file
and everything is done.
The rest you just build on top of.
It's very, very simple to get started.
I don't think it's super important for us to tackle right now.
But again, a very, very useful tool and it creates a nice bundled JS file.
So now all our e-mails look nice and simple.
And you know what?
That's it.
We've covered some of the most important topics in JavaScript and some really, really hard topics,
and I know your brain is hurting from all this information, but you've done it.
We've finished the section and previous sections and now we can actually build amazing apps with the
tools that we have.
Can't wait to show you how all these pieces come together to build something amazing.
I'll see you in the next video.
Bye bye.