2025'te React ve Backbone

• 2010'ların başındaki Backbone ile 2025'teki React karşılaştırılarak, 15 yıllık frontend gelişiminin gerçekte ne kadar ilerlediği tartışılıyor
• React dışarıdan sade ve modern görünse de, içeride karmaşık soyutlama katmanları üzerinden sadeliği taklit ediyor
• Backbone'da kod daha ayrıntılı olsa da, olay akışı ve DOM manipülasyonu açıkça belirtildiği için yeni başlayan geliştiriciler bile çalışmayı kolayca takip edebiliyor
• React'te durum yönetimi, bağımlılık dizileri ve closure sorunları nedeniyle, iç işleyiş anlaşılmadan hata ayıklamak zor bir yapıya dönüşüyor
• Sonuçta “olay + durum = UI” özünü yeniden hatırlatırken, basit ve hacklenebilir bir yapıya sahip yeni bir modele ihtiyaç olduğunu öne sürüyor

---

15 yıllık ilerleme

• Biri 2010'lar framework'ü (Backbone), diğeri ise 10 yılı aşkın süredir gelişen React ile yazılmış parola giriş alanı örneği
  • İki kod uygulamasının uzunluğu da benzer, işlevi de aynı
  • React, sayısız geliştirici saati ve devasa bir ekosistemin desteğini aldı
  • Buna rağmen yazar, “React ne kadar iyileşti?” sorusundan çok “ne kadar az ilerlediği”nin daha ilginç olduğunu vurguluyor
• React, görünürdeki sadelik yanılsaması sunuyor; ancak gerçekte karmaşık soyutlamalar yüzünden anlaşılması zor
  • Backbone, olayın oluşması → işleyicinin çalışması → HTML üretimi → DOM'a eklenmesi şeklindeki basit akışı açıkça gösteriyor
  • Buna karşılık React iç işleyişi gizliyor ve basit örneklerin ötesine geçildiğinde yalnızca iç mekanizmaları anlayarak çözülebilen sorunlar ortaya çıkıyor

Sadelik yanılsaması (The Illusion of Simplicity)

• React'te kod temiz görünüyor; ama bu, açık sadelik yerine soyut karmaşıklığın tercih edilmesinin sonucu
  • Backbone ayrıntılı olsa da “ne oluyor, ne zaman oluyor”u net biçimde gösteriyor
  • Yeni başlayan geliştiriciler bile kod akışını kolayca takip edebiliyor
• React'te iç durum ve render mantığı gizlendiği için beklenmedik hatalar sık görülüyor
  • Örneğin liste öğelerinin key değerini indeksle değiştirmek, React'in bunu farklı bir bileşen olarak algılayıp durumu sıfırlamasına yol açabiliyor
  • value değeri undefined olduğunda kontrolsüz → kontrollü bileşen geçişi yaşanıp giriş değerinin sıfırlanması görülebiliyor
• useEffect kullanırken sonsuz döngü oluşması da yaygın bir sorun
  • Bağımlılık dizisinde her render'da yeniden üretilen bir nesne varsa React bunu değişiklik olarak algılıyor
  • Bunu önlemek için useMemo, useCallback ile kimlikleri kararlı hale getirmek gerekiyor
  • Eskiden düşünmeye gerek olmayan kavramlarla uğraşma yükü doğuyor
• Tıklama işleyicisinin eski duruma (stale state) referans vermesi sorunu da var
  • Çünkü fonksiyon, oluşturulduğu andaki durumu yakalıyor
  • Çözüm olarak durumu bağımlılık dizisine eklemek ya da setState(x => x + 1) gibi fonksiyonel güncellemeler kullanmak öneriliyor
  • Ancak her iki yöntem de geçici çözüm (workaround) gibi hissettiriyor

Sihirin bedeli yüksektir (Magic Has a High Price)

