Applications forever on the web (aka ~2013+) have required a way of doing the following:

• Make a decent UX for developers
• Make ways to work in teams
• Make conventions that help those teams collborate
• Run something that makes those collaboration methods be smashed together and run on the web
• Deploy that thing and it works for everyone in every browser

React / Angular / you name it, usually leans on appliances like Webpack or Rollup to help accomplish this. These tooling workflows take all your stuff, web native and otherwise, smashes it together and gives you something you can send to a browser and whala an application exists!

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.

unbundling

Unbundling 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 unbundling:

• 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

Next up

So now that we have the background of what Bundling vs Unbundling is, what does this look like for PSU with web components? We'll dig into this in the next post.