Bạn đang dùng Rails không đúng cách

• Qua cuộc đối thoại giữa hai lập trình viên xoay quanh tích hợp Rails 8 và Vite, bài viết châm biếm môi trường phát triển web hiện đại đã trở nên phức tạp một cách không cần thiết
• Một người liên tục thêm vào hàng loạt công cụ như Vite, React, Babel, Tailwind, Docker, Husky và gọi đó là stack “hiện đại”
• Ngược lại, người kia cho thấy một ứng dụng chạy ngay lập tức chỉ với Rails thuần, không cần cấu hình, qua đó làm nổi bật giá trị của sự đơn giản
• Bài viết mỉa mai thực trạng phụ thuộc vào chuỗi công cụ phức tạp, đồng thời nhấn mạnh thông điệp ‘cứ dùng Rails đi’ và gợi nhắc về đức tính của sự đơn giản
• Chỉ ra rằng năng suất, tính nhất quán và niềm vui khi phát triển — những mục tiêu vốn có của Rails — đang dần bị lãng quên

“Just F#$%^& use Rails”

---

Bản dịch cuộc đối thoại gốc

Kevin: Này, cậu thử Vite cho Rails 8 chưa? Nhanh kinh khủng.

John: Tớ có nghe qua. Nó là build tool đúng không? Chẳng phải Rails đã có thứ như vậy rồi à?

Kevin: Có chứ. Nhưng Vite hiện đại hơn một chút. Chỉ cần cài Node với npm rồi cấu hình vài script là xong, nhưng rất đáng.

John: Khoan đã, giờ Rails cần cả Node à?

Kevin: Ừ, nếu muốn dùng React thì thế. Giờ ai cũng dùng React mà.

John: Chẳng phải Rails từng có thứ đó sao?

Kevin: Có, nhưng giờ phải dùng Vite cùng với React Refresh. Như vậy component sẽ được làm mới ngay lập tức. Nếu muốn dùng TypeScript thì cũng phải cấu hình thêm phần đó.

John: Nghe thôi đã thấy phức tạp rồi.

Kevin: Không đâu, có gì ghê gớm đâu. Cài Babel, cấu hình .babelrc, thêm vite-plugin-ruby, còn style thì dùng PostCSS là được.

John: PostCSS à?

Kevin: Ừ. Và tất nhiên phải dùng Tailwind nữa — chứ cậu đâu muốn tự tay viết CSS từng chút một, đúng không.

John: Tất nhiên rồi.

Kevin: Sau đó thì dọn code bằng ESLint và Prettier, rồi gắn hook bằng Husky trước khi commit là hoàn hảo.

John: Vậy là Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky. Hết chưa?

Kevin: Gần hết rồi. Nếu còn muốn server-side rendering thì phải dùng Next.js hoặc Remix nữa.

John: Khoan, mình vẫn đang nói về Rails đấy chứ?

Kevin: Đúng mà. Giờ stack lai đang là xu hướng! Nếu muốn dùng component có tính phản hồi mà không cần framework JS thì StimulusReflex hay Hotwire cũng ổn.

John: StimulusReflex à? Nghe như tên nhân vật Marvel ấy.

Kevin: Ha ha, là đồ thật đấy. Dùng cho cập nhật thời gian thực. Nhưng phải cấu hình ActionCable, và còn cần Redis nữa.

John: Redis nữa à?

Kevin: Ừ, vì cần một lớp pub/sub. Đừng lo, chỉ cần chạy thêm một container Docker nữa thôi.

John: Cả Docker cũng phải dùng à?

Kevin: Tất nhiên. Muốn cô lập dependency thì đó là bắt buộc. Muốn tái tạo môi trường đầy đủ thì còn phải có Docker Compose, triển khai lên Fly.io, và chạy pipeline bằng GitHub Actions nữa.

John: Nghe... khá phức tạp đấy.

Kevin: Chỉ là phát triển web hiện đại thôi mà, bạn hiền. Đơn giản lắm. Còn cậu đang làm gì?

