The very first question anyone should ask before using any tool is “WHY?” Why do I need it and what’s the benefit? If you have almost no idea about webpack, then big chance you are already asking these questions, for me, the situation was that the framework I used to work with decided to switch to webpack for the assets/JavaScript management, and as result I found myself struggling to understand how webpack works and wondering how to make the switch to adjust my code accordingly, if this sounds familiar to you, this book will help.

In the following introduction, we will discuss a little bit about why webpack and why you should even care about it. If you are looking for a quick answer, it should be this: your JavaScript development will be fun and much easier! Too good to be true?

I admit, I wasn’t a fan of webpack, and the reason was that I never took the necessary steps to learn it or understand it. In fact, I was taking the wrong approach, trying to copy snippets from here and there, or looking for quick answers on the internet to find out why my JavaScript compilation failed. Mostly I was stuck for long hours searching without moving ahead to what I was supposed to be doing. During that time, I started to notice other people complaining about webpack, asking how to install this or that, and why their preferred third-party libraries weren’t working anymore, especially in the world of web frameworks. It was a shared feeling, and to be honest learning another Javascript tool wasn’t a fun option, so I kept myself stuck until I changed my mind. That’s when I decided to figure things out for myself, which has led to a long journey with webpack, but if someone had handed me a book like this one back then, without any doubt, it would have saved a lot of time, frustration, and many hours of trial and error.

JavaScript is becoming more and more complex, and if you have a big project or app that will someday grow to a certain size, webpack will eventually save your day (we will see how over the upcoming chapters). One of the main things webpack will do for you is to compile your JavaScript to one file or more. For example, you can have two final scripts if you prefer to call one JS file in one page and a second one on another page.

Compiling your JavaScript into one file will prevent multiple server hits. Let’s imagine you are using many third-party libraries like jQuery, Tinymce, Bootstrap, Loadash, and so on.

The same principle applies to your own JavaScript files. Plus, you can add a hash string to your files name to bust cache and to reduce your site/app time load. Webpack has you covered.

Is this all that webpack will do for me? If you have ever used another build tool like gulp or Grunt , these tools were already doing this and doing it really well. All your JS code, for example, was concatenated and compiled into one file with a hash string as well (for caching) and life was far easier. However, have you ever thought about global variables and collision when concatenating multiple files into one and how they can cause a problem if you don’t use classes or wrap every file’s code with an Immediately Invoked Function Expression?

Well, with webpack, all these problems are solved out of the box for you, no need to reinvent the wheel. Also, one of the features I like most about webpack is how it will manage dependencies for you, and decide which file is necessary to load before another one, etc. I was faced with this situation in one of my projects and it was a huge pain to keep track of every file I needed to load, and which one depends on the other so that I can have them set in the right order. Maybe you have a small project right now and you don’t see the benefit. But as your JavaScript keeps growing, you will see how much benefit webpack will bring you, and you will be thankful that you made the right decision from the beginning.

That’s not all. Webpack can also manage your HTML, CSS, IMAGES, and other files like fonts (via loaders and plugins). I think the best way to think of it is like a manager of your assets. If you ever visited the webpack official website, you probably have seen the following image.

Source: https://webpack.js.org/

This illustration shows how each of your files (on the left side) may have one or more dependencies (your files could be of different types like png, sass, js, jpg, cjs, etc.), and how webpack can take care of them and turn all this chaos into one or more organized file(s) to serve your assets from.

Webpack can do a lot more than what I have described so far, and we will see the many things you can do with this powerful tool through concrete examples in the following chapters.

Webpack is a vast subject, and there are always new things and improvements being added to it. My goal is not to cover everything about it but to help you understand how it works so you can use it in your daily work (probably with your own preferred web framework) without having trouble understanding why things are done in a certain way, or why we use this loader, alias, etc. In short, this will help you to stop saying, “I don’t know how it works but it works!”

Another thing to know (as previously mentioned) is that most web frameworks have adopted webpack recently for building and compiling JavaScript; and if you are using a framework like Symfony or Rails etc, you may find that webpack is already configured and ready to use out of the box. This alone is a huge win if you had to configure it by yourself, but in order to use it, I believe that you need to learn a little bit about the configuration and how loaders and plugins work. Once you learn that, you will be able to see a very clear picture of how things will be used when dealing with your JS inside your X or Y framework . So, whether you are using webpack with a framework or not, just trust me on this, and let’s learn the fundamentals that will make you a problem solver when it comes to using webpack.