2 puan yazan GN⁺ 2026-03-13 | 4 yorum | WhatsApp'ta paylaş
  • Grubun setlist yönetim uygulamasını (setlist.rocks) geliştirirken uzun bir aradan sonra Ruby on Rails ile geliştirmenin keyfini yeniden keşfetti
  • En yeni Rails 8, geleneksel MVC yapısını korurken Hotwire (Stimulus·Turbo) tabanlı “no-build” frontend, Solid Cache/Queue/Cable gibi bileşenlerle modernleşti
  • SQLite, yalnızca varsayılan ayarlarla bile gerçek servis kullanımına uygun olacak kadar optimize edildi ve Kamal dağıtım aracı sayesinde konteyner tabanlı kesintisiz dağıtım kolaylaştı
  • Rails’in “yapılandırmadan çok gelenekler” felsefesi ve zengin gem ekosistemi sayesinde fikirden prototipe hızlıca geçmek mümkün
  • Ruby ve Rails’in popülaritesi eskisine göre düşmüş olsa da hâlâ olgun ve tutarlı bir açık kaynak çerçeve olarak geliştirme keyfi sunuyor

Yan proje ve Rails'e geri dönüş

  • Grubunun setlist'lerini ve şarkı notlarını yönetmek için web uygulamasını bizzat geliştirdi; mevcut e-tablo veya sohbet araçlarından daha verimli bir yöntem aradı
  • Geliştirme sürecinde Rails'in sadeliğini ve üretkenliğini yeniden hissettiğini, son dönemin karmaşık web ekosistemine kıyasla “saf geliştirme keyfi” yaşadığını söylüyor
  • Ruby, hâlâ doğal sözdizimi ve ifade gücü sayesinde düşünceleri koda aktarmayı kolaylaştıran bir dil olarak değerlendiriliyor
  • Stack Overflow 2025 anketine göre Ruby ve Rails'in popülaritesi gerilese de kişisel projelerde hâlâ tercih ediliyor

Rails 8'deki değişimler ve frontend

  • Rails 8, mevcut MVC yapısını korurken Hotwire (Stimulus·Turbo) tabanlı frontend entegrasyonunu da sunuyor
    • Turbo, bağlantı tıklamalarını ve form gönderimlerini yakalayarak SPA düzeyinde tepki hızı sağlıyor
    • Stimulus, yalnızca gereken alanlara JS davranışı ekleyerek minimum JavaScript yazımıyla etkileşimli arayüzler kurmayı mümkün kılıyor
  • Importmap sayesinde Webpack veya npm olmadan JS kütüphaneleri doğrudan CDN üzerinden çağrılabiliyor
  • Arayüz üretmek için yapay zeka araçlarını kullansa da yaratıcılık ile kodun sanatsallığı arasında bir ikilem yaşadığını da belirtiyor

Geliştirme iş akışı ve üretkenlik

  • Rails'in “yapılandırmadan çok gelenekler (Convention over Configuration)” yaklaşımıyla model, routing, controller ve view katmanları hızlıca kurulabiliyor
    • Örnek olarak Tag modeli oluşturma, RESTful routing'in otomatikleştirilmesi ve JSON yanıtlarının işlenmesi gösteriliyor
  • ERB şablonları ve live reload ile hızlı prototipleme yapılabiliyor
  • Zengin gem ekosistemi sayesinde CSV, PDF gibi çeşitli işlevler kolayca entegre edilebiliyor

Backend iyileştirmeleri: Solid* serisi ve SQLite

  • Solid Cache/Queue/Cable, Rails 8'e varsayılan olarak dahil edildi; böylece Redis olmadan cache, iş kuyruğu ve WebSocket işlemleri yürütülebiliyor
    • Solid Cache, veritabanı tabanlı cache ile RAM kullanımını azaltıp yapıyı sadeleştiriyor
    • Solid Queue, veritabanı tabanlı arka plan işlerini yönetiyor ve yalnızca SOLID_QUEUE_IN_PUMA=1 ayarıyla çalıştırılabiliyor
    • Solid Cable, veritabanı tabanlı bir Action Cable adaptörü olarak gerçek zamanlı özellikler sağlıyor
  • SQLite için database.yml içindeki pragmas: ayarlarıyla WAL modu ve NORMAL senkronizasyon gibi optimizasyonlar varsayılan olarak uygulanıyor
    • Ayrı bir veritabanı sunucusu olmadan da küçük ölçekli production ortamlarında pratik kullanım mümkün

