Choosing a Framework
Date: 2026-08-19
The choice is made on rendering needs, hiring pool and ecosystem fit — three things that are hard to reverse. It is argued about on benchmarks, bundle size and developer experience, which are the three that stop mattering within a year.
Choosing a framework is picking which decisions to stop making. That’s the whole trade: you accept someone else’s answers on routing, data loading and deployment in exchange for not having to reach them yourself — Libraries, Frameworks and Toolkits.
The questions that differentiate
What does the site need to render, and when? A content site that must be fast on a cold cache, a dashboard behind a login, and a storefront needing per-market pricing have genuinely different answers. This one is first because it’s the hardest to retrofit — Rendering Strategies and Framework Rendering Modes.
Who is going to work on this? A framework three people in the country know is a hiring problem disguised as a technical decision. Related and more often decisive: what do the people already here know? A team fluent in one ecosystem shipping in an unfamiliar one loses more to the transition than any framework difference could return.
Does the ecosystem cover this domain? For commerce that means a maintained SDK for the platform, payment components, a CMS integration and image handling. Being first in a young ecosystem means writing all four yourself, permanently.
How much does the escape cost? Not “can we migrate away” — nobody does — but “can one route do something the framework didn’t anticipate”. A framework with no way out has a ceiling, and you find it late.
Who is maintaining it, and on what cadence? A single-vendor framework tracks that vendor’s commercial interest. A foundation-governed one moves slower. Both are fine; not knowing which you picked is not.
What does it assume about hosting? Some frameworks run anywhere; some are the front end of a hosting product and quietly cost more elsewhere. Check what breaks off the paved path — usually image handling, revalidation and middleware.
The questions that don’t
| Argued about | Why it doesn’t decide |
|---|---|
| Benchmarks | Measure a rendering hot loop that no real page contains. Your bottleneck is the network and third-party scripts — Third-Party Scripts |
| Framework bundle size | A 20KB difference is one hero image. It matters at the tail of an already-optimised app, and nowhere else |
| GitHub stars, survey rankings | Popularity is a lagging indicator with a two-year delay, and partly measures marketing spend |
| ”Developer experience” | Usually means “familiar”. Real DX questions — error message quality, build speed, upgrade pain — are specific and testable |
| Syntax preference | Every model here is learnable in a fortnight. This is the loudest argument and the least consequential |
The costs nobody prices in
- Upgrade cadence. A major release a year with a codemod is a different commitment from one every three years. This is the recurring cost, and it’s paid in sprints, not in the decision meeting
- The second-system pull. Whatever you pick, some part of the team will want the newer thing within eighteen months. The framework didn’t fail; it stopped being novel
- Hiring after the peak. Frameworks have a popularity curve, and you may be hiring on the downslope of it
- Deep coupling by accident. Data loading conventions and auth patterns thread themselves through every file, so the real lock-in is never the render layer
The pragmatic reading
Most projects are well served by a boring, widely known meta-framework, and the decision matters much less than the team believes at the point of making it. Where it genuinely matters is at the extremes — a content site where every kilobyte shows up in Core Web Vitals, or an application complex enough that the data-loading model is the architecture.
The one thing worth being strict about: pick for the rendering needs and the people, then stop revisiting it. A framework re-litigated every quarter costs more than any of the candidates would have.