Rails’i doğru kullanmıyorsunuz

• Rails 8 ve Vite entegrasyonu etrafında geçen iki geliştiricinin diyaloğu üzerinden, gereksiz yere karmaşıklaşan modern web geliştirme ortamı hicvediliyor
• Taraflardan biri Vite, React, Babel, Tailwind, Docker, Husky gibi sayısız aracı ekleyip buna “modern” stack diyor
• Buna karşılık diğer kişi, hiçbir ayar yapmadan yalnızca temel Rails ile anında çalışan bir uygulama göstererek sadeliğin faydasını ortaya koyuyor
• Karmaşık toolchain’lere bağımlı bugünkü durumla alay ederken, “sadece Rails kullan” mesajını öne çıkarıp sadeliğin erdemini yeniden düşünmeye çağırıyor
• Rails’in başlangıçtaki amacı olan üretkenlik, tutarlılık ve geliştirmenin keyfinin unutulmakta olduğuna işaret ediyor

“Just F#$%^& use Rails”

---

Orijinal diyalog çevirisi

Kevin: Hey, Rails 8 için Vite’ı denedin mi? İnanılmaz hızlı.

John: Adını duydum. Bir build tool değil mi? Rails’te zaten böyle bir şey yok muydu?

Kevin: Vardı. Ama Vite daha modern. Node ve npm kurup birkaç script ayarı yapman gerekiyor ama değer.

John: Bir saniye, Rails artık Node mu istiyor?

Kevin: Evet, React kullanacaksan. Zaten bugünlerde herkes React kullanıyor.

John: Rails’te buna benzer bir şey yok muydu?

Kevin: Vardı ama artık React Refresh ile birlikte Vite kullanman gerekiyor. Böylece component’ler anında yenileniyor. TypeScript kullanacaksan onun ayarını da yapmalısın.

John: Sadece dinlerken bile karmaşık geliyor.

Kevin: Yok canım, o kadar da değil. Babel kurup .babelrc yapılandırıyorsun, vite-plugin-ruby ekliyorsun, stiller için de PostCSS kullanıyorsun.

John: PostCSS?

Kevin: Evet. Ve tabii ki Tailwind de kullanmalısın — şaka bir yana, CSS’i tek tek elle yazmak istemezsin herhalde.

John: Doğru.

Kevin: Sonra kodu ESLint ve Prettier ile düzenlersin, commit öncesi Husky ile hook da bağladın mı tamamdır.

John: Yani Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky. Hepsi bu mu?

Kevin: Neredeyse. Server-side rendering de istiyorsan Next.js ya da Remix kullanmalısın.

John: Bir dakika, biz hâlâ Rails’ten mi bahsediyoruz?

Kevin: Evet. Artık hibrit stack’ler moda! JS framework olmadan reaktif component’ler istiyorsan StimulusReflex ya da Hotwire da güzel.

John: StimulusReflex mi? Marvel karakteri adı gibi.

Kevin: Haha, gerçek. Gerçek zamanlı güncellemeler için. Ama ActionCable ayarlaman ve Redis de kurman gerekiyor.

John: Redis mi?

Kevin: Evet, bir pub/sub katmanı lazım. Merak etme, sadece bir Docker container daha çalıştırırsın.

John: Docker da mı kullanmak gerekiyor?

Kevin: Tabii. Bağımlılıkları izole etmek için şart. Ortamı tamamen yeniden üretilebilir yapmak istiyorsan Docker Compose, Fly.io deployment ve GitHub Actions ile pipeline da kurmalısın.

John: Bu... bayağı karmaşıkmış.

Kevin: İşte modern web geliştirme böyle dostum. Gayet basit. Sen ne yapıyorsun?

John: Sadece kurcalıyorum.

(John tek bir komut çalıştırır. Uygulama anında ayağa kalkar. Formlar çalışır, yükleme hızlıdır ve gezinme yıldırım gibidir.)

Kevin: Vay, oldukça karmaşık görünüyor. Hangi stack’i kullanıyorsun?

John: Sadece düz Rails.

Just F#$%^& use Rails.

[labeldock]

Ben her iki aracı da seviyorum. Bu iki aracın ekosistemleri ve amaçları bazı noktalarda kesişiyor; yani tamamen aynı araçlar değiller ve zorluk düzeyine göre değerlendirilmemeliler. vite ile yazarsanız scriptleri geniş kapsamlı ve ayrıntılı biçimde kurgulayabilirsiniz. Stimulus ya da Hotwire ise script geliştirmeyi en aza indirmek için daha uygundur.

[roxie]