• Bu sorunlar istisnai durumlar değil, orta ölçek ve üzeri uygulamalarda sık görülen genel problemler
  • Hata ayıklamak için reconciliation algorithm, render phase, scheduler (batch update) gibi kavramları anlamak gerekiyor
  • React, “neden çalıştığını bilmeseniz de çalışan” bir yapı sunuyor; ama sorun çıktığında çözmek için içini bilmek şart
• Hatta “React'i gerçekten anlamak için onu kendin yazmalısın” denecek kadar karmaşık
  • “Build your own React” gibi eğitimler var
  • Ancak basit bir parola doğrulayıcı yapmak için bile sanal DOM, zamanlama öncelikleri ve eşzamanlı render'ı anlamak gerekmesi eleştirel bir çıkarım sunuyor
• Backbone ve jQuery, dürüst ve hacklenebilir bir yapıya sahip
  • Kaynak koduna doğrudan bakıp değiştirmek mümkün
  • DOM metotları temelli olduğu için anlaması ve genişletmesi kolay
  • Buna karşılık React'in soyutlama katmanları, iç kısımlara erişimi ve bunları değiştirmeyi zorlaştırıyor

Sıradaki adım ne? (So, What's Next?)

• Sonuçta hem React hem de Backbone, “olay + durum = UI” şeklindeki aynı problemi çözmeye çalışıyor
• Büyük ölçekli uygulamalarda React'in karmaşıklığı haklı görülebilir; ancak çoğu küçük ve orta ölçekli uygulama için aşırı bir yük
• Sadelik ve şeffaflık sunan yeni bir UI modeline ihtiyaç var
  • DOM kadar sağlam ama sezgisel bir sistem
  • Backbone ya da jQuery gibi anında anlaşılabilen ve değiştirilebilen bir yapı hedefleniyor

[shakespeares]

Küçük ve orta ölçekli uygulamalarda Backbone ya da JQuery yerine JavaScript Class tasarlamak, bir sonraki aşamaya hazırlanmak için daha doğru bir tutum gibi görünüyor.
JQuery ya da Backbone’daki şablonları yeniden ezberleyerek ilerlemek ise gerileme gibi geliyor.

[GN⁺]

Hacker News görüşü

• Backbone, Angular 1, Ember ve React’in hepsini kullandım
  React’in neden popüler olduğunu gözden kaçırmamak gerek. Bileşen bileşimi, olay işleme, durum yönetimi, verimli DOM güncellemeleri gibi alanlarda React, önceki framework’lerin kronik sorunlarını çözdü
  Backbone’da DOM yaşam döngüsünü yönetmek karmaşıktı ve olay işleyicilerini string olarak belirtmek gerektiği için bakım zordu. React bunları tek yönlü durum akışı ve sanal DOM ile basitleştirdi
  Bugün saf JS kullanmak istesem, Backbone yerine lit-html gibi bir şablon çözümünün çok daha iyi olduğunu düşünürüm

  • Örneğin gerçekçi olmadığını düşünüyorum. Karşılaştırma yapılacaksa TodoMVC iyi bir temsilci. Backbone sürümü için bu kod bakım açısından tam bir kâbus seviyesinde. React sürümü (bağlantı) ise çok daha açık
    Frontend eskiden de karmaşıktı, şimdi de karmaşık ama artık çok daha az acı verici
  • Katılıyorum. React de kusursuz değil ama sonuçta mesele ödünleşim. Hangi aracı kullanırsanız kullanın, o karmaşıklığı geliştiricinin taşıması gerekiyor. Asıl önemli olan doğru ödünleşim noktasını seçip seçmediğimiz
  • Bugünlerde React dışında da bu özellikleri sunan pek çok framework var. Bu React’e özgü bir ayrıcalık değil

• Uygulama karmaşıklığı bileşen sayısından değil, durum yönetiminden gelir
  Backbone Store’un çift yönlü veri akışı yüzünden UI’nin donduğu sorunları sık yaşadım. React’in asıl yeniliği, tek yönlü veri akışı etrafında kurulan Flux mimarisiydi
  İyi bir framework’ün insanı doğal olarak “başarı çukuruna (Pit of Success)” yönlendiren bir araç olduğunu düşünüyorum. React bu rolü iyi oynadı

  • React/Flux/Redux öncesi frontend geliştirme gerçekten tam bir kaostu. 1000 satır bile olmayan kodlarda bile durum yönetimi sorunları patlıyordu
  • Yazının yazarı benim. Tek yönlü veri akışının sorunları çözdüğü doğru, ama React de yeni bir karmaşıklık getirdi
    Örneğin stale closure, sonsuz useEffect döngüleri, key değişimi yüzünden input’un sıfırlanması gibi sorunlar Backbone’da yoktu
    Backbone’un sorunları görünürdü ve debug etmesi kolaydı, ama React’in sorunları soyutlamanın arkasına saklanıyor
    Çoğu uygulama Facebook ölçeğinde olmadığı için, açık ve basit bir yaklaşım aslında daha iyi olabilir
  • Uzun süre Angular kullandıktan sonra React’e döndüm; kusursuz olmasa da React geliştiriciyi doğru yönde kod yazmaya yönlendiriyor
  • Bileşenlerin kendisi de ayrı bir karmaşıklık. İşaretleme, olaylar, iş mantığı ve erişilebilirlik tek bir yerde toplanıp dev bir yapı oluşturuyor. Sonuçta bu sadece konfor uğruna karmaşıklık; sadelik bedava gelmiyor
  • “Tek yönlü veri akışı” aslında DOM’un varsayılan davranışına benzemiyor mu? React ekibinin yaptığı şey Flux, Flow değil

• Popüler bir teknolojiyi doğrudan “kötü” diye damgalamak bir tür saf kibir gibi geliyor
  Elbette popülerlik kalite garantisi değil, ama dünyanın dört bir yanındaki harika mühendislerin hep birlikte kandırıldığını düşünmek de fazla kaçıyor

  • Popüler teknoloji her zaman doğru değildir. MongoDB, Kafka, Microservice modasını düşünmek yeterli
    Büyük şirketler ve pazarlama ittirdiğinde CTO’lar bunu benimsiyor ve ortada kariyer riski varsa kimse “bu pek iyi değil” demiyor. Popülerlik ≠ uygunluk
  • Yazının yazarı benim. “Paleo influencer” benzetmesi ilginç ama yeni olan şey otomatik olarak iyi olmuyor
    React sadece teknik üstünlüğüyle kazanmadı; bunda Facebook’un pazarlaması ve ekosistemin kendi kendini güçlendirmesi de etkiliydi
    15 yıl sonra bile kod uzunluğu ya da karmaşıklık çok azalmış değil. Sadece farklı bir şekilde karmaşık hale geldi
    Geçmişe bakmak nostalji olsun diye değil, orantısız karmaşıklık ekleyip eklemediğimizi sorgulamak için önemli
  • React veya Tailwind’in güçlü yanı işe alım dostu olmaları. Bunun nedeni teknik mükemmellikten çok onboarding kolaylığı
    Web hâlâ bir bakıma tasarım desenlerinin Vahşi Batı’sı gibi. Bunu kabul edince içim rahatladı
  • React’i doğrudan “aptalca” diye damgalamak kibir ve cehaletin karışımı gibi görünüyor. Onu kullanan milyonlarca geliştiricinin bir nedeni var. Tam bir reddiye, Chesterton’s Fence’i yok sayan bir tavır
  • Bu kibirden çok farklı bir bakış açısından gelen deneyim de olabilir. React ekosistemini sevenler de var, fazla JS yüzünden sevmeyenler de
    Sonuçta her projede ödünleşimleri yeniden değerlendirmek gerekiyor

• “Basit işler için React gerekmez” iddiası yaygın bir React yanılgısı (React fallacy)
  React’i basit örneklerle değerlendirmek, “bir dili Hello World uzunluğuna göre değerlendirmek” gibi
  Basit işlerde de React kullanılmasının nedeni, karmaşık işlerde de React kullanılması. Tutarlı bir araç seti bakım açısından avantaj sağlar

  • “Karmaşık işlerde de kullanıyoruz, o yüzden basit işlerde de kullanalım” demek biraz kamyonla market alışverişine gitmek gibi. Sonuçta kritik nokta uygun aracı seçmek

• Backbone “framework gibi görünen ama aslında yapıştırıcı kod yığını olan” bir şeydi
  React’in gerçek zaferi, DOM’u doğrudan manipüle etmeye gerek bırakmaması ve reaktif durum yönetimi sağlaması oldu. Bu ikisi geliştirici verimliliğini ciddi biçimde artırdı

  • Eskiden çok Backbone tutorial’ı yazmış biri olarak biraz nostalji hissediyorum
    Eski tutorial bağlantısı, arşiv sürümü
    Bugünlerde daha çok LLM’lerin kodu nasıl anladığıyla ilgileniyorum. JSX gibi deklaratif sözdizimleri LLM dostu
    Ama useEffect sonrası React, ifade gücü ve açıklık açısından bana daha bulanık geliyor
  • Marionette, Backbone’un boilerplate’inin çoğunu azaltmıştı
  • React’in içinde yerleşik bir durum yönetimi olup olmadığı soruluyor

• React’in neden bu kadar popüler olduğu burada net biçimde görülüyor
  React kodu büyük ölçüde saf JS ve HTML ve özü useState’ten ibaret. Sezgisel olduğu için dokümantasyon olmadan da anlaşılabiliyor
  Backbone, .space-y-2 gibi string selector’lara dayanıyordu ve bu da bakımı cehenneme çeviriyordu. Tek bir class adını değiştirince uygulamanın yarısı bozuluyordu
  React bu sorunu yapısal olarak çözdü

  • “O yazı doğrudan yazılmamış, galiba Claude’a yazdırılmış” diye bir şaka yapılıyor

• Backbone kodunda “ne oluyor ve ne zaman oluyor” daha açık, ama React’te iç işleyişi anlamak gerekiyor
  Ben de React’in çalışma zamanlarını anlamak için Dan Abramov’un useEffect rehberi ile Mark Erikson’ın blogunu defalarca okudum
  Backbone koduna 10 yıl sonra bile baksam hemen anlayabiliyordum

• 6 yıl önce ekibi Backbone’dan Angular’a taşıdık
  Backbone sezgisel ve sihirsiz bir yapı olduğu için junior’lar için iyiydi, ama sonuçta TypeScript ve Angular daha sistematikti
  Şimdi NG20 kullanıyoruz ve memnunuz. Bir gün tarayıcılar daha fazla özelliği varsayılan olarak sunarsa, belki yeniden daha basit yöntemlere dönebiliriz

• Biz her zaman soyutlamaların üzerinde programlama yapıyoruz
  Önemli olan, o soyutlamanın karmaşıklığa kıyasla üretkenlik kazancı sağlayıp sağlamadığı ve güvenilir olup olmadığı
  En kötü senaryoda bile debug edilebilir olması gerekir

• React’te input alanları, Backbone’a göre Undo davranışını daha doğal ele alıyor
  Backbone birer harf geri alırken, React kelime bazında geri alıyor

  • Neden tarayıcının varsayılan davranışını ezmenin daha iyi sayıldığını anlamıyorum. Bana daha çok doğal kaydırmayı bozan JS kütüphaneleri gibi geliyor
  • İlginç şekilde Chrome’da farklı, ama Firefox’ta iki framework de aynı şekilde davranıyor
  • Backbone’un yaklaşımının daha iyi olduğunu düşünüyorum
  • Hangi davranışın “doğru cevap” olduğu sonuçta kişisel tercih meselesi