การเปิดตัว Rails 8 ได้จุดประกายการถกเถียงอย่างเข้มข้นเกี่ยวกับความซับซ้อนของการพัฒนาเว็บ โดยนักพัฒนาตั้งคำถามว่าระบบนิเวศ JavaScript สมัยใหม่ได้กลายเป็นสิ่งที่ซับซ้อนเกินความจำเป็นหรือไม่ บทความล่าสุดที่เน้นความแตกต่างระหว่างแนวทางแบบ batteries-included ของ Rails กับ toolchain ที่แผ่ขยายของการพัฒนา frontend สมัยใหม่ได้กระทบจิตใจของชุมชนนักพัฒนา
การถกเถียงมีจุดศูนย์กลางอยู่ที่สถานการณ์ที่คุ้นเคย คือ นักพัฒนาถูกสนับสนุนให้นำเครื่องมือมากมายมาใช้ รวมถึง Vite , React , TypeScript , Tailwind CSS , ESLint , Prettier และเครื่องมืออื่นๆ อีกมากมาย ในขณะที่แอปพลิเคชัน Rails แบบง่ายๆ อาจบรรลุเป้าหมายเดียวกันได้ด้วยความซับซ้อนที่น้อยกว่ามาก การสนทนานี้เกิดขึ้นซ้ำๆ มานานกว่าทศวรรษ แต่ความสามารถที่เพิ่มขึ้นของ Rails 8 ได้นำมันกลับมาเป็นจุดสนใจอีกครั้ง
การเปรียบเทียบ Toolchain ของ JavaScript สมัยใหม่
| หมวดหมู่เครื่องมือ | ค่าเริ่มต้นของ Rails 8 | Modern JS Stack |
|---|---|---|
| Build Tool | Import Maps | Vite/Webpack |
| Frontend Framework | Hotwire/Stimulus | React/Vue/Svelte |
| CSS Framework | Built-in Tailwind | Tailwind + PostCSS |
| Type Checking | Ruby (dynamic) | TypeScript |
| Code Formatting | RuboCop | Prettier + ESLint |
| Deployment | Kamal | Docker + K8s |
ปัญหาความซับซ้อน
นักพัฒนาหลายคนโต้แย้งว่าการพัฒนาเว็บสมัยใหม่ได้กลายเป็นสิ่งที่ซับซ้อนเกินความจำเป็น โดยแต่ละเครื่องมือแก้ปัญหาที่สร้างขึ้นโดยเครื่องมืออื่นๆ ในวงจรที่ไม่มีที่สิ้นสุด ชุมชนแบ่งออกเป็นสองฝ่าย ระหว่างผู้ที่เห็นว่าความซับซ้อนนี้เป็นสิ่งที่มีอยู่โดยธรรมชาติในแอปพลิเคชันเว็บสมัยใหม่ และผู้ที่เชื่อว่าส่วนใหญ่เป็นสิ่งที่เราสร้างขึ้นเอง ผู้สนับสนุน Rails ชี้ไปที่ปรัชญาของเฟรมเวิร์กที่เน้น convention over configuration เป็นทางแก้ไขสำหรับการหมุนวนของความซับซ้อนนี้
อย่างไรก็ตาม ผู้วิจารณ์ชี้ให้เห็นว่า Rails เองก็ได้ผ่านการเปลี่ยนแปลงครั้งใหญ่ตลอดหลายปีที่ผ่านมา โดยเปลี่ยนจาก Bundler ไป Webpacker ไป Sprockets ไป Propshaft และจาก CoffeeScript ไปสู่โซลูชัน JavaScript ต่างๆ วิวัฒนาการนี้ได้สร้างความท้าทายในการอัปเกรดของตัวเอง โดยแอปพลิเคชัน Rails หลายตัวติดอยู่ในเวอร์ชันเก่าเนื่องจากความยากลำบากในการตามทันการเปลี่ยนแปลงเหล่านี้
ความแตกแยกของ Frontend Framework
ส่วนสำคัญของการถกเถียงมุ่งเน้นไปที่แนวทางการพัฒนา frontend ในขณะที่ Rails 8 ส่งเสริม Hotwire และ Stimulus เป็นทางเลือกที่ง่ายกว่าโซลูชันที่ใช้ React นักพัฒนาหลายคนพบว่าเครื่องมือเหล่านี้สับสนและมีข้อจำกัดสำหรับการโต้ตอบที่ซับซ้อน ชุมชนหันไปใช้โซลูชันอย่าง Inertia.js มากขึ้น ซึ่งเชื่อมต่อ backend ของ Rails กับ frontend framework สมัยใหม่อย่าง React หรือ Vue
ผมใช้ Rails กับ Inertia Rails ผมได้ความสุขเต็มที่จาก Rails แต่ผมสามารถสร้างคอมโพเนนต์ React ที่แสดงหน้าใดก็ได้ที่ผมต้องการเขียนใน React Inertia จะ serialize และส่งข้อมูลจาก controller ของผม ดังนั้นจึงไม่มี state แค่การสร้าง UI แบบบริสุทธิ์
แนวทางแบบผสมผสานนี้ดูเหมือนจะตอบสนองนักพัฒนาที่ต้องการความสามารถ backend ของ Rails ในขณะที่ยังคงเข้าถึงระบบนิเวศที่หลากหลายของคอมโพเนนต์และเครื่องมือ frontend
โซลูชันแบบไฮบริด
- Inertia.js: เชื่อมต่อ backend ของ Rails กับ frontend ที่ใช้ React/Vue/Svelte
- Turbo-Mount: การรวม React เข้ากับ Rails แบบมินิมอล
- Rails API + SPA: การแยกความรับผิดชอบออกจากกันอย่างสมบูรณ์
- Islands Architecture: การติดตั้งคอมโพเนนต์แบบเลือกสรรเพื่อการโต้ตอบ
ขนาดทีมและขนาดโปรเจกต์มีความสำคัญ
การถกเถียงเผยให้เห็นปัจจัยสำคัญที่มักถูกมองข้าม คือ ขนาดทีมและความซับซ้อนของโปรเจกต์ นักพัฒนาหลายคนสังเกตว่า vanilla Rails ทำงานได้อย่างยอดเยี่ยมสำหรับทีมเล็กและแอปพลิเคชัน CRUD ที่ตรงไปตรงมา แต่ทีมใหญ่ที่มีชุดทักษะที่หลากหลายอาจได้ประโยชน์จากแนวทางแบบโมดูลาร์มากกว่า ตลาดการจ้างงานก็มีบทบาทเช่นกัน เนื่องจากการหานักพัฒนาที่มีประสบการณ์กับ Hotwire และ Stimulus นั้นท้าทายกว่าการหานักพัฒนา React หรือ Vue อย่างมาก
สภาพแวดล้อมองค์กรนำเสนอข้อพิจารณาเพิ่มเติม ด้วย deployment pipeline ที่มีอยู่แล้ว ข้อกำหนดด้านความปลอดภัย และความต้องการในการบูรณาการที่อาจสนับสนุน toolchain ที่เป็นมาตรฐานมากกว่าค่าเริ่มต้นที่มีความเห็นของ Rails
ความขัดแย้งของประสิทธิภาพ
แม้จะมีความกังวลเรื่องความซับซ้อน นักพัฒนาหลายคนรายงานว่าการกลับมาใช้ Rails หลังจากหลายปีในระบบนิเวศ JavaScript ได้ปรับปรุงประสิทธิภาพของพวกเขาอย่างมาก ระบบนิเวศที่เป็นผู้ใหญ่ของ gem ที่ทำงานร่วมกันได้ของเฟรมเวิร์กตัดกันอย่างชัดเจนกับลักษณะที่แตกแยกของ npm package ซึ่งปัญหาความเข้ากันได้และความขัดแย้งของเวอร์ชันเป็นเรื่องปกติ
การปรับปรุงของ Rails 8 รวมถึงเครื่องมือ deployment ที่ดีขึ้นอย่าง Kamal และการจัดการ JavaScript ที่ง่ายขึ้นผ่าน import map ได้ทำให้แนวทาง vanilla Rails น่าสนใจมากขึ้น นักพัฒนาบางคนรายงานว่าเวลา deployment ลดลงจาก 30 นาทีเหลือ 5 นาทีหลังจากเอากระบวนการ build JavaScript ที่ซับซ้อนออก
คุณสมบัติหลักของ Rails 8
- Import Maps: โซลูชัน JavaScript แบบไม่ต้อง build สำหรับการจัดการ dependency ที่ง่ายขึ้น
- Kamal: เครื่องมือ deployment ที่เรียบง่าย ลดความซับซ้อนในการ deploy
- Hotwire/Stimulus: เฟรมเวิร์กสำหรับการโต้ตอบ frontend ที่ Rails แนะนำ
- Propshaft: โซลูชัน asset pipeline ปัจจุบัน
- Tailwind Integration: การรองรับ CSS framework ในตัว
มองไปข้างหน้า
การถกเถียงเน้นให้เห็นความตึงเครียดพื้นฐานในการพัฒนาเว็บระหว่างความเรียบง่ายและความสามารถ ในขณะที่ Rails เสนอเส้นทางสู่การพัฒนาอย่างรวดเร็วด้วยเครื่องมือน้อยที่สุด วิวัฒนาการของระบบนิเวศ frontend ไปสู่สถาปัตยกรรมแบบคอมโพเนนต์และการโต้ตอบที่หลากหลายได้สร้างคุณค่าที่แท้จริงที่นักพัฒนาหลายคนไม่เต็มใจที่จะละทิ้ง
การปรากฏของผู้ช่วยเขียนโค้ด AI อาจเอียงเกล็ดกลับไปสู่แนวทางที่เรียบง่ายและเป็นแบบแผนมากขึ้นอย่าง Rails เนื่องจากเครื่องมือเหล่านี้ทำงานได้ดีกว่าด้วยรูปแบบที่มีการยอมรับอย่างดีและข้อมูลการฝึกอบรมที่กว้างขวาง อย่างไรก็ตาม การเลือกขั้นสุดท้ายมักจะขึ้นอยู่กับความเชี่ยวชาญของทีม ข้อกำหนดของโปรเจกต์ และข้อพิจารณาการบำรุงรักษาระยะยาว มากกว่าความเหนือกว่าทางเทคนิคแบบสัมบูรณ์
อ้างอิง: You're doing Rails wrong.