İçeriğin büyük kısmı frontend geliştirmeye odaklanmış gibi görünüyor...

[GN⁺]

Hacker News yorumları

• Bu yazı 10 yıldan uzun süredir yeniden yazılıp duruyor
  Sözde “karmaşıklık” denilen şey, aslında her biri belirli bir sorunu çözen araçların bir listesinden ibaret
  Sorun araçların kendisi değil; asıl gerçek, modern web geliştirmede doğası gereği bir karmaşıklık olması
  Benzer “gizli” karmaşıklıkları ASP.NET ya da masaüstü GUI framework’lerinde de görebilirsiniz
  Örneğin Rails’i API backend olarak kullanıp frontend’i React’e bırakırsanız, bu geleneksel Rails monolitinden tamamen farklı bir mimari olur
  Vite, React, Prettier gibi araç listeleri tamamen başka sorunları hedefleyen tercihlerdir (frontend için Rails kullanmak istiyorsanız zaten doğrudan Rails kullanın; ben ara formları pek sevmiyorum)
  Asıl problem öğrenme yöntemi
  Günümüzde geliştiriciler çoğu zaman web’in temellerini (HTML, CSS, sunucu tarafı mantığı, veritabanı) öğrenmeden önce framework öğreniyor
  Her aracın var olmak için kendine göre bir nedeni var ve hepsi modern web için gerekli araçlar
  Buna sadece “çok fazla araç var” diye bakmak, sektörün gerçekliğini doğru görmemek demek

  • Karmaşıklık web geliştirmenin doğasında yok
    Hatta bugün daha az şeyle daha fazlasını yapabiliyoruz
    Hotwire neredeyse vanilla Rails gibi çalışıyor ve websocket üzerinden içeriğin gerçek zamanlı güncellendiği modern bir deneyimi tek satırla kurabiliyorsunuz
    Rails’te JS dağıtmanın yaygın yolu da import maps sayesinde çok basit hale geldi (ayrı bir build aşaması gerekmiyor)
    Tailwind eklemek de son derece kolay
    Deploy bile kamal ile çok daha kolaylaştı
    Bu yüzden karmaşıklığın özsel olduğu fikrine katılmıyorum ve Hotwire da karmaşıklığı azaltan bir rol oynuyor
    Öğrenme, “daha çok şey öğrenmekten” ziyade “daha az şeyle daha çok iş yapmayı” öğrenmek yönünde olmalı
    20 dil ya da sunucu bilmektense, 4 şeyle 3 kişilik bir ekibin bin kişiyi geride bırakması asıl beceridir

  • İnsanlar araçların varlığına karşı değil; sanki herkesin bunları mutlaka kullanması gerekiyormuş gibi yaratılan havaya tepki duyuyor gibi geliyor
    Her tutorial, her YouTube video başlığı “Mutlaka kullanmanız gereken MONGOOSE stack!” gibi olunca, yemek tarifi bloguna bile zorla redis eklemeye çalışan acemiler çıkıyor
    Oysa çoğu site için özel bir stack olmadan da her şey gayet yeterli
    Ama kimse bunu pazarlamadığı için, pek çok junior geliştirici bunun farkında bile değil
    Temel teknolojileri önce öğrenmek gerektiğine katılıyorum ama şirketlerin durmadan servis pazarladığı bir ortamda bu mesajı vermek kolay değil

  • Rails’te oldukça acemiyim ama başka dillerde yaklaşık 10 yıllık deneyimim var
    Gerekirse araç eklemek sorun değil (gerçekten gerekli olup olmaması ayrı konu)
    Ama Rails zaten özünde ORM’den konsola, scaffolding kod üretimine kadar her şeyi içeren devasa bir çok amaçlı framework
    Eğer ek araçlara ihtiyaç duyuluyorsa, belki de asıl Rails’in kendisini yeniden düşünmek gerekmiyor mu?
    Daha modüler bir şey belki daha iyi olabilir
    “Vanilla Rails” ifadesi bana bir uyarı işareti gibi geliyor. Bu kadar iri bir framework’e nasıl vanilla denebilir, anlamakta zorlanıyorum

  • Bu yazının ana fikri, insanların en başta gerçekten “modern web uygulaması”na ihtiyaçları olup olmadığını düşünmeden, vanilla Rails’in çoğu zaman yeterli olabileceğini bilmemeleri
    Vanilla Rails’in varsayılan tercihlerini kendileri anlamaya çalışma çabası eksik

  • “Modern web geliştirmenin karmaşıklığı”ndan söz etmek sadece mevcut durumu tarif etmektir, bir zorunluluk değil
    Sadece veritabanı ve birkaç SQL sorgusundan oluşan bir site için binlerce npm paketi çekiyorsanız, bir şeyi yanlış yapıyorsunuz demektir

