Enter Webpack

So, you now have beautiful frontend and backend code. Great! It looks so pretty sitting there on your laptop… so what's the next step? Publishing it to the world! It sounds easy, but when we have advanced JavaScript usage, such as with React, there are a couple more steps we might want to take to ensure our code is running at peak efficiency, all dependencies are resolved, and everything is compatible with modern technologies. Additionally, download size is a major consideration, so let's explore webpack, a tool to help mitigate these concerns.

We will cover the following points in this chapter:

• The need for bundling and modules
• Using webpack
• Deployment

Technical requirements

Be prepared to work with the code provided in the Chapter-16 directory of the repository: https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers/tree/master/chapter-16. As we'll be working with command-line tools, also have your terminal or command-line shell available. We'll need a modern browser and a local code editor.

The need for bundling and modules

Ideally, everything will work seamlessly on a website, without the need for any additional steps to be taken. You take your source files, drop them on a web server, and voilà: a site. However, this isn't always the case. For example, with React, we need to run npm run build to generate an output distribution directory for our project. We might also have other types of non-source files, such as SASS or TypeScript, which need to be converted into native file formats that the browser can understand.

So, what is a module? There's the concept of modular programming, which takes large programs and separates them by concern and encapsulation (scope) into smaller, contained chunks called modules. The ideas behind modular programming are many: scope, abstraction, logical design, testing, and debugging. Similarly, a bundle is a chunk of code that a browser can easily use, usually constructed from one or more modules.

Now here's the fun part...

Using webpack

Now, webpack is one of many modular tools that can be used in your program. Additionally, unlike React scripts, it has use outside of React: it can be used as a bundler for many different types of applications. To get our hands dirty, let's create a small, useless sample project:

1. Create a new directory and navigate into it: mkdir webpack-example ; cd webpack-example.
2. We'll be using NPM, so we need to initialize it. We'll also accept the defaults: npm init -y.
3. We have to then install webpack: npm install webpack webpack-cli --save-dev.

Note that we're using --save-dev here because we don't need webpack to be built into our production-level files. By using dev dependencies, we can help reduce our bundle size, a factor that can slow down applications if it bloats.

If you look in the node_modules directory here, you'll see that we've already installed over 3.5 thousand files from our dependencies. Our project is fairly boring as it...

Deploying our project

We've done a lot of development work so far, and now it's time to try a production build of our project. Run npm run build and, well, it's not quite so happy, is it? You should get some warnings like this:

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets: 
  index_bundle.js (263 KiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
  main (263 KiB)
      index_bundle.js


WARNING in webpack performance recommendations: 
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/
Child HtmlWebpackCompiler:
     1 asset
    Entrypoint HtmlWebpackPlugin_0 = __child-HtmlWebpackPlugin_0
    [0] ./node_modules/html-webpack-plugin/lib/loader.js...

Summary

Webpack is our friend. It modularizes, minifies, chunks, and makes our code more efficient, as well as warning us when certain pieces aren't properly optimized. There are ways to silence these alerts, but in general, it's a good idea to listen to them and at least try to resolve them.

One burning question, though, that remains unanswered: doesn't increasing the number of files downloaded increase the load time? This is a common misconception that's hung around from the early days of the web: more files == more load time. The fact is, however, that multiple browsers can open many non-blocking streams simultaneously, allowing for a more efficient download than one huge file. Is this a solution for all multiple files? No: a CSS image sprite, for example, is still a more efficient use of image resources. For performance, we must toe a fine line on how to provide the best user experience, while combining that with the best developer experience. Entire books are...