Beginner’s Guide to Web Development: Supercharge your Productivity with a Bundler

Back in the simpler days of web development, you would create an .html file in any text editor and open it in your browser to see it formatted nicely. To make changes, you’d update the file and refresh the browser. That was it. Contrast that with the following popular rant:

How it feels to learn JavaScript in 2016

Thousands of web development helper tools are improved upon every day. If used properly, incorporating them into your development environment will make you infinitely more productive. But unfortunately, using all these tools means that proportionally more time is spent managing and configuring them than writing code.

Enter: The Bundler.

A bundler helps web developers manage a group of tools that solve related problems. You can think of it as a “meta-tool,” where each sub-tool is managed by a plugin. Although bundlers can be used to do all kinds of fancy stuff, we will focus on three sets of problems here that apply to any web development project:

• Transpiling higher-level languages into HTML, CSS and JavaScript
• Serving files on an ad-hoc HTTP server with live-reloading
• Preparing the application for production: minify, concatenate, uglify

Transpiling languages into HTML, CSS and JavaScript

The Problem

Web browsers can natively only interpret three languages that work together to form what we know as a “web site” or “web application.”

• HTML is primarily used to structure content.
• CSS defines how that content is styled.
• JavaScript allows us to dynamically change content and styling, based on user interactions and other events.

These languages are defined by standards created by various non-profit technology organizations (W3C and ECMA). Naturally, the standards themselves evolve faster than stable and secure browsers can support them. But us developers want to write code in the new standards, because they make us more productive.

Additionally, developers have invented more succinct/easier/readable languages on top of these three basic ones that are preferable to code in. Here are a couple examples with sample code snippets for comparison:

• HTML: Pug, Haml

<!-- HTML -->
<div class="mycontainer">
  ...
</div>
// Pug
div.mycontainer
  ...
// Haml
%div.mycontainer
  ...

• CSS: Sass, Less

/* CSS */
div.mycontainer {
  background-color: gray;
}
// Sass
div.mycontainer
  background-color: gray

• JavaScript: ES6 aka ECMAScript 2015, TypeScript, CoffeeScript

// JavaScript
var addOne = function(a) {
  return a + 1;
}
// TypeScript
let addOne = (a) => a + 1;

The examples shown here may look trivial, but each language really does offer some substantial improvements over their basic counterparts.

If you are still writing plain HTML, CSS, or vanilla ES5 JavaScript, it’s time to power up your dev game!

So how can we use these new languages and standards, without direct browser support?

The Solution: Transpiling

Our development environment needs to transpile the languages into the three understood by browsers: HTML, CSS and JS. This should happen quickly and unobtrusively (without any extra steps, after we get everything set up) so we can make changes to our application and see the results instantly. Bundlers can be set up to do this for us automatically, so we can code in whatever languages we please.

Serving files on an ad-hoc HTTP server with live-reloading

Problems

• When you create an .html file on your computer, you can simply double-click it to open it in your browser. It even loads images, .css and .js files. However, the browser reads files directly from your hard drive via the file: protocol. This has some restrictions and differences to the http: protocol, which your application will be served over once it’s hosted on the web. For example, files hosted with file: cannot perform AJAX requests, and the relative file paths referenced in your .html files are handled differently.
• If you’ve ever made an HTML page before, you know how annoying it is to view the changes that you make. You must save your file, switch to the browser, and reload the page. Switching back and forth between windows and pressing “reload” (or cmd + r) becomes tedious very quickly. It would be a huge help to have the browser reload itself automatically when changes are saved to our source files.
• Sometimes we would like to see our changes in the browser without reloading the entire page. Consider a scenario where loading the page involves downloading and displaying data. When we are editing CSS and want to view a simple change, reloading the entire page every time is overkill. Wouldn’t it be nice if any change to our CSS (or Sass or Less) files would cause the browser to instantly re-render the page with the new styles instead of completely reloading it?
• Consider another scenario: We have a web application that relies upon various JavaScript modules. Not every screen needs every module, so only modules needed by a screen are loaded when that screen is loaded. For example, the “settings” screen might require a “settings” JavaScript module. As we make changes to the settings module, we don’t want to reload the page every time, because that would require us to navigate to the settings screen again to see the result of our changes. Wouldn’t it be nice if, upon saving the settings module, only that specific module could be reloaded under the hood, so we could test it instantly?

