React değilse, ne kullanmalı?
(infrequently.org)> "Frameworkism (çerçevecilik) artık işlemiyor. Cevap başka bir araç değil, mühendislik yapma cesareti"
- Son 10 yılda, masaüstü ve mobil web için farklı ürünler ve teknoloji yığınlarıyla 100'den fazla projede deneyim edinildi
- Zamanın büyük kısmı, web API’lerini iyileştirmekten çok React gibi frontend framework’lerinin yol açtığı performans ve erişilebilirlik sorunlarını çözmeye harcandı
- React zaten legacy bir teknoloji olmasına rağmen hâlâ yeni projelerde benimseniyor
- React’in "modern" olduğunu savunanlar var, ancak bu aslında geçmişteki yöntemleri tekrar etmekten ibaret
İstemci tarafı karmaşıklığını en aza indirme kuralı
- Sunucu tarafı kod geliştiricinin kontrolündedir; performans ve erişilebilirlik etkili biçimde yönetilebilir
- İstemci tarafı kod geliştiricinin kontrol edemediği çok çeşitli ortamlarda çalışır; bu yüzden kararlılığı ve performansı garanti etmek zordur
- En iyi strateji, istemciye gönderilen kod miktarını azaltmaktır
- JavaScript bağımlılığını en aza indirmek için önce HTML ve CSS kullanın
- React ve benzeri framework’ler gereksiz kod tekrarına ve performans düşüşüne yol açar
O hâlde alternatif ne?
Tartışma iki soruya ayrılıyor
- Dar soru: "İstemci tarafı render gerekiyorsa, React’in yerine hangi teknoloji kullanılmalı?"
- Modern framework’leri değerlendirmeye değer: Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil vb.
- Ancak bu framework’ler kullanılırken bile istemci tarafı payload ve karmaşıklık sıkı biçimde yönetilmelidir. JavaScript, HTML/CSS’ye göre en az 3 kat daha maliyetlidir
- Geniş soru: "React’e bağımlı bir teknoloji yığınını baştan sona yeniden değerlendirmek gerekiyorsa, bunu nasıl yapmalı?"
- Mesele sadece yeni bir araçla değiştirmek değil; mevcut mimarinin amacını ve sınırlarını anlayıp yeniden tasarlamaktır
Dar soruya yaklaşım
- Küçük ölçekli birden fazla PoC (Proof of Concept) oluşturarak performans ölçeklenebilirliği ve sınırları değerlendirin
- Bu tür nesnel deneyler ekip üyelerine anlamlı mühendislik deneyimi sağlar
Geniş soruyu soran ekiplerin ortak durumu
- React’i değiştirme tartışmalarında çoğu zaman kafa karışıklığı yaşanır
- Kararlar çoğunlukla mevcut mimariyi izleyerek alınmıştır
- Kullanıcı deneyimine dair net anlayışın ve veriye dayalı karar almanın eksikliği vardır
Çerçevecilik ile kullanıcı merkezli yaklaşım arasındaki fark
- Çerçevecilik: Framework’e daha fazla özellik eklenirse tüm sorunların çözüleceğine inanmak
- Gerçekte ise çoğu zaman kullanıcı sorunları çözülmez
- Standart dışı örüntüler ve veriye dayalı kanıtlar göz ardı edilir
- Gerçekçilik: Kullanıcı deneyimini ölçmek ve kararları gerçek verilere dayanarak almak
- Kullanıcı ihtiyaçlarını ve kısıtlarını anlayıp teknoloji yığınını buna göre tasarlamak
- Başlangıç noktası her zaman kullanıcı ihtiyacıdır
Gerçekçiliği nasıl benimsemeli?
- RUM verilerini kullanın: Core Web Vitals gibi kullanıcı merkezli performans metriklerini kullanın
- Performans testi: Temel kullanıcı yolculuklarını (critical user journeys) ölçmek için WebPageTest (WPT) gibi araçlardan yararlanın
- İş hedefleriyle kullanıcı deneyimini bağlayın: Veri üzerinden iyileştirme yönünü ve yatırımın etkisini değerlendirin
Veriye dayalı yaklaşımın önemi
- Framework’leri güvene dayanarak benimsemek yerine etkilerini veriyle doğrulayın
- Trendlere göre teknoloji benimsemenin gerçek maliyetini ve etkisini karşılaştırın
- Ölçülebilir metriklerle kullanıcı deneyimini optimize etmeye odaklı teknoloji seçimini teşvik edin
Değerli olan hiçbir şey kaybedilmedi
React’in yayılmasını sınırlayan politikaların etkisi
- React ve diğer framework merkezli yaklaşımları yasaklamak maliyetleri azaltmaya ve ekipleri kullanıcı merkezli yeniden hizalamaya katkı sağlar
- Ancak çerçevecilik tamamen dışlanmadıkça temel performans kazanımları elde etmek zordur
- Bir hatadan kaçınırken aynı kategoride başka hatalara yatırım yapılıyorsa etki sınırlı kalır
Geniş probleme yönelik genel çözümler
Kullanıcı merkezli
- Karar vericiler, mühendislik tercihlerinin sonuçlarından doğrudan sorumlu olmalıdır
- Mazeret olmaksızın, sistem kullanıcılar için (özellikle dışlanmış kullanıcılar için) iyi çalışmıyorsa alternatif bir sürüm devreye alınmalıdır
- Ortada yalnızca çözülmesi gereken sorunlar vardır; mevcut yaklaşımı sorgusuz koruyan "dokunulmazlık" anlayışı dışlanmalıdır
Kanıta dayalı yaklaşım
- Yönetim ile mühendislik arasında paylaşılan bir gerçekçilik taahhüdü gerekir
- Karar alma sürecinde daha iyi kanıt her zaman üstün gelmelidir
Koruma mekanizmaları
- Çerçeveciliğin hayalci iddialarını önlemek için politikalara ihtiyaç vardır
- Örneğin Birleşik Krallık Government Digital Service’in progressive enhancement teknik gereksinimleri
- Politikalar kurumsal duruma göre uyarlanabilir; örneğin istisnalar için escalation path oluşturulabilir
- Ancak önemli olan net ölçütler koymaktır. Kanıta dayalı politikalar güçlü etki yaratır
Teknoloji karşılaştırma değerlendirmesi
- Açıkça tanımlanmış temel kullanıcı yolculukları (critical user journeys) olmadan yeni bir sistem dağıtmayın
- Temel kullanıcı yolculukları, kullanıcıların sistemde en sık yaptığı işleri temsil eder
- Buna dayanarak her teknolojinin sonucu kısıtlar altında test eden karşılaştırmalı değerlendirmeler (bakeoffs) yapın
- Ürün yöneticileri yalnızca deney öneren kişiler olmaktan çıkmalı; ürün için açık hipotezler tanımlayıp başarı ölçütlerini belirlemelidir
- Bu rahatsız edici bir süreç olabilir, ancak ürün yöneticisinin temel rolüdür
- Bunun kendi işiyle uyuşmadığını düşünen PM’lerin ayrılması göze alınmalıdır
Vaka çalışması
Gerçekçilik ile çerçevecilik arasındaki fark: örneklerle anlama
- Teknoloji seçim ölçütleri
- Teknoloji seçimi ana veri güncelleme sayısı ve oturum süresi temelinde değerlendirilmelidir
- Bazı uygulama sınıfları uzun oturumlar ve sık veri güncellemeleriyle karakterize olur
- Bu durumda yerel veri modeli uygun olabilir
- Ancak bu nadir ve istisnai bir durumdur
- Kısa oturumlar söz konusuysa
- Ortalama oturum süresi kısa olan siteler ilk JavaScript yükünü en aza indirmelidir
- Sitelerin çoğu SPA mimarisi gerektirmez
- SPA mimarisi gerektiğinde
- SPA mimarisi yalnızca belirli koşullar sağlandığında düşünülmelidir
- Oturumlar uzunsa ve aynı veride birden fazla güncelleme gerekiyorsa
- Bu koşulları karşılamayan siteler SPA benimsememelidir
- SPA mimarisi yalnızca belirli koşullar sağlandığında düşünülmelidir
- Ana soru
- Seçim, JavaScript framework’leri arasında yapılan bir tercih değildir
- Çoğu durumda asıl mesele, SPA odaklı araçların kendisini kullanmanın uygun olup olmadığını değerlendirmektir
- Çoğu site için yanıt açıkça "hayır" olur
Bilgilendirici web siteleri (Informational)
- En uygun yapı: Semantik HTML ve gerektiğinde progressive enhancement kullanımı
- Statik site üreticileri uygundur: Hugo, Astro, 11ty, Jekyll
- Sık güncellenen içerikler için WordPress gibi CMS araçları kullanın
- Bloglar, pazarlama siteleri, şirket ana sayfaları ve kamusal bilgi siteleri istemci JavaScript payload’unu olabildiğince azaltmalıdır
- SPA mimarisi için tasarlanmış framework’ler kullanılmamalıdır
- Semantik işaretleme ve progressive enhancement neden uygundur?
- Kısa oturumlar ve sunucunun sahip olduğu veri modeli baskındır
- Sayfada gösterilen verinin kaynağı her zaman sunucu tarafından yönetilir
- İstemci veri modeli soyutlamalarına veya component tanımlarına gerek yoktur
- CMS yapısı:
- Yazarlar için düşük trafikli, yüksek etkileşimli bir editör
- Okuyucular için yüksek trafikli, düşük etkileşimli bir görüntüleyici arayüzü
- Kısa oturumlar ve sunucunun sahip olduğu veri modeli baskındır
E-ticaret (E-Commerce)
- Önerilen mimari: Sunucuda üretilmiş semantik HTML ve progressive enhancement
- Amazon ile React tabanlı rakipleri arasındaki performans farkı açıktır
- Walmart trafiğinin %70’ten fazlası mobilden gelir; SPA tabanlı Next.js yaklaşımı iş üzerinde olumsuz etki yaratır
- Progressive enhancement neden uygundur?
- E-ticaretin tipik yapısı:
- Sunulan ürünleri ve aramayı içeren landing page
- Filtre ve karşılaştırma özellikleri sunan arama sonuç sayfası
- Medya, incelemeler ve önerilen alternatifleri içeren ürün detay sayfası
- Sepet yönetimi, ödeme ve hesap yönetimi ekranları
- Sunucu sahipli durum:
- Taze içeriği korumak (ör. fiyatlar)
- Hafif sayfa optimizasyonuyla gecikmeyi azaltmak
- Agresif caching, görsel optimizasyonu ve sayfa boyutunu küçültme stratejileri kullanmak
- E-ticaretin tipik yapısı:
Medya tüketim siteleri (Media)
- Temel yapı: Progressive enhancement tabanlı tasarım
- Gerektiğinde ürün değişimlerine göre karmaşıklık eklenir
- Progressive enhancement ve islands mimarisi neden uygundur?
- Yorum zincirleri gibi etkileşimli öğeler bağımsız veri modelleri olarak kurgulanabilir
- Web Components kullanılarak statik sayfa içinde uygulanabilir
- SPA’nın uygun olduğu durumlar
- Medya oynatma sürekliliği:
- Sayfalar arasında gezinirken mini oynatıcının korunması gerekebilir
- SPA teknolojileri kullanılabilir, ancak istemci JS boyutu sıkı yönetilmelidir
- Çevrimdışı oynatma desteği:
- Yerel medya önbelleğini yöneten mantık gerekir
- Zero, Y.js gibi veri senkronizasyon sistemleri değerlendirilebilir
- Medya oynatma sürekliliği:
Sosyal medya (Social)
- Hibrit model: Sunucu sahipli veri modeline dayanan düşük etkileşim + aralıklı medya güncellemeleri
- Progressive enhancement neden uygundur?
- Tipik etkileşimler:
- "Beğen" tıklaması, aralıklı güncellemeler vb.
- Hotwire veya HTMX kullanan hibrit yaklaşım uygundur
- Tipik etkileşimler:
- SPA’nın uygun olduğu durumlar
- Derin etkileşim adacıkları:
- Taslak gönderi kaydetme gibi işlemlerde istemci önbelleği kullanılabilir
- Çevrimdışı destek:
- Önce HTML sunulup senkronizasyon ve çevrimdışı mantık Service Worker ile uygulanabilir
- Derin etkileşim adacıkları:
Üretkenlik uygulamaları (Productivity)
- Belge merkezli üretkenlik uygulamaları karmaşık gereksinimlere sahiptir: işbirlikli düzenleme, çevrimdışı destek, hafif görüntüleme modu
- Yerel veri modeli ve SPA tabanlı mimari uygun olabilir
- SPA neden uygundur?
- Sık veri güncellemeleri:
- Tuş vuruşları, fare sürükleme gibi işlemlerde istemci mantığı avantaj sağlar
- Performans kısıtları yönetilmelidir:
- İlk bundle boyutunu yönetmek
- Gecikmeli paket yükleme stratejileri uygulamak
- Sık veri güncellemeleri:
Diğer uygulama sınıfları (Other Application Classes)
- Belirli gereksinimler:
- 3D CAD, programlama editörleri, oyun yayını, web tabanlı oyunlar, medya düzenleme, müzik üretim sistemleri vb.
- Her uygulama sınıfı, üretkenlik uygulamalarında olduğu gibi dikkatle değerlendirilmelidir
- Başarı koşulları:
- Temel kullanıcı yolculuklarını tanımlamak
- Ortalama oturum derinliğini analiz etmek
- Performans garantisi metrikleri belirlemek
- Ana script’leri ve kaynakları kontrol etmek
Kurumsal yazılım hakkında bir not
- "Kurumsal iş uygulamaları" genellikle en kötü performans sorunlarını üretir
- Dashboard’lar, workflow sistemleri, kurumsal chat uygulamaları buna tipik örneklerdir
- Performans bir kültürdür:
- İlk yükleme süresini ve etkileşim sonrası performansı tanımlayıp ölçmede başarısız olunur
- Kullanıcıları görmezden gelen geliştirici merkezli kültür zehirleyicidir
"Ama..."
- React dâhil belirli framework’lere bağlı yöneticiler, bu seçimleri meşrulaştırmak için sık sık çeşitli argümanlar öne sürer
- Ancak bu tartışmalar kullanıcı deneyimini merkeze almaz; bu eksiklik kendini tekrar tekrar gösterir.
"...hızlı hareket etmemiz gerekiyor"
- Soru: "Bunun ne kadar sürdürülebileceğini düşünüyorsunuz?"
- Hızlı geliştirilen NPM tabanlı projeler erişilebilirlik sorunlarına, düşük performansa ve artan karmaşıklığa yol açar; sonuç olarak hız düşer
- Düzeltme maliyeti: JavaScript kaynaklı sorunları çözmek aylar alır ve özellik teslim hızı daha da düşer
- Product-Market Fit için erişilebilirlik ve kalite öncelikli olmalıdır
- React ile "hızlı hareket etme" tercihi uzun vadede daha pahalıya mal olur ve büyümeyi engeller
"...Facebook’ta gayet iyi çalışıyor"
- Şirketlerin çoğu Facebook’takine benzer sorunlarla karşılaşmaz
- Facebook da React kullanımından kaynaklanan performans sorunları yaşar, ancak tekel benzeri konumu sayesinde bunları perdeleyebilir
- Sıradan şirketler Facebook örneğini körü körüne izlememelidir
"...ekibimiz zaten React biliyor"
- React geliştiricileri web geliştiricisidir. CSS, HTML, JavaScript ve DOM bilgisi zorunludur
- React, teknoloji yığınındaki değiştirilebilir en basit katmandır
- Preact, Svelte, Lit, FAST gibi daha küçük ve daha hızlı framework’leri öğrenmenin önünde büyük bir engel yoktur
"...işe alım kolay olmalı"
- Bugünkü BT sektörü iyi geliştiricileri işe almak için büyük bir fırsat sunuyor
- React bilgisi işe alım ölçütü olamaz
- React bilen geliştiricilerin çoğu web standartlarını da kolayca öğrenebilir
- Daha basit sistemler çoğu zaman daha yüksek ROI sağlar
"...herkesin telefonu zaten hızlı"
- Mobil kullanımın arttığı son 10 yılda, istemci kaynaklarının ucuz olduğu varsayımı zaten yanlış bir kabul oldu
- Düşük performanslı telefon kullananlar da ürünün ana müşterileri arasında olabilir
- React’i seçerek tüm kullanıcıların pahalı cihazlar kullandığını varsaymak risklidir
"...React sektör standardı"
- React tutarlı bir standart değildir
- React’in kendi yaklaşımı (class component vs function component), TypeScript kullanımı, state management aracı seçimi gibi unsurlar her projede değişir
- React yığını her zaman değişkendir; "standart" iddiası ise yalnızca rahatlatıcı bir kurgudur
"...ekosistem..."
- Yalnızca React ile uyumlu kütüphaneler çok nadirdir; araçların çoğu Preact vb. ile de kullanılabilir
- Tüm NPM paketleri geleceğe dönük teknik borç üretir
- CSS-in-JS gibi gereksiz bağımlılıklar yalnızca maliyeti artırır
"...Next.js de yeterince hızlı"
- Next.js varsayılan olarak React’in performans sorunlarını beraberinde getirir
- HTML öncelikli araçlar (ör. Astro, 11ty), Next.js’e göre daha iyi performans sunar
- Ayrıca VC destekli startup API’lerine lock-in olma sorunu da vardır
"...React Native!"
- React Native mobil uygulamaları yavaşlatır ve bakım maliyetini yükseltir
- PWA ve Capacitor/Cordova kullanmak daha iyi bir seçimdir
- Facebook da React Native’den uzaklaşıyor.
12 yorum
Genel şirketler Facebook’un örneğini düşünmeden kopyalamamalı.
Düşük performanslı telefon kullananlar da ürünün ana müşterileri olma ihtimali yüksek.
React Native mobil uygulamaları yavaşlatıyor ve bakım için çok maliyet gerektiriyor.
Hahahahahaha hahaha
Yazı fazla uzun olduğu için ana fikir bulanıklaşıyor.
Yazar, React kullanalım görüşünün sanki koşulsuz olarak frameworkçülükten kaynaklandığını düşünüyor gibi görünüyor.
Frameworkçülüğün dışına çıkıp vakaya göre yaklaşalım dedikten sonra, her türlü mühendislik ihtiyacı için reçete oluşturmaya çalışıyor.
Öngörülen bütün karşı argümanlara tek tek cevap vermeye çalışma şeklindeki aşırı söylem alanı kaplama çabası dikkat çekiyor. Karşı argümanlara verdiği karşı cevaplar da fazlasıyla dar bakışlı.
Yani belirli vakaların ötesine geçip genel bir tartışma yürütmek için yazarın sahip olduğu tartışma tavrı ve becerileri oldukça yetersiz görünüyor.
Sonuç olarak ben React kullanmayı sevmiyor olsam da, yazarın tek taraflı tutumu yüzünden React kullanımını savunan insanların düşüncelerini biraz daha dinlemek ister oldum.
Şahsen şu an için en iyi seçeneğin React olduğunu düşündüğümden fikrimi paylaşayım.
Web geliştirmeye php ve jquery döneminde başladım; şu an çalıştığım şirkette AngularJS, Angular, class tarzı React ve hook tarzı React deneyimlemiş biri olarak şunu söyleyebilirim: teknoloji yığınını, önce kullananların deneme-yanılmaları yaşanıp kütüphane ekosistemi oturduktan sonra değiştirmek daha az baş ağrıtıyor. Semantik sürümleme açısından bakarsanız, en son sürüm yerine ondan bir önceki major sürümü kullanmak gibi. Gereksinimler ve yüksek seviye işlevler değişmediği için sorun olmuyor ama altyapı teknolojisine dair başvuru kaynakları yoksa verimlilik çıkmıyor. Ayrıca şirketimizdeki projelerin yapısı gereği, SaaS hizmetlerinden farklı olarak ürün döngüsü uzun ve sadece bakım yapılan dönemler de var; bu yüzden en yeni teknolojileri uygulamak daha da zor oluyordu.
Muhtemelen React, yönünü Next.js'e çevirip SPA desteğini sonlandırarak mimari değişikliği zorunlu kıldığı noktada teknoloji değişimini bir kez daha düşünmek gerekecek. Vue biraz daha yaygınlaşmış olursa adaylar arasında doğal olarak yer alır. Kullanmamak için bir neden yok.
Mobil uygulamaları RN yavaşlatıyorsa neden Capacitor ya da Cordova öneriliyor? En azından arayüzü native olarak göstermek, performans açısından hibrit web’den çok daha iyi bir yaklaşım bence.
Ne yazık ki Kore iş piyasasında "framework fanatizmi işe yaramaz" derseniz, mülakatta elenme ihtimaliniz çok yüksektir. Birçok mülakatta, ancak framework'ü çok kullanmış olanların bilebileceği sorular sorulur.
RN geliştiricisi hüngür hüngür ağlıyor
Ciddi konuşacak olursak, RN'in anlamı JS bundle ile native bileşenleri yönetebilmeyi sağlaması; bu yüzden PWA ile kullanım senaryosu tamamen farklı.
WebView ile bile yönetmesi zor olan kısımlar varken PWA mı? Uzun vadede o yöne gidileceğini ben de düşünüyorum ama şu an için erken. En baştan beri anlamsız bir karşılaştırma yapılıyor gibi geliyor bana.
Evet. Asıl metin, neredeyse native uygulamalara hiç gerek olmadığı seviyesinde bir görüş gibi duruyor.
Yeni olana ilgi duyan insanlar olduğu sürece bu tür meseleler tekrarlanacaktır. Zaten React ile kurulmuş bir sistem varken, işe alım meselesini göz ardı ederek gerçekliğin değişmesini bekleyemeyiz. Facebook'un React'i öne itmesinin nedeni ile 10 yıl sonra sıradan şirketlerin React'i seçme nedeni arasında fark var.
Mimariyi ve paradigmayı değiştirmeye yönelik tartışmaların bundan daha temkinli yürütülmesi ve mümkün olduğunca çok insanın ikna edilmesi gerektiğini düşünüyorum.
Ama preact de react-benzeri ve React'ten çıkınca kütüphane sayısı.....
İşe yarar gibi görünen tüm kütüphaneler de React'e özel olunca Vue geliştiricisi ağlıyor
Ben gayet iyi kullanıyorum ama biraz haksız eleştiri kokusu da yok değil.. Böyle uzun uzun yazınca sanki insanı büyük bir sorunla yüzleşmeye zorlamaya çalışıyormuş gibi bir his veriyor..
Hacker News görüşü
React kullanımına karşı çıkma nedenlerinin çoğunun yanlış sorunları çözmeye çalıştığını düşünüyorum. Performans sorunları gerçekte büyük bir mesele değil. Çoğu durumda backend’i iyileştirmek daha etkili olur
React ve jQuery’nin popüler olmasının nedeni, kodun temiz görünmesi. AngularJS’in ilk dönem kod örnekleri göze hoş gelmiyordu
React’in özü, O(n) UI durumunu fonksiyonel olarak render etmeyi mümkün kılmasıdır. Geçmişte O(n^2) durum geçişlerini yönetmek karmaşıktı
React’i kullanmaya devam etme nedeni, Java gibi istikrarlı ve olgun bir teknoloji olması. Topluluğu ve kaynakları çok zengin
Alex’in yazısı, tekrar eden tartışmalara duyduğu hayal kırıklığını gösteriyor. Birçok insan yazıyı sonuna kadar okumuyor
React geliştiricisinin web geliştiricisi olduğu sözü giderek daha az doğru geliyor. Sadece SPA React ve stillendirme framework’lerine alışkın birçok geliştirici var
Çoğu site için SPA gerekli değil. Ancak çok fazla veriye ihtiyaç duyan işler için SPA avantajlı
React’i sevmiyorum. Daha çok backend geliştiricisi olarak sunucuda üretilen HTML ve biraz JavaScript tercih ediyorum
Frontend geliştirmenin JavaScript framework’lerine kaymasının nedeni bakım maliyetleri
React’e yönelik çok sayıda yanlış eleştiri var. React geliştiricileri yeni bir template dili oluşturmadan işlerini bitirebiliyor