Rails, Laravel ve Next.js yerine neden Elixir Phoenix’i seçtim

 (akarshc.com)
7 puan yazan GN⁺ 2025-10-18 | 3 yorum | WhatsApp'ta paylaş
  • Phoenix LiveView, hem uygulama hızı hem de geliştirme hızı açısından yüksek verimlilik sunuyor
  • Frontend ve backend’i ayrı ayrı sürdürmek zorunda kalmadan, her şeyi tek bir dille monolitik olarak ele alabilmesi önemli bir avantaj
  • Rails Hotwire ve Laravel Livewire da değerlendirildi, ancak gerçek zamanlılık ve arka plan işleri uygulamasında daha fazla yapılandırma gerektiriyorlar
  • Elixir’in Phoenix framework’ü, Ruby on Rails’in zarafetini korurken çok daha üstün performans sunuyor; Oban ile arka plan işleri yerleşik olarak geliyor ve tanıdık, temiz bir sözdizimi sağlıyor
  • LiveView, WebSocket tabanlı gerçek zamanlı çift yönlü güncellemeler sunuyor; geleneksel sunucu tarafı render ile frontend odaklı framework’ler arasında denge kuruyor ve gerektiğinde Alpine.js ya da JavaScript kütüphaneleri hook’lar aracılığıyla kullanılabiliyor
  • Elixir/Erlang tabanlı hızlı geliştirme, yüksek eşzamanlılık, çoğu şeyi tek dille yazabilme, derleyiciyle hataları önceden yakalama ve hata toleranslı mimari gibi özellikler nihai seçimde belirleyici oldu

Neden Phoenix LiveView’u seçtim

  • Kod yazmanın amacı, sorunları en uygun şekilde çözmektir; benim için en önemli unsurlar da uygulama hızı ve geliştirme verimliliği
  • React veya Next.js’yi Laravel ile ya da Inertia.js’yi Laravel ile kullanınca hem frontend hem backend tarafındaki iki stack’i de birlikte sürdürmek gerekiyor
  • Tek başına çalışan bir geliştirici olarak iki farklı yerde state yönetmeye zamanım yoktu ve her şeyi birlikte ele alabileceğim sağlam bir monolitik çözüme ihtiyacım vardı

  • Alternatif karşılaştırması: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire ve Rails Hotwire, JavaScript’e yoğun şekilde bağımlı olmadan frontend işlerini basitleştiren harika araçlar
    • Tam JavaScript stack’i için Next.js de düşünüldü, ancak backend’de JavaScript kullanmayı tercih etmiyorum
    • Rails Hotwire, özellikle Rails ile MVP’yi hızlıca kurabilme yeteneği nedeniyle dikkat çekiciydi
    • Ancak arka plan işleri, gerçek zamanlı güncellemeler ve çift yönlü iletişim gerekiyordu; bunlar Rails ve Laravel’de de mümkün olsa da daha fazla kurulum emeği istiyordu

  • Elixir, Phoenix ve LiveView’un belirleyici avantajları

    • Elixir ve Phoenix, Ruby on Rails’in zarafetini korurken çok daha yüksek performans sunuyor
    • Oban ile yerleşik arka plan işleri, tanıdık ve okunabilir sözdizimi ile LiveView’un gerçek zamanlı çift yönlü iletişimi en güçlü yanları
    • LiveView, sunucu tarafı render yaklaşımı ile frontend ağırlıklı framework’ler arasında ideal bir denge kuruyor
    • WebSocket üzerinden gerçek zamanlı güncellemeler ve JavaScript kütüphaneleriyle (ör. Alpine.js) entegrasyon mümkün
    • Phoenix, Oban’ın yerleşik gelmesi sayesinde arka plan işi tanımlama ve otomatik kurtarma konusunda kolaylık sağlıyor

  • Elixir/Erlang’ın avantajları

    • Elixir, Erlang üzerinde inşa edilmiş derlenen bir dil; WhatsApp ve Discord gibi büyük ölçekli eşzamanlı sistemlerin temelini oluşturuyor
    • Yüksek eşzamanlılık, hata toleransı ve kesintilerden otomatik toparlanma sağlıyor

Nihai seçimin nedeni

  • Hızlı geliştirme ve yüksek eşzamanlılık desteği
  • Tek bir dille neredeyse her şeyi gerçekleştirebilme
  • Okunabilir kod yazabilme
  • Derleyicinin, production’a ulaşmadan önce çoğu hatayı yakalaması
  • Hata toleranslı mimari sayesinde uygulamanın neredeyse hiç çökmeden kararlılığını koruması

