All Playbooks
Frontendbeginner

Picking a Frontend Framework in 2026

Frontend framework debates are the bikeshed of our industry, and they cost teams real time. This playbook is the decision framework I use to settle the question quickly: profile the workload, decide on rendering strategy, pick the default for your shape of app, evaluate the alternatives honestly, pick the styling and deployment story, and document the choice so the team can move on.

45 min7 steps
7

Steps

4

Tools

5

Outcomes

beginner

Difficulty

Technologies used

Next.jsRemixAstroSvelteKit

The methodology

The phases, in order

Each phase below is something I actually run in a project. The descriptions are how I think about the work, not abstract definitions.

01

Phase

Phase 1 of 7

Profile the Workload

Three questions decide most of this: how dynamic is the content, how interactive is the UI, and what is the latency target for the first paint. A content-heavy marketing site has different needs than a real-time dashboard. Most teams pick a framework before answering these, which is how they end up fighting the framework later.
02

Phase

Phase 2 of 7

Decide on Rendering Strategy

Most apps need a mix: static for marketing, server-rendered for the app shell, and client-rendered for the interactive parts. I sketch this on a single diagram before choosing a framework, because the answer narrows the field significantly. Pure SPA is rarely the right answer in 2026.
03

Phase

Phase 3 of 7

Pick the Default

Next.js is the default for most projects. The ecosystem is broad, the deployment story is solved, and most engineers can hit the ground running. Going against the default needs a real reason. See Next.js vs Remix for the most common alternative.
04

Phase

Phase 4 of 7

Evaluate Astro for Content Sites

Astro is excellent for content-heavy sites with islands of interactivity, especially when the team is comfortable with vanilla web platform features. If most of the site is static content with occasional interactive widgets, Astro often beats Next.js on both performance and developer experience.
05

Phase

Phase 5 of 7

Pick the Styling System

Tailwind is my default for new projects: design tokens, zero runtime cost, easy theming. CSS-in-JS is fine for component libraries and tricky in app code. Read Tailwind vs CSS-in-JS for the full tradeoffs and when each one fits.
06

Phase

Phase 6 of 7

Pick the Deployment Platform

Vercel is the simplest path for Next.js. Cloudflare and Netlify are strong alternatives. Self-hosted on a VPS is reasonable for cost-sensitive workloads and teams with operational maturity. See Vercel vs Netlify for the head-to-head.
07

Phase

Phase 7 of 7

Document the Choice

I write an ADR with the rationale: what we chose, what we considered, what would change our minds. This is the single best defense against the next engineer trying to relitigate the choice, and it forces clarity at the moment of decision when it is cheapest to write down.

Results

What You'll Achieve

Expected outcomes from implementing this playbook

A framework choice with clear, written rationale
An aligned styling and deployment plan
Reduced bikeshedding for the team
A faster path to the first production deploy
Need help shipping fast? Web development service.

Use this playbook

Want me to run this with you?

The playbook is the public version. The private version is me running it for your team against a real deadline. If you have a project on the line, that is usually the faster path.

Start a projectJust ask a question

Next up

Architecture · 120 min

Designing Event-Driven Systems

Event-driven architectures unlock real autonomy between services, and they expose a whole new category of bugs if you do not respect their constraints. This playbook is the design discipline I use: model events as facts, version schemas carefully, choose the right broker, build idempotent consumers, handle ordering and failure, and add the observability that makes async systems debuggable in production.

Previous

Refactoring Without Freezing the Roadmap

Next

Designing Event-Driven Systems