- The Remix question has a new answer
- Nine frameworks, side by side
- Full-stack frameworks outside React
- Static-first tools for content sites
- Staying with React, just differently
- A lighter footprint in the browser
- What hydration means, in plain words
- Match the framework to the site you're building
- When to stay where you are
- How to trial a new framework without a rewrite
- Frequently asked questions
Leave only when you can name the gap. Developers who'd rather work outside the React world have full-stack frameworks built around other component libraries, content-heavy sites tend to suit static-first tools, and teams after lighter pages in the browser have one framework built to skip hydration. React teams can also stay in React with a router-based framework.
Next.js is a React framework for building full-stack web applications, and plenty of teams reach for it by default. If you're a web developer or a team lead looking around, you've probably hit a reason: a new project that's mostly content, a team that prefers a different component library, or a feeling that you're shipping more JavaScript than the page needs.
The frameworks are grouped by the reason someone would pick them. Find your reason, read that group, and skip whatever doesn't apply.
The Remix question has a new answer
Lots of older round-ups name Remix as the obvious React pick. Its own page now says the newest release is React Router. So if Remix was on your list, the place to read today is the router's own documentation, not a separate product.
That's why Remix isn't a row below, and its successor is. The router can be used as a whole framework or as a small routing layer, which means you can begin small and grow into the bigger features, rather than buying the whole house on day one.
It's a useful reminder for any framework shortlist. Names change, projects merge, and a blog post from a while back may be pointing you at something that no longer stands on its own. Go to the project's own docs before you commit a sprint to it.
Nine frameworks, side by side
| Framework | Group |
|---|---|
| Angular | Other component world |
| Astro | Content first |
| Eleventy | Content first |
| Gatsby | Stay in React |
| Nuxt | Other component world |
| Qwik | Lighter in the browser |
| React Router | Stay in React |
| SolidStart | Other component world |
| SvelteKit | Other component world |
If you love React, start with Gatsby and React Router. If you want out of it, start with the frameworks outside React. Skipping the rows that don't fit your reason saves a week of reading about tools you were never going to adopt.
Full-stack frameworks outside React
If the real wish is a different way of writing components, the framework usually follows the library. Each of these pairs a component library with the routing and server pieces you'd otherwise assemble yourself.
Angular
Its docs say a dedicated team maintains it.
Nuxt
Free, open-source and built with Vue.js.
SolidStart
The full-stack option for people who write components in Solid.
SvelteKit
The web application framework for Svelte.
Static-first tools for content sites
If your site is mostly articles, docs or marketing pages, an app framework can be more machinery than you need. These two start from content. If build tooling is part of the decision, our webpack vs Vite comparison covers that layer.
Astro
A JavaScript framework for content-driven websites.
Eleventy
Its home page calls it a simpler static site generator.
Staying with React, just differently
You don't have to give up React to leave. These two keep your components and change the shape around them. That's often the gentlest move for a team with a large shared component library, because the pieces people use every day stay the same while the routing and page structure change underneath.
Gatsby
A React-based, open-source framework for creating websites.
React Router
Use it as a full framework or a minimal router.
A lighter footprint in the browser
Some teams are chasing a specific feeling: pages that become usable sooner because less work happens in the browser after load.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Qwik
Its docs say its apps don't need hydration.
What hydration means, in plain words
When a server sends a finished page, the browser can show it straight away. Many frameworks then run code to attach click handlers and state to that page before it responds to taps and typing. That wiring step is what people call hydration.
A framework that says it skips that step is making a claim about how the page comes alive. Whether it matters for you depends on your pages. A mostly-static article won't feel much different. A busy product page with lots of interactive parts might. Measure your own pages before and after rather than trusting any headline.
Match the framework to the site you're building
Before you compare features, describe the site in one sentence. Is it a blog with a contact form, a dashboard behind a login, or a shop with both? A content site and a logged-in app pull in opposite directions, and the right pick for one is often the wrong pick for the other.
Then ask who'll maintain it. A framework your team already half-knows will beat a better-reviewed one nobody's touched. If the build step is what's bothering you, our Vite vs Next.js comparison may answer the question without a full rewrite.
It also helps to write down what you'd keep. Your design system, your tests and your written content usually outlive any framework, so a move that carries them across untouched is far less work than one that forces you to rebuild them as well.
Two more questions belong here. Which component library do the people you're hiring already know? And which pages bring in the most visitors, and would they be first or last to move? A framework that matches your hiring pool keeps the project staffed, and moving your busiest pages last keeps the risk where it can do least harm.
When to stay where you are
A framework swap is one of the most expensive decisions a web team makes in time, because it touches every page. If your current app ships on time, your developers are comfortable and your pages load well for real visitors, the case for moving is weak. Fix the slow page or the awkward build step first and see whether the itch goes away.
The strong reasons look different: a new product that's nearly all content, a hiring plan built around another component library, or a team that has already moved most of its work elsewhere. If one of those fits, go ahead and run a trial. Give it a fixed timebox, two weeks is plenty, and agree up front what result would make you stop.
How to trial a new framework without a rewrite
- Choose a single screen you already ship, such as a sign-up form or an article layout.
- Recreate it with the newcomer, sticking to the official getting-started guide.
- Note how long routing, data loading and deployment each took you.
- Check what the browser downloads for that page compared with your current version.
- Ask a teammate who didn't build it to change something and time how long that takes.
- Decide on evidence from that one page before planning any migration.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Is Remix still a separate framework?
No. Read the React Router docs instead.
Which of these call themselves open source?
Nuxt and Gatsby both say so in their own descriptions. For the other seven, read the licence file in each repository.
Can I keep my React components?
Yes, with Gatsby or React Router.
Which option suits a docs or blog site best?
Start with the content-first group: Astro or Eleventy.
Do I need to rewrite everything to move?
No. Trial one page first, then decide.
What does SolidStart build on?
Solid and Vite, according to its own docs.
