เวลาเปิดดู package.json ของโปรเจกต์เว็บสักตัว เรามักเจอชื่อเต็มไปหมด ทั้ง React, Vite, ESLint, React Router และ Next.js ทั้งหมดติดตั้งเป็น Package เหมือนกัน ใช้เขียนเว็บเหมือนกัน และบางตัวก็ทำงานร่วมกันอยู่ในโปรเจกต์เดียวกัน แล้วทำไม React ถึงเรียกว่า Library, Vite เรียกว่า Build Tool ส่วน Next.js กลับเรียกว่า Framework? หรือจริง ๆ แล้ว Framework ก็คือ Library ที่มีฟีเจอร์เยอะกว่า?

คำตอบคือ ไม่ได้แบ่งกันด้วยขนาดหรือจำนวนฟีเจอร์ครับ จุดต่างอยู่ที่ว่าเทคโนโลยีแต่ละตัวเข้ามารับผิดชอบส่วนไหนของโปรเจกต์ และมันเข้ามากำหนดวิธีที่เราเขียนหรือจัดโครงสร้างแอปมากแค่ไหน React ระบุตัวเองว่าเป็น Library สำหรับสร้าง User Interface ส่วน Next.js ระบุว่าเป็น React Framework สำหรับสร้าง Full-stack Web Application ขณะที่ Vite เป็น Build Tool ที่ช่วยจัดการการรันโปรเจกต์ระหว่างพัฒนาและการ Build สำหรับ Production อย่างชัดเจน แต่ก่อนจะไปดูว่าแต่ละแบบต่างกันยังไง มีอีกเรื่องที่ต้องแยกให้ออกก่อนครับ

ติดตั้งผ่าน npm เหมือนกัน ไม่ได้แปลว่าเป็นสิ่งประเภทเดียวกัน

หลายคนเริ่มสับสนจากตรงนี้ เพราะไม่ว่าจะเป็น React, Next.js, Vite หรือ ESLint เราก็เจอชื่อของมันอยู่ใน npm เหมือนกัน แต่ npm เป็นช่องทางสำหรับเผยแพร่ ค้นหา ติดตั้ง และจัดการ Package ไม่ได้เป็นตัวกำหนดว่า Package นั้นต้องเป็น Library, Tool หรือ Framework ตัว npm เองประกอบด้วย 3 ส่วนหลัก ได้แก่ เว็บไซต์, Command Line Interface หรือ CLI และ Registry ที่เก็บ Package รวมถึงข้อมูลของแต่ละ Package เอาไว้ พูดง่าย ๆ คือ การอยู่บน npm บอกเพียงว่าเราสามารถนำ Package นั้นมาใช้ในโปรเจกต์ได้ แต่ไม่ได้บอกว่ามันเข้ามาทำหน้าที่อะไร เหมือนเราซื้อทั้งไขควง สีทาบ้าน และชุดเฟอร์นิเจอร์จากร้านเดียวกัน ของทุกชิ้นมาจากร้านเดียวกันก็จริง แต่ไม่ได้แปลว่าทำหน้าที่เหมือนกันครับ

Tool คืออะไร?

คำว่า Tool เป็นคำที่ค่อนข้างกว้างในวงการ Development เรามักใช้เรียกซอฟต์แวร์ที่เข้ามาช่วยงานบางอย่างใน Workflow โดยไม่ได้เข้ามากำหนดโครงสร้างทั้งหมดของแอป ตัวอย่างที่เห็นภาพง่ายที่สุดคือ Vite ซึ่งเป็น Build Tool ที่มี Development Server สำหรับรันโปรเจกต์ในเครื่อง และมีคำสั่ง Build สำหรับสร้างไฟล์ที่พร้อมนำไปใช้งานบน Production ในโปรเจกต์ React ที่สร้างด้วย Vite เราอาจใช้คำสั่งประมาณนี้

npm run dev

Vite จะช่วยเปิด Development Server ให้เราแก้โค้ดและดูผลลัพธ์ได้สะดวกขึ้น เมื่อจะ Deploy ก็ใช้คำสั่ง

npm run build