John: Tớ chỉ đang nghịch chút thôi.

(John chạy một lệnh duy nhất. Ứng dụng khởi động ngay lập tức. Form hoạt động, tốc độ tải nhanh, điều hướng cũng nhanh như chớp.)

Kevin: Ồ, trông có vẻ khá phức tạp đấy. Cậu dùng stack gì?

John: Chỉ Rails thuần thôi.

Just F#$%^& use Rails.

[labeldock]

Tôi là một công cụ mà ai cũng yêu thích. Hai công cụ này có phần giao nhau về hệ sinh thái và mục đích sử dụng, chứ không phải là những công cụ hoàn toàn giống nhau, nên không nên đánh giá chúng dựa trên độ khó. Nếu viết bằng vite thì có thể xây dựng script rất rộng và tinh vi. Còn Stimulus hay Hotwire phù hợp hơn với việc giảm thiểu tối đa phát triển script.

[roxie]

Có vẻ như phần lớn nội dung đang tập trung vào phát triển frontend...

[GN⁺]

Ý kiến Hacker News

• Bài này đã được viết lại suốt hơn 10 năm rồi
  Cái gọi là “độ phức tạp” thực ra chỉ là danh sách các công cụ, mỗi công cụ giải quyết một vấn đề cụ thể
  Vấn đề không nằm ở bản thân công cụ, mà thực tế là phát triển web hiện đại vốn có độ phức tạp nội tại
  Có thể thấy kiểu độ phức tạp “ẩn” tương tự trong ASP.NET hay các framework GUI desktop
  Ví dụ, nếu dùng Rails làm API backend và để React phụ trách frontend thì đó đã là một kiến trúc hoàn toàn khác với Rails monolith truyền thống
  Danh sách công cụ như Vite, React, Prettier là các lựa chọn nhắm tới những vấn đề hoàn toàn khác nhau (nếu muốn dùng Rails cho frontend thì cứ dùng Rails, tôi không thích lắm các kiểu nửa vời)
  Vấn đề thật sự là cách học
  Dạo này nhiều lập trình viên học framework trước cả khi nắm được nền tảng của web như HTML, CSS, logic phía server, cơ sở dữ liệu
  Mỗi công cụ đều tồn tại vì một lý do riêng, và đều là công cụ cần thiết cho web hiện đại
  Nhìn mọi thứ theo kiểu “nhiều quá” là chưa phản ánh đúng thực tế của ngành

  • Độ phức tạp không phải là thứ vốn có của phát triển web
    Ngược lại, bây giờ ta có thể làm được nhiều hơn với ít thứ hơn
    Hotwire hoạt động gần như Rails thuần, và có thể dựng trải nghiệm hiện đại với nội dung cập nhật thời gian thực qua WebSocket chỉ bằng một dòng
    Cách phổ biến để triển khai JS trong Rails cũng đã rất đơn giản nhờ import maps (không cần bước build riêng)
    Tailwind cũng có thể thêm vào rất dễ
    Ngay cả việc deploy cũng dễ hơn nhiều với kamal
    Vì vậy tôi không đồng ý rằng sự phức tạp là bản chất, và Hotwire chính là thứ giúp giảm độ phức tạp
    Việc học nên hướng tới “làm được nhiều hơn với ít thứ hơn”, chứ không phải “học thêm thật nhiều”
    Kỹ năng thật sự là dùng 4 thứ với đội 3 người mà vượt qua 1.000 người, chứ không phải biết dùng 20 ngôn ngữ hay server

  • Có vẻ mọi người không phản đối sự tồn tại của công cụ, mà phản cảm với bầu không khí kiểu ai cũng buộc phải dùng tất cả những thứ đó
    Mọi tutorial, tiêu đề video YouTube đều kiểu “stack MONGOOSE bắt buộc phải dùng!”, nên mới có nhiều người mới cố nhét redis vào cả blog về làm bánh
    Thực ra phần lớn website không cần stack đặc biệt gì vẫn đủ dùng
    Nhưng chẳng ai quảng bá điều đó, nên rất nhiều junior developer ngoài đời không hề biết chuyện này
    Tôi đồng ý rằng nên ưu tiên học kỹ thuật nền tảng, nhưng rất khó truyền tải thông điệp đó trong lúc các công ty liên tục quảng bá đủ loại dịch vụ

  • Tôi khá là người mới với Rails, nhưng có khoảng 10 năm kinh nghiệm với ngôn ngữ khác
    Nếu cần thì thêm công cụ cũng không sao (có thật sự cần hay không thì chưa bàn)
    Nhưng Rails vốn là một framework khổng lồ kiểu vạn năng, từ ORM đến console, đến cả sinh mã scaffolding đều có sẵn
    Nếu vẫn cần thêm công cụ, chẳng phải nên xem lại chính Rails sao?
    Có khi dùng thứ modular hơn lại tốt hơn
    Cụm “Rails thuần” nghe giống dấu hiệu cảnh báo. Tôi không hiểu sao một framework to như vậy lại có thể gọi là thuần được

  • Ý chính của bài này là nhiều người không tự hỏi ngay từ đầu liệu mình có thật sự cần một “ứng dụng web hiện đại” hay không, và cũng không biết rằng chỉ Rails thuần thôi đã đủ
    Họ thiếu nỗ lực tự tìm hiểu các lựa chọn mặc định của Rails thuần

  • Việc nhắc đến “độ phức tạp của phát triển web hiện đại” chỉ là mô tả một tình trạng vấn đề, chứ không phải điều kiện bắt buộc
    Nếu một site chỉ có cơ sở dữ liệu và vài câu SQL mà lại kéo vào hàng nghìn gói npm thì rõ ràng là đang làm sai gì đó