• 2007’den beri Rails kodu yazıyorum
  Stack’in karmaşıklaşmasının nedenleri var ve yazının ölçütlerine göre “doğru yapan” ekip neredeyse yok
  Omakase framework’lerin (Rails gibi çoğu tercihi sizin yerinize yapan yapıların) sorunu, sadece ilk seçimleri değil sonrakileri de sürekli takip etmek ve bütün ekibi beraber sürüklemek zorunda olmanız
  Rails güçlü ama bakımcıları da geleceği kusursuz şekilde öngöremez
  Bu yüzden bugün neredeyse hiçbir uygulama yeniden vanilla Rails’e dönmüyor
  Eskiden, Docker öncesinde Rails deploy etmek gerçekten zahmetliydi. rsync ya da tarball yerine Capistrano gibi bir deploy sistemine ihtiyaç vardı.
  Docker ya da k8s de kullanışlı ama geçmişe kıyasla özellikle daha kötü değiller

  • Docker öncesi dönemde Rails deploy’unu “rsync yapıp tarball açmak” olarak hatırlıyorsanız, gerçekten çok kötü bir kurulumdu
    “Eski usul” Capistrano ile deploy etmek çok daha iyiydi

  • “rsync ya da tarball ile birden fazla instance’a dağıtmak” yaklaşımının tam olarak neden sorunlu olduğunu biraz daha anlatmanızı isterdim
    Kulağa o kadar da korkunç gelmiyor

  • Bu yüzden benim gönlüm hep Sinatra’dan yana

• Rails’in kutudan çıktığı haliyle sunduğu utility’lerin JS dünyasında hâlâ tam karşılığının olmaması üzücü
  Çoğu JS geliştiricisi bunun pek farkında değil
  Ama JS ekosistemi zaten hep tekerleği yeniden icat eden bir dünya

  • JS’in en büyük avantajı, herkese yeni bir platform yaratma fırsatı vermesi
    Birden fazla JS platformunu aynı anda birleştirseniz bile çoğu zaman bir şekilde çalışıyor; son derece genişletilebilir, hacklenebilir ve her şeyi lokalde kalıcı olarak build edip sabit bir site üretmek de mümkün
    Ama bu özgürlüğün yanında ölçülülük de gerekiyor
    Canı istediğinde yeni framework getirmek isteyen ekip arkadaşını durdurmak takımın görevi oluyor

  • Ember.js, Rails dünyasının büyük isimleri tarafından yapılmış, her şeyi içinde barındıran bir framework’tü (“bataryalar dahil”)
    Yine de neden diğer framework’ler kadar başarılı olamadığına dair bir sebep var

  • JS ekosisteminde de AdonisJS gibi her şeyi içeren backend framework’leri var
    Ancak NodeJS ekosistemi, Rails ya da Django gibi daha kalıplaşmış framework’lere tepki olarak mikroframework’lerden doğdu
    Express’in konsepti de “hızlı ve kabaca” bir şey yapıp kullanmaktı

  • JS tarafında da Rails’e benzeyen pek çok full-stack framework var
    Sails diye bir framework de var
    JS, Rails’in çözdüğü sorunlardan farklı problemleri çözdüğü için framework’lerin biçimi de doğal olarak farklı oluyor

  • Rails’in utility’leri çok ama uzun vadede kod tabanını düzenli olarak güncellemek ve Rails dünyasındaki trendleri sürekli takip etmek yorucu olabiliyor

