Anda sedang menggunakan Rails dengan cara yang salah

• Melalui percakapan dua pengembang seputar integrasi Rails 8 dan Vite, tulisan ini menyindir lingkungan pengembangan web modern yang telah menjadi terlalu rumit secara tidak perlu
• Salah satunya menambahkan begitu banyak alat seperti Vite, React, Babel, Tailwind, Docker, Husky dan menyebutnya sebagai stack yang ‘modern’
• Sebaliknya, yang lain menunjukkan aplikasi yang langsung berjalan hanya dengan Rails bawaan tanpa konfigurasi apa pun, memperlihatkan manfaat dari kesederhanaan
• Sambil menyindir situasi saat ini yang bergantung pada rantai alat yang rumit, tulisan ini menekankan pesan ‘gunakan saja Rails’ dan mengajak kita mengingat kembali keutamaan kesederhanaan
• Tulisan ini menunjukkan bahwa produktivitas, konsistensi, dan kesenangan dalam mengembangkan—yang dulu menjadi tujuan utama Rails—sedang dilupakan
  > “Just F#$%^& use Rails”

---

Terjemahan percakapan asli

Kevin: Hei, sudah coba Vite untuk Rails 8? Cepat banget.

John: Pernah dengar. Itu alat build, kan? Bukannya Rails sudah punya yang seperti itu?

Kevin: Dulu ada. Tapi Vite lebih modern. Kamu memang harus memasang Node dan npm lalu menyiapkan beberapa skrip, tapi itu sepadan.

John: Tunggu, sekarang Rails butuh Node?

Kevin: Iya, kalau mau pakai React. Sekarang semua orang pakai React, kan.

John: Bukannya Rails dulu punya sesuatu untuk itu?

Kevin: Dulu ada, tapi sekarang kamu harus pakai Vite bersama React Refresh. Jadi komponennya bisa langsung refresh. Kalau mau pakai TypeScript, konfigurasinya juga harus ditambahkan.

John: Baru dengar saja sudah terasa rumit.

Kevin: Ah, tidak juga. Tinggal pasang Babel, atur .babelrc, tambahkan vite-plugin-ruby, lalu untuk style pakai PostCSS.

John: PostCSS?

Kevin: Iya. Dan tentu saja harus pakai Tailwind — masa kamu mau menulis CSS sendiri satu per satu.

John: Ya tentu tidak.

Kevin: Setelah itu rapikan kode dengan ESLint dan Prettier, lalu pasang hook dengan Husky sebelum commit, beres deh.

John: Jadi Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky. Cuma itu?

Kevin: Hampir. Kalau mau server-side rendering, ya pakai Next.js atau Remix.

John: Tunggu, kita masih sedang membicarakan Rails, kan?

Kevin: Tentu. Sekarang zamannya hybrid stack! Kalau kamu ingin komponen reaktif tanpa framework JS, StimulusReflex atau Hotwire juga oke.

John: StimulusReflex? Kedengarannya seperti nama karakter Marvel.

Kevin: Hahaha, itu nyata. Buat pembaruan real-time. Tapi kamu harus mengatur ActionCable, dan juga butuh Redis.

John: Redis?

Kevin: Iya, karena butuh lapisan pub/sub. Tenang, tinggal jalankan satu kontainer Docker lagi.

John: Jadi Docker juga harus dipakai?

Kevin: Jelas. Penting untuk isolasi dependensi. Kalau mau reproduksi lingkungan yang lengkap, kamu juga harus pakai Docker Compose, deployment ke Fly.io, dan menjalankan pipeline lewat GitHub Actions.

John: Itu... cukup rumit juga.

Kevin: Ya begitulah pengembangan web modern, kawan. Sederhana kok. Kamu sendiri lagi pakai apa?

John: Cuma lagi utak-atik ini.

(John menjalankan satu perintah. Aplikasinya langsung menyala. Formulirnya berfungsi, pemuatannya cepat, dan navigasinya secepat kilat.)

Kevin: Wah, kelihatannya cukup rumit. Pakai stack apa?

John: Rails biasa saja.

> Just F#$%^& use Rails.

[labeldock]

Saya menyukai semua alat. Kedua alat itu memiliki ekosistem dan tujuan yang sebagian saling beririsan, jadi bukan alat yang benar-benar sama dan tidak seharusnya dinilai berdasarkan tingkat kesulitannya. Jika ditulis dengan vite, skrip bisa dibuat secara luas dan terperinci. Sementara Stimulus atau Hotwire lebih cocok untuk meminimalkan pengembangan skrip.