• Tôi đã viết code Rails từ năm 2007
  Có lý do khiến stack trở nên phức tạp hơn, và thực tế gần như không có đội nào làm “đúng cách” theo tiêu chuẩn của bài viết
  Vấn đề của các framework kiểu omakase (như Rails, nơi phần lớn thứ đã được quyết định sẵn) là không chỉ lựa chọn ban đầu, mà cả những lựa chọn về sau cũng phải đi theo, và phải kéo cả đội đi cùng
  Rails rất mạnh, nhưng ngay cả người bảo trì cũng không thể nhìn thấu tương lai hoàn hảo
  Vì vậy giờ gần như không còn ứng dụng nào quay về Rails thuần
  Hồi trước, trước thời Docker, deploy Rails thật sự rất phiền. Thay vì rsync hay tarball thì cần những hệ thống deploy như Capistrano.
  Docker hay k8s cũng tiện, nhưng so với ngày xưa thì không hẳn tệ hơn

  • Nếu bạn nhớ việc deploy Rails thời pre-Docker là “rsync rồi giải nén tarball”, thì đó là một thiết lập thật sự tệ hại
    Deploy bằng Capistrano “ngày xưa” còn tốt hơn nhiều

  • Tôi muốn nghe giải thích cụ thể hơn về việc “đẩy bằng rsync hay tarball lên nhiều instance” thì có vấn đề gì
    Nghe qua thì cũng không thấy nghiêm trọng đến vậy

  • Vì thế nên tôi luôn có thiện cảm với Sinatra

