Webpack → Vite: เรื่องราวของการย้าย Bundler
(engineering.ab180.co)ขอมาแบ่งปันเรื่องราวการย้ายจาก Webpack ที่ใช้งานมาตลอด 5 ปีหลังเปิดให้บริการ ไปสู่ Vite แม้ยังมีหลายส่วนที่อาจไม่สมบูรณ์ แต่หากอ่านกันอย่างเพลิดเพลินก็จะขอบคุณมาก
จุดเด่นของ Webpack และการเปลี่ยนแปลงของระบบนิเวศเว็บ
Webpack ถูกพัฒนาและดูแลมาตลอด 10 ปีที่ผ่านมา จึงมีระบบนิเวศที่พร้อมมาก
ถูกใช้งานในหลายที่รวมถึง Create React App และรองรับหลายเบราว์เซอร์ด้วยการรวมโมดูลในรูปแบบ IIFE
อย่างไรก็ตาม ตลอด 5 ปีที่ผ่านมา ฟีเจอร์ภายในบริการเพิ่มขึ้นเกือบ 3 เท่า ทำให้เวลา build เพิ่มขึ้นและประสบการณ์การพัฒนาแย่ลง อีกทั้งระบบนิเวศเว็บก็พัฒนาไปมาก มีการเปลี่ยนแปลงหลายอย่าง เช่น การรองรับ ES Module
Bundler + Native
ในช่วง 1–2 ปีหลังมานี้ แนวทางการทำ bundling และ transpiling โดยอาศัยพลังของ Native เริ่มได้รับความสนใจ
มีความพยายามเพื่อก้าวข้ามข้อจำกัดด้านการประมวลผลของ JS ที่เป็น single-threaded
esbuild ที่พัฒนาด้วย Golang และ SWC ที่พัฒนาด้วย Rust เป็นตัวอย่างที่เด่น
ความพยายามครั้งที่ 1: bundling โดยใช้ esbuild เพียงอย่างเดียว
ในเวลานั้น เมื่อพิจารณาเรื่องความเสถียร ปลั๊กอิน และระบบนิเวศ จึงตัดสินใจใช้ bundler ที่อิงกับ esbuild และอยากตรวจสอบด้วยว่าประสิทธิภาพของ esbuild เองอยู่ในระดับไหน
หลังติดตั้งแพ็กเกจแล้วลองรันสคริปต์ build พบว่า build ที่เดิมใช้เวลาประมาณ 210 วินาที เสร็จในเวลาเพียง 2.16 วินาที แสดงให้เห็นถึง ความเร็วในการ build ที่เร็วขึ้นราว 100 เท่า
แต่เมื่อใช้ Babel เพื่อรองรับ EmotionJS ความเร็วกลับช้าลง 10 เท่า
และเนื่องจาก esbuild ไม่รองรับ HMR จึงมองว่าใช้งานได้ยาก แม้จะสามารถทำ HMR เองได้ แต่เห็นว่าจะมีต้นทุนด้านแรงงาน การบำรุงรักษา และการจัดการสูงมาก
ความพยายามครั้งที่ 2: bundling ด้วย Vite
แนวคิดของ Vite คือการแยก Dependencies ออกจาก Source code
Dependencies จะไม่เปลี่ยนหลังติดตั้ง จึง transpile ล่วงหน้าด้วย esbuild ส่วน Source code เปลี่ยนบ่อย จึงโหลดด้วย ESM และ cache ผลลัพธ์การ build เพื่อให้สามารถ build สำหรับพัฒนาได้อย่างรวดเร็ว
ใช้เทมเพลตที่ Vite มีให้ จึงทำ migration ได้อย่างง่ายดาย แม้จะมีบางประเด็นที่ต้องแก้ แต่ก็แก้ได้อย่างรวดเร็ว และทำให้สามารถตั้งค่าได้สั้นและกระชับกว่า Webpack มาก
ผลลัพธ์ของการย้าย bundler
เมื่อวัดเวลา build บน Netlify จากค่าเฉลี่ย 250 วินาที → ค่าเฉลี่ย 90 วินาที ลดลงเหลือ ประมาณ 36% ของเดิม
เมื่อไฟล์ตั้งค่ากระชับขึ้น สมาชิกทีมก็สามารถสร้างสภาพแวดล้อม build แบบ custom เพื่อนำไปใช้งานได้ง่ายขึ้น ส่งผลให้ประสิทธิภาพการทำงานดีขึ้น
เพื่อการปรับปรุงที่ดียิ่งขึ้น อาจเปลี่ยนไปใช้ไลบรารี CSS-in-JS ที่ไม่พึ่งพา Babel และลองนำ Monorepo มาใช้ได้
ในด้านระบบนิเวศ หาก SWC มีเสถียรภาพมากขึ้น ก็อาจใช้แทน Babel ได้ และ TypeScript Type Checker ก็กำลังถูกพอร์ตเป็น Native อยู่เช่นกัน
บทเรียน
- งานที่ดูใหญ่ หากแบ่งให้เล็กลง ทดสอบทีละส่วน และพูดคุยกันมากพอ ก็แก้ได้ไม่ยาก
- เครื่องมือที่กำลังเป็นกระแสหลักในตอนนี้ ก็อาจหายไปอย่างรวดเร็วได้จากการพัฒนาของระบบนิเวศ
- การเข้าถึงที่ดีช่วยสร้างสภาพแวดล้อมที่ดี
3 ความคิดเห็น
ความเร็วของ esbuild น่าทึ่งมากครับ .
ตอนแรกก็ครึ่งเชื่อครึ่งสงสัยตอนเห็นว่าหน้าเว็บหลักของ esbuild ก็ชูจุดเด่นว่าเร็วกว่า 10-100x แต่พอได้เห็นกับตาจริง ๆ แล้วถึงกับช็อกเลยครับ!
ผมก็เฝ้ารอให้ยุคนั้นมาถึงจริง ๆ เหมือนกันครับ! รู้สึกว่าน่าจะทำให้การพัฒนาซอฟต์แวร์สนุกขึ้นมากเลย :)