Next.js vs Remix vs Nuxt 2025：組件驅動開發框架完整比較指南（實戰經驗）

如果你是習慣 vibe coding（快速產生大量本地組件）和宣告式開發的開發者，選擇適合的框架至關重要。作為一個深度使用 Next.js App Router 建構 MDX blog 的開發者，我將基於實際經驗分析六大主流選擇，幫你找到最適合的工具。

什麼是 Vibe Coding？

Vibe coding 是我在開發過程中總結的一種開發模式，特徵包括：

• 大量本地組件：每個頁面都有許多專屬的小組件
• 快速迭代：根據靈感快速調整、新增組件
• 宣告式結構：每次調整都有明確目的，程式碼結構清晰
• 就近管理：組件放在對應頁面附近，便於維護

我的實際經驗

在我的 Next.js MDX blog 專案中，每篇文章的結構是這樣的：

content/posts/article-name/
├── content.mdx           # 文章內容 + ESM metadata
└── components/
    ├── index.ts          # Barrel file
    ├── CustomChart.tsx   # 專屬圖表組件
    ├── InteractiveDemo.tsx
    └── DataVisualization.tsx

這種結構讓我能夠：

• 為每篇文章創建專屬的互動組件
• 輕鬆管理組件的版本和依賴
• 在 MDX 中直接使用組件，無需複雜的 import
• 保持程式碼的高度組織性和可維護性

框架評比總覽

基於我的實際使用經驗和測試，這是我的評比結果：

詳細分析

🥇 Next.js (App Router) - Vibe Coding 的完美選擇

為什麼最適合（基於我的實際使用經驗）：

我目前的 Next.js 15 專案完美支援了我的 vibe coding 需求：

• 完美的目錄結構：每個路由都可以有自己的 components 資料夾
• 宣告式路由：檔案結構即路由，意圖明確
• Server Components：組件可以選擇在伺服器或客戶端執行
• ESM Metadata：每個 MDX 檔案都可以有自己的 metadata export

我的實際架構：

// app/blog/[slug]/page.tsx - 我的實際實作
import { MDXRenderer } from './MDXRenderer'
import { getPostBySlug } from '@/lib/mdx'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug)
  
  if (!post) {
    notFound()
  }

  return (
    <article className="max-w-4xl mx-auto px-4 py-8">
      <MDXRenderer 
        content={post.content} 
        components={post.localComponents}
        metadata={post.metadata}
      />
    </article>
  )
}

我的組件載入機制：

// lib/mdx-loader.ts - 我的實際實作
"use client";

export async function loadLocalComponents(slug: string) {
  try {
    const components = await import(`@/content/posts/${slug}/components`)
    return components
  } catch (error) {
    return {}
  }
}

實際使用體驗：

# 資料視覺化範例

這是我的客製化圖表組件：

<CustomChart data={salesData} />

還有互動式示範：

<InteractiveDemo />

優點（親身體驗）：

• 組件就近管理，維護容易
• TypeScript 支援完整，開發體驗極佳
• 豐富的生態系統，什麼需求都能找到解決方案
• 部署選擇多樣（我使用 Vercel，體驗很棒）
• 與 Chart.js、Framer Motion 等第三方庫整合無痛

缺點（實際遇到的問題）：

• 學習曲線稍陡，特別是 Server/Client Components 概念
• "use client" 指令容易忘記，會導致 build 錯誤
• 有時候 ESM metadata 解析會有快取問題（開發環境）

🥈 Remix - 資料導向的 Vibe Coding

為什麼適合：

• 路由即組件：每個路由都是獨立的 React 組件
• 嵌套路由：天然支援複雜的組件層級關係
• 明確的資料流：loader/action 模式讓邏輯清晰

典型結構：

app/
├── routes/
│   ├── blog/
│   │   ├── $slug.tsx
│   │   └── components/
│   │       ├── CommentForm.tsx
│   │       └── PostMeta.tsx
│   └── _index.tsx

Vibe Coding 體驗：

// app/routes/blog/$slug.tsx
import CommentForm from './components/CommentForm'
import PostMeta from './components/PostMeta'

export async function loader({ params }: LoaderFunctionArgs) {
  const post = await getPost(params.slug)
  return json({ post })
}

export default function BlogPost() {
  const { post } = useLoaderData<typeof loader>()
  
  return (
    <article>
      <PostMeta post={post} />
      <main dangerouslySetInnerHTML={{ __html: post.content }} />
      <CommentForm postId={post.id} />
    </article>
  )
}

優點：

• 表單處理超級簡單
• 嵌套路由很直觀
• 資料載入邏輯清晰
• 純 React，沒有額外抽象

缺點：

• 生態系統較小
• 部署選擇相對有限
• MDX 支援需要額外配置

🥉 Nuxt.js - Vue 生態的優秀選擇

為什麼適合：

• 自動路由：基於檔案結構自動產生路由
• 組件自動載入：全域組件自動註冊
• Vue 3 Composition API：現代的組件開發體驗

典型結構：

pages/
├── blog/
│   ├── [slug].vue
│   └── components/
│       ├── CommentSection.vue
│       └── ShareButtons.vue

Vibe Coding 體驗：

<!-- pages/blog/[slug].vue -->
<script setup>
import CommentSection from './components/CommentSection.vue'
import ShareButtons from './components/ShareButtons.vue'

const { data: post } = await useFetch(`/api/posts/${$route.params.slug}`)
</script>