The Solution: HTTP Server

Running a simple HTTP server on our own local machine allows us to access our files via the http: protocol, mimicking the environment that the files will be hosted in when the site is published. Popular bundlers include an HTTP server plugin.

When set up properly, the bundler can watch your source files for changes. When you save a file in your editor, the bundler can tell your browser to either reload the entire page, re-render the page, or reload the specific JavaScript module.

When editing a file written in a higher-level language like Sass or TypeScript, the code must be transpiled into CSS or JavaScript before the browser is told to refresh. A properly configured bundler ensures that its plugins are executed in the right order.

Preparing the Application for Production

The Problem

While we are developing, even though we are writing our code in fancy languages that get transpiled into HTML/CSS/JS, we want those resulting files to look as close as possible to our original source files for debugging purposes. So when you get an error in your browser’s developer console like this one:

…you can click on test.html to see what code caused the error, or easily find the relevant line of code in your text editor.

However, when publishing your code, you typically don’t care about debugging it. (It should work perfectly, right?) Instead, priorities lie in maximizing performance, minimizing bandwidth and possibly purposefully obscuring your code. These are achieved via three processes: Minify, concatenate, and uglify.

• Minify — When we write code, we use lots of spaces or tabs and relatively long, comprehensive variable/function names to keep things clean and easy to understand. The extra characters needed for this nice formatting are completely unnecessary when interpreted by the browser. So to keep our file sizes down, we want to automatically remove whitespace, and replace JavaScript variable and function names with the shortest ones possible.
• Concatenate — Again, to help structure our code, we often split it into as many files and folders as we want. This allows us to stay sane with complicated projects. But when serving all this data in a production environment, it’s faster for the browser to download and parse a few large files than many separate smaller ones. Many developers prefer their web applications to consist of three files: one index.html, one .css file and one .js file. So we need a process that will combine lots of code from related file-types into a few files.
• Uglify — When writing code in compiled programming languages like C++ and Swift, you typically publish your application in compiled machine code instead of source code. Machine code cannot be read by humans, and is difficult to reverse-compile back into the source. This deters competitors and hackers from misusing your application. Conversely, HTML is a markup language, CSS is a stylesheet, and JavaScript is an interpreted scripting language. That means that the code you write is the same code sent to your users’/customers’ browser, which can be easily read and copied by humans. To combat this, many developers “uglify” their code before publishing it. This deforms the code to make it harder to decipher, for example by renaming variables and functions to be relatively incomprehensible.

Setting up each of these processes to run in the proper order and for the right situation is no small feat.

The Solution: Bundling!

Again, bundlers can do all of this for us. They allow us to set up various series of tasks for different purposes, like developing, testing, and production. Each series can be configured and tweaked to your heart’s desire.

When active, whenever a change to a source file is detected, the bundler can re-process and bundle your app appropriately.

Conclusion

Bundlers can solve an infinite number of problems, but the ones mentioned here are useful for any serious web developer.

Popular Bundlers

The most common bundlers for web development today are webpack and Grunt. They each have their own configuration syntax that, while very powerful, come with a steep learning curve. Gulp is another popular choice that many developers find easier to understand. And Brunch is yet another contender that strives to need even less configuration to set up.

New kid on the block: FuseBox

FuseBox is an open-source bundler project started in October 2016. It attempts to solve all problems mentioned here out-of-the-box, and more, with less configuration than any existing bundler tools.

Version 2.0 was released in May 2017. The following in-depth tutorial will walk you through how to set up FuseBox to handle all the issues mentioned above. Spoiler alert: It’s pretty easy. Try it out!

Introduction to FuseBox - a Faster, Simpler Webpack Alternative - SitePoint

Made it to the end and learned something? Leave some love 💚

Peter LoBue is a freelance UX designer, web developer and iOS developer living between Philadelphia and San Francisco. Reach out for availability: @pejalo