จากนั้น Vite จะสร้าง Production Build ตามการตั้งค่าของโปรเจกต์ แต่ Vite ไม่ได้เข้ามาบอกว่าเว็บไซต์ต้องมีหน้าอะไร ต้องจัด Business Logic แบบไหน หรือ Route /about ต้องแสดง Component ตัวใด เรื่องเหล่านี้ยังเป็นสิ่งที่เราหรือ Framework ตัวอื่นต้องจัดการ อีกตัวอย่างคือ ESLint ซึ่งเป็น Linter ที่ใช้ตรวจหาและรายงาน Pattern ในโค้ดตามกฎที่กำหนดไว้ ช่วยให้ทีมควบคุมคุณภาพและรูปแบบของโค้ดให้ไปในทิศทางเดียวกัน

Tool ที่ Dev ใช้กันจึงมีได้หลายแบบ เช่น

• Build Tool

• Linter

• Formatter

• Testing Tool

• Package Manager

• Debugging Tool

Tool แต่ละตัวช่วยคนละงาน และโปรเจกต์หนึ่งก็มักใช้หลายตัวร่วมกันอยู่แล้ว

แล้ว Library คืออะไร?

Library คือชุดความสามารถที่เราเลือกเรียกใช้จากโค้ดของเรา เราเป็นคนตัดสินใจว่าจะหยิบ API, Function หรือ Component ตัวไหนมาใช้ ตรงไหน และเมื่อไร React เป็นตัวอย่างที่ตรงที่สุด เพราะหน้าเว็บไซต์ทางการเรียก React ว่าเป็น Library สำหรับสร้าง User Interface บนเว็บและ Native โดยให้เราสร้าง UI จากส่วนย่อยที่เรียกว่า Component แล้วนำมาประกอบกันเป็นหน้าและแอป ลองดู Component แบบง่ายๆครับ

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

ในตัวอย่างนี้ เราเป็นฝ่ายเรียก useState จาก React และเป็นคนกำหนดเองว่า

• State เริ่มต้นเป็นเท่าไร

• จะเพิ่มค่าเมื่อเกิด Event ไหน

• จะแสดงข้อมูลออกมาอย่างไร

• Component นี้จะถูกนำไปใช้ที่หน้าไหน

React ช่วยจัดการเรื่อง Component, State และการแสดงผล UI แต่ไม่ได้กำหนดระบบทั้งหมดของแอปให้เรา หน้า React อย่างเป็นทางการอธิบายไว้ตรง ๆ ว่า React เป็น Library ที่ไม่ได้กำหนดวิธีทำ Routing และ Data Fetching ให้กับแอปทั้งหมด ดังนั้น ถ้าเราเริ่มโปรเจกต์จาก React กับ Vite เราอาจต้องเลือกสิ่งอื่นเข้ามาเพิ่มเอง เช่น

• จะใช้ Router ตัวไหน

• จะจัดการ Form อย่างไร

• จะโหลดและ Cache ข้อมูลด้วยอะไร

• จะวาง Folder Structure แบบไหน

• จะทำ Server-side Rendering หรือไม่

• จะจัดการ Authentication ที่ส่วนใด

ข้อดีคือเรามีอิสระในการเลือกค่อนข้างมาก แต่ข้อแลกเปลี่ยนคือทีมต้องเป็นคนตัดสินใจและดูแลการเชื่อมต่อของแต่ละส่วนเอง

Framework เข้ามาทำอะไรเพิ่ม?

Framework ไม่ได้มีแค่ Function หรือ Component ให้เราเรียกใช้ แต่จะเตรียม โครงสร้าง กติกา และ Flow การทำงานบางส่วน มาให้ด้วย เวลาใช้ Framework เราจึงไม่ได้เลือกทุกอย่างได้อย่างอิสระเหมือนเริ่มจาก Library เพียงอย่างเดียว แต่ต้องเขียนโค้ดให้เข้ากับ Convention ที่ Framework กำหนด Next.js เป็นตัวอย่างที่ชัดครับ เอกสารทางการระบุว่า Next.js เป็น React Framework สำหรับสร้าง Full-stack Web Application เราใช้ React Components ในการสร้าง UI แล้วใช้ความสามารถของ Next.js สำหรับส่วนอื่น ๆ เพิ่มเติม โดย Next.js ยังตั้งค่าเครื่องมือระดับล่างอย่าง Bundler และ Compiler บางส่วนให้โดยอัตโนมัติด้วย ตัวอย่างง่ายที่สุดคือระบบ Routing