<template>
  <article>
    <h1>{{ post.title }}</h1>
    <ShareButtons :post="post" />
    <div v-html="post.content" />
    <CommentSection :post-id="post.id" />
  </article>
</template>

優點：

• 學習成本低
• Vue 語法簡潔直觀
• 自動最佳化
• 豐富的模組生態

缺點：

• 需要學習 Vue（如果你來自 React）
• TypeScript 支援不如 React 生態完整
• MDX 支援需要額外配置

不適合 Vibe Coding 的框架

❌ Astro - 不適合大量 Local Components

我的實際測試經驗：

當我嘗試用 Astro 重建我的 blog 時，遇到了這些問題：

---
// 每個 React 組件都要這樣處理
import CustomChart from './components/CustomChart.tsx'
import InteractiveDemo from './components/InteractiveDemo.tsx'
---

<!-- 手動標記每個組件的載入方式 -->
<CustomChart client:load data={chartData} />
<InteractiveDemo client:idle />

問題：

• Component Islands 限制：每個 React 組件都需要明確標記 client-side
• 開發流程中斷：每次都要思考組件應該何時載入
• 不符合 vibe coding 哲學：Astro 假設大部分內容是靜態的，但我需要大量互動組件

❌ Gatsby - GraphQL 複雜度過高

我的實際測試經驗：

Gatsby 的 GraphQL 中心化設計與我的 vibe coding 需求衝突：

// 每次都要寫複雜的 GraphQL 查詢
export const pageQuery = graphql`
  query BlogPostBySlug($slug: String!) {
    mdx(fields: { slug: { eq: $slug } }) {
      body
      frontmatter {
        title
        date
        author
      }
    }
  }
`

問題：

• GraphQL 強制性：所有資料都要通過 GraphQL 查詢
• 建構時間長：大量組件會讓建構變慢
• 組件管理複雜：沒有清晰的 local component 約定

❌ Vite - 缺乏框架級支援

我的實際測試經驗：

用 Vite 建立類似結構需要大量手動配置：

// 需要手動設定所有路由
import { createBrowserRouter } from 'react-router-dom'

const router = createBrowserRouter([
  { 
    path: "/blog/vibe-coding-guide", 
    element: <VibeCodingGuide />,
    loader: () => import('./posts/vibe-coding-guide/content.mdx')
  },
  { 
    path: "/blog/framework-comparison", 
    element: <FrameworkComparison />,
    loader: () => import('./posts/framework-comparison/content.mdx')
  },
  // 每篇文章都要手動加...
])

問題：

• 純建構工具：沒有路由、組件管理約定
• 手動配置多：每個頁面都要手動註冊
• 開發體驗差：不符合快速 vibe coding 的需求

基於實際經驗的推薦決策樹

實戰建議

如果你選擇 Next.js（推薦）

基於我的實際經驗，這些是必須注意的：

1. 正確使用 "use client"：

// components/interactive/CustomChart.tsx
"use client";

import { Chart } from 'chart.js/auto';
import { Bar } from 'react-chartjs-2';

export default function CustomChart({ data }: ChartProps) {
  // 你的圖表邏輯
}

2. 設置 barrel files：

// content/posts/[slug]/components/index.ts
"use client";

export { default as CustomChart } from './CustomChart';
export { default as InteractiveDemo } from './InteractiveDemo';
export { default as DataTable } from './DataTable';

3. 使用 ESM metadata：

// content/posts/[slug]/content.mdx

常見問題解決

Q: Chart.js 組件在手機上顯示異常？ A: 設置正確的響應式配置：

const options = {
  responsive: true,
  maintainAspectRatio: false,
  plugins: {
    legend: {
      position: 'top' as const,
    },
  },
};

return (
  <div className="w-full" style={{ height: '400px' }}>
    <Bar data={data} options={options} />
  </div>
);

Q: 組件在 build 時報錯？ A: 檢查是否正確添加 "use client" 指令，特別是 barrel files。

最終建議

最佳選擇：Next.js (App Router)

• 完美支援 vibe coding
• 宣告式架構設計
• 豐富的生態系統
• 我個人使用 2 年以上，體驗極佳

次佳選擇：Remix

• 純 React，學習成本低
• 資料處理邏輯清晰
• 適合互動性強的應用

Vue 使用者：Nuxt.js

• Vue 生態最佳選擇
• 自動化程度高
• 開發體驗優秀

避免使用：Astro、Gatsby、Vite

• 都不適合大量 local components 的開發模式
• 學習成本高，開發體驗差
• 我親自測試過，確實不適合

結論

作為一個深度使用 Next.js App Router 進行 vibe coding 的開發者，我可以負責任地說：Next.js 是目前最適合這種開發模式的框架。它不僅支援你的開發習慣，還提供了現代化的開發體驗和豐富的生態系統。

我的 MDX blog 專案已經穩定運行一年多，處理了數百個本地組件，包括複雜的圖表、互動式示範、資料視覺化等。Next.js 的 App Router 讓我能夠：

• 快速創建新文章並添加專屬組件
• 輕鬆管理組件的生命週期
• 保持程式碼的高度組織性
• 享受出色的開發者體驗

如果你也是 vibe coding 的愛好者，強烈建議你試試 Next.js！

本文基於實際 Next.js 15 + MDX + TypeScript 專案開發經驗撰寫，所有代碼範例都來自真實專案。