• Đáng tiếc là các tiện ích có sẵn out-of-the-box mà Rails cung cấp thì thế giới JS đến giờ vẫn chưa thay thế được
  Phần lớn lập trình viên JS không hiểu rõ điểm này
  Nhưng JS vốn luôn là một hệ sinh thái thích phát minh lại bánh xe

  • Điểm mạnh lớn của JS là ai cũng có cơ hội tạo ra nền tảng mới
    Kể cả khi kết hợp nhiều nền tảng JS với nhau thì đa phần vẫn chạy được, rất mở rộng được, rất dễ hack, và cũng có thể build toàn bộ cục bộ một cách lâu dài để tạo ra site tĩnh cố định
    Nhưng tự do như vậy cũng cần sự tiết chế
    Việc ngăn đồng nghiệp lúc nào cũng muốn đưa thêm framework mới vào cuối cùng là trách nhiệm của cả đội

  • Ember.js là framework all-in-one (“kèm pin sẵn”) do những tên tuổi lớn trong cộng đồng Rails tạo ra
    Nhưng có lý do vì sao nó không thành công như các framework khác

  • Trong hệ sinh thái JS cũng có các framework backend “bao gồm mọi thứ” như AdonisJS
    Chỉ là hệ sinh thái NodeJS ban đầu xuất phát từ microframework như một phản ứng ngược với kiểu framework khuôn mẫu như Rails hay Django
    Ngay cả khái niệm của Express cũng là làm “nhanh và đại khái” để dùng

  • JS cũng có nhiều framework full-stack tương tự Rails
    Cũng có framework tên là Sails
    JS đang giải quyết những vấn đề khác với những gì Rails giải quyết, nên hình thái framework tất yếu cũng khác

  • Rails có nhiều tiện ích thật, nhưng về lâu dài thì việc phải định kỳ cập nhật codebase và liên tục chạy theo xu hướng của Rails cũng có thể rất mệt

• Stimulus và Hotwire giờ đã thành “rails way” rồi
  Đọc tài liệu rất chăm mà vẫn thấy quá khó hiểu
  Cứ có cảm giác mình đang tự lặp đi lặp lại việc viết lại các JS component bằng tay
  Theo tôi, tổ hợp Rails 8 + Inertia.js + React lại giúp bớt “phát minh lại bánh xe” hơn. Đặc biệt là khi dùng component shadcn

  • Tôi đồng ý điểm này
    Bên tôi cũng đã thay frontend Hotwire bằng Inertia, và khác biệt đúng là một trời một vực
    Trừ khi đúng nghĩa 100% là dự án nhỏ do một người tự làm, còn không Hotwire rất nhanh biến thành mớ hỗn độn mà cả team không ai dám đụng vào

  • Cá nhân tôi lại thích Stimulus đến mức mang nó sang dùng ngay trong ứng dụng Phoenix thay vì Rails
    Nhưng tôi nghĩ vấn đề là mọi người hiểu sai công cụ này
    Stimulus không phải là lựa chọn thay thế cho React
    Nếu bạn quen với ứng dụng JS hàng chục nghìn dòng thì React có thể phù hợp
    Nhưng nếu ứng dụng do server-side làm chủ và bạn chỉ muốn mài giũa UX bằng vài chục dòng JS thì Stimulus là quá hợp
    Trong Phoenix, nó là giải pháp tối giản chen vừa khít vào khoảng giữa HTML tĩnh và LiveView động
    Chẳng ai bảo dùng Stimulus để làm SPA cả, và nếu làm vậy thì chắc chắn sẽ rất vất vả

  • Stimulus thực sự rất nhỏ gọn, là một hệ thống sự kiện có HTML hook nên rất hợp với vòng đời request của Rails
    Tôi tò mò không biết có ai từng xây được thứ gì thật sự phức tạp bằng Stimulus một cách thành công chưa
    Cảm giác của tôi là làm đến mức đó sẽ rất khó

  • Tôi cũng có thể coi là fanboy Rails, nhưng vẫn thấy tiếc cho tình hình hiện tại của Stimulus và Hotwire
    Ý tưởng thì rất tuyệt, triển khai có khi cũng tốt thật
    Nhưng tài liệu quá thiếu đến mức kinh khủng, ngay từ đầu đã ngại bắt tay vào, và mỗi dự án đều thiếu thông tin để trả lời câu hỏi kiểu “nếu bắt đầu bằng cái này thì sau này có bị đâm vào ngõ cụt không?”

  • Tôi đã dùng Stimulus với Symfony cho các tương tác nhỏ, và thấy đây là một API nhỏ gọn, thiết kế khá tốt
    Tôi chưa dùng trọn bộ Turbo/Hotwire, còn với các trang phức tạp hoặc cần nhiều state thì tôi thường dùng Vue