สมมติว่าเราต้องการสร้างหน้า /about ด้วย Next.js App Router เราสามารถวางไฟล์ไว้แบบนี้

app/
├── page.tsx
└── about/
    └── page.tsx

จากนั้นเขียน Component ใน app/about/page.tsx

export default function AboutPage() {
  return (
    <main>
      <h1>About Us</h1>
    </main>
  );
}

Next.js ใช้ Folder เป็นตัวกำหนด URL Segment และใช้ไฟล์พิเศษอย่าง page.tsx สร้าง UI ของ Route นั้น เพราะฉะนั้น app/about/page.tsx จึงกลายเป็นหน้า /about ตาม Convention ของ Framework เราไม่ได้เขียน Router ขึ้นมาแล้วบอกว่า /about ต้องเชื่อมกับ AboutPage โดยตรง แต่เลือกวางไฟล์ให้ถูกตำแหน่ง จากนั้น Next.js เป็นคนจัดการ Flow ของ Routing ให้ นี่คือความต่างที่เริ่มเห็นได้ชัดระหว่าง Library กับ Framework ครับ

จุดต่างจริง ๆ คือใครควบคุม Flow ของโปรเจกต์

มีคำอธิบายที่ Dev มักใช้เพื่อแยกสองคำนี้ออกจากกันว่า

ตอนใช้ Library โค้ดของเราเรียก Library
แต่ตอนใช้ Framework เรานำโค้ดไปวางในจุดที่ Framework กำหนด แล้ว Framework เป็นคนเรียกใช้งานต่อ

คำอธิบายนี้ช่วยให้เห็นภาพได้ดี แม้จะไม่ใช่กฎที่ใช้แบ่งเทคโนโลยีทุกตัวได้แบบตายตัว ตอนใช้ React เราเป็นฝ่ายเรียก Hook หรือ Component ที่ต้องการ แต่ตอนใช้ Next.js เราสร้างไฟล์อย่าง page.tsx, layout.tsx หรือไฟล์พิเศษอื่นตาม Convention แล้ว Next.js จะนำโค้ดเหล่านั้นไปใช้ในกระบวนการ Routing และ Rendering ของมัน

Framework จึงมักตัดสินใจบางเรื่องแทนเรา เช่น

• ไฟล์บางประเภทควรวางอยู่ที่ไหน

• Route ถูกสร้างอย่างไร

• หน้าและ Layout เชื่อมกันแบบไหน

• โค้ดบางส่วนทำงานที่ Server หรือ Client

• กระบวนการ Build ถูกตั้งค่าอย่างไร

• ระบบรองรับการ Render รูปแบบใดบ้าง

ข้อดีคือทีมไม่ต้องออกแบบและต่อระบบพื้นฐานทุกอย่างใหม่เอง ส่วนข้อแลกเปลี่ยนคือ เราต้องเรียนรู้ Convention และข้อจำกัดของ Framework นั้น รวมถึงต้องยอมทำงานอยู่ภายใน Flow ที่มันเตรียมไว้

ลองสร้างหน้าเดียวกันด้วย React Router และ Next.js

เพื่อให้เห็นความต่างชัดขึ้น ลองกลับมาที่หน้า /about อีกครั้ง ถ้าเราใช้ React Router แบบ Declarative เราสามารถประกาศ Route ผ่านโค้ดได้ประมาณนี้

import {
  BrowserRouter,
  Routes,
  Route,
} from "react-router";

import Home from "./pages/Home";
import About from "./pages/About";

export default function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

ในโค้ดนี้ เราเป็นคนเขียนความสัมพันธ์ระหว่าง URL กับ Component อย่างชัดเจน

• / ใช้ Component Home

• /about ใช้ Component About

แต่ใน Next.js App Router เราใช้โครงสร้างไฟล์เป็นตัวกำหนด Route แทน

