Astro Islands vs React Server Components: Content Sites vs Apps — How to Choose Based on Project Type

Every time you start a new project, the same question comes up. "Should I go with Next.js App Router, or try Astro this time?" Honestly, at first I thought they were similar tools — both "render on the server and reduce client JS," or so I'd heard. But after applying them to actual projects, I found the philosophies behind these two approaches were surprisingly different.

In January 2026, Cloudflare's acquisition of Astro brought some interesting changes. Starting with Astro 6, the dev server runs on Cloudflare's workerd runtime, and Server Islands integrate naturally with the Cloudflare CDN edge. In plain terms, "static shell delivered instantly from global CDN cache, dynamic personalized content injected lazily from edge servers" is now possible within a single framework. Meanwhile, with React 19 stabilizing RSC, both sides have entered maturity. By the end of this article, you'll understand the practical differences between the two architectures and be able to judge which fits your project's nature.

This article is written primarily for frontend developers with some React experience. It assumes familiarity with basic React concepts like useState, Context, and Suspense boundary. If React is entirely new to you, working through the official tutorial first will make this article much easier to follow.

Core Concepts

Astro Islands: A World Where Zero JavaScript Is the Default

Astro's island architecture implements the pattern proposed by Jason Miller. The idea is simple: render the entire page as static HTML, and independently hydrate only the components that strictly require interactivity as "islands."

.astro files run server-side only by default. If you want to send JS to the browser, you must explicitly attach a client:* directive.

astro

---
// src/pages/index.astro
import Header from '../components/Header.astro'; // Server-only, no JS
import Counter from '../components/Counter.tsx'; // React component
import Map from '../components/Map.vue';         // Vue components can be mixed in too
---
<html>
  <body>
    <Header />
 
    <!-- Without client:visible, Counter renders as static HTML only — React runtime not included -->
    <!-- client:visible: hydrate when it enters the viewport -->
    <Counter client:visible />
 
    <!-- client:idle: hydrate when the browser is idle -->
    <Map client:idle />
  </body>
</html>

The granular loading strategies turn out to be quite useful in practice. Components outside the viewport can wait with client:visible until scrolled into view, and less critical widgets can be deferred with client:idle to be handled when the main thread is free.

Island Architecture Core: Each island is an independent hydration root. React, Vue, and Svelte components can be mixed on a single page, and since each is isolated, they don't conflict with one another.

Server Islands: Static Shell with Dynamic Holes

server:defer, added in Astro 5, takes the concept one step further. Where a traditional Client Island was "static + client JS," a Server Island is "static shell + a hole filled dynamically from the server."

astro

---
// src/pages/shop.astro
import ProductGrid from '../components/ProductGrid.astro';
import PersonalizedBanner from '../components/PersonalizedBanner.astro';
---
<html>
  <body>
    <!-- Cacheable static content -->
    <ProductGrid />
 
    <!-- Personalized content: static shell is delivered first, this part lazily loaded from server -->
    <PersonalizedBanner server:defer>
      <span slot="fallback">Loading...</span>
    </PersonalizedBanner>
  </body>
</html>

You might wonder why <span slot="fallback"> is needed. Server Islands work in two phases. The first response delivers the static shell together with the fallback slot, and once the server generates the personalized content, it replaces that slot. The role is similar to RSC's Suspense boundary, but the structure differs. RSC's Suspense fills in via streaming within a single React tree, whereas a Server Island's fallback is a static HTML fragment entirely independent of React — with no hydration cost.

The charm of Server Islands is being able to personalize dynamic content without any JavaScript.

RSC: Server-Client Boundaries Within a Single React Tree

React Server Components declare the boundary within the same React component syntax using a single 'use client' directive. Server components stream only HTML and send no JS whatsoever.

tsx

// app/page.tsx — Server Component (default)
import CartButton from './CartButton';
 
export default async function ProductPage() {
  // Direct DB query on the server. This logic is never exposed to the client.
  const products = await db.query('SELECT * FROM products');
 
  return (
    <div>
      {products.map(p => (
        <article key={p.id}>
          <h2>{p.name}</h2>
          <p>{p.description}</p>
          {/* Only this component needs client JS */}
          <CartButton productId={p.id} />
        </article>
      ))}
    </div>
  );
}

tsx

// app/CartButton.tsx — Client Component
'use client';
 