• Stimulus ve Hotwire artık “rails way” olarak yerleşmiş durumda
  Dokümantasyonu dikkatle okusam da hâlâ fazlasıyla kafa karıştırıcı geliyor
  Sürekli kendi JS component’lerimi tekrar tekrar sıfırdan yazıyormuşum gibi hissediyorum
  Bana göre Rails 8 + Inertia.js + React kombinasyonu, özellikle shadcn component’leri kullanınca, “tekerleği yeniden icat etme”yi daha az gerektiriyor

  • Buna katılıyorum
    Biz de Hotwire frontend’ini Inertia ile değiştirdik ve aradaki fark geceyle gündüz gibi
    Gerçekten %100 tek başınıza küçük bir proje yapmıyorsanız, Hotwire kısa sürede ekibin tamamının dokunamadığı bir karmaşaya dönüşüyor

  • Ben ise Stimulus’u o kadar sevdim ki Rails’ten Phoenix uygulamasına geçerken onu da aynen kullandım
    Ama bence mesele bu aracın yanlış anlaşılması
    Stimulus, React alternatifi değil
    On binlerce satırlık JS uygulamalarına alışkınsanız React size daha uygun olabilir
    Ama sunucu tarafının merkezde olduğu bir uygulamada UX’i birkaç düzine satır JS ile iyileştirmek istiyorsanız, Stimulus tam oturuyor
    Phoenix’te statik HTML ile dinamik LiveViews arasına tam denk gelen minimal bir çözüm
    Kimse Stimulus ile SPA yapın demedi ve bunu denerseniz işlerin zorlaşacağı çok açık

  • Stimulus gerçekten çok küçük; HTML hook’ları olan bir event system ve Rails’in request lifecycle’ı ile iyi uyum sağlıyor
    Stimulus ile gerçekten çok karmaşık bir şeyi başarıyla yapan birini merak ediyorum
    Bana hep, o kadar ileri gitmenin fazlasıyla zor olduğu hissini verdi

  • Ben de kendime Rails fanboy’u denebilecek biriyim ama Stimulus ve Hotwire’ın bugünkü hali beni hayal kırıklığına uğratıyor
    Fikir harika, implementasyon da muhtemelen iyi olabilir
    Ama dokümantasyon o kadar korkunç derecede yetersiz ki başlamak bile göz korkutuyor; ayrıca bir projeye bununla başlarsam ileride çıkmaza girer miyim sorusuna yanıt verecek bilgi de yok

  • Stimulus’u Symfony ile birlikte küçük etkileşimler için kullandım; küçük ve iyi tasarlanmış bir API’si olduğu için oldukça iyiydi
    Turbo/Hotwire’ın tamamını henüz kullanmadım; karmaşık ya da state gerektiren sayfalarda genelde Vue kullanıyorum

• Zaten bugünlerde greenfield proje neredeyse kalmadı denecek kadar az
  Kurucular dışında greenfield nadir; bir şey satıyorsanız vakaların %99’unda Shopify wrapper’ı ya da benzeri bir şeyle çözülüyor
  Büyük şirketlerde de greenfield işler, türlü gereksinimler ve şirket içi framework’lerle bağlı olduğu için kimse “rails new” ile başlamıyor
  Bu tartışmaların çok anlamı yok; benzer tartışma ve yazılar son 10 yıldır, hatta 15–20 yıldır tekrar edip duruyor, artık bayat ve sıkıcı
  Yeni yazılar yerine gerçekten yeni bir şeyler inşa edilse keşke

  • Kesinlikle katılıyorum
    Ruby/Rails ile 10 yıl çalıştım ve gördüğüm en “yeni” kod tabanı bile 5 yıldan daha eskiydi
    Dürüst olmak gerekirse yeni bir greenfield Rails uygulaması yaptığım oldu ama o da sadece API sunan bir microservice’ti, yani frontend gerekmiyordu
    Ölçekli şirketlerde Rails frontend çözümü baştan yok sayılıyor
    Hotwire bilen mühendis bulamayabilirsiniz ama React ya da Vue geliştiricisi bulmak çok daha kolay
    Rails’in FE stack’i de sık sık değişiyor; takip etmesi zor (ör. CoffeeScript dönemini hatırlıyorum), doğru dürüst dokümantasyon da yok ve gerçek dünyadaki etkisi de sınırlı
    Bu yüzden bu tartışmalar fiili gerçeklikten kopuk kalıyor

  • “Greenfield projeler kurucular dışında artık kalmadı” iddiasına katılamıyorum
    Eski büyük şirket monolitlerini ya da Fortune 500 örneklerini genellemek, toplamın içindeki çok küçük ve sıra dışı bir kesime bakmak olur
    Hatta “rails new” komutunun makul ve hemen kullanılabilir varsayılanları özenle bir araya getirmesini etkileyici buluyorum
    Bu yaklaşım Hello World ile aşırı basit API dokümanları arasındaki boşluğu çok iyi dolduruyor
    Rails kullanmasanız bile bu kısmı örnek alınabilir