app/
├── page.tsx
└── about/
    └── page.tsx

ผลลัพธ์ที่ผู้ใช้เห็นอาจคล้ายกัน แต่สิ่งที่ต่างคือวิธีที่โปรเจกต์อธิบาย Routing React Router แบบ Declarative ให้เรากำหนด Routing ผ่าน API ส่วน Next.js ให้เราทำตาม File-system Convention ของ Framework ไม่ได้แปลว่าแบบหนึ่งดีกว่าอีกแบบเสมอไปครับ โปรเจกต์ที่ต้องการควบคุม Route Configuration เองอาจชอบวิธีแรก ขณะที่ทีมที่ต้องการโครงสร้างร่วมกันชัดเจนอาจทำงานกับ File-system Routing ได้สะดวกกว่า

แล้ว React Router เป็น Library หรือ Framework กันแน่?

ถ้าเป็นบทความเมื่อหลายปีก่อน เราอาจเห็น React Router ถูกเรียกว่า Routing Library แต่สถานะปัจจุบันของมันมีรายละเอียดมากกว่านั้น React Router ระบุว่าตัวเองเป็น Multi-strategy Router for React และมีรูปแบบการใช้งานหลัก 3 Mode ได้แก่ Declarative, Data และ Framework

1 .Declarative Mode

เหมาะกับการทำ Routing พื้นฐาน เช่น จับคู่ URL กับ Component, เปลี่ยนหน้า และตรวจสอบว่า Link ใดกำลัง Active อยู่

2. Data Mode

เพิ่มความสามารถด้าน Data Loading, Action, Pending State และ API อย่าง loader, action และ useFetcher

3. Framework Mode

เพิ่มความสามารถระดับ Framework เช่น Route Module, Type Safety, Code Splitting รวมถึงกลยุทธ์การ Render แบบ SPA, SSR และ Static Rendering ความสามารถของแต่ละ Mode จะเพิ่มขึ้นตามลำดับ แต่สิ่งที่เราต้องแลกคือระดับการควบคุม Architecture บางส่วน ซึ่งเอกสาร React Router อธิบายไว้ตรง ๆ ว่าให้เลือก Mode ตามระดับที่ต้องการควบคุมเอง หรืออยากให้ React Router เข้ามาช่วยจัดการ

ดังนั้น การบอกว่า “React Router คือ Tool ส่วน Next.js คือ Framework” แบบไม่มีบริบทจึงไม่ค่อยตรงกับสถานะปัจจุบันแล้ว คำตอบที่แม่นกว่าคือ React Router สามารถใช้งานได้ตั้งแต่ระดับ Router แบบเรียบง่าย ไปจนถึง Framework เต็มรูปแบบ ขึ้นอยู่กับ Mode ที่เราเลือก

Tool, Library และ Framework ใช้พร้อมกันได้ไหม?

ได้ และเป็นเรื่องปกติมากครับ โปรเจกต์ Next.js หนึ่งตัวอาจมี

Framework ไม่ได้มาแทนที่ Library และ Library ก็ไม่ได้ทำให้เราไม่ต้องใช้ Tool แต่ละอย่างอยู่คนละระดับและรับผิดชอบคนละส่วนของงาน เพราะฉะนั้น แทนที่จะถามว่า “ควรเลือก Tool หรือ Framework?” คำถามที่เหมาะกว่าคือ

โปรเจกต์นี้ควรให้ Framework เข้ามาจัดการส่วนไหน และส่วนไหนที่ทีมต้องการเลือกหรือควบคุมเอง?

ควรประกอบ React App เองเมื่อไร?

เราสามารถสร้าง React App โดยไม่ใช้ Full-stack Framework ได้ โดยเริ่มจาก Build Tool อย่าง Vite, Parcel หรือ Rsbuild แล้วค่อยเลือก Router และเครื่องมือส่วนอื่นเข้ามาเอง เอกสาร React มีคู่มือสำหรับการสร้าง React App จากศูนย์ด้วยแนวทางนี้โดยตรง และอธิบายว่า Build Tool จะช่วย Package และรัน Source Code พร้อมมี Development Server และ Build Command สำหรับนำแอปไป Deploy