import { useState } from 'react';
 
export default function CartButton({ productId }: { productId: string }) {
  const [added, setAdded] = useState(false);
 
  return (
    <button onClick={() => setAdded(true)}>
      {added ? 'Added to cart' : 'Add to cart'}
    </button>
  );
}

In his overreacted.io post "RSC for Astro Developers," Dan Abramov described RSC as a "fractal islands" concept. Because it's a single React tree, a client context provider can be positioned above a server subtree, allowing the context to be read from anywhere beneath it.

tsx

// app/layout.tsx — Auth context wraps the entire tree
import { AuthProvider } from './providers';
 
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <AuthProvider> {/* Client Component provider */}
          {children}   {/* Server Components below also benefit from the context */}
        </AuthProvider>
      </body>
    </html>
  );
}

In Astro, islands are isolated from each other, making this kind of global state sharing structurally impossible. This is the most decisive difference between the two architectures.

'use client' Boundary Caveat: Props crossing this boundary must be serializable. Passing functions or class instances directly will cause runtime errors. For Date objects, convert to .toISOString() before passing them across.

Practical Application

Example 1: Content-Heavy Blog or Documentation Site — Astro Islands

If your site is 80% content and 20% interactivity, Astro has a structural advantage. The reason large media sites choose Astro — the difference in initial bundle size and build performance — becomes clear when you look at the code below.

astro

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';
import ShareButton from '../../components/ShareButton.tsx';
import Newsletter from '../../components/Newsletter.tsx';
 
export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({ params: { slug: post.slug }, props: { post } }));
}
 
const { post } = Astro.props;
const { Content } = await post.render();
---
<article>
  <h1>{post.data.title}</h1>
  <!-- Post body: pure HTML, no JS -->
  <Content />
 
  <!-- Only the share button is hydrated -->
  <ShareButton client:visible url={Astro.url.href} />
  <!-- Newsletter: loaded when main thread is free -->
  <Newsletter client:idle />
</article>

Code Point	Description
`getCollection('blog')`	Type-safe content access via the Content Layer API
`client:visible`	JS loaded only on viewport entry, not included in initial bundle
`client:idle`	Loaded when main thread is free, minimizing performance impact
`<Content />` rendering	Markdown body is pure HTML, no React runtime

The higher the proportion of static content, the greater the build time difference compared to Next.js. Benchmark reports consistently confirm this, and the effect becomes more noticeable as the page count grows.

Example 2: SaaS Dashboard — RSC (Next.js App Router)

In apps requiring frequent navigation, shared auth state, and real-time updates, RSC's single tree proves its worth. It's a situation you encounter often in practice — seeing firsthand how natural it is to handle authentication and data fetching on the server and pass only the rendered output to the browser makes it click.

tsx

// app/dashboard/page.tsx — Server Component
import { auth } from '@/lib/auth';
import { RevenueChart } from './RevenueChart';
import { ActivityFeed } from './ActivityFeed';
 
export default async function DashboardPage() {
  // Auth check and DB query on the server
  const session = await auth();
  const metrics = await fetchMetrics(session.userId);
 
  return (
    <main>
      <h1>{session.user.name}'s Dashboard</h1>
      {/* metrics data computed server-side; only chart rendering and interaction on the client */}
      <RevenueChart data={metrics.revenue} />
      <ActivityFeed userId={session.userId} />
    </main>
  );
}

tsx

// app/dashboard/RevenueChart.tsx — Client Component
'use client';
 
import { LineChart, Line, XAxis, YAxis, Tooltip } from 'recharts';
 
export function RevenueChart({ data }: { data: RevenueData[] }) {
  return (
    <LineChart data={data} width={600} height={300}>
      <XAxis dataKey="date" />
      <YAxis />
      <Tooltip />
      <Line type="monotone" dataKey="amount" stroke="#6366f1" />
    </LineChart>
  );
}

The auth() call and DB query happen exclusively on the server, and the browser receives only the rendered HTML and chart interaction code. Since AuthProvider lives in the top-level layout, any client component in the dashboard can read session information from context. Implementing this pattern in Astro would require an entirely different design, because context cannot be shared between islands.

What to Use for Which Project