• Sevimli bir fikir ama tek bir Rails uygulamasının zamanla bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling gibi şeyler arasında göç etmek zorunda kaldığı gerçeğinden hiç söz etmiyor
  autoloader’dan zeitwerk’e, Turbo’dan Hotwire’a kadar gerçekten çok fazla şey değişti
  Hatta sadece Rails bültenlerindeki reklamlara bakınca bile “uzmanlar Rails uygulamanızı upgrade etmenize yardımcı olur” türü ilanlar dolu

  • Buna değinmenize sevindim
    “Sadece vanilla Rails kullanalım” demek kolay ama Rails’in son 5 yılında neredeyse her sürümde JS yönetim biçimi tamamen değişti
    Hâlâ sprockets’e bağlı gem’ler çok olduğu için, Rails’in önerdiği yolu izleseniz bile kaçınılmaz olarak karmaşık bir JS yığınına sürükleniyorsunuz
    Şu an gerçekten kafa karıştırıcı bir durum var. Belki bir gün düzelir ama bunda Rails’in de ciddi payı var

  • CoffeeScript’i de unutmamak lazım
    Yakın zamana kadar çalıştığım şirket hâlâ CoffeeScript taşımasını ertelemeye devam ediyordu, yeni kodlar ise Vue ile yazılıyordu

• 30’dan fazla geliştiricinin farklı uzmanlıklarla aynı anda çalışmadığı projelerde, frontend/backend ayrımının getirdiği karmaşıklığa aslında gerek olmadığını bizzat deneyimleyerek öğrendim
  Freelancer olduğum dönemde 1–2 kişilik ekiplerde bile gereksiz yere aşırı tasarım yaptım ama artık genelde Django üstüne biraz Tailwind ekleyip geçiyorum

  • Bu yıl Django geliştiricisi işe aldık; başvuranların neredeyse hepsi ince bir API backend’i Django ile kurup frontend’i büyük ölçüde React ile yapıyor, hatta business logic’i bile çoğu zaman frontend’e yüklüyordu
    Nedenini sorduğumuzda neredeyse hiçbiri bunu açıklayamıyordu
    Sonunda yalnızca server-side rendering kullanan birkaç aday kalabildi

  • Eğer gerçekten çok etkileşimli bir frontend gerekiyorsa ne yapmanız gerektiğini düşünmeniz gerekebilir

  • Ben de katılıyorum
    Sektörün büyük kısmında müşteriler, aşırı ölçeklenebilirlik ve microservices gerekip gerekmediğini ya da bir monolit ve PostgreSQL’in yeterli olup olmadığını pek umursamıyor

• Pek çok kişi en yeni teknolojilerin peşinden koşup sonsuz ölçeklenme hedefiyle kurulum yapıyor gibi görünüyor
  Oysa Rails basit tasarımlarla bile çok faydalı ve çoğu zaman “sıkıcı”, “eğlenceli değil” diye overengineering yapılıyor
  Ama Rails gerçekten bataryalar dahil geliyor ve aşırı mühendisliği bıraktığınızda gayet iyi çalışıyor

  • Uzun bir aradan sonra Rails’e döndüm; 10 yılı aşkın bir projenin Rails 5’ten 8’e yükseltilmesi başta zorladı ama sonrasında yeni SaaS/CRUD projelerinde sadece Rails kullanıyorum
    Bir noktadan sonra en önemli değerin üretkenlik olduğunu hissediyorsunuz

• Şimdi daha karmaşık olabilir ama bu kavramların kendisi yeni değil
  15 yıl önce Django öğrenirken tutorial’ların benden belirli bir Vagrant, VirtualBox ve Chef sürümü kurmamı istemesi yüzünden çıldıracak gibi olmuştum
  Bugün hâlâ Django’yu seviyor ve kullanıyorum ama o araçlarla hiç uğraşmıyorum
  Django Rest Framework bile çoğu zaman odağı dağıtan bir unsur olmuştu

• “Web geliştirme tooling yorgunluğu” çok gerçek bir şey

  • 10 yıl önce de gerçekti ve bu karmaşa genelde geliştiricilerin hobi tercihlerini iş ortamına taşımasının sonucu oluyor
    Ayrıca sadece frontend için de geçerli değil; DevOps tarafında da durum benzer

  • Sonuç olarak, ilgili alanlara başvurmak için sanki tüm araçları bilmek, üstüne 10 yıl deneyim, çeşitli backend’ler, SQL ve Docker da şartmış gibi bir hava oluşuyor

  • Bunu profesyonel olarak yapıyorsanız bir kez kurup sonra devam ediyorsunuz ama tek seferlik projelerde ya da web geliştirmenin asıl işiniz olmadığı durumlarda bunun yorucu olduğu kesin
    Yine de bundan kaçınmanın yolları var
    Ben bir web sitesini Fresh(https://fresh.deno.dev/) framework’ü ile yaptım ve sadece bu yeterli oldu
    Genel olarak Node/Webpack kombinasyonundan çok daha basitti, ayrıca Typescript ve TSX de kullanabildim
    Birden fazla kişi çalışsaydı belki ESLint gibi şeyler eklerdim ama onsuz bile başlamak son derece kolaydı