แนวทางนี้อาจเหมาะกับกรณี เช่น

• ต้องการเพิ่ม React เข้าไปเพียงบางส่วนของเว็บไซต์เดิม

• โปรเจกต์มี Architecture เฉพาะ

• เป็นแอปภายในที่มีขอบเขตไม่ซับซ้อนมาก

• ทีมต้องการเลือก Data Layer และ Router ด้วยตัวเอง

• ต้องการเรียนรู้ว่าแต่ละส่วนของ React App เชื่อมกันอย่างไร

สิ่งที่ต้องระวังคือ เมื่อโปรเจกต์โตขึ้น ทีมอาจเริ่มต้องจัดการ Routing, Data Fetching, Code Splitting, Error Handling และ Convention ต่าง ๆ เองมากขึ้น บางทีมเริ่มต้นเพราะไม่อยากใช้ Framework แต่สุดท้ายกลับสร้าง Convention ภายในขึ้นมาจำนวนมาก จนกลายเป็น Framework ขนาดเล็กของทีมโดยไม่รู้ตัว

แล้วโปรเจกต์แบบไหนเหมาะกับ Framework?

Framework มักเหมาะกับแอปที่มีหลายส่วนต้องทำงานร่วมกัน และต้องการโครงสร้างที่ชัดตั้งแต่ต้น เช่น

• มี Routing หลายหน้า

• มีการโหลดและแก้ไขข้อมูลจาก Server

• ต้องการ Server-side หรือ Static Rendering

• มีสมาชิกในทีมหลายคน

• ต้องการ Convention ที่ทุกคนใช้ร่วมกัน

• ไม่ต้องการตั้งค่า Build และ Integration ทุกส่วนเอง

React แนะนำว่าโปรเจกต์ใหม่ส่วนใหญ่จะได้ประโยชน์จาก Framework โดยเฉพาะเมื่อแอปต้องมี Routing เพราะ Framework สามารถเชื่อม Routing เข้ากับ Data Fetching และ Code Splitting มาให้พร้อมกว่าเริ่มประกอบทุกส่วนเอง แต่ไม่ได้หมายความว่าเห็นคำว่า Framework แล้วต้องเลือกใช้ทันที

เรายังต้องดูด้วยว่า Framework นั้น

• รองรับ Requirement ของโปรเจกต์หรือไม่

• Deploy ใน Environment ที่เราต้องการได้หรือเปล่า

• ทีมมีความรู้และประสบการณ์กับมันแค่ไหน

• Convention ช่วยลดงานจริง หรือเพิ่มความซับซ้อน

• ความสามารถที่ให้มามีสิ่งที่โปรเจกต์ต้องใช้จริงมากน้อยแค่ไหน

Framework ที่ได้รับความนิยมอาจเป็นตัวเลือกที่ดี แต่ไม่จำเป็นต้องเป็นตัวเลือกที่เหมาะที่สุดสำหรับทุกโปรเจกต์ครับ

แล้ว Create React App ยังควรใช้ไหม?

ปัจจุบัน Create React App ถูกประกาศ Deprecate สำหรับการสร้างแอปใหม่แล้ว ทีม React แนะนำให้โปรเจกต์ใหม่เลือกใช้ Framework ที่เหมาะสม หรือเริ่มด้วย Build Tool อย่าง Vite, Parcel หรือ Rsbuild ในกรณีที่ต้องการประกอบระบบเองถ้าเราเจอบทเรียนเก่าที่ใช้คำสั่ง

npx create-react-app my-app

ไม่ได้หมายความว่า Concept ของ React ในบทเรียนนั้นผิดทั้งหมด แต่ควรรู้ว่าขั้นตอนการตั้งโปรเจกต์ไม่ใช่แนวทางหลักที่ทีม React แนะนำในปัจจุบันแล้ว สำหรับโปรเจกต์ใหม่จึงควรตรวจสอบ Documentation ล่าสุดก่อนเลือก Starter หรือคำสั่งสร้างโปรเจกต์เสมอ

FAQ

React เป็น Library หรือ Framework?

