Tech Stack Modernization Volumes 1 and 2 covered my thought process behind modernization and a review of Angular.Volume 4 will review my selected framework, (spoiler: it’s Vue.JS), but before I get there I want to write a bit about Webpack and NPM. Both of these are tools that can be used with any tech stack (Angular, React, Vue.JS, etc.), and they bring their own benefits and pain!
Webpack is a “module bundler,” but I think of it as a highly configurable build tool that can be plugged into your project’s tool chain. At its most basic, you process files with Webpack, transform them with various 3rd party loaders and plugins, and then output something different. Sounds pretty similar to a compiler or a tool like MsBuild, and it is except that it’s easier to extend so it can be used for many more purposes. Here are some common uses:
- Process CSS styles in some language other than CSS (like Less, Sass or Stylus), and output to plain CSS (again maybe merging multiple files into one).
- Run various linters to check your code for possible issues, or run unit or integration tests.
Webpack has a neat development time feature called Hot Module Replacement. This basically runs Webpack as a local web server, which monitors your input files and reprocesses them each time they change. You write your web app to load scripts from the Webpack dev server, and it automagically refreshes your scripts, CSS (and templates for a framework that supports it) every time the files change, without refreshing the browser! It’s pretty cool to edit a file, save it and then see it appear in your browser instantly. It does have some extra challenges associated, but for the most part works pretty well.
Webpack also helps solve module dependencies. You can use
require() calls—or better, the new
This is also used to support an advanced feature called code splitting. Imagine you have a Single Page Application (SPA) with 10 different areas (or views or whatever) in it. You can use code splitting to put the code for each area in different bundles, which can be downloaded dynamically only when the area is actually accessed. This is pretty easy to enable, and adds a huge performance boost when users first load your application. They would only need to download a main script and the script for the first area, instead of all 10 areas.
Webpack is not without downsides however. It has notoriously poor documentation, and while it has a lot of configurability, you can expect to spend hours setting up the proper configuration and debugging your build chain. I fell into plenty of rabbit holes with Webpack and 3rd party loaders. I eventually got where I wanted to go, but not without some frustration along the way.
You could instead look at a Webpack competitor (like Gulp or Grunt) to get similar functionality. I focused on Webpack because it’s widely used, has active 3rd party loader/plugin development, and a developer I trust said that Webpack had won and we should just use it despite the configuration headaches!
I have a love/hate relationship with every package manager. I like how easy they make it to grab modules and libraries. I like how they automate managing dependency trees (package A needs package B, which in turn needs package C). The downside though is that they lead to a “kitchen sink” style of programming where packages are added without much thought, and each brings in a host of dependencies—so many that you can’t actually be aware of all of them. It becomes a huge black box.
Modern web development requires aids to support and optimize common use cases like SPAs, and to speed development and improve maintenance. There is no shortage of tools available, and picking a winner is difficult. I hope that you can leverage my experience with Webpack and NPM in your own research into the right tools for your tool chain. Good luck!