- Günümüzde React benimsenmesi teknik üstünlükten değil, varsayılan seçim olmasından kaynaklanıyor ve bu da frontend ekosistemindeki inovasyonu yavaşlatıyor
- Birçok ekip kısıtları değerlendirmeden “herkesin bildiği React”i seçerken, ağ etkileri mimari kararları teknik uygunluktan daha fazla belirler hale geliyor
- Svelte, Solid, Qwik gibi yenilikçi framework’ler daha iyi performans modelleri sunsa da, düşük benimsenme oranları nedeniyle ana akım rekabette geri planda kalıyor
- React’ın birçok güçlü yanı var, ancak asıl sorun React-varsayılan düşünce biçiminin fırsat maliyetini büyütmesi ve daha iyi alternatiflerin değerlendirilmesini engellemesi
- Sağlıklı bir ekosistem için çeşitlilik ve rekabet gerekiyor; mesaj şu: framework’ler varsayılan olarak değil, kısıtlar ve uygunluk temelinde seçilmeli
React’ın varsayılan zaferi ve sınırları
- React artık teknik üstünlüğü nedeniyle değil, çoğu zaman varsayılan olarak benimsendiği için seçiliyor
- Bu da ekiplerin proje kısıtlarını değerlendirmeden otomatik olarak React kullanma alışkanlığını güçlendiriyor
- Alternatif framework’ler (Svelte, Solid, Qwik), belirli senaryolarda React’tan daha avantajlı performans sunsa da gerektiği gibi değerlendirilmiyor
- Sorun React’ın kendisinden çok, React-varsayılan düşünce biçiminin inovasyonu engelleyen bir yapı üretmesi
İnovasyon tavanı
- React’ın Virtual DOM yaklaşımı 2013’te uygun olabilirken, bugün gereksiz bir ek yük haline gelebiliyor
- Hooks, class component’lerin sorunlarını çözdü ama dependency array ve stale closure gibi yeni karmaşıklıklar getirdi
- Server Components ve React Compiler performansı iyileştirmeye çalışsa da, bunlar React modelinin kısıtlarını dolanmak için kullanılan çözümler
- Buna karşılık Svelte’in Runes’u, Solid’in ince taneli reaktivitesi, Qwik’in Resumability yaklaşımı tamamen farklı modellerle daha yüksek bir potansiyel gösteriyor
Teknik borç
- React’ı varsayılan seçim olarak almak, gereksiz runtime maliyeti ve rerender yönetimi yükü doğuruyor
- Geliştiriciler iş değerine odaklanmak yerine effect bağımlılıkları ya da hydration yönetimiyle zaman harcıyor
- Benchmark’larda Solid, React’tan 2-3 kat daha hızlı güncelleme performansı gösteriyor
- React kalıpları merkezli düşünme, web’in temel prensiplerini zayıflatıyor ve mimari ataleti derinleştiriyor
Alternatif framework’ler
-
Svelte: derleyici devrimi
- Svelte işin büyük bölümünü compile time aşamasında halleder ve virtual DOM’u ortadan kaldırır
- Component’ler web’in temel yapısına daha yakın hale gelir ve çalışma zamanı ek yükü ciddi ölçüde azalır
- Ancak “iş fırsatı az” algısı nedeniyle benimsenme oranı düşüktür
- The Guardian, Wired, Shawn Wang gibi çeşitli örnekler, Svelte’e geçildikten sonra bundle boyutunun ve yükleme süresinin ciddi biçimde azaldığını, geliştirici verimliliğinin arttığını gösteriyor
- Örneğin Shawn Wang, React’ta 187KB olan site boyutunu Svelte ile 9KB’ye indirdi
-
Solid: ince taneli reaktiviteye yalın yaklaşım
- Solid, ince taneli reaktiviteyi JSX sözdizimiyle birleştirerek sunar
- Signal’lar üzerinden yalnızca değişen DOM’a doğrudan erişir ve reconciliation darboğazını tamamen aşar
- Olağanüstü performans ve sade state management güçlü yanları arasındadır
- Benimsenme örnekleri hâlâ sınırlı olsa da, erken dönemde kullanan ekiplerin deneyimleri verimlilik ve kod sadeliğinde büyük sıçramalara işaret ediyor
-
Qwik: Resumability inovasyonu
- Qwik, traditional hydration yerine resumability ile anında startup avantajı sunar
- Yalnızca o anda gerekli olan işlevler kademeli olarak yüklenir; hem state hem de kod serialize edilebilir
- Büyük sitelerde, uzun oturumlarda ve yavaş ağlarda çok güçlü sonuçlar verir
- Henüz çok sayıda ekip denememiş olsa da, kullanan ekipler ilk yükleme süresi ve kaynak verimliliğinde büyük iyileşmeler bildiriyor
-
React API’sinin karmaşıklığı ve alternatif framework’lerin sadeliği
- React API’si hook, context, reducer, memoization gibi karmaşık kavramlar içerdiğinden geliştiricinin bilişsel yükünü artırır
- Yanlış kullanıldığında bağımlılık sorunlarından kaynaklanan bug’lar ya da aşırı tasarım yükü ortaya çıkabilir
- Örneğin, Cloudflare’in 12 Eylül 2025 tarihli kesintisinin nedeni de
useEffectiçindeki dependency array ayar hatasıydı - Buna karşılık Svelte, Solid ve Qwik gibi alternatifler çok daha küçük ve odaklı API’lerle sadelik ve web’in temel ilkelerini öne çıkarır
- Bu üç framework de teknik açıdan yeterli üstünlüğe sahip olsa da, React’ın varsayılan kültürü nedeniyle çoğu zaman deney aşamasına bile gelemeden eleniyor
Ağ etkilerinin hapishanesi
- React hâkimiyeti, kendi kendini güçlendiren bariyerler oluşturuyor
- İşe alım pazarında yalnızca “React geliştiricisi” aranıyor; organizasyonlarda component library’ler ve geliştirme alışkanlıkları React etrafında katılaşıyor
- Riskten kaçınan liderler doğal olarak güvenli seçenek olan React’ı tercih ediyor, eğitim kurumları da buna göre şekilleniyor
- Bu yapı, sağlıklı rekabetin ortadan kalktığı bir ekosistemin tipik özelliği
Ağ etkisini kırmak
- Bundan çıkmak için bilinçli seçim gerekiyor
- Teknik liderler ataleti bırakıp yapıyı gereksinimlere göre belirlemeli; şirketler de pilot bütçe ayırarak alternatifleri deneyebilmeli
- Geliştiriciler de tek bir paradigma üzerinde ısrar etmek yerine farklı framework anlayışlarını öğrenmeli
- Eğitim kurumları framework-agnostic kavramlara daha fazla yer vermeli, açık kaynak katkıcıları da daha küçük ekosistemleri destekleyebilmeli
Değişim kendiliğinden gelmez; bilinçli olarak inşa edilmelidir.
Framework değerlendirme kontrol listesi
Yeni bir projede aşağıdakiler değerlendirme ölçütü olabilir
- Performans gereksinimleri: ilk yükleme, güncelleme verimliliği, bundle boyutu ve compile time optimizasyonu olup olmadığı
- Ekip yetkinliği ve öğrenme eğrisi: mevcut deneyim dikkate alınmalı; Solid gibi React’a uyumlu alternatifler de vardır
- Ölçeklenebilirlik ve sahip olma maliyeti: bakım, bağımlılık yönetimi ve teknik borç dahil uzun vadeli maliyetler değerlendirilmelidir
- Ekosistem uyumu: olgunluk ile yenilik arasında denge; çekirdek olmayan işlerde pilot denemeler ve ROI testleri yapılabilir
Yaygın itirazlar ve yanıtlar
- Ekosistem olgunluğu: Yaşlı bir ekosistem bugün karşılaşılan sorunlara zorunlu olarak daha uygun değildir. Üçüncü taraf paketlere yüksek bağımlılık; bakım yükü, güvenlik açıkları ve şişen bundle boyutları gibi yan etkiler doğurabilir. Daha küçük ekosistemler ise web’in temellerine daha fazla odaklanabilir; ayrıca yapay zeka araçlarının gelişimi sayesinde özel çözümler daha kolay ve hızlı geliştirilebilir.
- İşe alım sorunu: Talep, işe alım kriterini belirler. Çekirdek olmayan alanlarda alternatifler test edilip sahada öğrenmeyle eksik yetkinlikler kapatılabilir.
- Component library’ler: Framework bağımsız design system’lar ve Web Component kullanımıyla lock-in azaltılırken üretkenlik korunabilir.
- Kararlılık: React da hooks, Server Components gibi alanlarda sürekli değişiyor. Alternatif framework’ler çoğu zaman daha tutarlı API’ler sunabiliyor.
- Büyük ölçekli örneklerle doğrulama gerekliliği: Bir zamanlar jQuery de küresel ölçekte örnek gösteriliyordu. Geçmiş başarıların gelecekte de geçerli olacağının garantisi yok.
Ekosistem ve sektör geneline etkileri
- React tek kültürü, web’in gelişimini doğrudan yavaşlatıyor
- Yetenek ve sermaye yalnızca React sorunlarını çözmeye yöneliyor; platformun kendine özgü inovasyonları gecikiyor
- Eğitim kurumları da hemen işe yerleşmeye odaklı müfredat nedeniyle taşınabilir olmayan becerileri daha fazla öğretiyor
- Platformun (web’in) kendi gelişimi, “React varsa yeter” anlayışıyla tıkanıyor; ekosistemde çeşitlilik eksikliği uzun vadede herkese zarar veriyor
Birlikte kurabileceğimiz daha sağlıklı ekosistem
- Çeşitlilik, sağlıklı bir ekosistemin vazgeçilmez koşuludur
- Farklı paradigmalar rekabet edip etkileşime girdiğinde inovasyon ortaya çıkar
- Geliştiriciler farklı düşünme biçimlerini öğrenerek büyür; web platformunun kendisi de bu çeşitlilikteki meydan okumalar sayesinde gelişir
- Tek bir framework’e tamamen yüklenmek, tekil bir arıza noktası yaratır. Sınıra gelindiğinde büyüme durur ve daha iyi fırsatlar da kaybolur
- Her projede seçim, teknik kısıtlar ve uygunluk temelinde yapılmalı; yalnızca React varsayılanına dayanmak doğru değildir
- Gerçek inovasyonu ancak çeşitlilik garanti eder
- Artık herkesin aynı “tohumu” (React) ekmesi yerine, daha çeşitli framework deneyleriyle web ekosistemini daha dayanıklı ve daha yenilikçi hale getirmeye katkı sunmanın zamanı geldi
- Seçim bizim elimizde
19 yorum
Junior geliştiricilerin React'i seçmesi kaçınılmaz olabilir, ancak kıdemli geliştiricilerin diğer alternatifler üzerine düşünmeyi bırakması sorun.
React ya da Java, çok daha iyi alternatiflerin zaten bol olduğu eski çağlardan kalma çöpler olmasına rağmen bu kadar uzun süre piyasayı götürmeleri gerçekten doğru lol
Deneyler, önceki büyük kaotik framework döneminde fazlasıyla yapıldı...
İş tarafında, mevcutta kullanılan şeyi baştan aşağı değiştirmeye gerek yok; yeni bir proje olsa bile
hem daha önce iyi çalışan şeyi bırakıp yeniden öğrenerek geçiş yapmaya razı olan çok kişi yok, hem de işe alım tarafında bununla ilgili sorunlar var..
Umarım Solid gerçekten başarılı olur..... React tekelini nasıl kıracağız acaba
Son yaklaşık 10 yılda FE ekosisteminde sayısız araç ortaya çıktı; yükselişler ve çöküşlerin ardından ancak şimdi bir ölçüde istikrar sağlanmışken, bir kez daha böyle büyük bir kaosu denemeyi istemek...
Bu yazı fazla taraflı değil mi?
"Svelte, Solid ve Qwik gibi yenilikçi framework'ler daha iyi performans modelleri sunuyor, ancak düşük benimsenme oranları nedeniyle ana akım rekabette geride kalıyor"
Eğer "yenilik" kelimesinin anlamını anlamaya yönelik tutarlı bir ölçüt yoksa,
varsayımın kendisi baştan yanlış gibi görünüyor.
Böyle yazıları görünce, sanki ürün yapmaya odaklanmak yerine yazılım mühendisliğine fazla takılıyorlarmış gibi geliyor. Nasıl olsa hepsi aşağı yukarı benzer; önemli olan ürünü iyi yapmak. Ama sürekli yeni framework, yeni mimari peşinde koşup over-engineering yapıyorlar, sonra da bunun daha iyi olduğunu söyleyip yine değiştirelim diyorlar. Bence önemli olan yeninin iyi olması değil, ne olursa olsun onu iyi kullanıp ürünü ortaya çıkarmak.
Kaçınılmaz; çünkü yerli büyük teknoloji şirketleri React (Next.js) odaklı işe alım yapıyor.
Büyük sayılan
vue.jsiçin bile büyük teknoloji şirketlerinde işe alım yapan çok fazla pozisyon yok.Ekosistemi görmezden gelmek mümkün değil... Son zamanlarda çıkan üçüncü taraf ya da açık kaynak kütüphanelerin çoğu React’i resmî olarak destekliyor, diğer framework’ler ise yalnızca topluluk desteği alıyor; bu yüzden şunu bunu birleştirip kullanmak istediğinizde sonuçta React en güvenli seçenek olmak zorunda kalıyor...
Frontend kadar çeşitli denemelerin yapıldığı başka hangi alan var ki...
React’in Facebook geliştirme ekibinin adanmışlığı sayesinde web uygulaması geliştirme konusunda birçok zorluk aşıldı. Kötü adam değil..
php jquerydönemini sona erdirdi.Hacker News görüşü
Bence React varsayılan haline gelmedi; çok etkili ve iyi tasarlanmış olduğu için fiili standart oldu ve aynı zamanda artık kötü adam rolüne itildi
React’in inovasyonu yavaşlattığı iddiası bana oldukça saçma geliyor
React, sayısız "beni de kat" tarzı framework ve kafa karıştırıcı tasarımlar arasında fiilen tek istikrarlı ve makul seçenek
Buna mütevazı bir şekilde katılmıyorum
Ben hiç React ile karmaşık etkileşimli uygulamalar yapmadım; sadece ekip arkadaşlarımın önceden React seçtiği basit siteleri birkaç kez yaptım
Bunun sonucunda React’in aslında basit sitelerde pek iyi küçülemediğini gördüm
Basit bir giriş sayfası için durumu doğrudan DOM’da tutup yalnızca
<form>kullanarak değerleri göndermek yeterli, şifreyi göster/gizle için de biraz JS kâfiAma bunu React ile yapmak için JSX, hooks, component lifecycle, development build, production packaging gibi öğrenilecek çok şey var
Vue ya da Alpine gibi diğer framework’ler "kademeli" olarak kullanılabiliyor ve yalnızca CDN ile hemen başlanabiliyor
React de kademeli olduğunu iddia ediyor ama JSX’in doğası gereği build-compile süreci zorunlu olduğundan, resmi belgelerde CDN ile doğrudan başlama yöntemi yok
Zorlayınca imkânsız değil ama sonunda derleyiciyi de istemciye göndermeniz gerekiyor, bu da pratikte en kötü seçenek
Çoğu site Facebook, Spotify ya da Netflix ölçeğinde değil (hatta Netflix bile React’ten uzaklaştığını duyurdu); bu yüzden React’in bu kadar etkili ve iyi tasarlanmış olduğu iddiasına katılmak zor
React 12 yıl önce çıktığında gerçekten devrimciydi
Ama kısa süre sonra benzer birçok framework çıktı ve o andan sonra inovasyonun merkezi olmaktan ziyade "idare eder" seviyesinde kaldı
Artık eskiyen Virtual DOM tasarımının sorunlarını çözmeye çalışırken giderek daha fazla boilerplate üretiyor ve modern alternatiflere kıyasla cazibesini yitiriyor
Başlığın anlamı tersine dönmüş
Aslında olan şey, "inovasyonun" React formülüne (başarı formülüne) yetişememesi gibi geliyor
Ne kadar inovasyona gerçekten ihtiyaç olduğunu da sormak lazım
Aslında tekrar ve iyileştirme çoğu zaman daha iyi ve daha ucuz oluyor
Bu yazıyı ve 2015~16 dönemindeki çoğulcu bakışı seviyorum
Ekip içinde "Svelte ile ayrı bir küçük kullanım senaryosu yapalım" demek istiyorum ama değerlendirme kontrol listesi yazının iddiasının tam tersine işliyor
Performans: uygulamaların %99’unda fark hissedilmiyor, sonuç React
Ekip yetkinliği ve öğrenme eğrisi: herkes sadece React biliyor, Qwik gibi şeyleri bilmiyor. Doğal olarak React
Ölçeklenebilirlik, işletme maliyeti: büyük fark yok
Ekosistem: React çok daha büyük ve oturmuş. React
Üstelik bugünlerde AI araçları da React ile iyi çalışıyor ve geliştiriciler de neredeyse otomatik olarak React merkezli öğreniyor
Sonuçta React rasyonel seçenek olmaktan çıkamıyor
Web components’in bu framework tekelimsi durumundan çıkış yolu olduğunu düşünüyorum
React dışındaki tüm framework’lerin web components’i güçlü biçimde desteklemesi; her birinin kendi React ekosistemini baştan kurmaya çalışması yerine uyumlu component ve utility ekosistemlerinden yararlanması çözüm olabilir
Birçok kişi web components’i framework’lerin rakibi gibi görüyor ama aslında bunlar component implementasyonları ile tarayıcı arasındaki arayüzü tanımlayarak birlikte çalışabilirlik ve güvenilir birleştirme sağlıyor
Bu tür düşük seviyeli API’lerin üstünde, component üretmenin çok farklı yolları (build’siz, JSX, template, custom syntax, compiler vb.) ve component birleştirme ile state management alanında da pekâlâ inovasyon yapılabilir
"Bizim yeni Flugle framework’ümüz her framework ile iyi çalışıyor ve otomasyon araçları da çok zengin!" diyebilmek, React tekeline karşı çıkmanın yolu
Ben de boilerplate’ten kaçınmak için wrapper kullanarak web components kullanıyorum
Bu şekilde web component özelliklerinin %80’ini çok az çabayla elde edebildim
İlgili GitHub: ZjsComponent, eski HN tartışmasına da bakabilirsiniz (HN tartışması)
Mükemmel değil ama benim için yeni HTML component’leri oluşturmanın daha kolay ya da daha hızlı bir yolu yok
React Native seviyesinde bir alternatif yoksa web components tek başına yeterli değil
Tarayıcı teknolojileri, native uygulama düzeyine ulaşacak kadar hızlı değil
React’in en büyük değeri, platformlar genelinde GUI geliştirmeyi birleştirebilmesi
lit web components ile iş uygulamaları geliştirme deneyimim oldu
Tüm property’lerin string olması gerekmesi oldukça rahatsız ediciydi ve real-time odaklı component kütüphaneleriyle kıyaslanamazdı
Bizim büyük şirkette şirket içi uygulamalarda merkezi React kütüphanesinin kullanılması zorunlu
Durum "varsayılan olduğu için React" değil, "yalnızca React kullanılabilir"
Çıkış yolunun merkezi kütüphaneyi web components olarak yeniden yazıp istenen framework’ün kullanılmasını sağlamak olduğunu düşünüyorum
React UI kütüphanesinde web components’i iyi kullanan biri var mı merak ediyorum
Belirli bir tasarım sistemine göre component kütüphanesi oluştururken RAC gibi headless kütüphanelere dayanmak tatmin edici geliyor
Web components’in tamamlayıcı olabileceğini anlıyorum ama pratikte en iyi nerede kullanıldığını pek bilmiyorum
Aslında bu yazı React’in performansından çok, "sosyal getirilerinin" alternatiflere kıyasla çok daha büyük olması nedeniyle diğer seçeneklerin zorlandığını anlatıyor
Yani React teknik olarak öne çıkmasa da varsayılan tercih haline geldiği ve ağ etkilerinin teknik uygunluktan daha fazla karar belirlediği fikrine katılıyorum
Yine de ekipler için React’in alternatiflere karşı açık avantajları sürüyor
Gerçekte çoğu yetkin ekip, ancak gerçekten istisnai durumda olduklarında başka alternatifleri seçmeleri gerektiğini iyi ayırt ediyor
Birçok şirket ve startup’ta teknoloji yığını kararlarına katıldım ama React seçimi için hiç "framework’ün kendisinin avantajları" gerekçesini duymadım
Kararlar her zaman aşinalık, işe alım kolaylığı ve ekosistem temelinde verildi
Web geliştiricilerinin rasyonel karar verdiğini varsayıyorsunuz ama benim deneyimimde durum böyle değil
İnsanlar “sosyal kanıt”, “otorite” gibi insani önyargılardan kolayca etkileniyor
Hiç "React’i sevdiğimiz için kullanıyoruz" dendiğini duymadım
Sebep hep "işe alım kolay" oldu
React karmaşık problemleri çözmede güçlü
Ama her problem karmaşık değil ve karmaşık bir aracı varsayılan yapmak projeye gereksiz karmaşıklık ve daha az esneklik getiriyor
Geçmiş ya da gelecekteki özellikler yüzünden bakım verilmesi gereken ekosistem istikrarsızlığı da sadece React’e özgü bir sorun değil
Bundan sonra mevcut nesil web app paradigmasının ötesine geçen yeni akımlar çıkmasını umuyorum
Frontend tek kültürü (React tekeli) konusunda endişelenmek için nedenler var ama ilginç olan şu ki, 10 yıl önce durum tam tersiydi
Her hafta HN’de yeni framework’ler yağıyordu, Angular 1.x’ten 2.0’a geçiş kargaşası vardı ve hatta "JavaScript yorgunluğu" diye bir terim ortaya çıkmıştı; frontend geliştirme gerçekten zordu
Şimdi React açık biçimde standart haline geldi ve bunun sayesinde rahatça asıl ürün geliştirmeye odaklanabiliyoruz
React’i övmüyorum (ben de hooks’u çok sevmem) ama en azından 2015’teki gibi bir dönemde olmadığımız için memnunum
Zaman geçtikçe havanın yeniden değişmeye başlaması da ilginç
Delicesine çeşitli butik JavaScript kütüphanelerinin ortalıkta dolaştığı zamanı hatırlıyorum
React’in baskın hale gelmesini bir tür zafer olarak görüyorum
"İnovasyon" gibi muğlak bir kavram uğruna tanıdık ve istikrarlı şeyi zorla terk etmeye çalışmaya karşı dikkatli olunmalı
Buna gerçekten katılıyorum
2009~2015 arasında oldukça öncü sayılabilecek biçimde, native uygulama düzeyinde tarayıcı UX’leri çok yaptım
Gücümüz web standartları ve bunları mümkün olduğunca doğrudan kullanmaktı; sonra backend tarafına yöneldim ve React’in yükselişini uzaktan izledim
React bana verimsiz görünüyordu ve JSX’in "her şey bir expression olmalı" sınırlaması da sıkıcıydı
Yine de React’in state management konusunda önemli bir paradigma değişimi getirdiğini teslim etmek gerekir
Geçmişteki durum modellerinden tek yönlü immutable data akışına geçmek zor bir süreçti ama sonuçta anlamlıydı
O karmaşık dönemde bile React’in hem inovasyon getirdiği hem de web app tasarımına bakışı büyük ölçüde değiştirdiği doğru
Ama bugün SolidJS ile karşılaştırınca, Solid aynı avantajları daha yalın biçimde, daha yüksek performansla ve çok daha kolay yönetilebilir şekilde sunuyor
JSX, server components ve reactive state management tarafını da daha iyi veriyor; ayrıca React geliştiricileri de kolayca geçiş yapabiliyor
Uygulama yapısını düşünme biçimi de neredeyse aynı, yani React’te fiilen elde edilen avantajların neredeyse tamamını daha iyi, daha hızlı ve çok daha küçük bundle boyutuyla alabiliyorsunuz
Yine de tüm pazar React’e yığılmış durumda olduğu için istemeden kullanmaya devam etmek zorunda kalıyoruz
SolidJS’in de hâlâ can yakan yerleri var
En büyük sorun, bir prop’un signal olup olmadığının sezgisel biçimde anlaşılamaması
Tip sistemi de burada çok yardımcı olmuyor
React’te referans değişirse prop’u alan tarafın yeniden render edileceği nettir; Solid’de ise değişimin gözlemlenip gözlemlenmeyeceği belirsizleşebiliyor
Bence çoğu insan bildiği şeyi kullanmakla yetiniyor
React’i zorla kullanmak istemeyen çok geliştirici var ama sonunda en iyi bildikleri şeye dönüyorlar
Zaman sınırlı; aile, hobiler ve hayatın geri kalanı için verimli seçim yapmak gerekiyor
React’e bağlı kalmak zorunda değilsiniz
Benim şirketimin (aslında neredeyse tek başıma) son 10 yılda geliştirdiği bir framework var ve MIT lisansıyla open source olarak yayımlandı
Q.js bağlantısı
Görüş duymak isterim
Hooks, class component’lerin bazı sorunlarını çözdü ama beraberinde yeni karmaşıklıklar da getirdi (dependency array, stale closure, kötüye kullanım vb.)
Ama bu sorunlar yalnızca hooks yüzünden ortaya çıkmadı; geçmişte class tabanlı component döneminde de vardı
Dependency array sorunları geçmişte de props ve state değişimlerini kaçırmaktan doğan bug’lar şeklinde çok yaygındı
Stale closure, setState’in ikinci argümanında da aynı şekilde yaşanıyordu
Lifecycle method’ların (
componentDidMount,componentWillMountvb.) kötüye kullanımı da sık görülüyorduBence geçmişte de "Effect’i yalnızca gerçekten gerektiğinde kullan" gibi belgeler gerekli olurdu
Hooks, hata yapma fırsatlarını azaltıyor, bu fırsatların görülmesini kolaylaştırıyor ve hatta uyarılar veriyor; bu yüzden açıkça bir iyileştirme sağlıyor
Dependency array sorunu eslint’te react-hook kuralları kullanılırsa çok kolay çözülebiliyor
Prop testlerinde fast-check kullanmak, küçük değişikliklerin bug’a dönüşmesini önlemede inanılmaz yardımcı oluyor
JavaScript topluluğu birkaç yıl boyunca inovasyona ara verse iyi olabilir
Fazlasıyla inovasyon oldu ama karşılığında somut fayda azdı
Artık web için makul component geliştirmeyi tarayıcı tarafının üstlenmesi gerekiyor
Tarayıcı düzeyinde backend destekli combobox ya da standart bir date picker gelse, her seferinde bu temel UI kontrollerinin state management tarafını yeniden icat etmek zorunda kalmayız
Bence sorunlardan biri de tarayıcıların artık kendi asli rolünü tam yerine getirmemesi
Google, Chrome üzerinden neredeyse tekele yakın bir etkiye sahip; bu yüzden Google’ın ilgilenip mühendislik kaynağı ayırdığı şeyler dışında web standartlarında da ilerleme zor oluyor
Safari ve Firefox bir miktar denge sağlıyor ama platformun gerçekten farklılaşmış bir yapıya evrilmesi için birilerinin liderliği alıp ileri taşıması gerekiyor
Sonuçta JS dünyası, platform seviyesinde destek gelmediği için sürekli NAND çipi lehimler gibi hack yaparak ilerlemek zorunda kalıyor; bu da üzücü
Son dönemde tarayıcılar ve CSS, geleneksel olarak JS’e bağımlı olan kullanım senaryolarını istikrarlı biçimde iyileştirip çözmeye başladı diye hissediyorum
Bu eğilimin daha da güçlenmesi iyi olur
Hatta alışveriş, bankacılık, sosyal vb. gibi 5~6 tür tarayıcıya ayrılmayı bile düşünebiliriz
Böylece her hizmet backend’de inovasyon için yarışır, frontend ise birleşik bir deneyim sunar; bu kullanıcı için daha iyi olur
Her şirketin aynı frontend’i tekrar tekrar ayrı ayrı geliştirmesi muazzam bir israf
Bir sandviç dükkânı daha iyi sandviç yapmakta yarışmalı; uygulama kuran kullanıcıların %8’ini kapmak için benzer frontend’ler üretmekte değil
Aslında framework’lerin HTML/CSS/JS gibi bu kadar karmaşık bir platform üzerinde başardıklarına şaşmamak elde değil
'Web' başlangıçta belge/metin ve basit formlar için uygun bir yapıya sahipti; bugün ise karmaşık etkileşimli uygulamalar için oldukça uygunsuz bir temel
Bir gün tamamen yeniden kurgulanması gerekecek
React "en iyi olduğu için" değil, "güvenli varsayılan" haline geldiği için kazandı
Herkes React biliyor, işe alım kolay, ekosistem büyük; bu da onu güvenli kılıyor
Bunun sonucu olarak inovasyon azalıyor ve Svelte ya da Solid gibi daha hafif alternatifler çoğu zaman hiç denenmiyor
React hâlâ iyi çalışıyor ama bence gerçekte uygunluktan çok ataletten dolayı kullanılıyor
Yazarın görüşüne katılıyorum. Ancak React kullanma ataleti söylendiği kadar yanlış değil. Bahsettiğiniz Svelte gibi alternatifler iPhone 17 ise, React’i en fazla iPhone 15 ya da 16 gibi görüyorum. Maliyetine göre hâlâ kullanılabilir durumda ve özellikle değiştirme ihtiyacı da hissettirmiyor. Frontend’in büyük karmaşa döneminde React’i seçmiş olmamız, yazarın dediğinden farklı olarak bilinçli verilmiş bir karar değildi. Çeşitli şeyler kullandıkça React en kullanışlı olanı gibi hissettirdiği için seçile geldi. Gelecekte React rahatsız edici hâle gelir ve başka bir şey daha kullanışlı görünürse, özellikle bilinçli biçimde meydan okumaya ya da deney yapmaya gerek kalmadan doğal bir geçiş yaşanacağını düşünüyorum.
VHS ile Betamax'ın karşı karşıya geldiği video kaset standardı savaşına bakınca, teknik olarak daha üstün olanın her zaman piyasada tercih edilmediği anlaşılıyor.
Asıl sorun, front-end tarafında gerekenden fazla ve aşırı yenilik yapılması değil mi?
Bir ölçüde katılıyorum.
Backend tarafında da spring boot framework’ünün e-Government Framework’e kadar uzanan bir standarda dönüşmesiyle üretkenliğin arttığı yönler kesinlikle var; bu yüzden React’in de böyle bir biçime evrilmekte olduğunu düşünüyorum.
Evet, oldukça geniş bir çoğunluğun anlayabildiği bileşen tabanlı tasarımı ve render davranışını yerleştirmiş olmasının React’ın asıl önemi olduğunu düşünüyorum. Ancak React, tek başına web uygulaması geliştirmek için düşük seviyeli bir framework; en azından router ve form gibi şeyleri varsayılan olarak sunsaydı keşke. Ayrıca state ve effect tarafında derin karşılaştırmayı varsayılan olarak destekleseydi ve mantığı yalnızca yapı ve fonksiyonlarla yazabilseydik nasıl olurdu diye düşünüyorum. JavaScript’in sığ karşılaştırma kısıtları yüzünden, custom hook sözdizimiyle sınıf yazar gibi oluyor insan.
Düşük seviye... demek için de... formu uygulamak için sadece HTML
inputetiketi kullanınca olacak bir iş içinstate'i,jsx'i, kontrolsüz/kontrollü bileşeni gereksiz yere bilmek zorunda kalmak, ayrıca çok fazla kod üretmek zorunda kalmak gibi şeyler metnin motivasyonu olmadı mı diye düşünüyorumKatılıyorum.