Dağıtım otomasyonu ve Kamal

  • Geçmişteki Capistrano ve Ansible tabanlı dağıtımların karmaşıklığından söz ederek Kamal'ı Rails 8'in varsayılan dağıtım aracı olarak tanıtıyor
    • Konteyner build → push → sunucuya dağıtım → health check → kesintisiz geçiş sürecini otomatikleştiriyor
    • kamal-proxy, trafik geçişi ve SSL işlemlerini üstleniyor
    • .kamal/secrets dosyasıyla ortam değişkeni tabanlı güvenli secret yönetimi sağlanıyor
  • GitLab CI ile entegre edildiğinde yalnızca git push ile dağıtım yapılabiliyor; bu da eski Heroku sadeliğini yeniden yaşatıyor

Kimlik doğrulama ve diğer özellikler

  • Rails 8, yerleşik kimlik doğrulama üreticisi (auth generator) sunarak Devise'dan daha sade bir kimlik doğrulama sistemi kurmayı mümkün kılıyor
  • Devise, zengin özellikleri ve dokümantasyonuyla hâlâ yararlı olsa da Rails'in varsayılan kimlik doğrulamasındaki sadelik de çekici bulunuyor

Rails ekosisteminin bugünü ve sürekliliği

  • Ruby ve Rails'in popülaritesi azalmış olsa da Shopify, Basecamp, SoundCloud ve GitHub gibi önemli servislerde hâlâ kullanılıyor
  • Birçok gem bakım aşamasında olsa da Rails her yıl düzenli sürüm döngüsünü sürdürüyor
  • “Yeni geliştirici akışı azalmış olsa da hâlâ keyifle geliştirme yapılabilecek bir framework” olarak değerlendiriliyor

Sonuç

  • Rails, son trendlerden uzak kalsa da geliştirme keyfi ve sadeliği yeniden kazandıran bir araç olarak öne çıkıyor
  • Popülerlikten çok üretme keyfi ve yaratıcılığı önemseyerek, “bir kez daha Rails'i dene” mesajıyla yazı sona eriyor

4 yorum

 
joyfui 2026-03-14

Rails ise bunun "konfigürasyon yerine teamül" olduğunu hatırlıyorum, "teamül yerine konfigürasyon" değil...

 
savvykang 2026-03-14

> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails tüm bunları bir kenara attı ve “configuration yerine convention” anlayışını tanıttı.

Görünüşe göre LLM, sözcük sırasını değiştirmeden girdiyi olduğu gibi çıktılamış. Orijinal metinde doğru şekilde yer alıyor.

 
xguru 2026-03-14

