Frontend bundlers minified

Frontend web development has truly evolved at an extremely rapid rate, it’s pretty impressive that we have moved from writing HTML to almost no HTML at all and mostly writing JavaScript (JSX)! All that advancement is made smooth and possible by programs working behind the scenes to take our code and give it to the world, Bundlers give us a lot however no one talks much about them, lets ‘minify’ these complex programs and make sense of how they have evolved over the years and helped us while also seeing their state today

Websites are simple.

In theory, a website (like the one you are looking at right now) is a simple dish prepared with 3 ingredients. CSS, JavaScript and HTML. In the end, it’s just these 3 components that make up almost everything you see on your screen.

However with the web being so big, we have websites and multi-function web apps involving millions of users by the day, this calls for more development to meet demands of complex logic, use-cases, and ideas and as a result, your codebase gets complicated by the day.

Today simply using those 3 isn’t enough (and since we developers love to over-engineer things, using plain vanilla is never the answer even if the problem is very simple). Over the years this ecosystem has seen tremendous changes, especially JS, a language ridiculed for being a messy 10-day product has become one of the most used and consumed languages all over the world to the point where Atwood’s Law, seems very much true.

NPM has become the biggest ecosystem hosting millions of packages that get downloaded billions of times a month. With this, we maintain our codebases with powerful tools that make our lives easier by handling the ‘linking’, ‘merging’, ‘integrating’, and ‘managing’ packages almost seamlessly without us even batting an eye. They are of course the unsung heroes: Bundlers.

Bundlers - from ‘let me use require’ to being a must-have

The earliest forms of bundlers weren’t made with the intention of what they do today, one of the earliest bundlers was simply known as += aka concatenation which just combined all your code into a singular file so that your js would not violate the 6 connection per origin limit of HTTP/1.

Then came browserify, one of the first non-concatenation bundlers that solved a simple problem, it allowed developers to use nodejs code in the browser, making it easier to share code and make it reusable, thanks to browserify we can have shared libraries that work in the backend as well as frontend.

A new challenger appears

with time node saw a huge spike in adopters mainly due to the rise of React, as react grew in popularity so did the bundler that came with it, Webpack. People realized the way it created a dependency graph across all assets in a website was extremely convenient and dev-friendly. Webpack even took liberties making some code work that was not supposed to work on node, for example:

require("styles.css")

or

const Logo = require("./assets/logo.svg")

This meant frontend applications could be efficiently modularised and split into ‘components’ for an extremely better development experience. Features such as code-splitting, loaders, etc made webpack a no-brainer.

Hail the king

With this Webpack was crowned the king of the bundler space with its huge set of features, backed by prominent developers and making everything ‘just work’. This was a time when browsers used an old version of JavaScript, while developers developed in a ‘newer’ version. Soon we had modern syntaxes and tree shaking coming up. With those

const library= require('library')

// caused the whole size of library added to bundle

Now became the ‘newer’ ‘cooler’

import {module1,module2} from 'library'

// causes only sizes of module1 and module2 to be added selectively

While webpack had features made to keep everyone happy, newer bundlers came up providing their solutions and alternative approaches to webpack. These were Rollup and Parcel.

Soon these ‘upcoming’ bundlers also gained popularity with many projects adopting them.

Rollup Offered a modern syntax and deeper analysis of your code, excluding anything you don’t use to make smaller bundles.

Parcel favored faster build times with zero config making it ideal for rapid prototyping where setting up has to have the least overhead.

The ESNext era of today

Today browsers have become more than capable of running the latest javascript, earlier:

const a = () => console.log("i am a cool arrow function")

// This would not work

function a() {
  console.log("i may not be as exciting but I get the job done")
}

//This would work

but today browsers support all the ‘cool’ features. as of today, browsers have full support for things like nullish coalescing

null ?? "default string" // gives 'default string'

and optional chaining

const obj = { a: "I exist" }

console.log(obj.a) // 'I exist'

console.log(obj.something.shouldThrowError) // gives an error

console.log(obj?.something?.shouldThrowError) // gives undefined

Which were implemented rather fast, this meant bundlers would have to do lesser work to actually ‘bundle’ your codebase and implement a newer approach to ‘keep up with the times’

Throwing other languages in the mix

Now that bundlers were actually doing such complex and sometimes heavy work it was pretty evident that simply JavaScript won’t be able to meet the performance requirements

We soon had projects leveraging other high-performance languages like rust and go, NextJS by vercel introduced their rust compiler for faster builds and improved performance, and one of the most impressive projects written in go that provides ‘a build step 10×-100× faster than Node-based bundlers’, ESBuild.

Enter ESBuild and Snowpack

ESbuild is actually seen many by a game-changer by many in the industry as it ensures extremely fast build times. However, it’s yet to become production-ready for the big projects to seriously think about using it.

Snowpack was the ‘newer’ bundler having support for ESNext, meaning you could write code and directly ship it to the browser as it is without ‘bundling’ or doing any magic to it. For instance:

import React from ‘/web_modules/react.js’; // This would work in your browser

Snowpack actually uses esbuild behind the scene using it for some of its processes, it offers more features like caching and removing duplication of code via its own method of exposing the ESM (ECMAScript Modules) import tree so that browser does the ‘linking’ and figures stuff itself. This means we can have only the modified files sent to the browser and cache the non-modified ones giving faster updating. However there’s some cases where webpack could still perform equally well (like when you have a lot of import statements). However Snowpack gives you the freedom to choose your own bundler if you do need to bundle, it still focused more on developer experience and didn’t solve bundling needs, hence is seeing slow adoption.

But it all changed when the new player came.

Vite - The new kid in town

Created by Evan Yu, the developer behind Vuejs, vite is a build tool that has seen a very fast adoption with big frameworks like svelte kit, astro adopting and becoming an instant favorite among developers all over.

It also favors the no bundle approach of snowpack but uses a more mature bundler - rollup and esbuild for dependency pre-bundling. It’s far more opinionated and has a ‘batteries included’ ideology.

Many features like css-splitting, extremely fast performance, lib mode, and async chunk loading make it look like today’s ‘no-brainer’ similar to webpack. The backing its receiving is very similar to webpack in its infancy and points to an extremely promising future. if you haven’t yet, do try vite for yourself. The difference between cra and a vite project is impressive. It’s as simple as

npm create vite@latest

The great thing about Vite is it not only improves developer experience with its Hot Module Reload but also improves build times at the same time making it a perfect middle point between snowpack and Rollup, the Antstack Frontend team is testing its waters with vite for being the full-time bundling and development tool and have seen great success

The Future Era

With browsers being more capable by the day, maybe there might be a day where we just hand over our code to the browser and it does everything. With deno coming soon and bringing a new approach to doing things, maybe the future of bundlers.

So this was a quick insight into tools that work hard in the background and how they have evolved over the years to help us center that div even faster and in more than one framework!!