CDN dependencies vs npm + Vite (build pipeline)

[Gaurav0]

CDN dependencies vs npm + Vite (build pipeline)

This note compares loading libraries from a CDN with installing them via npm and bundling with Vite. It assumes exact versions are already pinned on the CDN (stable URLs / SRI), so reproducibility of what loads is not the main differentiator.

Advantages of npm + Vite

Modern JavaScript
You can use TypeScript, JSX, Vue SFCs, path aliases, and tree-shaking. The bundler ships only what you use.

Development experience
Fast HMR, clear error overlays, and a single dev server instead of juggling multiple script tags and global variables.

Fewer globals and clearer modules
Dependencies are explicit imports; less reliance on window.* and load order.

Optimization
Code splitting, minification, asset hashing for caching, and (with plugins) image optimization — harder to match with hand-wired CDN scripts.

Ecosystem
You get the full npm registry, not only what vendors expose on a CDN.

Security workflows
With a pinned CDN URL you control which released artifact you load, but you cannot remediate transitive vulnerabilities inside that artifact the way npm can. For example, the released Mocha version this project uses has known issues in transitive dependencies. From a CDN you accept Mocha’s bundled dependency graph as-is. With npm, you can use npm audit, package.json → overrides (scoped under mocha or other parents), and lockfile updates to record, audit, and patch nested packages without waiting for upstream to bump ranges — while keeping dev vs production scope clear (e.g. test tooling vs site bundle).

Disadvantages / tradeoffs

Build step
You need Node, CI that runs npm ci + vite build, and somewhere to host built assets (or a framework that does this for you).

Operational complexity
Compared to “drop a <script src=…> in HTML,” you maintain package.json, lockfile, and possibly more CI/cache tuning.

Learning curve
Team members need to understand modules, env vars, and how Vite fits into deploys.

Not always faster for tiny sites
A minimal static page with one library from a CDN can stay very simple; a full pipeline can be overkill if you truly only need a few globals.

Pinned CDN already mitigated “surprise updates”
The migration is less about version drift on the wire and more about DX, language features, bundling, and end-to-end dependency management.

CDN cache behavior
Popular libraries on shared CDN hostnames can still benefit from cross-site caching in some environments; self-hosted Vite output is cached per-origin. Browser privacy changes have weakened the old “everyone shares jQuery” effect, but the tradeoff remains.

Summary

With exact CDN pins, the strongest argument for migrating is not “we need pinned versions” — you already have that for those assets. The remaining reasons are tooling (TypeScript, imports, Vite dev), bundling and performance, unified dependency and security workflows (including transitive fixes via npm), and maintainability as the script surface grows. The main downside is introducing and operating a build pipeline where pinned CDN scripts were enough.

[Gaurav0]

Some more cool advantages with vite I'm discovering:

1. We can remove the huge item-metadata.js from being committed to our repo. It can exist only in the dist directory and be .gitignore'd.
2. We can use CSS modules with vite! These are bits of CSS scoped to our components that cannot be overridden accidentally from outside. Uses scoped CSS in both development and production.
3. We can optimize our runtime modules sizes for performance in production. Instead of dozens of tiny modules + 1 big item-metadata.js module, we can have 1 ~100kb module for all the source js, and 1 -20kb module for vendor js (including mithril, etc.) and 1 ~1.3 MB module for item-metadata.js (or even split the last one for much better performance). I'm already seeing decent perf improvement in Build with Vite and import item metadata as module #413 and we're just getting started.
4. We're moving from testem to vitest-browser and playwright! This is a modern test runner now being used by everyone rather than the clunky 15 year old thing (although TBH I kinda liked it in a nostalgic sort of way).

One more disadvantage:

1. We have to copy the huge spritesheets directory into dist. (Whether from it's current location in spritesheets or if it were moved inside vite's special public folder.) This currently takes more than 5 minutes (the first time or in ci) even with all the optimizing I've been able to do. Hopefully it will get faster as @jrconway3 works on converting everything to use the new palette system.