[Frontend Architecture] Frameworks in Detail

About this article

As the fourth installment of the “Frontend Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains frontend frameworks.

There are many choices, and the primary axis is “can it survive 5 years of operation?” This article compares UI libraries like React/Vue/Svelte/Astro and meta-frameworks like Next.js/Nuxt/SvelteKit, covering how to choose by use case, hiring availability, and AI-era code-generation accuracy.

What is a frontend framework in the first place

A frontend framework is, roughly speaking, “a skeleton and toolset for efficiently building UIs that run in the browser.”

Imagine art supplies. Oil painting set (React), watercolor set (Vue), digital painting software (Svelte) — you can paint with any of them, but the characteristics and techniques are completely different. Once you start a piece with one set, switching mid-work is essentially starting over. On top of that, meta-frameworks (Next.js, Nuxt, etc.) bundle “supplies + canvas + frame” together, providing a foundation including routing and SSR.

Why frontend framework selection matters

What happens if you pick the wrong framework? Hiring is especially non-trivial. Choosing a niche FW leads to the tragedy of “can’t find developers, 3-month hiring campaign.” Prioritizing hiring and team scalability over technical superiority is often the right answer in practice.

The criterion is not “technically best” but “can we operate it for 5 years and find people?”

In particular, hiring availability cannot be ignored. Choose a minor framework and you’ll face the tragedy of “spending 3 months recruiting and finding no one who can develop it.” In practice, prioritizing hiring and team scalability over technical superiority is often the right answer.

The selection standard is “5-year operation and hiring availability” - not “technically the best.”

The layered structure — the real choice is which meta-framework

Modern frontend has a layered structure, and the mainstream is to combine layers like “React + Next.js” rather than “React alone.” Understanding this hierarchy is the starting point of design.

Even when people say “build it with React,” the reality is that React almost always runs on top of a meta-framework like Next.js, Remix, or Astro. UI libraries alone lack routing, build, and SSR, so going UI-library-only is unrealistic in modern projects.

“React” and “Next.js” sit at different layers. Choosing the meta-framework is the substantive decision.

One layer up sit the meta-frameworks, and that is where the real decision is made.

Next.js is a React meta-framework developed by Vercel, the de facto React standard. It’s so dominant you could say “using React = using Next.js.”

Main features:

• App Router (RSC + Server Actions support)
• Per-page switching of SSR / SSG / ISR
• Image optimization / font optimization
• Middleware / Edge Functions

Suited for: SaaS, e-commerce, large-scale web apps, SEO-focused sites. It’s extremely tightly integrated with Vercel hosting, so on Vercel you can ship to production in record time.

Nuxt is the Vue meta-framework, occupying the position equivalent to Next.js. Centered on Vue, it provides features equivalent to Next.js (SSR/SSG/ISR, file-based routing, image optimization, etc.). Nitro is Nuxt’s underlying server engine, and its strength is “universality” - deployable to Vercel, Cloudflare, Netlify, or self-hosted servers.

The modern feel is Next.js if you choose React. For Vue, Nuxt is the standard.

Where each framework fits

React + Next.js — the default for application development

React is a UI library developed by Meta, and even today it holds the overwhelming No.1 position. In ecosystem, job count, and information volume, it leads the others by a wide margin - and unless there’s a special reason, you can choose it as the default.

React intentionally provides only “the bare minimum” of features - routing, state management, styling, etc. are filled in by users via peripheral libraries. This freedom is both a strength and a weakness.

For large-scale, long-term, or hiring-focused projects, React is the only choice. Place it as the default.

Astro — the first candidate for content sites

Astro is a multi-framework foundation specialized for content sites. It takes the unique approach of shipping zero JS by default and running only the necessary parts as Islands using React/Vue/Svelte.

This series’s home, senkohome.com, is also built on Astro. For content-centric sites like blogs and documentation, Astro’s SSG can be called the fastest modern option.

The first choice for blogs. For content sites you can run them far faster than Next.js SSG.

Vue + Nuxt — learning cost, and its track record in Japan

Vue is a UI library developed by Evan You (formerly of Google), gaining strong support thanks to its low learning cost. It’s especially popular in Japan and China, often adopted by government agencies and gradual replacements of legacy systems.