Sonuç ve tavsiye

  • Phoenix, her durumda Rails, Laravel ve Next.js’ten üstün değil
  • Tüm framework’ler harika; her biriyle farklı projelerde kullanım deneyimim oldu
  • Kendi özel durumum ve projem (Hyperzoned.com) için Phoenix en uygun seçimdi
  • Zaten bildiklerinin ötesini keşfetmeye çalışırsan, bir sonraki problemi çözmek için daha iyi ve verimli yollar bulabilirsin
  • Öğrenmeyi bırakma

İlgili okumalar

3 yorum

 
clastneo 2025-10-23

JSP ile aynı nedenle, belli bir seviyeyi aşınca artık kullanılamaz gibi geliyor.
 
GN⁺ 2025-10-18
Hacker News görüşü

  • Rails, Livewire, Phoenix ve React için CKEditor entegrasyonunu bizzat denedim. Bunlar arasında geliştirici deneyimi açısından en etkileyici olan Phoenix'ti. Framework çok iyi tasarlanmış, bu yüzden entegrasyon işi gerçekten çok basitti. Rails ve React'ta, özellikle de Next.js'te, bu memnuniyeti hiç hissetmedim. Next.js'te router değişiklikleri de fazla sık oluyor; sürekli değiştiği için güven vermiyor. Livewire, Phoenix'e benzer bir his veriyor ama görece daha az sezgisel ve özellik bakımından daha zayıf. Örneğin Livewire component slot'larını desteklemiyor, ama Phoenix bunu sorunsuzca hallediyor. Slot olmayınca template yapısı darmadağın oluyor ve kod gereksiz yere karmaşıklaşıyor. Merak eden olursa ckeditor5-phoenix GitHub'ına bakabilir

    • PHP (Laravel) ve jQuery kombinasyonu da 2025'e kadar hâlâ iş görür. Ama kişisel olarak Livewire kullanmak istemem. Node.js üretkenliği düşürebilir ama daha güçlü özellikler gerektiğinde işe yarar. async/await, socket.io, TypeScript hepsini destekliyor. Next.js, hem SEO hem de etkileşimli UI gerektiğinde faydalı ama pratikte bir web sitesinin aynı anda bunların hepsine ne kadar ihtiyacı oluyor ki? Muhtemelen ancak LinkedIn benzeri servislerde geçerlidir

    • Livewire'ın Phoenix kopyası olduğunu düşünmüyorum. İsme bakınca öyle gibi duruyor ama bildiğim kadarıyla iki proje de neredeyse aynı anda başladı ve Livewire hatta daha eski bir proje. Hotwire ise bunların içinde en son çıkan. İki proje farklı yaklaşımlar benimsiyor; zaten PHP ile Elixir'nin doğası da çok farklı. Bence Livewire da oldukça kullanışlı. PHP'de WebSocket'i rahat kullanmak kolay olmadığı için daha çok HTTP merkezli çalışıyor ama çoğu durumda bu da yeterli. Hatta LiveView'nun WebSocket kullanımı fazla bile olabilir

    • Rails'te yaşadığın sorunları daha somut duymayı isterim. Hangi kısımlar zordu?

    • Rails kullanırken seni zorlayan şeylerin ne olduğunu merak ediyorum

    • Livewire 4'te component slot desteği planlanıyor. Ama daha birkaç hafta var. Yeni sürümde performans ve geliştirici ergonomisi iyileştirmeleri de olacağı söyleniyor

  • Bu yazı, yazarın kendi seçtiği framework'ü savunup diğer framework'lerin özelliklerini bilerek görmezden geldiği bir yazı gibi duruyor. Phoenix'in avantajı diye anlatılan şeylerin hepsi Rails'te de var. Ayrıca yazı, Rails'in frontend ile WebSocket üzerinden iletişimi desteklemediği izlenimini veriyor ama son 3 yılda Rails ile uygulama yapmış biri için bu tamamen yanlış. Elbette Phoenix ve LiveView da iyi araçlar, bunda şüphe yok, ama benim Rails kullanmaya devam etme sebebim Hotwire Native. Hem mobil hem web uygulamasını kısa sürede tek başıma çıkarabilmek üretkenlik açısından çok büyük avantaj

    • Ruby'yi pek kullanmadım ama topluluk dışında Ruby on Rails'in Elixir & Phoenix'e göre hangi yönlerinin üstün olduğunu merak ediyorum. BEAM sayesinde soft real-time sistemler, hata toleransı, NIF'ler, actor model, çok sayıda hafif process, düşünmesi kolay concurrency, functional programming, OTP, kesintisiz GC gibi konularda Phoenix'in teoride çok daha iyi olduğunu düşünüyorum. Tabii herkes sevdiğini kullanır; ben de Hotwire Native'i denemeyi planlıyorum

    • Rails'in frontend ile WebSocket üzerinden konuşabildiği açık. Ben de Rails geliştiricisiyim ama çok sayıda sürekli socket bağlantısı gerekecekse Phoenix'i seçerdim. Phoenix, Gigalixir gibi servislerde 100 bin bağlantıyı çok daha ucuza ve kolayca kaldırabiliyor. Altyapıyı kendin yönetiyorsan tablo değişir. Ama Heroku'da birkaç bin bağlantı bile zor ve maliyetli

    • Yazıda Rails'in frontend ile WebSocket iletişimini desteklemediğinin nerede söylendiğini merak ediyorum. Asıl metinde yalnızca "Rails ve Laravel'de de yapılabiliyor ama kurulum biraz daha zaman alıyor" deniyor. Bu tamamen farklı bir ton

    • Rails + Hotwire kombinasyonu da gerçekten çok güçlü; Hotwire Native eklenince daha da iyi oluyor. Yazının ana fikri Phoenix ve LiveView'nun mutlak olarak daha iyi olduğu değil, LiveView mimarisinin (sunucu güdümlü state, process ayrımı, hafif channel'lar vb.) belirli durumlarda daha uygun olması. İki ekosistem de benzer problemleri farklı şekillerde çözüyor. Rails convention ve progressive enhancement ile yaklaşıyor, Phoenix ise BEAM'in concurrency ve hata toleransı ile. Sonuçta önemli olan, hangi mimarinin yaptığın ürüne daha iyi uyduğu

    • Hotwire Native'i eskiden duymuştum ama sonra haberleri azaldı gibi. Gerçek mobil uygulamada kullananların deneyimi, destek ve dokümantasyon durumu, uygulama olgunluğu ilgimi çekiyor

  • Ben de Elixir konusunda yazar kadar olmasa da oldukça olumlu hissediyorum ama CTO olarak 3 yıl production'da kullandıktan sonra, ölçek büyüdükçe hayal kırıklıkları da arttı. BEAM (concurrency, fault tolerance) vaat ettiklerini yerine getirdi; Ecto, Oban, remote iex, yetenek havuzu da çok iyiydi. Ama geliştirici deneyimi zamanla darboğaz oldu. 300 bin satırlık büyük bir projede şu sorunları yaşadık:

    • Derleme süresi: Kodda tek satır değişse bile geliştirme ortamında 10 saniyeden uzun compile sürmesi akışı sürekli bölüyordu
    • Tooling: ElixirLS autocomplete güvenilir değildi; fonksiyon adları ya da schema alanlarını aramak için zaman harcıyorduk
    • LiveView: Karmaşık UI'lar için uygun değildi, bu yüzden mecburen React tabanlı bir frontend ekledik ve sonunda GraphQL ile bölünmüş stack karmaşıklığı geri geldi
      Uzun vadede kullanacağın stack'i düşünüyorsan 3 yıllık Retrospective'i okumak faydalı olabilir

    • Elixir'de geliştirme ortamında tek bir derlemenin 10 saniyeyi aşması beni çok şaşırttı. Elixir'nin Rails'e göre yalnızca avantajları olduğunu duyuyordum; gerçek iş ortamında bunun ne kadar yaygın olduğunu merak ediyorum

    • Elixir öğrenirken ben de benzer bir deneyim yaşadım. Dili sevdim ama Windows'ta WSL ile çalışırken LSP sık sık bozuluyordu ve rahatsız ediciydi. resmî LSP'nin yakında çıkması bekleniyor; umarım bu alan ciddi biçimde iyileşir

    • LiveView ya da React gibi frontend'ler iyi yönetilmezse büyük uygulamalarda kod çok hızlı dağınık hale geliyor. Ekip büyüdükçe code review ve gereksiz mantığı temizleme işi şart oluyor. Sanırım bu tüm framework'ler için geçerli. Burada hâlâ çok fazla gelişim alanı var

  • "Background job'ları, gerçek zamanlı güncellemeleri ve çift yönlü iletişimi hafifçe desteklemek Rails ve Laravel'de de biraz ayar ekleyerek mümkün" deniyor ama Rails, Solid Queue (job) ve Solid Cable (gerçek zamanlı mesajlaşma) desteğini zaten varsayılan olarak sunuyor

    • Kısa süre önce Rails'e geçmiş biri olarak söyleyebilirim ki SolidQueue gerçekten sadece temel ayarla hemen kullanılabiliyor. Solid Queue Dashboard'u da eklersen tüm durumu tek bakışta görmek mümkün

    • Yalnız gerçek zamanlı mesajlaşma açısından bakınca Solid Cable kurulumu bana LiveView'dan daha uğraştırıcı geliyor. LiveView render işini de kendisi üstlendiği için, Rails'teki SolidCable geliştirmesinin oldukça önünde olduğunu düşünüyorum

    • Her şey Rails ile de yapılabilir. Çok güzel bir framework, ama Phoenix ile daha kolay ve daha keyifli oluyor. Kesinlikle en az bir kez denemeni öneririm

    • Hem Rails hem Elixir'yi iş ortamında kullanmış biri olarak söyleyeyim: Bu iki sistem kesinlikle eşdeğer değil. Oban'ın kullanımı net ve tekrar çalıştırma için sadece DB sütunlarını güncellemen yeterli; gerisini Oban supervisor hallediyor. Solid Queue'da başarılı olmuş bir job'ı yeniden çalıştırmanın kolay bir yolu yok. Tablo sayısı da fazla, yönetmesi zor. Oban yalnızca iki tabloyla basitçe yönetiliyor ve aynı uygulama içinde doğal biçimde çalışıyor; Solid Queue ise düzgün çalışsın diye çeşitli blog'lardan ayar toplayıp değiştirmeyi gerektiriyor. Varsayılan ayarları yetersiz. Erlang/Elixir'nin doğası sayesinde Oban çok basit olup harika çalışabiliyor ve bu geliştirici olarak insana keyif veriyor. Ben de Solid Queue'yu mecburen kullanıyorum

  • Uzun yıllar Rails geliştirdikten sonra bugünlerde temel stack'im Phoenix/Elixir oldu. Rails hâlâ CRUD uygulamalarını hızlı üretmekte gerçekten en iyilerden biri; bu alanda açık ara güçlü. Ama karmaşıklık arttıkça ve zaman geçtikçe Phoenix/Elixir genel olarak daha iyi bir araç haline geliyor

    • LLM'lerin çıkışıyla bu tür basit uygulamalar artık birkaç dakikada üretilebiliyor. Ama gerçekten dikkat edilmesi gereken ana kısımlarda Phoenix'in daha fazla kontrol verdiğini hissediyorum

    • Hangi yönlerden daha iyi uyduğunu, nelerin daha üstün geldiğini biraz daha somut anlatabilir misin?

  • "Sorunları en iyi şekilde çözmek için kod yazarız" cümlesinde ciddi bir tutku hissediliyor. Ben ise sorun çözüldüğünde makul ölçüde tatmin olan taraftayım; o yüzden Rails'te kalmak bana daha uygun gibi geliyor

    • O cümleyi görünce kahkaha attım. Gerçekçi olmak gerekirse sadece optimizasyon düşünerek kod yazarsan işler eninde sonunda yavaş ilerler. Benim için kod yazmak hem geçim kaynağı hem de bazen eğlence

  • Elixir'nin topluluğu küçük denir ama son derece ileri kütüphanelerle oldukça yüksek bir seviyeyi hedefliyor. Eski bir geliştiricinin söylediği "daha azsa daha iyidir" sözü aklıma geliyor. elixir-dbvisor/sql gibi çok iyi açık kaynaklar var

    • Tersine, JS ekosistemi bana büyüklüğü yüzünden yorucu geliyor. On tane kütüphane birbirinden bağımsız biçimde duruyor ve kimse bir standardı izlemiyor. Bir bakıma ABD'deki dev marketlerde menü seçmeye ya da Vercel zinciri bir restoranda zorla seçim yapmaya benziyor

  • Elixir'nin gerçek gücünü hissetmek istiyorsan Saša Jurić'in tüm konuşmalarını izlemeni öneririm

    • Saša Jurić, 'Elixir in Action' kitabının yazarı; kitap da gerçekten çok iyi

  • Bu yazı, framework'ün tamamından çok Phoenix LiveView'ya odaklanıyor. Aslında Phoenix'te LiveView'yu oluşturma seçeneklerinden çıkarsan bile etrafta varsayılan LV kodunun kalmasından hoşlanmıyorum

    • Ben de LiveView'nun çok opinionated ve bol boilerplate'li olduğu görüşüne katılıyorum. Elixir'nin sadeliğini ve ifade gücünü seviyorum ama LiveView bana bunun tersi gibi geliyor

  • Elixir'yi seçmememin tek nedeni type checker eksikliğiydi. Bu konuda bir değişiklik olup olmadığını merak ediyorum
 
colus001 2025-10-18

Livewire'ın eğlenceli olduğu doğru ama UI biraz karmaşıklaşınca cehenneme dönüyor. O andan itibaren Phoenix avantajlarını hızla kaybediyor. Döngü uzadıkça iş zorlaştığı için ben pek tavsiye edemiyorum.