[roxie]

Sepertinya sebagian besar isinya berfokus pada pengembangan frontend...

[GN⁺]

Komentar Hacker News

• Artikel ini sudah ditulis ulang selama lebih dari 10 tahun
  Apa yang disebut “kompleksitas” itu hanyalah daftar alat untuk menyelesaikan masalah tertentu
  Alat itu sendiri bukan masalahnya; kenyataannya memang ada kompleksitas yang inheren dalam pengembangan web modern
  Kompleksitas “tersembunyi” serupa juga bisa dilihat di ASP.NET atau framework GUI desktop
  Misalnya, jika Rails dipakai sebagai backend API dan frontend ditangani React, itu sudah menjadi arsitektur yang sepenuhnya berbeda dari monolit Rails tradisional
  Daftar alat seperti Vite, React, dan Prettier adalah pilihan yang menargetkan masalah yang sama sekali berbeda (kalau ingin memakai Rails untuk frontend, ya pakai saja Rails; saya kurang suka bentuk tengah-tengah)
  Masalah yang sebenarnya adalah cara belajar
  Sekarang banyak developer belajar framework lebih dulu sebelum dasar-dasar web (HTML, CSS, logika server-side, database)
  Setiap alat ada karena alasan masing-masing, dan semuanya memang alat yang dibutuhkan di web modern
  Melihatnya sebagai “terlalu banyak” berarti belum benar-benar melihat realitas industri

  • Kompleksitas bukan sesuatu yang inheren dalam pengembangan web
    Justru sekarang kita bisa melakukan lebih banyak dengan lebih sedikit
    Hotwire bekerja hampir seperti Rails vanilla, dan pengalaman modern dengan konten yang diperbarui secara real-time lewat websocket bisa disusun hanya dengan satu baris
    Cara umum untuk mengirimkan JS di Rails juga jadi sangat sederhana berkat import maps (tanpa perlu tahap build terpisah)
    Tailwind juga sangat mudah ditambahkan
    Bahkan deployment jadi jauh lebih mudah dengan kamal
    Jadi saya tidak setuju kalau kompleksitas itu esensial, dan Hotwire justru berperan menurunkan kompleksitas
    Belajar seharusnya bukan soal “belajar lebih banyak”, melainkan belajar “melakukan lebih banyak dengan lebih sedikit”
    Keahlian teknis yang sesungguhnya bukan bisa memakai 20 bahasa atau server, melainkan mengungguli seribu orang dengan tim 3 orang dan 4 teknologi

  • Sepertinya orang bukan menolak keberadaan alat itu sendiri, tapi menolak suasana bahwa semuanya wajib dipakai
    Semua tutorial dan judul video YouTube terasa seperti “stack MONGOOSE yang WAJIB dipakai!”, jadi banyak pemula yang akhirnya memaksakan redis ke blog tentang baking
    Faktanya, kebanyakan situs sudah cukup tanpa stack khusus
    Tapi tidak ada yang mempromosikan itu, jadi banyak developer junior benar-benar tidak tahu hal ini
    Saya setuju bahwa pembelajaran teknologi dasar harus diprioritaskan, tapi sulit menyampaikan pesan itu di tengah perusahaan-perusahaan yang sibuk mempromosikan berbagai layanan

  • Saya sendiri masih cukup pemula di Rails, tapi punya sekitar 10 tahun pengalaman di bahasa lain
    Menambahkan alat kalau memang perlu itu tidak masalah (apakah benar-benar perlu adalah hal lain)
    Tapi Rails pada dasarnya adalah framework raksasa serba bisa yang sudah mencakup segalanya dari ORM sampai console dan generator kode scaffolding
    Kalau masih perlu alat tambahan, bukankah justru Rails itu sendiri yang perlu dipertanyakan ulang?
    Mungkin sesuatu yang lebih modular justru lebih baik
    Istilah “Rails vanilla” terasa seperti tanda bahaya. Sulit memahami bagaimana framework sebesar itu bisa disebut vanilla

  • Inti tulisan ini adalah bahwa banyak orang tidak pernah benar-benar bertanya pada diri sendiri sejak awal apakah mereka memang butuh “aplikasi web modern”, dan tidak tahu bahwa Rails vanilla saja sebenarnya sudah cukup
    Kurang ada upaya untuk memahami pilihan default dari Rails vanilla itu sendiri

  • Menyebut “kompleksitas pengembangan web modern” hanyalah cara menggambarkan situasi masalah, bukan syarat wajib
    Kalau Anda menarik ribuan paket npm ke situs yang cuma berisi database dan beberapa query SQL, berarti ada yang salah dalam cara Anda mengerjakannya

