Skip to content

← All writing

How to Choose a Web Framework (Without Reading 50 Listicles)

· by Andergrove Software

"Which web framework should I use?" generates more contradictory advice than almost any question in software, because most answers start from the wrong end — with a favourite framework in search of a justification. Worked forwards, the decision is smaller than it looks: four questions eliminate most of the field, and among the survivors the honest answer is usually "several of these would be fine".

Question 1: What language can your team actually ship in?

This is the question that does the most work, and the one listicles skip. A team fluent in Python will ship a better product on Django than on a theoretically superior TypeScript stack, because framework choice is dwarfed by fluency: debugging speed, library instincts, hiring. If you have an existing team or codebase, the language is usually already chosen — and your framework menu just shrank to a handful of options.

Starting solo from zero? Then invert it: JavaScript/TypeScript if your project is UI-heavy (it's the only language that runs natively in the browser), Python if it leans on data or ML, and otherwise the language whose community you enjoy.

Question 2: Where should your HTML come from?

The rendering model is the most consequential technical fork, and it follows from what you're building:

  • Content the public finds via search — blogs, docs, marketing, e-commerce listings — wants HTML that exists before JavaScript runs: static generation (Astro, SvelteKit, Nuxt) or server rendering (Next.js, classic Django/Rails/Laravel templates).
  • Logged-in applications — dashboards, admin panels, SaaS internals — don't care about SEO, so a client-rendered SPA (React, Vue, Angular, Solid) is fine and often simpler to reason about.
  • APIs consumed by other software don't render HTML at all — that's FastAPI, Fastify, Gin, Axum, Spring Boot territory.
  • Server-rendered apps with sprinkles of interactivity are quietly back in fashion: Django or Rails or Laravel templates plus HTMX covers a remarkable share of real applications with no build step and one language.

Question 3: Batteries included, or bring your own?

Batteries-included frameworks — Rails, Django, Laravel, Angular, and increasingly Next.js — decide the routine things (ORM, auth, file layout) so you build features on day one. The cost is fighting the framework when your needs diverge from its conventions. Minimal cores — Flask, Express, Fastify, React-plus-libraries — never fight you, but every decision they didn't make is one you now own, forever, including the upgrades.

A usable heuristic: the smaller the team and the more standard the product, the more batteries pay off. Two founders building a SaaS should almost certainly take the batteries.

Question 4: What does the ecosystem look like when things go wrong?

You will hit a problem the docs don't cover, roughly weekly. That's when community size stops being an abstract metric: a framework with a decade of Stack Overflow answers, actively maintained plugins and multiple job-market's worth of practitioners fails you gently; a brilliant niche framework fails you at 11pm with a GitHub issue from 2024 and no reply. GitHub stars, release cadence and "who runs this in production" (GitHub on Rails, Instagram on Django, Netflix on Spring) are the quick proxies worth checking — our framework finder surfaces all three per framework.

The things that matter less than the internet says

  • Benchmarks. Framework overhead is rarely your bottleneck; your database queries are. Choose Rust/Axum or Go/Gin for performance when you've measured a need, not preemptively.
  • Novelty. New frameworks solve last framework's problems and introduce their own, minus ten years of answered questions. Being two years behind the frontier is a stable place to build a business.
  • Twitter/X discourse. The loudest framework arguments are between people for whom any of the options would work.

A 30-minute decision procedure

Answer the four questions to get a shortlist of two or three (the framework finder automates this — language, use case and rendering filters against a curated catalogue with stars and notable users). Then spend a evening building the same trivial slice of your app — one page, one form, one database read — in each finalist. The framework you were fastest and least annoyed in is your answer, and it's a better-quality signal than any ranking, including ours.