Project Characteristics	Recommended Choice	Reason
High content ratio, minimizing JS is top priority	Astro Islands	0KB JS default, build performance advantage
Frequent page transitions + global state (auth, cart)	RSC (Next.js)	Context shared freely within a single tree
Existing React team + migrating to fullstack app	RSC (Next.js)	Minimal learning curve, leverage existing ecosystem
Mixed frameworks (React + Vue + Svelte)	Astro Islands	Framework-agnostic structure
Blog, documentation site, marketing landing page	Astro Islands	Static content-focused, SEO optimized
SaaS dashboard, admin panel, e-commerce app	RSC (Next.js)	Complex state and navigation management

Put simply:

Sites for "reading pages" → Astro Islands
Apps for "doing things on pages" → RSC

If there's more in-page interaction than page transitions, and login state flows throughout the entire site, RSC is the natural choice. On the other hand, if the primary purpose is reading articles, searching documentation, or browsing product pages, Astro's zero JS default shines brightly.

Pros and Cons Analysis

Advantages

Astro Islands

Item	Details
Zero JS default	Static pages send no JS to the browser whatsoever — in contrast to Next.js "Hello World" at ~85-100KB (gzip)
Framework agnostic	React, Vue, Svelte, and Solid components can be mixed within a single project
Build performance	The higher the static content ratio, the more favorable the build time compared to Next.js
Server Islands	Mix static shell and dynamic content without hydration via `server:defer`
Simple mental model	The boundary between `.astro` (server) and Client Islands (client) is clear at the file level

RSC (Next.js App Router)

Item	Details
Single React tree	Global Context works across server-client boundaries, making auth and theme sharing easy
SPA-level navigation	Client-side routing delivers smooth page transitions on repeat visits
Server Actions	Handle form submissions and data mutations without separate API routes
Mature ecosystem	React 19 stable, broad enterprise adoption, and a vast community

Drawbacks and Caveats

Astro Islands

Item	Details	Mitigation
No state sharing between islands	React Context, Zustand, etc. cannot cross independent hydration roots	Use nanostores (a lightweight, framework-agnostic state management library) or pass state via URL parameters or LocalStorage
MPA navigation	Implementing complex SPA-like experiences is structurally difficult	Can be alleviated with the View Transitions API (built into Astro 5)
RSC-exclusive features not supported	React-specific features like full Server Actions integration cannot be used as-is	Use Astro's own form handling or API endpoints

RSC (Next.js App Router)

Item	Details	Mitigation
Initial bundle cost	React runtime is always included, minimum ~85-100KB (gzip)	Accept the disadvantage compared to Astro when used for content sites
Boundary management complexity	`'use client'`/`'use server'` errors are only discovered at runtime	TypeScript strict mode + lint rules for early detection
Next.js dependency	The full RSC experience is effectively tied to Next.js App Router	Consider alternatives like Waku or TanStack Start
Hydration mismatch	Server-client mismatch errors are difficult to debug	Keep Suspense boundaries small, avoid overusing `suppressHydrationWarning`

Serializable Props Warning: In RSC, props passed from server components to client components must be JSON-serializable. Date objects, functions, and class instances cannot cross the boundary.

The Most Common Mistakes in Practice

Attempting to share state between Astro islands via React Context — Each island is an independent hydration root, so one island's Context cannot be read in another. The solution is to use nanostores (Astro's officially recommended lightweight, framework-agnostic state management library), or route state through URL parameters or LocalStorage.
Declaring the 'use client' boundary too high up in RSC — Adding 'use client' to the top-level layout makes it effectively no different from a traditional CSR app. The right way to leverage RSC is to attach 'use client' only to leaf components that need state, keeping the server component tree as deep as possible.
Over-engineering content sites with Next.js App Router — Using Next.js for a blog or documentation site means you'll rarely use RSC's advantages like global state sharing or SPA navigation. Meanwhile, the React runtime bundle of ~85-100KB remains a burden you carry regardless. If the team is already on Next.js it makes sense to stay, but for a new content site, Astro is worth serious consideration.

Closing Thoughts

Both technologies point in the same direction — "minimize client JS" — but the philosophical difference in how they get there makes the choice criteria far more important than a simple feature checklist. Astro chose physical separation with "only raise islands," while RSC chose logical separation with "declare a boundary." The proportion of content versus the need for global state — these two factors are the crux of the decision.

Three steps you can take right now:

Diagnose your project's nature — Look at your spec document or wireframes and count whether there are more "pages to read" or "pages to do things on." If it's static content with scattered interactivity, Astro is the natural starting point; if it's frequent navigation with shared state, RSC is.
Quick Astro experiment — Run pnpm create astro@latest to generate the official blog template and you'll immediately see examples of the Content Layer, Markdown rendering, and client:visible in use. Checking the bundle size in browser DevTools makes the meaning of the zero JS default tangible.
Practice RSC boundaries — In a Next.js App Router project, try attaching 'use client' only to leaf components, then use the React DevTools "Server Components" panel to visually confirm which components are rendered on the server. Your intuition for boundaries will develop quickly.

References

#AstroIslands#ReactServerComponents#NextJS#ServerIslands#IslandsArchitecture#Hydration#AppRouter#ServerActions#TypeScript#Cloudflare

Astro Islands vs React Server Components: Content Sites vs Apps — How to Choose Based on Project Type | DEV BAK - 기술블로그

frontend

Astro Islands vs React Server Components: Content Sites vs Apps — How to Choose Based on Project Type

Core Concepts

Astro Islands: A World Where Zero JavaScript Is the Default

.astro files run server-side only by default. If you want to send JS to the browser, you must explicitly attach a client:* directive.

astro

---
// src/pages/index.astro
import Header from '../components/Header.astro'; // Server-only, no JS
import Counter from '../components/Counter.tsx'; // React component
import Map from '../components/Map.vue';         // Vue components can be mixed in too
---
<html>
  <body>
    <Header />
 
    <!-- Without client:visible, Counter renders as static HTML only — React runtime not included -->
    <!-- client:visible: hydrate when it enters the viewport -->
    <Counter client:visible />
 
    <!-- client:idle: hydrate when the browser is idle -->
    <Map client:idle />
  </body>
</html>

Island Architecture Core: Each island is an independent hydration root. React, Vue, and Svelte components can be mixed on a single page, and since each is isolated, they don't conflict with one another.

Server Islands: Static Shell with Dynamic Holes

astro

---
// src/pages/shop.astro
import ProductGrid from '../components/ProductGrid.astro';
import PersonalizedBanner from '../components/PersonalizedBanner.astro';
---
<html>
  <body>
    <!-- Cacheable static content -->
    <ProductGrid />
 
    <!-- Personalized content: static shell is delivered first, this part lazily loaded from server -->
    <PersonalizedBanner server:defer>
      <span slot="fallback">Loading...</span>
    </PersonalizedBanner>
  </body>
</html>

The charm of Server Islands is being able to personalize dynamic content without any JavaScript.

RSC: Server-Client Boundaries Within a Single React Tree

React Server Components declare the boundary within the same React component syntax using a single 'use client' directive. Server components stream only HTML and send no JS whatsoever.

tsx

// app/page.tsx — Server Component (default)
import CartButton from './CartButton';
 
export default async function ProductPage() {
  // Direct DB query on the server. This logic is never exposed to the client.
  const products = await db.query('SELECT * FROM products');
 
  return (
    <div>
      {products.map(p => (
        <article key={p.id}>
          <h2>{p.name}</h2>
          <p>{p.description}</p>
          {/* Only this component needs client JS */}
          <CartButton productId={p.id} />
        </article>
      ))}
    </div>
  );
}

tsx

// app/CartButton.tsx — Client Component
'use client';
 
import { useState } from 'react';
 
export default function CartButton({ productId }: { productId: string }) {
  const [added, setAdded] = useState(false);
 
  return (
    <button onClick={() => setAdded(true)}>
      {added ? 'Added to cart' : 'Add to cart'}
    </button>
  );
}

tsx

// app/layout.tsx — Auth context wraps the entire tree
import { AuthProvider } from './providers';
 
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <AuthProvider> {/* Client Component provider */}
          {children}   {/* Server Components below also benefit from the context */}
        </AuthProvider>
      </body>
    </html>
  );
}

In Astro, islands are isolated from each other, making this kind of global state sharing structurally impossible. This is the most decisive difference between the two architectures.

'use client' Boundary Caveat: Props crossing this boundary must be serializable. Passing functions or class instances directly will cause runtime errors. For Date objects, convert to .toISOString() before passing them across.

Practical Application

Example 1: Content-Heavy Blog or Documentation Site — Astro Islands