LLM bunu yanlış yapmış. Düzelttim. Teşekkürler.

 
GN⁺ 2026-03-13
Hacker News yorumları
  • Rails’i gerçekten çok seviyorum, ancak büyük ölçekli dinamik olmayan tipli kod tabanlarında çalıştıktan sonra kişisel projeler dışında Rails’e geri dönmek zor geliyor
    Tiplendirme olmayan büyük kod tabanları, RubyMine gibi güçlü bir IDE olsa bile bakım açısından tam bir kâbus
    Bu günlerde Sorbet’in ne kadar geliştiğini, özellikle de RoR ile ne kadar uyumlu olduğunu merak ediyorum

    • Bu aralar en ilginç framework’ün Rust/Loco olduğunu düşünüyorum
      Rails felsefesini iyi takip ederken Rust öğrenimini de kolaylaştırıyor
    • IHP ise Haskell tabanlı, Rails’ten ilham alan bir framework; iki dünyanın avantajlarını birleştirmeye çalışıyor
      Hafta sonu denemeye değer
    • Sorun sadece tip eksikliği değil; fonksiyonların ve özelliklerin çalışma anında tanımlanması yüzünden debug etmek neredeyse imkânsız
      Gerçek prodüksiyon verisini lokale kopyalamak ya da sunucuya SSH ile bağlanıp REPL üzerinden durumu incelemek gerekiyor
      IDE içinde debug etmek cehennem gibi bir deneyimdi
      Ruby’yi gerçekten seviyordum ama canlı debug sürecini yaşadıktan sonra zor gelmeye başladı
    • Büyük ölçekli dinamik olmayan tipli kod tabanlarının neden bu kadar kâbus gibi olduğunu merak ediyorum
    • Bu günlerde agentic coding sayesinde dilin ya da framework’ün önemi giderek azalıyor
      Artık özellikle Ruby ya da Python seçmek için güçlü bir neden yok
      Python, ML alanında biraz daha dayanır ama sonunda ortadan kalkacak gibi geliyor
  • Ben de bu düşüncelerin açıkça söylenmesine sevindim
    Son zamanlarda aşırı mikroservis mimarisinden yoruldum
    Akşamları gereksiz yapı olmadan, sorunu doğrudan çözen projelerle uğraşıyorum
    Eskiden çok fazla PHP yapısı ile çalıştım ama Rails de PHP de sonuçta sadece problem çözme araçları

    • Yılın başından beri yeni bir projede RoR kullanıyorum ve gerçekten temiz hava gibi bir deneyim
      Eski masaüstü IDE geliştirmelerinde olduğu gibi her şeyin “kutunun içinde” çalıştığını hissettiriyor
      Web geliştirmedeki karmaşık bileşen yönetiminden uzaklaşıp yeniden üretkenlik odaklı sadeliğe kavuşmuş gibiyim
      Ayrıca TypeScript kullanmak zorunda olmamak harika. Bence TypeScript uzun ve gereksiz boilerplate yığını
    • STOA’nın ne anlama geldiğini merak ediyorum
    • “Düşünce ile kod arasındaki çevirinin en aza inmesi” sözü bana Ruby’nin özünü çok iyi anlatıyor gibi geliyor
  • Biz 2007’den beri Rails uygulamalarını prodüksiyonda çalıştırıyoruz
    Rails’in uzun ömürlülüğünün sırrı yaşı değil, istikrarı ve pragmatikliği
    Backend’de JavaScript kullanmanın verimliliği artırdığı iddiası artık çürütüldü
    Teknoloji yığını değişimlerinin çoğu gerçek mühendislik gereksinimlerinden değil, özgeçmiş optimizasyonu ya da trend kaygısından kaynaklanıyor
    Rails sessizce gerçek işletmeleri çalıştırmaya devam etti
    NPM’in 3,1 milyon paketinin RubyGems’in 190 bin paketinden daha fazla işlev sunduğunu kimsenin düşündüğünü sanmıyorum

    • Biz de 2011’den beri iki şirkette Rails’i prodüksiyonda kullanıyoruz
      Inertia + Vue.js’e geçiyoruz ve bu kombinasyon o kadar güçlü ki backend’de neredeyse hiç değişiklik gerekmiyor
      Üretkenlik artışı sayesinde işe alım zorluğu da dengeleniyor
    • NPM’de daha fazla paket olması daha fazla kullanıcı olduğu anlamına gelir
      Kullanıcı sayısı arttıkça ekosistem daha sağlıklı olur
      Ama RubyGems’te de çok eski paketler var, bu yüzden doğrudan karşılaştırmak zor bence
  • RoR ya da Django’nun “bataryalar dahil” felsefesi güzel ama eski projelerin bakımı çok zaman alıyor
    5-6 yıllık bir projeyi güncellemek istediğinizde bağımlılık yönetimi büyük yük oluyor
    Bu yüzden artık Go ile basit framework’leri kullanmayı ya da tamamen frameworksüz geliştirmeyi tercih ediyorum

    • Ben 300 bin satırdan fazla Django kod tabanı yönetiyorum ve doğrudan bağımlılıklarım sadece 32 tane
      Sadece gerçekten gerekli kütüphaneleri kullanırsanız bakım kolay oluyor
    • Sorun sanırım sürekli değişim (churn)
      Güvenlik yamaları dışında neden güncelleme yapmak gerektiğini sorguluyorum
    • Laravel’de bu tür sorunları neredeyse hiç yaşamıyorum
      Son bir buçuk yılda 5 büyük sürüm yükselttim ve buna rağmen nispeten kolaydı
    • Sonuçta bakım zorluğu bağımlılık yönetimi stratejisine göre değişiyor
      Başta dikkatli kurarsanız uzun süre neredeyse hiç dokunmanız gerekmez
    • “Bataryalar dahil” yaklaşımının aslında yükseltmeleri zorlaştırıp zorlaştırmadığını merak ediyorum. Ben tersine olacağını düşünüyorum
  • Bence yükseltme deneyimi yeterince değer görmüyor
    Next.js’de her büyük sürümde yapı tamamen değişirken Rails’te kademeli kullanım dışı bırakma (deprecation) döngüsü daha yavaş, dolayısıyla çok daha istikrarlı
    Ürünü sürekli yayına alırken en yeni paradigmalardan çok arayüz istikrarı önemli oluyor

    • Bunu gerçekten ancak Rails’i uzun süre çalıştırmış olanlar anlar
      Next.js’in pages → app router geçişi fiilen tam bir yeniden platformlama düzeyinde değişimdi
      Rails’te ise belgelenmiş yükseltme yolları ve öngörülebilir kullanım dışı bırakma döngüleri var
      Ruby sürüm yönetimi de rbenv/asdf sayesinde ortam uyumsuzluğu sorunlarını neredeyse ortadan kaldırıyor
    • Next’in app router geçişi yapısal bir kırılma olduğundan, bu aşamada TanStack Start gibi daha az görüş dayatan alternatiflere bakmaya değer
  • 10 yıldan uzun süredir Rails ile DevOps’tan tek kişilik web geliştiriciliğine kadar her şeyi yaptım ve tekrar başlasam yine aynı seçimi yapardım
    Rails her şeyi sunan temiz ve üretken bir framework
    Stack Overflow anketlerinde hâlâ “bir sonraki projede kullanmak istenen stack Top 5” içinde yer aldı

    • Rails’in “tek kişilik framework” yapısı gerçekten çok çekici
      Altyapı kurulumuyla neredeyse hiç uğraşmanız gerekmiyor ve deploy da kolay
    • Rails ile gerçekten çalışan insanlar anketlere katılma ihtiyacı duymuyor olabilir
      Sonuçta önemli olan başkalarının ne düşündüğü değil, kendinize uygun aracı kullanmak
    • Rails 2004’te çıktı; yani artık 20 yılı aşkın bir framework
      Django’dan bir yıl daha eski
    • Stack Overflow 2025 anketinde Rails, web framework’leri için “Admired vs Desired” kategorisinde 10. sırada yer aldı
      Anket bağlantısı
  • Eskiden Ruby/Rails’in çoğu problem için en iyi çözüm olduğunu düşünürdüm; bugün de hâlâ öyle düşünüyorum

  • Rails’i hiç kullanmadım ama günümüzün karmaşık web geliştirme ortamı konusundaki görüşlere katılıyorum
    Bu yüzden geleceğe bakarak Elixir ve Phoenix seçtim

    • Son birkaç günde Ruby ile proje yaptığımı söyleyince beş ayrı kişi Elixir önerdi
      Bir sonraki projede mutlaka denemeyi düşünüyorum
      Elixir’de bu kadar çekici olan şeyin ne olduğunu ve ilk başta nelere dikkat etmem gerektiğini merak ediyorum
  • 10 yıl önce İsveç’te büyük bir yayın kuruluşunun streaming frontend’ini Rails ile kurduk
    Heroku üzerinde 1 milyondan fazla eşzamanlı bağlantıyı kaldırdı ve gerçekten çok iyi çalıştı
    Sonrasında streaming altyapısı, API, AI/ML gibi başka alanlara geçtim ama bunun nedeni Rails’in başarısız olması değil, problemin doğasının değişmesiydi
    Rails veri modeli ve iş mantığı merkezli problemlere çok uygun; eşzamanlılık ya da altyapı odaklı problemler içinse başka diller daha uygun
    Ruby hâlâ güzel ve ifade gücü yüksek bir dil olarak özlem uyandırıyor

    • Ben de “probleme uygun aracı seçmek” yaklaşımına katılıyorum
      Ama sevdiğiniz dillere dair kişisel önyargıları tamamen bırakmak zor gibi geliyor
      Bir sonraki projeyi hangi dille yaptığınızı merak ettim
  • Statik tip eksikliğinden yakınanlar için Sorbet gibi harika çözümler var
    Ruby’nin üretkenliğini, statik tiplemeyi ve LSP entegrasyonunu birlikte sunuyor
    Shopify sayesinde Rails tarafında da Sorbet desteği oldukça iyi
    Bu ekosistemi o kadar seviyorum ki hâlâ Rails ile çalışmak isterim
    Yapay zeka araçlarındaki gelişme sayesinde artık sınırın yalnızca hayal gücü olduğunu düşünüyorum

    • Bu aralar yapay zeka alanındaki en büyük gündem OpenClaw
      Bunu kullanarak 7/24 mağaza izleme ve Slack bildirimi yapan bir e-ticaret ajanı yaptım
      Yapay zeka ile ilgili proje yapıyorsanız selzee.com/openclaw’a mutlaka bakmaya değer