คุณกำลังใช้ Rails ผิดวิธี
(bananacurvingmachine.com)- ล้อเลียนสภาพแวดล้อมการพัฒนาเว็บสมัยใหม่ที่ซับซ้อนเกินจำเป็น ผ่านบทสนทนาของนักพัฒนาสองคนเกี่ยวกับ การผสาน Rails 8 กับ Vite
- คนหนึ่งเพิ่มเครื่องมือมากมายอย่าง Vite, React, Babel, Tailwind, Docker, Husky แล้วเรียกมันว่าเป็น สแตกแบบ “modern”
- ขณะที่อีกคนโชว์แอปที่ รันได้ทันทีด้วย Rails พื้นฐานล้วน ๆ โดยไม่ต้องตั้งค่าอะไรเลย ทำให้เห็นคุณค่าของความเรียบง่าย
- เสียดสีสภาพปัจจุบันที่พึ่งพา toolchain อันซับซ้อน พร้อมเน้นย้ำข้อความว่า ‘แค่ใช้ Rails ก็พอ’ และชวนให้ย้อนมอง คุณค่าของความเรียบง่าย
- ชี้ให้เห็นว่า ประสิทธิภาพการพัฒนา ความสม่ำเสมอ และความสนุกในการพัฒนา ซึ่งเป็นเป้าหมายดั้งเดิมของ Rails กำลังถูกลืมเลือน
> “Just F#$%^& use Rails”
คำแปลบทสนทนาต้นฉบับ
Kevin: เฮ้ เคยใช้ Vite สำหรับ Rails 8 ไหม? มันเร็วมากเลยนะ
John: เคยได้ยินอยู่ มันคือ build tool ใช่ไหม? ใน Rails มีอะไรแบบนั้นอยู่แล้วไม่ใช่เหรอ?
Kevin: มีสิ แต่ Vite มันทันสมัยกว่า หน่อยเดียวเอง แค่ติดตั้ง Node กับ npm แล้วตั้งค่าสคริปต์เพิ่มอีกนิด แต่คุ้มแน่นอน
John: เดี๋ยวนะ ตอนนี้ Rails ต้องใช้ Node แล้วเหรอ?
Kevin: ใช่ ถ้าจะใช้ React ก็ต้องมีสิ เดี๋ยวนี้ใคร ๆ ก็ใช้ React กัน
John: ใน Rails ไม่มีอะไรแบบนั้นอยู่แล้วเหรอ?
Kevin: เคยมีนะ แต่ตอนนี้ต้องใช้ Vite คู่กับ React Refresh แบบนี้คอมโพเนนต์จะรีเฟรชได้ทันที แล้วถ้าจะใช้ TypeScript ก็ต้องตั้งค่าส่วนนั้นเพิ่มด้วย
John: แค่ฟังก็ดูซับซ้อนแล้ว
Kevin: ไม่หรอก เรื่องเล็กน่า แค่ติดตั้ง Babel ตั้งค่า .babelrc เพิ่ม vite-plugin-ruby แล้วเรื่องสไตล์ก็ใช้ PostCSS
John: PostCSS เหรอ?
Kevin: ใช่ แล้วแน่นอนว่าต้องใช้ Tailwind ด้วย — พูดจริงนะ คงไม่อยากมานั่งเขียน CSS เองทีละบรรทัดหรอกใช่ไหม
John: ก็จริง
Kevin: จากนั้นก็จัดระเบียบโค้ดด้วย ESLint กับ Prettier แล้วใส่ hook ด้วย Husky ก่อน commit ก็สมบูรณ์แบบ
John: งั้นก็มี Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky แค่นั้นเองเหรอ?
Kevin: เกือบหมดแล้ว ถ้าจะทำ server-side rendering ด้วย ก็ต้องใช้ Next.js หรือ Remix
John: เดี๋ยวก่อน นี่เรายังคุยเรื่อง Rails กันอยู่ใช่ไหม?
Kevin: ใช่สิ เดี๋ยวนี้ hybrid stack กำลังมาแรงนี่! ถ้าอยากใช้คอมโพเนนต์แบบ reactive โดยไม่ต้องพึ่ง JS framework จะใช้ StimulusReflex หรือ Hotwire ก็ได้
John: StimulusReflex? ฟังเหมือนชื่อตัวละคร Marvel เลย
Kevin: ฮ่าๆ มีจริงนะ เอาไว้ทำอัปเดตแบบเรียลไทม์ แต่ต้องตั้งค่า ActionCable แล้วก็ต้องมี Redis ด้วย
John: Redis อีกเหรอ?
Kevin: ใช่ ต้องมีเลเยอร์ pub/sub ไง ไม่ต้องห่วง แค่เปิด Docker container เพิ่มอีกตัวก็พอ
John: ต้องใช้ Docker ด้วยเหรอ?
Kevin: แน่นอน ต้องใช้เพื่อแยก dependencies ถ้าอยากให้สภาพแวดล้อมทำซ้ำได้ครบก็ต้องมี Docker Compose, deploy ไป Fly.io แล้วก็รัน pipeline ด้วย GitHub Actions
John: ฟังดู...ซับซ้อนพอตัวเลยนะ
Kevin: ก็แค่การพัฒนาเว็บสมัยใหม่ไงเพื่อน เรียบง่ายจะตาย แล้วนายล่ะ ใช้อะไรอยู่?
John: ก็แค่ลองเล่นดูน่ะ
(John รันคำสั่งหนึ่งคำสั่ง แอปก็สตาร์ตขึ้นมาทันที ฟอร์มก็ทำงานได้ โหลดก็เร็ว และการนำทางก็เร็วราวสายฟ้า)
Kevin: ว้าว ดูซับซ้อนไม่น้อยเลยนะ ใช้สแตกอะไร?
John: แค่ Rails ล้วน ๆ
> Just F#$%^& use Rails.
3 ความคิดเห็น
ผมชอบทั้งสองเครื่องมือครับ ทั้งสองอย่างมีส่วนที่ระบบนิเวศและจุดประสงค์ทับซ้อนกันอยู่บ้าง แต่ไม่ใช่เครื่องมือแบบเดียวกันทั้งหมด จึงไม่ควรถูกประเมินโดยยึดระดับความยากเป็นเกณฑ์ หากเขียนด้วย vite ก็สามารถเขียนสคริปต์ได้อย่างกว้างขวางและละเอียดซับซ้อน ส่วน Stimulus หรือ Hotwire จะเหมาะกับการลดงานพัฒนาสคริปต์ให้เหลือน้อยที่สุดมากกว่า
ดูเหมือนว่าเนื้อหาส่วนใหญ่จะโฟกัสไปที่การพัฒนาฝั่งฟรอนต์เอนด์...
ความคิดเห็นจาก Hacker News
บทความนี้ถูกเขียนใหม่วนมาเรื่อย ๆ มากว่า 10 ปีแล้ว
สิ่งที่เรียกว่า “ความซับซ้อน” นั้น แท้จริงก็เป็นเพียงรายการของเครื่องมือที่ใช้แก้ปัญหาแต่ละแบบเท่านั้น
ตัวเครื่องมือเองไม่ใช่ปัญหา ความจริงคือการพัฒนาเว็บสมัยใหม่มีความซับซ้อนโดยเนื้อแท้อยู่แล้ว
เราเห็นความซับซ้อนที่ “ซ่อนอยู่” แบบเดียวกันได้ใน ASP.NET หรือเฟรมเวิร์กเดสก์ท็อป GUI เช่นกัน
ยกตัวอย่างเช่น ถ้าใช้ Rails เป็น API backend และให้ React ดูแลฝั่ง frontend ก็จะกลายเป็นสถาปัตยกรรมที่ต่างจาก Rails monolithic แบบดั้งเดิมโดยสิ้นเชิง
รายชื่อเครื่องมืออย่าง Vite, React, Prettier เป็นตัวเลือกที่มุ่งแก้ปัญหาคนละแบบกันโดยสิ้นเชิง (ถ้าอยากใช้ Rails เป็น frontend ก็ใช้ Rails ไปเลย ไม่ค่อยชอบรูปแบบกึ่งกลางเท่าไร)
ปัญหาที่แท้จริงคือวิธีการเรียนรู้
ทุกวันนี้นักพัฒนาจำนวนมากเรียนเฟรมเวิร์กก่อนจะเข้าใจพื้นฐานของเว็บเสียอีก (HTML, CSS, server-side logic, database)
เครื่องมือแต่ละตัวมีเหตุผลของมัน และทั้งหมดก็เป็นเครื่องมือที่จำเป็นต่อเว็บสมัยใหม่
การมองว่า “มันเยอะเกินไป” เป็นการมองความจริงของอุตสาหกรรมไม่ครบถ้วน
ความซับซ้อนไม่ใช่สิ่งที่เป็นแก่นแท้ของการพัฒนาเว็บ
ตรงกันข้าม ตอนนี้เรากลับทำอะไรได้มากขึ้นด้วยของที่น้อยลง
Hotwire ทำงานแทบจะเหมือน Rails แบบ vanilla และสามารถสร้างประสบการณ์สมัยใหม่ที่อัปเดตเนื้อหาแบบเรียลไทม์ผ่าน WebSocket ได้ด้วยโค้ดเพียงบรรทัดเดียว
วิธีทั่วไปในการส่ง JS ใน Rails ก็เรียบง่ายขึ้นมากด้วย import maps (ไม่ต้องมีขั้นตอน build แยก)
แม้แต่ Tailwind ก็เพิ่มเข้าไปได้ง่ายมาก
การ deploy เองก็ง่ายขึ้นมากด้วย kamal
ดังนั้นจึงไม่เห็นด้วยกับคำกล่าวที่ว่าความซับซ้อนเป็นสิ่งโดยเนื้อแท้ และ Hotwire ก็มีบทบาทในการลดความซับซ้อนด้วย
การเรียนรู้ควรไปในทิศทางของ “ทำให้ได้มากขึ้นด้วยของที่น้อยลง” ไม่ใช่ “เรียนให้มากขึ้นเรื่อย ๆ”
ความสามารถที่แท้จริงไม่ใช่การใช้ได้ 20 ภาษาและ 20 เซิร์ฟเวอร์ แต่คือการใช้ 4 อย่างแล้วให้ทีม 3 คนเอาชนะทีมพันคนได้
คนไม่ได้ต่อต้านการมีอยู่ของเครื่องมือหรอก แต่เหมือนจะรู้สึกต่อต้านบรรยากาศที่ทำเหมือนว่าทุกคนต้องใช้มันทั้งหมด
ทุก tutorial และชื่อวิดีโอ YouTube ชอบออกแนว “MONGOOSE stack ที่ต้องใช้!” จนมีมือใหม่จำนวนมากพยายามยัด redis เข้าไปในบล็อกทำขนมแบบฝืน ๆ
ทั้งที่จริงแล้ว เว็บไซต์ส่วนใหญ่ก็เพียงพอแล้วโดยไม่ต้องมี stack พิเศษอะไร
แต่เพราะไม่มีใครโฆษณาแนวทางนั้น นักพัฒนารุ่นจูเนียร์จำนวนมากจึงไม่รู้ข้อเท็จจริงนี้
เห็นด้วยว่าควรให้ความสำคัญกับการเรียนพื้นฐานก่อน แต่การส่งสารแบบนั้นท่ามกลางบริษัทต่าง ๆ ที่พยายามโปรโมตบริการสารพัดก็ไม่ใช่เรื่องง่าย
ผมยังถือว่าเป็นมือใหม่กับ Rails พอสมควร แต่มีประสบการณ์กับภาษาอื่นมาราว 10 ปี
ถ้าจำเป็น การเพิ่มเครื่องมือก็นับว่าโอเค (จะจำเป็นจริงไหมเป็นอีกเรื่อง)
แต่ Rails เดิมทีก็เป็นเฟรมเวิร์กอเนกประสงค์ขนาดใหญ่ที่มีครบตั้งแต่ ORM, console ไปจนถึงการ generate scaffolding code
ถ้ายังต้องใช้เครื่องมือเพิ่มอีก แบบนี้ไม่ควรกลับมาทบทวน Rails เองหรือ?
บางทีอะไรที่ modular กว่านี้อาจจะเหมาะกว่า
คำว่า “vanilla Rails” ดูเป็นสัญญาณเตือนสำหรับผม ไม่เข้าใจว่าจะเรียกเฟรมเวิร์กใหญ่ขนาดนั้นว่า vanilla ได้อย่างไร
ใจความของบทความนี้คือ คนจำนวนมากไม่ได้ถามตัวเองตั้งแต่แรกว่าจำเป็นต้องมี “modern web application” จริงหรือไม่ และไม่รู้ด้วยซ้ำว่าแค่ vanilla Rails ก็เพียงพอแล้ว
ขาดความพยายามที่จะทำความเข้าใจตัวเลือกพื้นฐานที่ Rails มีให้ด้วยตัวเอง
การพูดถึง “ความซับซ้อนของการพัฒนาเว็บสมัยใหม่” เป็นเพียงการบรรยายสภาพปัญหา ไม่ใช่ข้อกำหนดที่หลีกเลี่ยงไม่ได้
ถ้าคุณกำลังดึง npm package มาหลายพันตัวทั้งที่เว็บไซต์มีแค่ฐานข้อมูลกับ SQL query ไม่กี่ตัว ก็แปลว่ากำลังทำอะไรผิดแล้ว
ผมเขียนโค้ด Rails มาตั้งแต่ปี 2007
stack มันซับซ้อนขึ้นก็มีเหตุผลของมัน และแทบไม่มีทีมไหนที่ทำ “ถูกต้อง” ตามเกณฑ์ในบทความจริง ๆ
ปัญหาของเฟรมเวิร์กแบบ Omakase (แนวที่กำหนดทุกอย่างมาให้เป็นส่วนใหญ่เหมือน Rails) คือไม่ใช่แค่ต้องยอมรับตัวเลือกตั้งต้น แต่ต้องยอมรับตัวเลือกในอนาคตต่อไปเรื่อย ๆ และพาทั้งทีมไปกับมันด้วย
Rails ทรงพลังมาก แต่แม้แต่ผู้ดูแลเองก็ไม่ได้มองอนาคตได้สมบูรณ์แบบ
เพราะแบบนี้แทบไม่มีแอปไหนที่กลับไปเป็น vanilla Rails ในตอนนี้
เมื่อก่อนการ deploy Rails ก่อนยุค Docker นั้นยุ่งยากมาก ต้องใช้ระบบ deploy อย่าง Capistrano แทนที่จะ rsync หรือส่ง tarball เฉย ๆ
Docker หรือ k8s ก็สะดวกดี แต่ถ้าเทียบกับสมัยก่อนก็ไม่ได้แย่กว่าอะไรนัก
ถ้าจำการ deploy Rails ยุคก่อน Docker ว่าเป็นแค่ “rsync แล้วแตก tarball” นั่นคือ setup ที่เละเทะมาก
การ deploy ด้วย Capistrano แบบ “สมัยก่อน” ดีกว่ามาก
อยากให้ช่วยอธิบายเพิ่มว่าปัญหาของ “การ push ไปหลาย instance ด้วย rsync หรือ tarball” คืออะไรโดยเฉพาะ
ฟังดูแล้วก็ไม่ได้ร้ายแรงขนาดนั้นนะ
เพราะงั้นผมถึงผูกพันกับ Sinatra มาตลอด
น่าเสียดายที่ utility แบบ out-of-the-box ที่ Rails มีให้ ยังไม่มีอะไรในโลก JS มาแทนที่ได้จริง
นักพัฒนา JS ส่วนใหญ่ไม่ค่อยรู้จุดนี้
แต่ JS ก็เป็น ecosystem ที่ชอบสร้างล้อขึ้นมาใหม่อยู่เสมอ
ข้อดีใหญ่ของ JS คือทุกคนมีโอกาสสร้างแพลตฟอร์มใหม่ได้
ต่อให้เอาหลายแพลตฟอร์ม JS มาผสมกันพร้อม ๆ กัน มันก็มักจะยังพอทำงานร่วมกันได้ ซึ่งทั้งขยายต่อได้ แฮ็กต่อได้ และยัง build ทุกอย่างแบบ local ถาวรเพื่อสร้างเว็บไซต์แบบ fix ไว้เลยก็ได้
แต่เสรีภาพแบบนี้ก็ต้องมีความยับยั้งชั่งใจ
หน้าที่ของทีมคือการหยุดเพื่อนร่วมงานที่อยากลากเฟรมเวิร์กใหม่เข้ามาได้ทุกเมื่อ
Ember.js คือเฟรมเวิร์กแบบ all-in-one (“batteries included”) ที่สร้างโดยคนดังฝั่ง Rails
แต่ก็มีเหตุผลบางอย่างว่าทำไมมันถึงไม่ประสบความสำเร็จเท่าเฟรมเวิร์กอื่น
ใน ecosystem ของ JS ก็มี backend framework แบบรวมทุกอย่างมาให้เหมือนกัน เช่น AdonisJS
เพียงแต่ ecosystem ของ NodeJS เริ่มต้นจาก microframework เพื่อเป็นแรงต้านต่อเฟรมเวิร์กแบบตายตัวอย่าง Rails หรือ Django
แนวคิดของ Express เองก็ประมาณว่า “ทำให้เร็ว ทำแบบหยาบ ๆ แล้วใช้ไป”
ใน JS ก็มี full-stack framework หลายตัวที่คล้าย Rails
มีเฟรมเวิร์กชื่อ Sails ด้วย
JS แก้ปัญหาคนละแบบกับที่ Rails แก้อยู่ ดังนั้นหน้าตาของเฟรมเวิร์กจึงย่อมต่างกัน
Rails มี utility เยอะจริง แต่ในระยะยาว การต้องอัปเดต codebase เป็นระยะและต้องตามเทรนด์ของ Rails อยู่ตลอดก็อาจทำให้เหนื่อยได้
ตอนนี้ Stimulus กับ Hotwire ได้กลายเป็น “rails way” ไปแล้ว
ต่อให้อ่านเอกสารตั้งใจแค่ไหนก็ยังสับสนมากอยู่ดี
รู้สึกเหมือนต้องคอยสร้าง JS component ขึ้นมาใหม่ซ้ำ ๆ ด้วยมือตลอด
ในความเห็นผม ชุดผสม Rails 8 + Inertia.js + React กลับช่วยลดการ “ประดิษฐ์ล้อใหม่” ได้มากกว่า โดยเฉพาะถ้าใช้คอมโพเนนต์ของ shadcn
เห็นด้วยกับจุดนี้มาก
พวกเราก็เปลี่ยน frontend จาก Hotwire ไปเป็น Inertia เหมือนกัน แล้วมันต่างกันราวฟ้ากับเหวจริง ๆ
ถ้าไม่ใช่โปรเจ็กต์เล็ก ๆ ที่ทำคนเดียว 100% Hotwire จะกลายเป็นกองความยุ่งเหยิงที่ทั้งทีมแตะต้องไม่ได้อย่างรวดเร็ว
ผมกลับชอบ Stimulus มากจนย้ายจาก Rails ไปใช้ในแอป Phoenix ทันที
แต่ผมคิดว่าปัญหาคือความเข้าใจผิดเกี่ยวกับเครื่องมือนี้
Stimulus ไม่ใช่ตัวแทนของ React
ถ้าคุณคุ้นกับแอป JS ระดับหลายหมื่นบรรทัด React อาจเหมาะกว่า
แต่ถ้าอยากแต่ง UX ด้วย JS แค่ไม่กี่สิบบรรทัดในแอปที่ server-side เป็นตัวหลัก Stimulus นี่แหละเหมาะมาก
ใน Phoenix มันเป็นโซลูชันมินิมอลที่สอดแทรกอยู่พอดีระหว่าง HTML แบบ static กับ LiveViews แบบ dynamic
ไม่เคยมีใครบอกให้ใช้ Stimulus สร้าง SPA อยู่แล้ว และถ้าทำแบบนั้นก็น่าจะเจอสถานการณ์ลำบากแน่นอน
Stimulus มันเล็กมาก เป็นระบบ event ที่มี HTML hook และเข้ากับ request lifecycle ของ Rails ได้ดี
อยากรู้เหมือนกันว่ามีใครเคยใช้ Stimulus สร้างอะไรที่ซับซ้อนมาก ๆ สำเร็จไหม
จากที่ผมรู้สึก มันยากเกินไปถ้าจะทำอะไรไปไกลถึงขนาดนั้น
ผมก็เรียกตัวเองว่าเป็นแฟนบอย Rails ได้เหมือนกัน แต่ก็เสียดายกับสถานะปัจจุบันของ Stimulus และ Hotwire
แนวคิดยอดเยี่ยม และตัว implementation เองก็คงดีด้วยซ้ำ
แต่เอกสารมันขาดแคลนจนน่าตกใจ ทำให้เริ่มต้นก็ไม่กล้าแล้ว และในแต่ละโปรเจ็กต์ก็ไม่มีข้อมูลมากพอจะตอบได้ว่า “ถ้าเริ่มด้วยสิ่งนี้ วันหน้าจะติดทางตันไหม”
ผมเคยใช้ Stimulus กับ Symfony สำหรับ interaction เล็ก ๆ และรู้สึกว่ามันโอเคมาก เพราะ API เล็กและออกแบบมาดี
ยังไม่เคยใช้ Turbo/Hotwire แบบเต็มชุด และสำหรับหน้าที่ซับซ้อนหรือมี state มาก ผมมักใช้ Vue
ยังไงตอนนี้โปรเจ็กต์ greenfield (โปรเจ็กต์ที่สร้างใหม่ตั้งแต่ต้น) ก็แทบจะหายไปหมดแล้ว
นอกจากฝั่งผู้ก่อตั้งแล้ว greenfield เองก็หาได้ยาก และถ้าจะขายอะไร สุดท้าย 99% ก็ไปจบที่ Shopify wrapper หรือของทำนองนั้น
แม้แต่ในบริษัทใหญ่ โปรเจ็กต์ greenfield ก็ถูกผูกไว้กับข้อพิจารณาต่าง ๆ และเฟรมเวิร์กภายในบริษัท จนแทบไม่มีใครเริ่มจาก
rails newจริง ๆการถกเถียงแบบนี้เลยแทบไม่มีความหมาย และข้อถกเถียงกับบทความแนวนี้ก็วนซ้ำมา 10 ปี 15–20 ปีแล้ว จนน่าเบื่อและน่าหน่าย
แทนที่จะมีบทความใหม่ ๆ อยากเห็นคนสร้างของใหม่จริง ๆ มากกว่า
เห็นด้วยสุด ๆ
ผมทำงานกับ Ruby/Rails มา 10 ปี และแม้แต่ codebase ที่ “ใหม่ที่สุด” ก็ยังมีอายุมากกว่า 5 ปีแล้ว
พูดตามตรง ผมเคยทำแอป Rails greenfield ใหม่อยู่บ้าง แต่นั่นก็เป็นแค่ API-only microservice เลยไม่ต้องมี frontend
ในบริษัทขนาดใหญ่ โซลูชัน frontend ของ Rails ถูกมองข้ามไปเลย
หา engineer ที่ใช้ Hotwire ได้ยาก แต่หา React หรือ Vue developer ได้เท่าไรก็ได้
FE stack ของ Rails ก็เปลี่ยนบ่อยจนตามไม่ทันด้วย (ยังจำยุค CoffeeScript ได้) แถมแทบไม่มีเอกสารดี ๆ และในโลกจริงก็ไม่มีอิทธิพลเท่าไร
เพราะงั้นการถกเถียงแบบนี้จึงห่างไกลจากสภาพจริงมาก
ผมไม่เห็นด้วยกับคำกล่าวที่ว่า “โปรเจ็กต์ greenfield ไม่เหลือแล้วนอกจากฝั่งผู้ก่อตั้ง”
ถ้ายกตัวอย่างแต่ monolith เก่าในองค์กรใหญ่หรือ Fortune 500 นั่นคือคนส่วนน้อยมากที่เบี่ยงจากค่าเฉลี่ยของทั้งวงการ
ตรงกันข้าม ผมกลับคิดว่าความตั้งใจในการทำให้
rails newมี default ที่ sane และพร้อมใช้งานทันทีนั้นน่าทึ่งมากแนวทางนี้ช่วยเติมช่องว่างระหว่าง Hello World กับเอกสาร API ที่เรียบง่ายเกินไปได้ดี
ถึงจะไม่ใช้ Rails ก็ตาม แต่ส่วนนี้ก็น่าเอาอย่าง
มันน่ารักดี แต่ก็ไม่ได้พูดถึงความจริงที่ว่าเมื่อแอป Rails เติบโตขึ้น คุณต้องย้ายผ่าน bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling และอื่น ๆ ไปเรื่อย ๆ
ตั้งแต่ autoloader ไป zeitwerk, จาก Turbo ไป Hotwire ฯลฯ ในความเป็นจริงมีส่วนที่เปลี่ยนไปแบบนี้เยอะมาก
แค่ดูโฆษณาในจดหมายข่าว Rails ก็ยังเห็นบ่อย ๆ ว่า “ผู้เชี่ยวชาญช่วยอัปเกรดแอป Rails ของคุณ”
ดีใจที่มีคนพูดถึงจุดนี้
การพูดว่า “ใช้ vanilla Rails ก็พอ” นั้นง่าย แต่ตลอด 5 ปีที่ผ่านมา วิธีจัดการ JS ของ Rails เปลี่ยนไปคนละเรื่องแทบทุกเวอร์ชัน
ยังมี gem อีกมากที่พึ่งพา sprockets อยู่ ดังนั้นต่อให้ทำตามวิถี Rails ก็หนีไม่พ้นก้อน JS ซับซ้อนอยู่ดี
ตอนนี้มันสับสนจริง ๆ บางทีวันหนึ่งอาจดีขึ้น แต่ Rails ก็มีส่วนรับผิดชอบชัดเจน
อย่าลืม CoffeeScript ด้วย
จนไม่นานมานี้บริษัทที่ผมทำงานอยู่ก็ยังเลื่อนการพอร์ต CoffeeScript ออกไปเรื่อย ๆ และโค้ดใหม่ก็เขียนด้วย Vue
จากประสบการณ์ตรง ผมได้เรียนรู้ว่าถ้าไม่ใช่โปรเจ็กต์ที่มีนักพัฒนามากกว่า 30 คนจากหลายสายความเชี่ยวชาญมาร่วมงานพร้อมกัน ก็ไม่จำเป็นต้องรับความซับซ้อนจากการแยก frontend/backend เข้ามา
ตอนเป็นฟรีแลนซ์ผมเองก็เคยออกแบบเกินเหตุให้ทีมแค่ 1–2 คนเหมือนกัน แต่สุดท้ายทุกวันนี้ผมใช้แค่ Django กับ Tailwind นิดหน่อย
ปีนี้ผมรับสมัคร Django developer แล้วพบว่าแทบทุกคนสร้าง API backend บาง ๆ ด้วย Django และทำ frontend ก้อนใหญ่ด้วย React (บางคนถึงขั้นยัด business logic ไปไว้ฝั่ง frontend ด้วย)
พอถามเหตุผล ส่วนใหญ่ก็อธิบายไม่ได้
สุดท้ายเลยเหลือแค่ผู้สมัครไม่กี่คนที่ใช้ server-side rendering ล้วน
ถ้าจำเป็นต้องมี frontend ที่ interactive มากจริง ๆ คุณก็อาจต้องคิดต่อว่าจะทำยังไง
ผมก็เห็นด้วย
ในอุตสาหกรรมส่วนใหญ่ ลูกค้าไม่ได้สนใจนักหรอกว่าต้องการความสามารถในการขยายระบบระดับสุดโต่งกับ microservices หรือว่าแค่ monolith กับ PostgreSQL ก็พอแล้ว
ดูเหมือนหลายคนจะตั้งระบบโดยมีเป้าหมายคือการขยายไม่สิ้นสุด และคอยไล่ตามแต่เทคโนโลยีใหม่ล่าสุด
ทั้งที่จริง Rails มีประโยชน์มากแม้ใช้การออกแบบเรียบง่าย และบ่อยครั้งคนก็ทำเกินความจำเป็นเพราะรู้สึกว่าแบบเรียบง่ายมัน “น่าเบื่อ” หรือ “ไม่สนุก”
แต่ Rails เป็นเฟรมเวิร์กแบบ batteries included จริง ๆ และถ้าหยุด overengineering มันก็ทำงานได้ดีเฉย ๆ
แต่หลังจากนั้น โปรเจ็กต์ SaaS/CRUD ใหม่ที่ทำ ผมใช้ Rails อย่างเดียว
ถึงจุดหนึ่งแล้ว productivity กลายเป็นคุณค่าที่สำคัญที่สุดจริง ๆ
ตอนนี้มันแค่ซับซ้อนขึ้น แต่แนวคิดพวกนี้ไม่ใช่เรื่องใหม่เลย
ตอนเรียน Django เมื่อ 15 ปีก่อน แค่ tutorial ก็ยังบังคับให้ติดตั้ง Vagrant, VirtualBox, Chef เวอร์ชันเฉพาะ จนแทบเป็นบ้า
ตอนนี้ผมก็ยังชอบและยังใช้ Django อยู่ แต่ไม่สนใจเครื่องมือพวกนั้นแล้ว
แม้แต่ Django Rest Framework เองก็ดูเหมือนจะเป็นตัวที่ทำให้เสียสมาธิมากกว่า
“ความล้าจาก tooling ฝั่งเว็บ” เป็นเรื่องจริงมาก
มันก็จริงมาตั้งแต่ 10 ปีก่อนแล้ว และความสับสนแบบนี้มักเป็นผลจากการที่นักพัฒนานำรสนิยมแบบงานอดิเรกเข้ามาใช้ในงานอาชีพ
เพิ่มเติมอีกนิดคือ ไม่ใช่แค่ฝั่ง frontend เท่านั้น ฝั่ง DevOps ก็คล้ายกัน
ผลก็คือ ถ้าจะสมัครงานในสายที่เกี่ยวข้อง ต้องรู้เครื่องมือทุกตัว แถมยังต้องมีประสบการณ์ 10 ปี รู้ backend หลายแบบ SQL และ Docker ครบหมดด้วย
ถ้าทำเป็นอาชีพจริง ๆ ก็ตั้งค่าแค่ครั้งเดียวแล้วจบ แต่ถ้าเป็นโปรเจ็กต์ครั้งเดียวหรือเว็บไม่ใช่งานหลัก ก็ย่อมเหนื่อยจริง
อย่างไรก็ตาม มันก็หลีกเลี่ยงได้แบบนี้
ผมเคยทำเว็บไซต์ด้วยเฟรมเวิร์ก Fresh(https://fresh.deno.dev/) และแค่นี้ก็พอแล้ว
โดยทั่วไปมันเรียบง่ายกว่า Node/Webpack มาก และยังใช้ Typescript กับ TSX ได้ด้วย
ถ้าทำงานกันหลายคนอาจจะเพิ่ม ESLint เข้าไป แต่ถึงไม่มีก็เริ่มต้นได้ง่ายมากอยู่ดี