Less JavaScript, More Leverage: Why I Ship With a 35KB Budget
The default web stack in 2026 ships 200-300KB of JavaScript before a single line of business logic runs. Framework runtime, router, state management, build tooling overhead - it adds up fast. For a lot of products, especially content-driven ones, that's a terrible deal.
I'm not here to tell you React is bad or that you should never use a framework. I use whatever gets the job done. But for the class of products I tend to build - content sites, internal tools, lean MVPs - I've found that aggressively limiting JavaScript is one of the highest-leverage decisions I can make.
The cost of JavaScript nobody talks about
The conversation usually stops at "bundle size," but that's the least interesting cost. The real expenses are:
Time to first meaningful interaction. Every kilobyte of JavaScript has to be downloaded, parsed, compiled, and executed before the user sees a working page. On a mid-range phone on a 3G connection - which describes a large chunk of the global market - the difference between 35KB and 300KB is seconds, not milliseconds.
Ongoing maintenance burden. Framework upgrades, breaking changes in build tooling, dependency security patches, hydration bugs that only reproduce in production. A team of one or two can't afford to spend 20% of their time keeping the build green instead of shipping features.
Failure modes. A heavy JS app that fails to load shows a white screen. A progressively enhanced HTML site that fails to load JavaScript still shows content. For a content product, the second failure mode is dramatically better for the business.
Hiring and onboarding. "You need to understand our Webpack config, our custom SSR pipeline, and the specific version of our framework's routing conventions" is a much harder job description than "you need to know HTML and can learn the rest in a day."
What I use instead
The stack is intentionally boring:
| Layer | Tool | Why |
|---|---|---|
| Content | Markdown + frontmatter | Authors don't need to touch code |
| Build | Node script (build.js) |
One file, no plugins, no config |
| Components | Native Web Components | Browser-native, zero runtime |
| Interactivity | HTMX (~14KB) | Declarative, progressive enhancement |
| Hosting | Static CDN (Netlify) | Effectively free at most traffic levels |
Total JavaScript shipped to the browser: ~35KB. That's 85-90% less than a typical React/Vue setup, and the user experience is indistinguishable for a content product.
Where this approach wins
Content products. Blogs, documentation sites, knowledge bases, media properties. The core value is the content, not the UI interactions. Shipping less JavaScript means faster page loads, better SEO, and lower hosting costs. This site is the proof - the full architecture and build pipeline are documented in detail.
MVPs and validation. When you're testing whether an idea has legs, every hour spent on build tooling is an hour not spent talking to users. A static site with HTMX for interactivity can be live in an afternoon and costs nothing to run while you validate.
Internal tools. Admin panels, dashboards, CRUD interfaces. These rarely need the interaction complexity that justifies a full framework, and the people using them care about speed and reliability more than animations.
Marketing and lead-gen. Landing pages where every 100ms of load time measurably impacts conversion rate. Less JavaScript is directly more revenue.
Where this approach doesn't win
I want to be honest about the boundaries. If you're building:
- A real-time collaborative editor
- A complex drag-and-drop interface
- A product with deep, stateful client-side interactions (think Figma, not a blog)
...you probably need a framework, and you should use one without guilt. The minimal approach isn't universally correct. It's correct for a specific class of products - and that class is larger than most developers assume.
The compound effect
The individual benefits - faster loads, cheaper hosting, simpler debugging - are nice but not transformative on their own. What matters is how they compound over time:
- Less infrastructure means more time on product.
- Fewer dependencies means fewer surprise breakages.
- Simpler builds mean faster iteration cycles.
- Lower costs mean longer runway.
For a solo builder or a small team trying to ship something real, those compounding advantages are the difference between a side project that stalls and a product that ships. I'll take 35KB and a boring stack over a cutting-edge framework and a six-month build cycle, every time.
If you want to see progressive enhancement in practice, the HTMX + progressive enhancement article walks through the mechanics. For the analytics side - proving that lean stacks can still give you real data - see the analytics pipeline.