Vue’s SFC (Single File Component) is a format where <template> <script> <style> are written in one file with HTML-like syntax. For people coming from HTML, it feels intuitive and is very approachable for beginners. With Composition API (Vue 3), large-scale projects are also well supported.

A strong choice for Japan-region projects, small-to-medium scale, or when learning cost matters most.

Svelte / Solid / Qwik — the technically-led newcomers

Svelte is a UI library getting attention for its innovative approach of “no virtual DOM, optimized at compile time.” It minimizes the bundle at compile time, so the runtime size is tiny and performance is outstanding.

Svelte’s writing experience is described as “the framework closest to vanilla JS,” and it’s not unusual to see code volume reduced by 30-50%. However, large-enterprise adoption is still limited, so caution is needed from a hiring-availability standpoint.

Solid and Qwik sit alongside Svelte in that same group.

Solid and Qwik are emerging frameworks that preserve a React-like feel while pursuing performance through different philosophies. They are technically excellent, but adoption track records are thin, so they are best suited for experimental projects right now.

Qwik’s resumability is an innovative technology where the client picks up the server-rendered state directly, with near-zero hydration cost. Because it ships almost no JS, initial load is astonishingly fast. However, the concept is complex, the team’s learning cost is high, and new adoption should be decided cautiously.

Novelty is high but adoption is still rare. Production deployment may be premature.

Across all of them, a few currents are settling in.

Frontend trends shift rapidly, but here are the streams settling in now. These are not mere fads - they are predicted to “remain mainstream for years to come.”

• Spread of RSC (React Server Components) - the decisive blow for JS bundle reduction
• Server Actions - new API where form submission can be written concisely
• Generalization of Islands / Partial Hydration - Astro-originated philosophy goes mainstream
• Type-safe full-stack (tRPC / Next.js + Zod / Astro Actions) - shared types between backend and frontend
• Edge First - low-latency delivery via Vercel / Cloudflare / Deno Deploy

In particular, “type-safe full-stack” means sharing backend API types with the frontend so TypeScript can use them like function calls - tRPC being the leading example. It improves both productivity and bug reduction.

How to choose — use case × scale × talent

Framework selection has clear right answers by use case. Choose along the following matrix and you won’t go badly wrong.

The blog this series is hosted on (senkohome.com) is Astro, while apps like trivia-master use React + Vite - we follow the policy of “choosing the optimal one per use case.”

Within React itself, the meta-framework choice splits further.

Once you’ve decided to “adopt React,” choosing within meta-frameworks matters too. Next.js dominates, but other options exist depending on requirements.

Remix was acquired by Shopify, with integration with React Router progressing. “Default to Next.js” is the safest, with the largest information volume and support range.

Maturity by use case, as of April 2026, lines up as follows.

Frontend FWs are chosen not by “which is newest” but by use case × scale × people. Below is the practical 2026 matrix.

“React + Next.js is the de facto AI tool standard” - UI generation AIs like v0, Bolt, and Lovable produce the highest-accuracy code on this combination. Vue/Nuxt is also at a usable level, but trails by one step in AI training-data volume. Svelte/Qwik/Solid may be technically excellent, but hiring becomes 10x harder, so cautious judgment is needed outside personal projects.

For business: React + Next.js + Tailwind + shadcn/ui; for content: Astro. These two without hesitation.

Three scenarios

If you are building solo or at a startup

Astro for a content site, Next.js with Tailwind and shadcn/ui for an application. There is no need to agonise beyond those two. This is also the configuration that UI-generating AI such as v0 and Bolt writes most accurately, which effectively multiplies the productivity of a one-person project several times over.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

Next.js with Tailwind, shadcn/ui and design tokens is the configuration to back. That said, for a team inside the Vue world, staying on Nuxt 3 is the rational choice — the cost of forcing a move to React is hard to justify. At this size, ease of hiring belongs among the first-class criteria for framework selection.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large enterprise

The existing skill set inside the company and the hiring market are the deciding factors. In an organisation where Angular is established, continuing with Angular is rational, and running two tracks — introducing React and Next.js from new products onward — is the realistic answer. Svelte and Qwik may be technically superior, but securing people becomes an order of magnitude harder, so they are best avoided for business systems.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

AI decision axes — Line it up with the AI UI generators

Tailwind + component libraries and AI generation