astro

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';
import ShareButton from '../../components/ShareButton.tsx';
import Newsletter from '../../components/Newsletter.tsx';
 
export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({ params: { slug: post.slug }, props: { post } }));
}
 
const { post } = Astro.props;
const { Content } = await post.render();
---
<article>
  <h1>{post.data.title}</h1>
  <!-- Post body: pure HTML, no JS -->
  <Content />
 
  <!-- Only the share button is hydrated -->
  <ShareButton client:visible url={Astro.url.href} />
  <!-- Newsletter: loaded when main thread is free -->
  <Newsletter client:idle />
</article>

Code Point	Description
`getCollection('blog')`	Type-safe content access via the Content Layer API
`client:visible`	JS loaded only on viewport entry, not included in initial bundle
`client:idle`	Loaded when main thread is free, minimizing performance impact
`<Content />` rendering	Markdown body is pure HTML, no React runtime

Example 2: SaaS Dashboard — RSC (Next.js App Router)

tsx

// app/dashboard/page.tsx — Server Component
import { auth } from '@/lib/auth';
import { RevenueChart } from './RevenueChart';
import { ActivityFeed } from './ActivityFeed';
 
export default async function DashboardPage() {
  // Auth check and DB query on the server
  const session = await auth();
  const metrics = await fetchMetrics(session.userId);
 
  return (
    <main>
      <h1>{session.user.name}'s Dashboard</h1>
      {/* metrics data computed server-side; only chart rendering and interaction on the client */}
      <RevenueChart data={metrics.revenue} />
      <ActivityFeed userId={session.userId} />
    </main>
  );
}

tsx

// app/dashboard/RevenueChart.tsx — Client Component
'use client';
 
import { LineChart, Line, XAxis, YAxis, Tooltip } from 'recharts';
 
export function RevenueChart({ data }: { data: RevenueData[] }) {
  return (
    <LineChart data={data} width={600} height={300}>
      <XAxis dataKey="date" />
      <YAxis />
      <Tooltip />
      <Line type="monotone" dataKey="amount" stroke="#6366f1" />
    </LineChart>
  );
}

What to Use for Which Project

Project Characteristics	Recommended Choice	Reason
High content ratio, minimizing JS is top priority	Astro Islands	0KB JS default, build performance advantage
Frequent page transitions + global state (auth, cart)	RSC (Next.js)	Context shared freely within a single tree
Existing React team + migrating to fullstack app	RSC (Next.js)	Minimal learning curve, leverage existing ecosystem
Mixed frameworks (React + Vue + Svelte)	Astro Islands	Framework-agnostic structure
Blog, documentation site, marketing landing page	Astro Islands	Static content-focused, SEO optimized
SaaS dashboard, admin panel, e-commerce app	RSC (Next.js)	Complex state and navigation management

Put simply:

Sites for "reading pages" → Astro Islands
Apps for "doing things on pages" → RSC

Pros and Cons Analysis

Advantages

Astro Islands

Item	Details
Zero JS default	Static pages send no JS to the browser whatsoever — in contrast to Next.js "Hello World" at ~85-100KB (gzip)
Framework agnostic	React, Vue, Svelte, and Solid components can be mixed within a single project
Build performance	The higher the static content ratio, the more favorable the build time compared to Next.js
Server Islands	Mix static shell and dynamic content without hydration via `server:defer`
Simple mental model	The boundary between `.astro` (server) and Client Islands (client) is clear at the file level

RSC (Next.js App Router)

Item	Details
Single React tree	Global Context works across server-client boundaries, making auth and theme sharing easy
SPA-level navigation	Client-side routing delivers smooth page transitions on repeat visits
Server Actions	Handle form submissions and data mutations without separate API routes
Mature ecosystem	React 19 stable, broad enterprise adoption, and a vast community

Drawbacks and Caveats

Astro Islands

Item	Details	Mitigation
No state sharing between islands	React Context, Zustand, etc. cannot cross independent hydration roots	Use nanostores (a lightweight, framework-agnostic state management library) or pass state via URL parameters or LocalStorage
MPA navigation	Implementing complex SPA-like experiences is structurally difficult	Can be alleviated with the View Transitions API (built into Astro 5)
RSC-exclusive features not supported	React-specific features like full Server Actions integration cannot be used as-is	Use Astro's own form handling or API endpoints

