Thomas Nguyen's Blog
Bundled vs unbundle

Bundled vs unbundle

Thomas Nguyen's photo
Thomas Nguyen
·

4 min read

Up until now, we’ve been using bundlers like rollup and webpack to turn all of those modules into a single JavaScript file that the browser can run (or perhaps several of them, if we’re code-splitting).

There are some potential benefits in not having to bundle things anymore: caching improves since we’re able to handle changes in a single module without invalidating everything; the file structure remains the same (or very similar) between development and production, simplifying debugging; and the build process could become simpler.

That said, can unbundled one replace bundled one?

1. Bundled

Pros

  • Developers write in conventions easiest for them. CSS dev writes a .css file. A JS dev references it via something like const css = require('their-file.css'); or import { css } from "their-file.css";

  • Large teams can have duplication of efforts unknowingly (like importing something 10x across 50 devs). The bundler will "tree shake", realize 10x use this thing and make sure only 1 copy is in the final output.

  • Workflows / tooling trees surrounding this usually allow automation to run the real builds. Lots of people know how to use these things and big teams can slot in a new devops / tooling person

  • JS Devs can use ES5,ES6,ES10, it doesn't matter what syntax / edition of JS mashed together successfully and it'll work on all browsers in the end (reducing platform specific testing) because tools like Babel will transform everything to a browser target and all newer versions work

Cons

  • Have people ensuring that the workflow engine itself is maintained. Devops / engineering in tooling workflows requires maintenance and changes project to project.

  • Developers learn non-standard conventions like importing CSS, JSON and other assets as part of how they code. These conventions are not actually part of the JavaScript standard, confusing people when moving to other workflows.

  • Always looking for the webpack + FrameworkName + thatOneThingICan'TThinkToGoogleCorrectly package name

  • Native ways of deduping assets are becoming faster than JS based processing methods (CommonJS vs native ES Modules of ES6+).

  • New people look at webpack configuration and go "uhhhhh.."

For this reason, Rollup is starting to pick up momentum and while less complex than webpack, it still is tooling. If you use tooling, that's fine. Let's not argue about how good/bad tooling is, I'm simply trying to establish the world view here.

2. Unbundled

Unbundled is gaining popularity because of the work pioneered by Pika Package / Snowpack. The pika manifesto (of sorts) is best summed up in their blog post A Future Without Webpack. If you need convincing that the world will get beyond webpack / bundlers, it's a great write up of the details and how they see snowpack helping solve this.

The basic concepts with unbundled:

  • readable code in end product: Files are shipped in their named form. what/ever/path.js remains what/ever/path.js though they may be compiled

  • Target newest browsers first: The goal is to remove compilers as well (babel) or at least reduce dependency on them by shipping native code as much as possible. Native is not only faster than compiled, it will only get faster over time

  • ES Modules are a native way in evergreen browsers for the browser to resolve dependencies

  • ES modules support "Dynamic Imports" import() and have Promise's, allowing developers to embed application resolution timing on their end without needing a bundler to do so

Pros

  • Assets sit in their normalized path like whatever.com/build/node_modules/my-project/project.js for easier debugging

  • Assets can be leveraged multiple times by multiple applications. Have an accessibility / security issue in 1 asset? Update in once place and all apps fixed

  • No complex bundling routine

  • Code that executes faster client side because it is native to that browsing target (ES8 code will run faster than same code compiled to ES5 for example)

  • 90%+ of global traffic is now Evergreen traffic meaning you can safely serve them ES8 as a minimum target and ES5 to the rest

Cons

  • Can involve larger "bundles" because there's more files

  • Still involves a method to compile at some level; either at the CDN layer (Pika does this) or pre-compiled to multiple formats in order to hit older browsers

  • Assumes HTTP/2 or HTTP/3 capable server. HTTP/1, don't even think about it

Frontend DevelopmentWeb DevelopmentwebpackBundler