Where AI brings the greatest benefit in frontend dev is UI component generation. Here, Tailwind CSS + shadcn/ui (or headless UI libraries like Radix UI) is overwhelmingly advantageous in the AI era.

Tailwind class names directly represent style meaning, so AI can accurately reproduce “this component’s appearance” from context. With custom CSS design (BEM, etc.) you’d need to teach AI project-specific naming conventions, but with Tailwind the publicly available information alone produces sufficiently accurate code.

shadcn/ui is even more compatible because components are designed to be “copied and pasted into your project.” Since they’re not hidden behind npm packages, AI can directly read and write component internals. Customization instructions also pass through well - edits like “remove border radius on this button and change background color on hover” execute directly.

Tools that generate UI directly from a prompt — Vercel v0, Bolt and the rest — are multiplying, and what they emit is basically React + Tailwind + shadcn/ui. Align your project to that stack and AI-generated components drop straight in; with a bespoke CSS design or a minor UI library, every incorporation needs conversion work, and that overhead accumulates into a cost that is not trivial.

The Server Components boundary is easy for AI to handle

Next.js App Router’s Server Components (RSC) have great AI compatibility because “the boundary is determined by whether 'use client' exists at the top of the file.” When AI generates code, it can judge per-file whether a component runs on server or client, making mistakes like calling browser APIs in the wrong place less likely.

On the other hand, with configurations that manually control hydration boundaries (manual Islands Architecture placement, etc.), AI sometimes can’t correctly grasp boundaries and mixes server-only code into clients. Astro’s case is also AI-friendly since client:load / client:idle directives are explicit.

Tools that directly generate UI from prompts - Vercel v0, Bolt, GPT-4o’s UI mode - are multiplying. The code these output is basically React + Tailwind + shadcn/ui. So if your project aligns to this stack, AI-generated components can be incorporated directly.

With custom CSS design or minor UI libraries, conversion work is needed every time AI-generated code is incorporated, and this overhead becomes non-trivial costs when accumulated.

Pitfalls and forbidden moves

Choosing on “new and sharp” leaves you stuck on hiring five years later. Here are the six most dangerous.

Create React App going out of maintenance in 2023, styled-components entering maintenance mode in 2024 — the frontend world is the textbook domain where “the newest thing at the time” turns into debt within a few years.

Author’s note — the day “the newest thing at the time” became a landmine

When AngularJS (Angular’s predecessor) reached official end-of-support in January 2022, projects worldwide were forced into full rewrites - a case often cited as a frontend-selection lesson. AngularJS and Angular (2 and beyond) are “different frameworks,” more like a “from-scratch rebuild” than a migration, and many sites that trusted “it’s by Google so it’s safe” were hit hard.

Many teams that exhausted themselves on the AngularJS-to-new-Angular migration ended up switching to React in the end. It’s a textbook case of “cutting-edge at adoption” becoming “a landmine 5 years later.” Similar stories apply to Backbone, Ember, Knockout, and Meteor - all stars of their era, but rarely showing up on new-adoption shortlists today.

“Will that framework’s job listings still be around in 3 years?” If you can’t answer that with confidence, leaning toward the mainstream is the safe move.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• UI library (React / Vue / Svelte etc.)
• Meta FW (Next / Nuxt / SvelteKit / Astro)
• Whether to adopt RSC (when adopting Next.js)
• Supported browser range (IE, old Safari)
• Mobile Web support (whether or not to build a PWA (Progressive Web App, the framework that delivers app-like experiences using Web tech))
• Boundaries with parts that no-code can handle

How to record decision reasons

Framework selection is a judgment that constrains the entire project for years. Documenting the background and reasons at selection time as an ADR (Architecture Decision Record) lets you trace the decision rationale even after team changes or technology-trend shifts.

Store ADRs in the repo’s docs/adr/ with numbering and attach them to tech-selection PRs. The greatest value of an ADR is that when you look back, “why we made this choice” is clear at a glance.

Related Articles

Summary

This article covered frameworks in detail, including UI libraries, meta-FWs, hiring availability, and AI accuracy.

Apps go on React + Next.js, content on Astro. The combination that maximizes AI benefits is the practical answer in 2026.

Next time we’ll cover CSS design (Tailwind / CSS Modules / CSS-in-JS).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.