- รวมโครงสร้างแบบคู่เดิมของ esbuild + Rollup ให้เป็น Rolldown บันเดลเลอร์ที่พัฒนาด้วย Rust ตัวเดียว ทำให้ได้ ประสิทธิภาพการบิลด์เร็วขึ้นสูงสุด 10–30 เท่า
- เปิดตัว ปลั๊กอินรีจิสทรี ใหม่ ที่สามารถค้นหาและจัดการปลั๊กอินของ Vite·Rolldown·Rollup ได้
- เพิ่มความสามารถอำนวยความสะดวกในการพัฒนา เช่น Vite Devtools, การแก้เส้นทาง TypeScript, Wasm SSR, การส่งต่อคอนโซล
- รีลีสครั้งนี้คือ การเปลี่ยนแปลงเชิงโครงสร้างครั้งใหญ่ที่สุดของอีโคซิสเต็ม Vite และเป็นรากฐานสำหรับการพัฒนาทูลเชนแบบบูรณาการต่อไปในอนาคต
Vite 8 บนพื้นฐานของ Rolldown
- Vite 8 รวมโครงสร้างบันเดลเลอร์แบบคู่เดิมของ esbuild (สำหรับการพัฒนา) และ Rollup (สำหรับโปรดักชัน) ให้เป็น Rolldown บันเดลเลอร์ตัวเดียว
- Rolldown คือ บันเดลเลอร์ประสิทธิภาพสูงที่เขียนด้วย Rust และรองรับ Plugin API แบบเดียวกับ Rollup
- ปลั๊กอิน Vite เดิมส่วนใหญ่ทำงานได้โดยไม่ต้องแก้ไขเพิ่มเติม
- ด้าน ประสิทธิภาพ เร็วกว่า Rollup 10–30 เท่า และรองรับความสามารถขั้นสูงอย่าง การแคชระดับโมดูล, การแบ่งชังก์อย่างยืดหยุ่น, Module Federation
กระบวนการนำ Rolldown มาใช้
- ในช่วงแรกมีการปล่อยเทคโนโลยีพรีวิวผ่านแพ็กเกจ
rolldown-vite เพื่อรวบรวมฟีดแบ็กจากคอมมูนิตี้
- ทดสอบกับโค้ดเบสจริงที่หลากหลายและแก้ปัญหาความเข้ากันได้
- สร้าง ระบบทดสอบ CI เฉพาะทาง สำหรับปลั๊กอินและเฟรมเวิร์กหลัก
- เดือนธันวาคม 2025 ได้เปิดตัว Vite 8 เบตา พร้อมผนวก Rolldown อย่างสมบูรณ์
- ระหว่างช่วงเบตา Rolldown ได้พัฒนาจนมีเสถียรภาพในระดับ Release Candidate
ตัวอย่างการปรับปรุงประสิทธิภาพจริง
- หลายบริษัทได้รายงาน ผลของการลดเวลาบิลด์
- Linear: 46 วินาที → 6 วินาที
- Ramp: ลดลง 57%
- Mercedes-Benz.io: ลดลงสูงสุด 38%
- Beehiiv: ลดลง 64%
- ยิ่งเป็นโปรเจกต์ขนาดใหญ่ ผลลัพธ์ยิ่งโดดเด่น และมีการคาดหมายว่าจะมีการปรับปรุง Rolldown อย่างต่อเนื่อง
ทูลเชนแบบบูรณาการและเทคสแต็ก
- Vite 8 พัฒนาไปสู่ ทูลเชนแบบ end-to-end ที่ Vite (เครื่องมือบิลด์), Rolldown (บันเดลเลอร์) และ Oxc (คอมไพเลอร์) ทำงานร่วมกันอย่างใกล้ชิด
- ทำให้เกิดความสอดคล้องตลอดทั้งกระบวนการ parsing·transformation·optimization
- สามารถทำ tree shaking optimization โดยใช้ semantic analysis ของ Oxc
- เป็นโครงสร้างที่รองรับการนำสเปก JS ใหม่มาใช้ได้อย่างรวดเร็ว
ความสามารถเพิ่มเติม
- Vite Devtools: วิเคราะห์สถานะของโปรเจกต์ใน development server ได้แบบภาพรวม
- รองรับ การแก้ path (alias) ของ TypeScript อัตโนมัติ และ emitDecoratorMetadata ในตัว
- Wasm SSR: รองรับการอิมพอร์ต
.wasm?init ในสภาพแวดล้อม server-side rendering
- การส่งต่อ browser console: ส่งข้อผิดพลาดจากเบราว์เซอร์ไปยังเทอร์มินัลเพื่อเพิ่มประสิทธิภาพในการดีบัก
- @vitejs/plugin-react v6: ตัด Babel ออก ใช้ React Refresh บนพื้นฐาน Oxc และลดขนาดการติดตั้ง
ทิศทางการพัฒนาในอนาคต
- Full Bundle Mode (ทดลอง): ทำบันเดิลแม้ในระหว่างการพัฒนา ทำให้ เริ่มเซิร์ฟเวอร์เร็วขึ้น 3 เท่า, รีโหลดเร็วขึ้น 40%, และ มีคำขอเครือข่ายน้อยลง 10 เท่า
- ลดช่องว่างด้านประสิทธิภาพระหว่าง Rust และ JS ด้วย การส่ง Raw AST และ Native MagicString transformation
- กำลังมีความร่วมมือในอีโคซิสเต็มเพื่อทำให้ Environment API มีเสถียรภาพ
การเปลี่ยนแปลงของขนาดการติดตั้ง
- Vite 8 มีขนาดใหญ่กว่า Vite 7 ประมาณ 15MB
- lightningcss (ประมาณ 10MB): ให้ความสามารถบีบอัด CSS แบบพื้นฐาน
- Rolldown binary (ประมาณ 5MB): ขนาดที่เพิ่มขึ้นเพื่อเพิ่มประสิทธิภาพความเร็ว
- มีแผนปรับขนาดให้เหมาะสมต่อไปในรีลีสถัด ๆ ไป
คู่มือการย้ายระบบ
- โปรเจกต์ส่วนใหญ่สามารถ อัปเกรดได้โดยไม่ต้องเปลี่ยนการตั้งค่า
- การตั้งค่า
esbuild และ rollupOptions เดิมจะถูกแปลงให้อัตโนมัติ
- สำหรับโปรเจกต์ขนาดใหญ่ แนะนำ การย้ายระบบแบบ 2 ขั้นตอน
- เปลี่ยนจาก Vite 7 ไปใช้
rolldown-vite ก่อน แล้วค่อยอัปเกรดเป็น Vite 8
- ขั้นตอนโดยละเอียดสามารถดูได้จาก Migration Guide และ Changelog อย่างเป็นทางการ
ขอบคุณ Rollup และ esbuild
- Rollup ได้วางรากฐานให้อีโคซิสเต็มปลั๊กอินของ Vite และ Rolldown ก็สืบทอด API นั้นต่อมา
- esbuild เป็นเทคโนโลยีหลักที่ทำให้เกิดประสบการณ์การพัฒนาอันรวดเร็ว และเป็นแรงผลักดันให้เกิดการพัฒนาทูลิงบนพื้นฐาน Rust·Go
- การมีส่วนร่วมของทั้งสองโปรเจกต์ ฝังลึกอยู่ใน DNA ของ Vite
คอมมูนิตี้และความร่วมมือ
- การพัฒนา Vite 8 สำเร็จได้ด้วยความร่วมมือจาก sapphi-red และทีม Vite, ทีม Rolldown และผู้มีส่วนร่วมจากคอมมูนิตี้จำนวนมาก
- VoidZero, Bolt, NuxtLabs เข้าร่วมเป็นพาร์ตเนอร์หลัก
5 ความคิดเห็น
ความคิดเห็นจาก Hacker News
มันทำให้นึกขึ้นมาอีกครั้งว่าอุตสาหกรรมนี้เสียทรัพยากรคอมพิวต์ไปมากแค่ไหนกับ เครื่องมือที่ไม่มีประสิทธิภาพ ซึ่งทุกคนใช้กันโดยแทบไม่ตั้งคำถามภายใต้ความเชื่อว่า “การบิลด์ก็ต้องช้าเป็นธรรมดา”
พวกเราจัดตารางงานให้เข้ากับการบิลด์ที่ช้า เอาเวลาพักมาล้อเล่นกัน และถึงขั้นสร้างชั้นแคชเพิ่มขึ้นมา
ขอชื่นชมผู้ดูแล Vite
ซอฟต์แวร์โปรดักชันส่วนใหญ่นั้นช้ากว่าที่จำเป็นหลายสิบเท่า
แอป Electron ที่กิน RAM หลาย GB แต่ยังกระตุกกว่าซอฟต์แวร์เมื่อ 40 ปีก่อนก็คือหลักฐาน
เมื่อ 14 ปีก่อน ผมตระหนักถึงเวลาที่เสียไปกับการรอบิลด์ และรู้สึกว่าปัญหานี้หนักมากโดยเฉพาะใน ecosystem ของ Java
สมัยก่อนโปรเจ็กต์ Ruby หนึ่งที่ผมทำ integration test ใช้เวลา 10 นาทีทุกครั้งเพราะต้องสร้าง DB ใหม่เสมอ
Kotlin/Spring Boot ก็คอมไพล์ช้า และคอมไพเลอร์ของ Rust ก็ไม่ได้เร็วมาก
แต่สิ่งที่เราควบคุมได้คือการทดสอบ unit test ควรจบในระดับมิลลิวินาที และ integration test ก็ปรับปรุงได้มากด้วยการทำขนานและสุ่มข้อมูล
บน MacBook Pro ผมรัน spring integration test หลายร้อยตัวพร้อม Redis, DB และ Elasticsearch ได้ภายใน 40 วินาที
พอตั้งค่าแบบนี้ไว้แล้วก็จะได้ feedback loop ที่รวดเร็ว และความสนุกในการพัฒนาก็กลับมาอีกครั้ง
ส่วนที่ผมมีส่วนร่วมกับ Vite 8 คือ รองรับ Wasm SSR
ขยายให้การ import
.wasm?initใช้งานได้ในสภาพแวดล้อม SSR ด้วยกระบวนการจะช้าอยู่บ้าง แต่ผมประทับใจที่ทีมช่วยดูรายละเอียดอย่างดีและยังเพิ่มเอกสารให้ด้วย
รู้สึกได้ว่าทีม Vite ไม่ได้จริงจังแค่กับการสร้างเครื่องมือ แต่ยังจริงจังกับ การสอนผู้มีส่วนร่วมและการทำงานร่วมกัน ด้วย
ดีใจมากที่ได้เห็น การปรับปรุงด้านประสิทธิภาพ แบบนี้ในยุค Electron
โปรเจ็กต์ที่ผมดูแลมานานมากตัวหนึ่ง (เริ่มมาตั้งแต่ก่อน React hooks) เมื่อก่อนใช้ react-scripts บน Webpack แล้วบิลด์ใช้เวลา 2 นาที
ตอนนี้เปลี่ยนมาเป็น Vite 8 แล้วเสร็จใน 1 วินาที นี่เป็นตัวอย่างชัดเจนว่าเราสิ้นเปลืองทรัพยากรกันไปแค่ไหน
เบราว์เซอร์ควรจะรันได้ตรงๆ และ TypeScript ก็ถูกออกแบบมาให้รันได้ทันทีหลังจากลบ type ออก
การมีอยู่ของ build tool พวกนี้เองก็ดูเหมือนเป็นทิศทางที่ผิด
ทีมของเราหลังนำ Vite 8 มาใช้ เวลาบิลด์ลดจาก 4 นาทีเหลือ 30 วินาที
แทบจะเป็นการ แทนที่แบบ drop-in เลย และต้องขอบคุณทีม Vite
ผมใช้มันมาตั้งแต่ก่อนรวมเข้ากับ Vite แล้ว มันยอดเยี่ยมจริงๆ
คนบอกว่าเร็วกว่าทั้ง Next เสียอีก ถ้าระดับนั้นก็น่าจะใหญ่มาก
ขอบคุณทีม Vite ที่สร้าง โซลูชัน bundling โอเพนซอร์ส ที่ไม่ถูกผูกกับเฟรมเวิร์กใดเฟรมเวิร์กหนึ่ง
(กระแอมเบาๆ พร้อมเอ่ยถึง Turbopack)
เป็นข่าวที่ดีมาก แต่ดูเหมือน Next.js จะไม่ได้อาศัยผลสำเร็จจากคอมมูนิตี้แบบนี้
เพราะ อาการ NIH ของ Vercel
เริ่ม Turbopack alpha ใน Next 13 แล้วเพิ่งเปลี่ยนให้เป็นค่าเริ่มต้นใน Next 16
ในปี 2022 benchmark เทียบกับ Vite ก็ยังบิดเบือน
ทั้งปัญหาแคช ประสิทธิภาพช้า ช่องโหว่ความปลอดภัยของ RSC app router ที่สับสน และความยุ่งยากเมื่อโฮสต์นอก Vercel
การเลือก Next.js คือ ความเสี่ยง
ลิงก์ที่เกี่ยวข้อง: การเปรียบเทียบและถกเถียง, ประวัติของแคช, วิเคราะห์ประสิทธิภาพ, CVE ด้านความปลอดภัย, OpenNext
แม้แต่ในเอกสารทางการที่พูดถึง Next เป็นค่าเริ่มต้นก็ยังดูแปลก
ผมไม่เข้าใจเหตุผลว่าทำไมต้องใช้ React แบบ ไม่ใช่ SPA
เช่น Sitecore Cloud, Sanity, Contentful เป็นต้น
ด้วย Vite+, Void Cloud, Void Framework ฯลฯ
ดูเหมือนว่าศึกระหว่าง Vercel กับ Void กำลังจะเริ่มขึ้นแล้ว
โดยเฉพาะเดโม PRC(Server Functions) ที่น่าสนใจ เพราะแสดงให้เห็น type safety แบบ end-to-end ตั้งแต่ DB จนถึง UI
พวกเรากำลังศึกษาแนวทางออกแบบ RPC ด้วย Telefunc(ทางเลือกแทน tRPC) และหวังว่าจะได้ร่วมงานกับทีม Void
ลิงก์ที่เกี่ยวข้อง: วิดีโอเดโม PRC, Telefunc, Vike
Void Cloud ดูเหมือนจะสร้างอยู่บน Cloudflare Workers และตอนนี้ก็ยังมีข้อมูลไม่มาก
แต่การที่พวกเขา เปิด Vite+ เป็นโอเพนซอร์สภายใต้ MIT นั้นน่าส่งเสริมมาก
ถ้า Bun มัวแต่โฟกัสการสนับสนุน Anthropic จนละเลย OSS ก็อาจเสียความได้เปรียบทางการแข่งขันได้
อ้างอิง: Void Cloud
ถึง ecosystem ของ JS จะวุ่นวาย แต่ Vite ก็ยังแสดงให้เห็น DX ที่ยอดเยี่ยมและคุณภาพระดับโปรดักชันอย่างสม่ำเสมอ
ด้วย bundler Rolldown ที่รวมเข้ามา มันจะเป็นรากฐานที่เร็วขึ้นและยืดหยุ่นขึ้น
ในฐานะคนที่ทำเว็บมาตั้งแต่ปี 1998 ผมเป็นแฟนตัวยงจริงๆ
เพราะให้ความสำคัญกับการดูแลระยะยาว ผมจึง ใช้ esbuild ตรงๆ
ผมไม่ชอบต้องคอยแก้ทุกครั้งที่ wrapper อย่าง Vite พังเพราะมีการเปลี่ยนแปลงภายใน
ใช้ Zod จัดการตรวจสอบ type และสร้างโค้ดแค่สำหรับ Postgres types
ถ้าทำอีกครั้งรอบหน้าผมน่าจะใช้ Kysely
รองรับ tsconfig paths ในตัว เป็นการปรับปรุง QoL ที่ดีมาก
ช่วยลดความซ้ำซ้อนของการตั้งค่าได้
สำหรับบางโปรเจ็กต์มันอาจง่ายกว่า
จริง ๆ แล้วเดิมที JS เป็นภาษาที่ไม่จำเป็นต้องมีกระบวนการบิลด์ เบราว์เซอร์ควรจะรันมันได้ตรง ๆ และ TypeScript เองก็ถูกออกแบบมาให้รันได้ทันทีแค่ลบ type ออก ผมเลยรู้สึกว่าการมีอยู่ของเครื่องมือบิลด์พวกนี้เองน่าจะเป็นทิศทางที่ผิด -> แล้วเราจะทำให้มันกลับสู่สภาพปกติได้อย่างไร;
จากเดิมที่รันกันแค่ในเบราว์เซอร์ ตอนนี้กลายเป็นว่ารันบนเซิร์ฟเวอร์ได้โดยตรงแล้ว ก็ดูเหมือนจะเป็นพัฒนาการที่เลี่ยงไม่ได้ครับ
ผมคิดว่านี่เป็นปรากฏการณ์ที่เกิดขึ้นอย่างเป็นธรรมชาติเมื่อเว็บแอปมีความซับซ้อนและพัฒนามากขึ้น
บางทีเราน่าจะต้องเลิกใช้ JS บนเบราว์เซอร์เหมือนตอนที่ทิ้ง Flash ไปหรือเปล่า? แต่ดูเหมือนว่ายังไม่มีวี่แววว่า JS จะถูกทิ้ง