• Dù sao thì giờ các dự án greenfield gần như đã biến mất rồi
  Ngoài các founder ra thì greenfield vốn đã hiếm, và nếu bán thứ gì đó thì gần như 99% sẽ xử lý bằng kiểu Shopify wrapper hay thứ tương tự
  Ngay cả ở các công ty lớn, greenfield cũng bị trói bởi đủ loại cân nhắc và framework nội bộ, nên không có chuyện bắt đầu từ rails new
  Những tranh luận kiểu này chẳng có nhiều ý nghĩa, và những cuộc cãi vã, bài viết tương tự đã lặp đi lặp lại suốt 10 năm, thậm chí 15–20 năm, đến mức mệt mỏi và nhàm chán
  Thay vì bài viết mới, tôi muốn thấy người ta thực sự làm ra thứ gì mới hơn

  • Hoàn toàn đồng ý
    Tôi làm với Ruby/Rails suốt 10 năm, và ngay cả codebase “mới” nhất cũng đều đã hơn 5 năm tuổi
    Thành thật mà nói tôi cũng từng làm app Rails greenfield mới, nhưng đó là microservice chỉ dành cho API nên không cần frontend
    Ở các công ty có quy mô, giải pháp frontend của Rails gần như bị phớt lờ
    Có thể không tuyển được kỹ sư biết Hotwire, nhưng tìm React hay Vue developer thì không thiếu
    Stack FE của Rails cũng đổi liên tục nên rất khó theo kịp (ví dụ, tôi còn nhớ cả thời CoffeeScript), tài liệu tử tế thì hầu như không có, và thực tế cũng chẳng có nhiều ảnh hưởng
    Vì thế bản thân cuộc tranh luận này khá xa rời thực tế

  • Tôi không thể đồng ý với nhận định “ngoài founder ra thì không còn dự án greenfield nào nữa”
    Nếu chỉ lấy ví dụ từ các đại monolith cũ kỹ hay Fortune 500 thì đó là một thiểu số cực nhỏ, lệch hẳn khỏi mặt bằng chung
    Ngược lại, tôi nghĩ nỗ lực để rails new có default hợp lý, dùng được ngay là điều rất đáng nể
    Cách tiếp cận này lấp rất tốt khoảng trống giữa Hello World và tài liệu API quá sơ sài
    Dù không nhất thiết phải dùng Rails, đây vẫn là điểm đáng để học hỏi

• Nghe thì dễ thương đấy, nhưng nó không nói đến thực tế là một app Rails khi phát triển sẽ phải liên tục chuyển qua bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling...
  Từ autoloader sang zeitwerk, từ Turbo sang Hotwire, thực tế đã có rất nhiều thứ thay đổi như vậy
  Chỉ cần nhìn quảng cáo trong newsletter về Rails thôi cũng thấy đầy những chỗ kiểu “chuyên gia giúp nâng cấp app Rails”

  • Cảm ơn vì đã nhắc đến chuyện này
    Nói “cứ dùng Rails thuần thôi” thì dễ, nhưng trong 5 năm qua hầu như mỗi version Rails lại thay đổi hoàn toàn cách quản lý JS
    Vẫn có rất nhiều gem còn phụ thuộc vào sprockets, nên kể cả đi theo cách của Rails thì vẫn không tránh khỏi đống JS phức tạp
    Hiện tại đúng là rất hỗn loạn. Có thể sau này sẽ khá hơn, nhưng rõ ràng Rails cũng phải chịu phần trách nhiệm lớn

  • Cũng đừng quên CoffeeScript
    Mãi đến gần đây công ty tôi làm vẫn còn trì hoãn việc port CoffeeScript, trong khi code mới thì lại viết bằng Vue