• Saya sudah menulis kode Rails sejak 2007
  Ada alasan mengapa stack menjadi lebih kompleks, dan praktis tidak ada tim yang “melakukannya dengan benar” menurut standar di artikel utama
  Masalah dengan framework omakase (seperti Rails yang menentukan sebagian besar pilihan) bukan cuma pilihan awal, tapi juga bahwa pilihan-pilihan setelahnya harus terus diikuti, dan seluruh tim harus ikut dibawa ke arah itu
  Rails itu kuat, tapi para maintainernya juga tidak bisa melihat masa depan dengan sempurna
  Karena itu, sekarang hampir tidak ada aplikasi yang kembali ke Rails vanilla
  Dulu, sebelum Docker, deployment Rails benar-benar merepotkan. Alih-alih rsync atau tarball, Anda butuh sistem deployment seperti Capistrano.
  Docker atau k8s memang nyaman, tapi dibanding masa lalu, sebenarnya tidak lebih buruk

  • Kalau kenangan Anda tentang deployment Rails era pra-Docker adalah “rsync lalu ekstrak tarball”, berarti setup-nya memang benar-benar berantakan
    Deployment dengan Capistrano “zaman dulu” jauh lebih baik

  • Saya ingin ada penjelasan lebih rinci soal apa tepatnya masalah dari “mendorong ke banyak instance dengan rsync atau tarball”
    Kedengarannya tidak separah itu

  • Karena itulah saya selalu punya tempat khusus untuk Sinatra

• Sayang sekali utilitas yang diberikan Rails secara out-of-the-box masih belum benar-benar punya padanan di dunia JS
  Kebanyakan developer JS tidak terlalu menyadari hal ini
  Tapi JS memang selalu menjadi ekosistem yang terus menemukan ulang roda

  • Kelebihan besar JS adalah semua orang punya kesempatan membuat platform baru
    Menggabungkan beberapa platform JS sekaligus pun biasanya tetap jalan, dan itu membuatnya sangat bisa diperluas, bisa di-hack, serta memungkinkan semuanya dibangun permanen secara lokal untuk menghasilkan situs statis
    Tapi kebebasan seperti ini butuh pengendalian diri
    Menahan rekan kerja yang ingin membawa framework baru kapan saja pada akhirnya menjadi tugas tim

  • Ember.js adalah framework all-in-one (“batteries included”) yang dibuat oleh nama-nama besar dari kubu Rails
    Tapi ada alasan mengapa ia tidak sesukses framework lain

  • Di ekosistem JS juga ada framework backend serba lengkap seperti AdonisJS
    Hanya saja, ekosistem NodeJS berangkat dari microframework sebagai reaksi terhadap framework yang kaku seperti Rails atau Django
    Konsep Express juga memang “cepat dan seadanya”

  • Di JS juga ada banyak framework full-stack yang mirip Rails
    Bahkan ada framework bernama Sails
    JS menyelesaikan masalah yang berbeda dari Rails, jadi bentuk framework-nya memang tak terhindarkan akan berbeda

  • Rails memang punya banyak utilitas, tapi dalam jangka panjang melelahkan juga karena codebase harus diperbarui secara berkala dan Anda harus terus mengikuti tren Rails