RSC (Next.js App Router)

Item	Details	Mitigation
Initial bundle cost	React runtime is always included, minimum ~85-100KB (gzip)	Accept the disadvantage compared to Astro when used for content sites
Boundary management complexity	`'use client'`/`'use server'` errors are only discovered at runtime	TypeScript strict mode + lint rules for early detection
Next.js dependency	The full RSC experience is effectively tied to Next.js App Router	Consider alternatives like Waku or TanStack Start
Hydration mismatch	Server-client mismatch errors are difficult to debug	Keep Suspense boundaries small, avoid overusing `suppressHydrationWarning`

Serializable Props Warning: In RSC, props passed from server components to client components must be JSON-serializable. Date objects, functions, and class instances cannot cross the boundary.

The Most Common Mistakes in Practice

Attempting to share state between Astro islands via React Context — Each island is an independent hydration root, so one island's Context cannot be read in another. The solution is to use nanostores (Astro's officially recommended lightweight, framework-agnostic state management library), or route state through URL parameters or LocalStorage.
Declaring the 'use client' boundary too high up in RSC — Adding 'use client' to the top-level layout makes it effectively no different from a traditional CSR app. The right way to leverage RSC is to attach 'use client' only to leaf components that need state, keeping the server component tree as deep as possible.
Over-engineering content sites with Next.js App Router — Using Next.js for a blog or documentation site means you'll rarely use RSC's advantages like global state sharing or SPA navigation. Meanwhile, the React runtime bundle of ~85-100KB remains a burden you carry regardless. If the team is already on Next.js it makes sense to stay, but for a new content site, Astro is worth serious consideration.

Closing Thoughts

Three steps you can take right now:

Diagnose your project's nature — Look at your spec document or wireframes and count whether there are more "pages to read" or "pages to do things on." If it's static content with scattered interactivity, Astro is the natural starting point; if it's frequent navigation with shared state, RSC is.
Quick Astro experiment — Run pnpm create astro@latest to generate the official blog template and you'll immediately see examples of the Content Layer, Markdown rendering, and client:visible in use. Checking the bundle size in browser DevTools makes the meaning of the zero JS default tangible.
Practice RSC boundaries — In a Next.js App Router project, try attaching 'use client' only to leaf components, then use the React DevTools "Server Components" panel to visually confirm which components are rendered on the server. Your intuition for boundaries will develop quickly.

References

#AstroIslands#ReactServerComponents#NextJS#ServerIslands#IslandsArchitecture#Hydration#AppRouter#ServerActions#TypeScript#Cloudflare

Core Concepts

Astro Islands: A World Where Zero JavaScript Is the Default

Server Islands: Static Shell with Dynamic Holes

RSC: Server-Client Boundaries Within a Single React Tree

Practical Application

Example 1: Content-Heavy Blog or Documentation Site — Astro Islands

Example 2: SaaS Dashboard — RSC (Next.js App Router)

What to Use for Which Project

Pros and Cons Analysis

Advantages

Drawbacks and Caveats

The Most Common Mistakes in Practice

Closing Thoughts

References

Core Concepts

Astro Islands: A World Where Zero JavaScript Is the Default

Server Islands: Static Shell with Dynamic Holes

RSC: Server-Client Boundaries Within a Single React Tree

Practical Application

Example 1: Content-Heavy Blog or Documentation Site — Astro Islands

Example 2: SaaS Dashboard — RSC (Next.js App Router)

What to Use for Which Project

Pros and Cons Analysis

Advantages

Drawbacks and Caveats

The Most Common Mistakes in Practice

Closing Thoughts

References

Recommended Posts

Why React Compiler Structurally Favors Zustand, and the Current Compatibility Status of Jotai and Valtio

Next.js App Router and Feature-Sliced Design (FSD): Causes of `app`·`pages` Directory Conflicts and Isolation Strategies

Astro Server Islands vs Next.js Partial Prerendering (PPR): Internal Mechanics and Caching Strategy Comparison

After Introducing FSD (Feature-Sliced Design) to Our Team, "Where Does This Code Go?" Disappeared

When React Compiler Quietly Gives Up on Optimization — Bailout Causes and Detection Strategies (React Compiler v1.0)

Halving Your Vite 6.x Bundle Size with manualChunks and Dynamic Import Strategies