React เป็น Library สำหรับสร้าง User Interface ตามคำอธิบายจากเว็บไซต์ทางการ โดยให้เราสร้าง UI จาก Component แล้วนำมาประกอบกันเป็นหน้าและแอป React ไม่ได้กำหนดระบบ Routing และ Data Fetching สำหรับทั้งแอปมาให้ หากต้องการสร้างแอปเต็มรูปแบบ เราสามารถใช้ React ร่วมกับ Framework หรือเลือกประกอบเครื่องมือส่วนอื่นด้วยตัวเองได้

Vite เป็น Framework ไหม?

Vite เป็น Build Tool ไม่ใช่ Application Framework หน้าที่หลักคือช่วยรัน Source Code ระหว่างพัฒนา มี Development Server และสร้าง Production Build สำหรับนำไป Deploy Vite สามารถใช้ร่วมกับ React, Vue, Svelte และเทคโนโลยีอื่นได้ แต่ไม่ได้กำหนด Routing หรือ Architecture ทั้งหมดของแอปให้เรา

Next.js ใช้แทน React ได้ไหม?

ไม่ได้ใช้แทนกันโดยตรงครับ เพราะ Next.js เป็น Framework ที่ใช้ React Components เป็นพื้นฐานในการสร้าง User Interface แล้วเพิ่มระบบอื่น เช่น Routing, Rendering และการตั้งค่าเครื่องมือระดับล่างเข้ามา พูดอีกแบบคือ เมื่อเขียน Next.js เราก็ยังเขียน React อยู่ แต่เขียนภายใต้โครงสร้างและ Convention ของ Next.js

เริ่มโปรเจกต์ใหม่ควรใช้ Vite หรือ Next.js?

ขึ้นอยู่กับลักษณะของโปรเจกต์ Vite เหมาะเมื่อเราต้องการเริ่มจาก Build Tool และเลือก Router, Data Layer รวมถึงโครงสร้างต่าง ๆ ด้วยตัวเอง ส่วน Next.js เหมาะเมื่อโปรเจกต์ต้องการ Framework ที่มี Routing, Rendering และ Convention หลายอย่างเตรียมไว้ให้แล้ว ทีม React แนะนำให้โปรเจกต์ใหม่ส่วนใหญ่พิจารณา Framework โดยเฉพาะแอปที่ต้องมี Routing แต่ยังรองรับแนวทางการสร้าง React App จากศูนย์ด้วย Build Tool อย่าง Vite เมื่อ Framework ไม่เหมาะกับ Requirement ของงาน

สรุป Tool, Library และ Framework ต่างกันยังไง?

จำแบบง่าย ๆ ได้ประมาณนี้ครับTool ช่วยงานบางอย่างในกระบวนการพัฒนา เช่น Build, Lint, Test หรือจัดการ Package Library ให้ API หรือความสามารถที่เราเลือกเรียกใช้ในโค้ด เช่น React ที่ใช้สร้าง User Interface จาก Component Framework เตรียมทั้งความสามารถ โครงสร้าง และ Convention มาให้ แล้วให้เราเขียนโค้ดอยู่ภายใน Flow ของมัน เช่น Next.js แต่คำเหล่านี้ไม่ใช่กล่องที่แยกขาดจากกันเสมอไป เทคโนโลยีบางตัวอาจรองรับได้หลายบทบาท อย่าง React Router ที่ใช้งานได้ตั้งแต่ Declarative Router ไปจนถึง Framework Mode สิ่งสำคัญจึงไม่ใช่แค่จำว่าแต่ละตัวถูกเรียกว่าอะไร แต่ต้องดูว่า มันเข้ามารับผิดชอบส่วนไหน มันกำหนดโครงสร้างของโปรเจกต์มากแค่ไหน มีเรื่องอะไรที่มันจัดการให้เราแล้ว ทีมยังต้องเลือกและดูแลอะไรเองบ้าง

เพราะสุดท้ายแล้ว การเลือกเทคโนโลยีไม่ได้วัดจากว่าตัวไหนใหญ่กว่า หรือมีฟีเจอร์เยอะกว่า แต่ดูว่าระดับการควบคุมและความช่วยเหลือที่มันให้มาเหมาะกับโปรเจกต์ของเราหรือไม่