• Stimulus dan Hotwire sekarang sudah menjadi “cara Rails” yang resmi
  Saya sudah membaca dokumentasinya dengan serius, tapi tetap saja sangat membingungkan
  Rasanya seperti terus-menerus membangun ulang sendiri komponen JS yang sama
  Menurut saya kombinasi Rails 8 + Inertia.js + React justru membuat kita lebih jarang “menciptakan ulang roda”, apalagi kalau memakai komponen shadcn

  • Saya setuju soal ini
    Kami juga mengganti frontend Hotwire dengan Inertia, dan bedanya benar-benar siang dan malam
    Kecuali Anda benar-benar mengerjakan proyek kecil sendirian 100%, Hotwire cepat sekali berubah jadi kekacauan yang tak bisa disentuh seluruh tim

  • Saya justru sangat menyukai Stimulus sampai langsung membawanya dari Rails ke aplikasi Phoenix
    Tapi menurut saya masalahnya adalah kesalahpahaman soal alat ini
    Stimulus bukan pengganti React
    Kalau Anda terbiasa dengan aplikasi JS puluhan ribu baris, React mungkin memang lebih cocok
    Tapi kalau Anda ingin memoles UX dengan beberapa puluh baris JS di aplikasi yang berpusat pada server-side, Stimulus sangat pas
    Di Phoenix, ia adalah solusi minimalis yang pas di antara HTML statis dan LiveViews yang dinamis
    Tidak ada yang menyuruh orang membangun SPA dengan Stimulus, dan kalau dipakai untuk itu saya yakin hasilnya akan menyulitkan

  • Stimulus benar-benar kecil, sistem event dengan HTML hook, jadi sangat cocok dengan request lifecycle Rails
    Saya penasaran apakah ada orang yang pernah berhasil membangun sesuatu yang sangat kompleks dengan Stimulus
    Dari yang saya rasakan, itu terlalu sulit untuk dibawa sejauh itu

  • Saya juga bisa dibilang fanboy Rails, tapi kondisi Stimulus dan Hotwire saat ini tetap disayangkan
    Konsepnya bagus, dan implementasinya mungkin juga bagus
    Tapi dokumentasinya sangat buruk sampai terasa sulit mulai dari awal, dan di tiap proyek tidak ada cukup informasi untuk menjawab pertanyaan seperti “kalau mulai dengan ini, apakah nanti saya akan mentok di jalan buntu?”

  • Saya pernah memakai Stimulus bersama Symfony untuk interaksi kecil, dan API-nya yang kecil serta dirancang dengan baik terasa cukup bagus
    Saya belum pernah memakai seluruh Turbo/Hotwire, dan untuk halaman yang kompleks atau butuh state biasanya saya memakai Vue

• Pada akhirnya sekarang proyek greenfield nyaris bisa dibilang sudah menghilang
  Selain founder, greenfield sendiri jarang ada, dan kalau menjual sesuatu, hampir 99% ditangani dengan wrapper Shopify atau semacamnya
  Bahkan di perusahaan besar, proyek greenfield pun terikat oleh berbagai pertimbangan dan framework internal, jadi tidak benar-benar dimulai dari rails new
  Diskusi seperti ini tidak terlalu berarti, dan perdebatan serta tulisan serupa sudah berulang selama 10 tahun, 15–20 tahun terakhir sampai terasa membosankan
  Daripada tulisan baru, saya ingin orang benar-benar membuat sesuatu yang baru

  • Sangat setuju
    Saya sudah 10 tahun bekerja dengan Ruby/Rails, dan bahkan codebase yang paling “baru” pun semuanya sudah berumur lebih dari 5 tahun
    Jujur saya memang pernah membuat aplikasi Rails greenfield baru, tapi itu pun microservice khusus API jadi tidak butuh frontend
    Di perusahaan yang cukup besar, solusi frontend Rails benar-benar diabaikan
    Engineer yang bisa Hotwire sulit dicari, sementara developer React atau Vue bisa didapat sebanyak yang Anda mau
    Stack FE Rails juga sering berubah sehingga sulit diikuti (misalnya saya masih ingat era CoffeeScript), hampir tidak punya dokumentasi yang layak, dan secara realistis juga tidak punya pengaruh
    Jadi diskusi seperti ini terasa jauh dari kenyataan di lapangan

  • Saya tidak bisa setuju dengan klaim bahwa “proyek greenfield selain founder sudah tidak ada lagi”
    Kalau contohnya hanya monolit perusahaan tua besar atau Fortune 500, itu justru minoritas yang sangat menyimpang dari rata-rata keseluruhan
    Saya justru mengagumi upaya rails new dalam menyusun default yang masuk akal dan siap pakai
    Pendekatan seperti ini menjembatani dengan baik antara Hello World dan dokumentasi API yang terlalu sederhana
    Bahkan kalau tidak memakai Rails pun, bagian seperti ini layak dicontoh