• Qua trải nghiệm thực tế, tôi học được rằng nếu dự án không có từ hơn 30 lập trình viên với nhiều chuyên môn khác nhau cùng tham gia một lúc thì thường chẳng cần mang vào độ phức tạp của việc tách frontend/backend
  Hồi làm freelancer tôi cũng từng over-engineer vô ích cho cả team chỉ 1–2 người, nhưng giờ thì chủ yếu dùng Django với thêm chút Tailwind

  • Năm nay tôi có tuyển Django developer, và gần như mọi ứng viên đều làm Django thành một API backend mỏng, còn frontend thì xây lớn bằng React (thậm chí nhiều trường hợp còn nhồi cả business logic sang frontend)
    Hỏi lý do thì gần như ai cũng không giải thích được
    Cuối cùng tôi chỉ giữ lại vài ứng viên dùng thuần server-side rendering

  • Nếu thực sự cần một frontend có tính tương tác rất cao thì có lẽ vẫn phải cân nhắc cách làm khác

  • Tôi cũng đồng ý
    Trong phần lớn ngành này, khách hàng thật ra chẳng mấy bận tâm chuyện có cần siêu mở rộng, microservice hay không, hay chỉ monolith với PostgreSQL là đủ

• Có vẻ nhiều người cứ chạy theo công nghệ mới nhất rồi thiết lập mọi thứ với mục tiêu mở rộng vô hạn
  Thực ra Rails vẫn rất hữu ích ngay cả với thiết kế đơn giản, và nhiều trường hợp over-engineer chỉ vì thấy “nhàm chán”, “không vui”
  Nhưng Rails đúng là loại “kèm pin sẵn”, và nếu ngừng over-engineer thì nó cứ thế chạy tốt thôi

  • Sau một thời gian dài tôi quay lại Rails, phải nâng một dự án hơn 10 năm tuổi từ Rails 5 lên 8 nên ban đầu rất vất vả, nhưng từ đó về sau các dự án SaaS/CRUD mới tôi đều dùng Rails
    Đến một lúc nào đó, tôi bắt đầu cảm thấy năng suất mới là giá trị quan trọng nhất

• Bây giờ đúng là phức tạp hơn, nhưng bản thân những khái niệm này thì chẳng có gì mới
  15 năm trước khi học Django, tôi cũng từng gần phát điên vì tutorial yêu cầu cài đúng version của Vagrant, VirtualBox, Chef
  Đến giờ tôi vẫn thích và tiếp tục dùng Django, nhưng tôi chẳng buồn bận tâm đến các công cụ kiểu đó nữa
  Django Rest Framework thậm chí còn là thứ khiến tôi mất tập trung hơn

• “Sự mệt mỏi vì tooling web” là rất có thật

  • 10 năm trước nó cũng đã rất có thật rồi, và kiểu hỗn loạn này thường là kết quả của việc lập trình viên mang gu sở thích cá nhân vào nơi làm việc
    Nói thêm thì không chỉ frontend mới vậy, phía DevOps cũng tương tự

  • Kết quả là muốn ứng tuyển vào lĩnh vực liên quan thì bạn phải biết hết mọi công cụ, lại còn đòi 10 năm kinh nghiệm, đủ loại backend, SQL, cả Docker nữa

  • Nếu làm chuyên nghiệp thì chỉ cần setup một lần là xong, nhưng với dự án dùng một lần hoặc khi web development không phải công việc chính thì rõ ràng là rất mệt
    Dù vậy vẫn có thể né theo kiểu này
    Tôi đã làm website bằng framework Fresh(https://fresh.deno.dev/), và chỉ riêng nó thôi là đủ
    Nhìn chung nó đơn giản hơn rất nhiều so với tổ hợp Node/Webpack, mà vẫn dùng được Typescript và TSX
    Nếu nhiều người cùng làm thì có thể tôi sẽ thêm ESLint, nhưng kể cả không có thì bắt đầu cũng cực kỳ dễ dàng