What is Webpack and why should I care? [Part 1][Introduction]
WHO IS THIS SERIES FOR?
The merits of nodejs are beyond the scope of this tutorial. To learn more, go to https://nodejs.org. It is assumed that you are using the node package manager for these tutorials.
Web applications are also programs, and I will use the term interchangeably throughout my blog
WHAT ARE WE BUILDING?
We are going to build a lightweight application called
Caterpillar that demonstrates using Webpack to load
Ahead of Time Compilation and
Tree Shaking by the end.
WHAT IS REQUIRED FOR THIS SERIES?
- You are expected to have the node package manager installed; yarn is an acceptable equivalent, if you are familiar with it — but the tutorial will assume
- You must have internet access.
- You are running any version of
Apple OSX, or any flavor of
Linux. You do not need to know any intricacies of the operating system.
- You should know some rudimentary
- It is assumed you have a preferred development environment, such as Notepad++, Atom, Visual Studio Code, WebStorm, etc. This tutorial should work no matter what you are using, as it is completely agnostic of the development environment.
- It is assumed you know how to open and run a terminal in Windows, Mac OSX, or any flavor of Linux well enough to do the following;
— move between directories
WHAT IS WEBPACK?
Webpack is a module builder. This is important to understand, as Webpack does not run during your page, it runs during your development.
Webpack is a tool wherein you use a configuration to explain to the builder how to load specific things. You describe to Webpack how to load
*.js files, or how it should look at
.scss files, etc. Then, when you run it, it goes into your entry point and walks up and down your program and figures out exactly what it needs, in what order it needs it, and what each piece depends on. It will then create bundles — as few as possible, as optimized as possible, that you include as the scripts in your application.
Some developers feel using module loaders is unwise, and prefer the old fashioned style of manually doing everything. There is certainly still merit to understanding all of this, and you should not feel compelled to use a module loader — however, there are as many arguments for how module loaders improve the development process. I personally feel it is wise to use them, but you should experiment and find out for yourself what works the best!
HOW IT WAS
Once upon a time, we had very few scripts on a webpage. You would include them with a few simple lines, such as this;
This was a simpler time, when pages had few or sparse scripts. You could fit everything in a few files, and you could easily load them without conflict.
HOW IT IS NOW
In the last 10 years, the entire scope and spectrum of web development has completely changed. Now we have dozens of scripts, each with a different purpose, each oftentimes created by a different person, each with different requirements.
It’s not uncommon for a modest, or even a small website to need several script libraries. What is more, these libraries oftentimes depend on other libraries — called “dependencies”. Not only do you have to load these scripts, you have to understand what they need to have loaded first!
ASYNCHRONOUS BY DEFAULT
This behavior is called asynchronous — it means that when the executing context (in this case, the web browser) encounters code, it begins to run it, but keeps going before it finishes.
SEND IN THE MODULES
The problems with scripts are so pervasive that the entire development community as a whole set out to solve it; This emerged as a series of standards called modules. The idea behind modules is a standard way to encapsulate scripts in such a way that they can be referred to as a package, and they can be loaded easily, and declared as dependencies of other modules. Ideally, this would allow everything to load where it is needed, to understand what it needs, and to keep the overhead slim.
LOADERS TO THE RESCUE!
There are many module loaders, but some of the most popular are Webpack, SystemJS, JSPM, RequireJS, and RollUp. This series of tutorials will focus on Webpack because it is the loader of my choice. There are more module loaders that I’ve not listed, as I obviously have not experienced all of them.
Please note, I am not advocating Webpack as being better than any other loader. It is the loader I choose, It is the loader I like. Every loader out there is incredibly useful and used by many various companies. In fact, many companies use different loaders for different parts of a project in large applications! As an example, Google’s Angular uses Webpack internally with its @angular/cli, but it uses RollUp to create the @angular packages!