• Walau terdengar manis, ini tidak membahas kenyataan bahwa satu aplikasi Rails harus terus berpindah dari bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling, dan seterusnya seiring berkembang
  Dari autoloader ke zeitwerk, dari Turbo ke Hotwire, dan banyak sekali bagian yang benar-benar berubah seperti itu
  Bahkan hanya dengan melihat iklan di newsletter Rails, sudah banyak yang menawarkan “para ahli membantu upgrade aplikasi Rails”

  • Senang ada yang menyinggung hal ini
    Mudah sekali berkata “pakai saja Rails vanilla”, tapi selama 5 tahun terakhir, di Rails cara mengelola JS benar-benar berubah total di tiap versi
    Masih banyak gem yang tetap bergantung pada sprockets, jadi bahkan kalau mengikuti cara Rails pun Anda tetap terpaksa menghadapi gumpalan JS yang kompleks
    Kondisinya sekarang benar-benar membingungkan. Mungkin suatu saat akan membaik, tapi jelas Rails juga punya tanggung jawab besar

  • Jangan lupa CoffeeScript juga
    Sampai baru-baru ini pun perusahaan tempat saya bekerja masih menunda porting CoffeeScript, sementara kode baru ditulis dengan Vue

• Dari pengalaman langsung saya belajar bahwa kalau proyeknya tidak melibatkan lebih dari 30 developer dengan berbagai spesialisasi yang bekerja bersamaan, kompleksitas dari pemisahan frontend/backend itu tidak perlu dibawa masuk
  Saat jadi freelancer saya juga pernah berlebihan mendesain untuk tim 1–2 orang, tapi sekarang saya biasanya hanya memakai Django dengan sedikit Tailwind di atasnya

  • Tahun ini saya merekrut developer Django, dan hampir semua pelamar membuat backend API tipis dengan Django sementara frontend-nya dibangun besar-besaran dengan React (bahkan sering memasukkan logika bisnis ke frontend)
    Saat ditanya alasannya, hampir semuanya tidak bisa menjelaskan
    Pada akhirnya yang tersisa hanya sedikit pelamar yang memakai server-side rendering saja

  • Kalau memang benar-benar butuh frontend yang sangat interaktif, mungkin perlu dipikirkan pendekatan lain

  • Saya juga setuju
    Di sebagian besar industri, dari sudut pandang pelanggan hampir tidak ada yang terlalu peduli apakah Anda butuh skalabilitas super tinggi dan microservice, atau cukup monolit biasa dengan PostgreSQL

• Sepertinya banyak orang mengejar teknologi terbaru sambil menyiapkan semuanya untuk skalabilitas tanpa batas
  Padahal Rails sangat berguna bahkan dengan desain yang sederhana, dan sering kali orang melakukan overengineering hanya karena dianggap “membosankan” atau “kurang seru”
  Tapi Rails itu benar-benar batteries included, dan kalau berhenti overengineering, ya ia bekerja dengan baik begitu saja

  • Setelah lama tidak kembali ke Rails, saya sempat kesulitan karena harus menaikkan proyek berusia lebih dari 10 tahun dari Rails 5 ke 8, tapi setelah itu untuk proyek SaaS/CRUD baru saya sekarang selalu memakai Rails
    Pada titik tertentu, produktivitas terasa menjadi nilai yang paling penting

• Yang berubah hanya sekarang lebih kompleks; konsep seperti ini sendiri bukan hal baru
  15 tahun lalu saat belajar Django pun tutorialnya meminta instalasi versi tertentu dari Vagrant, VirtualBox, dan Chef sampai rasanya nyaris gila
  Sampai sekarang saya tetap suka dan memakai Django, tapi saya tidak merasa perlu terlalu memikirkan alat-alat semacam itu
  Django Rest Framework pun justru terasa mengganggu fokus

• “Kelelahan tooling pengembangan web” itu sangat nyata

  • 10 tahun lalu pun itu sudah nyata, dan kekacauan seperti ini biasanya muncul karena developer membawa selera hobi mereka ke tempat kerja
    Tambahan lagi, ini bukan cuma masalah frontend; di sisi DevOps situasinya juga mirip

  • Akibatnya, untuk melamar ke bidang terkait orang jadi dituntut tahu semua alat itu, plus 10 tahun pengalaman, berbagai backend dan SQL, sampai Docker juga

  • Kalau dikerjakan secara profesional, biasanya cukup setup sekali lalu selesai, tapi untuk proyek sekali jalan atau kalau pengembangan web bukan pekerjaan utama, memang melelahkan
    Namun ini juga bisa dihindari seperti itu
    Saya pernah membuat situs web dengan framework Fresh(https://fresh.deno.dev/), dan itu saja sudah cukup
    Secara umum jauh lebih sederhana daripada kombinasi Node/Webpack, dan tetap bisa memakai Typescript serta TSX
    Kalau dikerjakan banyak orang mungkin saya akan menambahkan ESLint atau semacamnya, tapi bahkan tanpa itu pun sangat mudah untuk mulai bekerja dengannya