- React hâlâ en yaygın kullanılan UI framework'ü, ancak son birkaç yılda topluluk içinde karmaşa, tartışma ve güvensizlik arttı; resmi ekiple dış geliştiriciler arasındaki iletişim eksikliği ve hatalı pazarlama birleşerek endişeleri büyüttü
- React 19 resmi olarak yayımlandı ve Server Components, yeni
use hook'u, form entegrasyonu gibi büyük özellikler eklendi; ancak "yalnızca framework önerilir" politikası ve Next.js merkezli yapı birçok kullanıcıda memnuniyetsizlik yarattı
- "React artık yalnızca Next.js içinde düzgün kullanılabiliyor" ve "yakında yalnızca istemci desteği sona erecek" gibi yanlış anlamalar ve FUD yayıldı; fakat gerçekte istemci tarafı render desteğinin ortadan kalkması söz konusu değil ve RSC ile sunucu özellikleri de tamamen isteğe bağlı
- React ekibinin framework merkezli politikası; performans/yapı standardizasyonu ve kullanıcı deneyimini iyileştirme amacı taşıyor, ancak SPA'lere ve farklı mimarilere yeterince saygı gösterilmemesi ile gayriresmî/dostça olmayan dokümantasyon topluluktaki karmaşayı büyüttü
- Ancak yakın zamanda Vite·Parcel tabanlı SPA'ler gibi farklı yöntemler resmi dokümantasyona eklendi; buna rağmen server components (RSC) için resmi açıklamaların yetersizliği ve zayıf iletişim hâlâ sürüyor
Giriş ve amaç
- 2025 itibarıyla React topluluğu; başarı, güvensizlik ve tartışmanın iç içe geçtiği karmaşık bir dönemde
- Bu yazının amacı, React'in gelişim sürecini, geliştirme yönünü ve temel kararların arka planını toparlayarak FUD'u ve kafa karışıklığını gidermek
Yazarın geçmişi ve topluluğa katılımı
- React ekibinin bir üyesi değil, ancak 2015'ten beri React ekosisteminin derinlerinde yer alıyor
- Redux ailesi kütüphanelerinin, özellikle Redux Toolkit'in bakımcısı ve önemli bir topluluk figürü
- Çok sayıda React/Redux öğreticisi, blog yazısı, konuşma ve podcast'e katkıda bulundu
- Reactiflux Discord, /r/reactjs subreddit gibi büyük topluluklarda yönetici ve moderatör olarak görev aldı
- React ekibiyle birlikte çalışma deneyimi var (ör.
useSyncExternalStore hook'u için alfa testçisi) ve çeşitli dahili geri bildirim gruplarında yer aldı
- React DevTools, sourcemaps, Replay DevTools gibi alanlarda çeşitli teknik katkılar sundu
-
Önyargılar ve sınırlara dair not
- Her zaman haklı olmayabileceğini, bilgi sınırları, yanlış anlamalar veya özetleme sürecinde bazı anlatımların kısmen hatalı olabileceğini kabul ediyor
- Redux bakımcısı olarak React kullanım deneyiminin de çoğunlukla dahili araçlar ve SPA biçimine ağırlık verdiğini belirtiyor
- SSR, RSC, büyük trafik, i18n gibi alanlarda pratik deneyimi sınırlı
- Topluluk içinde derinlemesine tartışılan konulara aşina olsa da, bu durum sıradan uygulama geliştiricilerinin günlük pratiğinden kısmen uzak olabilir
- React ekibiyle yaşadığı hem olumlu hem olumsuz kişisel deneyimler bakış açısını etkiliyor
- Tarihsel/yapısal arka planı anlatırken olguları olabildiğince dürüst aktarmaya çalışıyor
React'in kısa tarihi
- 2011~2012 arasında Facebook'ta (şimdiki Meta) şirket içinde geliştirildi, 2013'te açık kaynak oldu
- Yakın zamana kadar tüm çekirdek geliştirme Facebook/Meta içindeki React ekibi tarafından yürütüldü
- Temel kavramlar (component, props, state, data flow) korundu, ancak uygulama, API ve kullanım kapsamı sürekli genişleyip değişti
createClass → ES6 class → fonksiyonel component'ler (Hooks desteğiyle)- React Native ile mobil,
react-reconciler ile WebGL (react-three-fiber), CLI (ink) gibi çeşitli platformlara genişleme
- İçeride tamamen "Fiber" mimarisine geçilerek kapsamlı refactor yapıldı (performans/yapı yeniliği)
- 2018'de Hooks'un gelmesiyle fonksiyonel component'lere state/effect desteği eklendi
- "Minimal UI kütüphanesi (MVC'deki V)" stratejisiyle, mimari, üst seviye framework, build ve state management gibi konular topluluğa bırakıldı
- Bunun sonucunda Redux/Mobx/Zustand (state), Styled-Components/Emotion/CSS Modules (stil), React Query/Apollo/SWR(RTK Query) (veri), Webpack/Vite/Parcel gibi çok sayıda üçüncü taraf kütüphane ve build aracı ortaya çıktı
- Esneklik bir avantajdı, ancak her projede gerekli kütüphaneleri seçmek zorunluydu → beraberinde kod tabanı çeşitliliği, yorgunluk ve standart eksikliği sorunları geldi
-
Build araçları ve CRA
- Başlangıçta Webpack/Babel gibi karmaşık yapılandırmalar zorunluydu
- Create React App (CRA): Webpack+Babel tabanlı bir CLI; karmaşıklığı gizliyor ve tek komutla proje oluşturmayı mümkün kılıyordu (black box yaklaşımı)
- Veri çekme ve state yönetimi için ayrı üçüncü taraf araçlara bağımlıydı
- SSR (server-side rendering) özelliği baştan beri vardı, ancak elle kurulması gerekiyordu
- Sonrasında Next.js (SSR/dosya sistemi tabanlı routing, veri çekme), Gatsby (statik site, GraphQL), Remix (sunucu veri loader'ları) gibi framework'ler çıktı
-
React Server Components (RSC) ve framework'e geçiş
- 2020 sonlarında React Server Components (RSC) prototipi duyuruldu; asenkron component'ler ve sunucu veri çekmeyi React içinde standartlaştırmaya dönük mimari bir değişimdi
- Geliştirme sürecinde bazı React ekibi üyeleri Vercel'e geçti ve Next.js ile iş birliği yaparak App Router ile ilk RSC uygulamasını geliştirdi
- 2020~2023 arasında React resmi dokümantasyonu (
react.dev) baştan aşağı yenilendi; etkileşimli eğitimler ve API referansı güçlendirildi
-
Resmi önerilen kullanım biçimindeki değişim
- Geçmişte resmi dokümantasyon CRA tabanlı SPA ile başlamayı öneriyor, SSR/statik site gerekiyorsa Next/Gatsby gibi alternatiflere yönlendiriyordu
- Yeni dokümantasyon (
react.dev), framework kullanımını güçlü biçimde öneriyor (routing, veri çekme, build entegrasyonu) ve RSC uygulaması olarak yalnızca Next.js'ten söz ediyor
- CRA, 2022 civarından itibaren fiilen bakımsız kaldı (resmen deprecated ilan edilmemiş olsa da, topluluk giderek alternatiflere yöneldi)
- Resmi belgelerde ve toplulukta “Next.js gerçek React 18'dir” gibi görüşlerle Next.js ile güçlü bağ öne çıktı
React ile sahibi/sponsoru olan şirket arasındaki ilişki
-
Meta (Facebook)
- React, başından beri Facebook/Meta'nın sahip olduğu ve yön verdiği bir projeydi
- Açık kaynak olsa da fiili geliştirme Meta içindeki React ekibi tarafından yapıldı; çekirdek toplantılar ve yol haritası da tamamen şirket içi odaklıydı
- Yeni özellikler dışarı açılmadan önce Meta içindeki çeşitli uygulama ekiplerinde gerçek kullanımda doğrulanıp test edildi
- React ekibi yüksek geliştirme özgürlüğüne sahipti ve yol haritası ile vizyonu büyük ölçüde kendisi belirledi
- Üretilen işin ve projenin Meta işine nasıl katkı sunduğunun şirket içinde doğrulanması gerekiyordu
- Meta; kendi sunucu altyapısını, GraphQL ve Relay gibi kendi teknolojilerini yoğun biçimde kullanıyor, bu yüzden routing ve state management gibi alanlarda React'i topluluktan farklı şekillerde kullanıyor
- Bu nedenle Meta içinde dış üçüncü taraf kütüphanelerin kullanımı daha az yaygın
-
Vercel, Next.js ve React
- Vercel, web uygulaması hosting platformu ve aynı zamanda Next.js framework'ünün geliştiricisi
- İş modeli, Next gibi framework'lerin yayılması ve ardından bunların Vercel platformunda host edilmesine dayanıyor
- CEO Guillermo Rauch, en başından beri React'in render felsefesine derin güven duydu ve buna yatırım yaptı
- 2021'de React ekip lideri Sebastian Markbage, Meta'dan Vercel'e geçti; ardından Andrew Clark, Tom Occhino gibi önemli isimler de katıldı
- Vercel'e geçen bu üyeler React Server Components (RSC) ve Next.js App Router gibi temel özellikleri hem React hem Next.js tarafında hayata geçirdi
- Vercel bünyesindeki mühendisler de React çekirdeği ve server rendering özelliklerine somut katkılar sağladı
- 2025 itibarıyla React ekibi Meta ile Vercel arasında dağılmış durumda (ana ağırlık Meta'da olsa da önemli çekirdek uygulamalarda Vercel de yer alıyor); ayrıca bazı dış katkıcılar da var
React kullanım kalıpları
-
Standart mimariler
- React'in kendisi SPA, SSR, SSG ve hibrit gibi çeşitli yaklaşımların tümünü destekliyor
- SPA: boş bir HTML içine tüm React ağacının istemci tarafında render edilmesi
- SSR: her istekte sunucuda dinamik HTML üretilmesi
- SSG: build sırasında statik HTML'in önceden oluşturulması
- Python/Django, Ruby/Rails, PHP/WordPress gibi çeşitli diller veya framework'lerle birlikte kullanılabilmesi
- 2015 civarından beri SPA (istemci tarafı render) yaklaşımı standarttı; ancak ilk yükleme hızı, JS bundle boyutu ve tarayıcıların yerel davranışlarından sapma gibi trade-off'lar vardı
- Veri çekme mantığı başlangıçta Redux gibi araçlarda doğrudan yazılıyordu; sonrasında React Query/Apollo/SWR/RTK Query gibi özel hook'lar ve kütüphanelerle sadeleşti
- Next.js ve Remix gibi framework'ler SSR, SSG ve dosya sistemi tabanlı routing'i standartlaştırıp veri çekmeyi yapılandırarak React'in kullanım alanını genişletti
- Eğilim, SSR tabanlı mimarilere (server rendering, prefetching, code splitting vb.) doğru kaydı
- React ekibi, "data fetching waterfall" olgusundan kaçınmayı savunuyor ve route düzeyinde önceden veri çekme gibi performans kalıplarını öneriyor
-
Build araçları ve framework kullanım durumu
- Başlıca araçlar/framework'ler:
- Next.js (SSR/SSG/RSC/SPA)
- Remix / React-Router v7 (SSR/SSG/SPA)
- Vite (SPA, build aracı, çeşitli framework plug-in'lerini destekler)
- Create React App (SPA)
- Vite, Vue ekosisteminden çıkmış olsa da React, Svelte ve daha fazlasını destekliyor → React için resmi plug-in'i var ve framework build araçlarında standart haline geldi
- Remix/React-Router da yakın zamanda Vite tabanlı SSR/SSG yapısına yöneldi
- İndirme istatistiklerinin özeti:
- Next.js kullanım oranında açık ara 1 numara
- Vite'in React plug-in'i hızla büyüdü ve en çok kullanılan ikinci seçenek oldu
- CRA (
react-scripts) 2023'ten sonra gerilese de hâlâ kayda değer kullanımda
- Remix kulaktan kulağa güçlü olsa da genel ölçeği sınırlı; React Router'ın framework mode'a geçişi daha yavaş
- Gatsby, Next/Vite/CRA'nın oldukça gerisinde ve son dönemde Astro'nun (çoklu framework statik site yaklaşımı) da arkasına düştü
- Astro, React'e özel değil ama Remix'e yakın ölçekte
- Vite+CRA kullanımını birleştirince Next ile başa baş geliyor → SPA yaklaşımına talep hâlâ yüksek
React Server Components (RSC) iç yapısı ve framework'lerle ilişkisi
-
RSC'nin geliştirilme arka planı ve Vercel iş birliği
- Meta'nın dahili altyapısı zaten kendi sunucu mimarilerine dayandığı için RSC'nin geliştirilmesi ve test edilmesinde sınırlamalar vardı
- RSC, React ekibinin doğrudan yön verdiği ileriye dönük bir tasarımdı; Meta veya Vercel'in talimatı ya da baskısıyla değil, React ekibinin bağımsız vizyonuyla başladı
- React ekibi RSC vizyonunu Vercel'e önerdi, Vercel de geliştirme için deney alanı ve destekçi olarak katıldı
- Sebastian Markbage, Andrew Clark gibi çekirdek React üyeleri Meta'dan Vercel'e geçti ve Next.js ekibi App Router'ı (RSC'nin ilk gerçek kullanım örneği) inşa etti
- Bu süreçte Next.js neredeyse baştan tasarlanıp uygulandı
- Shopify (Hydrogen), Remix gibi başka framework'ler de erken test ve iş birliği denemeleri yaptı; ancak ciddi katılım sınırlı kaldı
- Sonuçta yalnızca Next.js App Router gerçek anlamda "production-ready" RSC uygulaması haline geldi; diğer framework'ler (React Router, Parcel, Waku vb.) hâlâ entegrasyon üzerinde çalışıyor, ancak kitlesel kullanımda Next tek başına öne çıkıyor
-
RSC ile framework/bundler entegrasyonunun yapısı
- "RSC neden mutlaka bir framework veya bundler gerektiriyor?" sorusu sıkça geliyor
- Mevcut SSR (
renderToString, renderToPipeableStream) her yerde çalıştırılabilirken, RSC yapısal olarak çok daha karmaşık
- Kod içindeki
'use client', 'use server' direktiflerinin yorumlanması
- İstemci/sunucu component'lerinin ayrıştırılması ve kaydının otomatik yapılması gereği
- Tüm modül grafiğini analiz edip derleyen bundler'larla (ör. Webpack, Vite vb.) sıkı entegrasyon zorunluluğu
- React çekirdeği yalnızca RSC'nin temel mantığını ve veri serileştirme API'sini sağlıyor; gerçek çalışma, routing, endpoint çağrıları gibi konular framework'ün sorumluluğunda
- Her framework'te RSC'nin kullanım biçimi, mimarisi ve uygulaması farklı
- Next.js App Router kendi layout ve routing kurallarını uyguluyor
- Parcel, Waku, React Router gibi araçlar farklı tasarımlar benimsiyor
- Özet:
- RSC, React çekirdeğine gömülü hibrit bir özellik olsa da, pratikte kullanılabilmesi için mutlaka bundler/framework entegrasyonu gerekir
- Framework desteklemediği sürece RSC'nin güçlü yanlarından gerçekten yararlanmak mümkün değil
Topluluktaki endişeler ve kafa karışıklığı
-
1. "Vercel React'i ele geçirdi" endişesi
- Vercel'in önemli React ekip üyelerini işe alması ve Next.js'in belgelerde/örneklerde öne çıkması, “Vercel React geliştirmesine yön veriyor” şüphesini yaydı
- Gerçekte ise RSC vizyonuna ve Next App Router yapısına yön veren taraf React ekibiydi; Vercel daha çok destekçi ve deney alanı rolündeydi
- Yani Vercel'in React'i "ele geçirmesinden" çok, React çekirdek ekibinin bir bölümünün Vercel'e geçerek bu vizyonu hayata geçirmesi söz konusu
-
2. "React artık sadece Next üzerinde çalışıyor" yanlış anlaması
- Yalnızca Next.js'in tek production RSC uygulaması olarak öne çıkması bu yanlış anlamayı doğurdu
- React resmi dokümantasyonunda, Next dışında da farklı framework'ler ve framework'süz kullanım biçimleri anılıyor
- Next, yalnızca React tabanlı bir framework'tür; React tek başına veya başka araçlarla da kullanılmaya devam edebilir
-
3. "İstemci uygulamalarında React ortadan kalkabilir" kaygısı
- Sunucu özelliklerinin (RSC, SSR vb.) vurgulanması, SPA/istemci desteğinin sona ereceği endişesini doğurdu
- React'in istemci tarafı render özelliği asla ortadan kalkmayacak
- Meta gibi büyük kod tabanları da istemci tarafı yaklaşımı yoğun biçimde kullanıyor
- React ekibi uyumluluk ve geçiş desteği konusunda çok titiz davranıyor
-
4. "React neden framework kullanımını dayatıyor?"
- React ekibi; veri çekme, routing ve SSR entegrasyonu gibi alanlarda framework'lerin verimlilik ve performans avantajlarını gerekçe göstererek bunu varsayılan öneri haline getirdi
- Tutumları kabaca, "elle kurulum (özel SPA) uzun vadede verimsizdir, framework'ler sektör standardıdır" şeklinde
- Oysa pratikte farklı kullanım kalıpları var ve öneri aşırı tek tip hale geldi
- Başlangıç bariyeri, sunucu barındırma sınırlamaları olan şirketler ve SPA hosting'in basitliği gibi gerçek nedenlerle SPA hâlâ geçerli
- Resmi belgelerde "framework'süz yaklaşım"ın ikincil konuma düşmesi toplulukta dışlanmışlık hissi yarattı
-
5. Resmi dokümantasyonun sınırları ve iyileştirme tartışması
- CRA (
react-scripts) resmen deprecated oldu, fakat alternatif araçlardan (Vite vb.) geç söz edilmesi kafa karışıklığını artırdı
- SPA gibi "framework'süz" yaklaşımlar da artık resmi olarak kabul edilip rehbere eklendi (2025 güncel dokümantasyonu)
- Vite gibi ana build araçlarının resmi belgelerde geç anılması nedeniyle topluluk ve ekosistem figürleri (ör. Evan You) de eleştiri getirdi
- Güncellenmiş belgeler artık SPA, Vite/Parcel/RSPack gibi seçenekleri öneriyor ve router/veri çekme tercihleri için rehber sunuyor
-
6. RSC için resmi belgelerin ve açıklamaların yetersizliği
- Next.js, Vercel gibi dış kaynaklarla karşılaştırıldığında React resmi belgelerinde RSC açıklamaları ve kavramsal rehberlik yetersiz
- Bilgiler çoğunlukla yalnızca API Reference içine dağılmış durumda; genel kavramlar ve uygulama rehberi eksik
- Topluluk ve Dan Abramov gibi önde gelen isimler bunları tamamlamaya çalışsa da, resmîleşmemiş olması sürekli kafa karışıklığı yaratıyor
- RSC'nin kavramı, mimarisi, kullanım örnekleri ve SSS'si için ayrı dokümantasyon bölümlerine ihtiyaç var
Başlıca endişelere dair özet
- Framework ve sunucu özelliklerinin öne çıkarılmasının “Vercel'in çıkarı için” yapıldığı yönündeki yanlış algı toplulukta kök saldı, ancak gerçekte durum böyle değil
- Yine de React ekibinin iletişim biçimi ve resmi belgelerdeki ifade tarzı bu yanlış anlamayı büyüttü
- React'in istemci tarafı rendering özellikleri gelecekte de korunacak; sunucu özellikleri (RSC/SSR vb.) yalnızca bir seçenek, yani SPA gibi mevcut yaklaşımlar kullanılmaya devam edebilir
- Topluluktaki kaygı ve karmaşanın bir nedeni de React ekibinin zayıf iletişimi ve yetersiz geliştirici ilişkileri (DevRel) çalışmaları
- Resmî pozisyonun netleştirilmesi, yanlış anlamaların giderilmesi ve farklı kalıpların tanınıp açıklanması gerekiyor
- “Framework kullanımı” önerisi iyi niyetle başlamış olsa da, pratikte fazla tekdüze hissedildiği ve farklı kullanım kalıplarını dışladığı yönünde eleştiriler var
- 2025 sonrasında resmi dokümantasyon iyileşerek SPA/özel build yaklaşımlarını da tanıyıp rehber ekledi, ancak topluluk geri bildirimlerinin yansıması uzun sürdü
- RSC (React Server Components) kavramı ve trade-off'ları gibi temel konular için resmi belgelerin güçlendirilmesi gerekiyor
- Bu, topluluğun doğru anlamasına ve gereksiz tartışmaların önlenmesine yardımcı olur
Son söz
- Metin; React'in nasıl geliştiği, hangi etkiler ve hedefler altında geliştirildiği ve mevcut ekosistemde kullanım kalıplarının nasıl şekillendiği gibi çeşitli sorulara yanıt sunuyor
- React ekibinin yönelimi ve değişimleri etrafında oluşan kafa karışıklığını ve FUD'u (korku, belirsizlik, şüphe) gidermeyi amaçlıyor
- Teknik yönelime katılmasanız ya da RSC/büyük framework'leri kullanmayı gerekli görmeseniz bile, React ekibinin niyeti ve yönü yeterince makul
- React ekibinin politikası, performansı standartlaştırma ve topluluğun UX'ini iyileştirme gibi iyi niyetli amaçlardan doğdu, ancak dostça olmayan iletişim ve dokümantasyon gereksiz karmaşayı büyüttü
- SPA'lere, framework'lere ve farklı build araçlarıyla oluşan gerçek kullanım çeşitliliğine daha fazla saygı ile resmi belgelerde iyileştirme ihtiyacı büyüyor
- Bundan sonra topluluk geri bildirimini yansıtan, farklı mimarileri kapsayan dokümantasyon iyileştirmeleri ve açık iletişim, React'in sağlıklı gelişimi için kritik olacak
16 yorum
React, sanki bazı vidaları eksik, tamamlanmamış bir kütüphane gibi hissettiriyor... Mesela
useEffectresmi dokümantasyonunda üst üste yazılanlara bakınca... insan sadece afallıyor... Bu kadar çok tavşan deliği açıp sonra da iyi kullanın tavrı neyin nesi... Bana sık sık çok da düşünmeden geçici yamalarla durumu idare etme hissi veriyor.AWS'de olaylar patlarken izleyince yine... insanın aklına böyle düşünceler geliyor.
İyileştirme önerisi sunamıyorsan, sen juniorsun
React Native tarafında da benzer bir hava var. React için Next.js neyse, React Native için de Expo o. Resmî belgeler de Expo framework'ünün kullanılmasını öneriyor ve eski CLI yöntemi artık bulunması zor bir hâle gelmiş.
Aslında burada web frontend geliştirme konuları epey az paylaşılıyor... Buna rağmen son zamanlarda nextjs'in çok fazla anılması bana pek hayra alamet gelmiyor.
Sanki sadece Server Component sorunlu, diğer her şey iyiymiş gibi bir hava var.
JS/FE tarafında ekosistem bir kez tamamen çöküp baştan resetlensin lütfen. Ve state management gibi şeyleri de en baştan içine katan bir framework yapılsın. Aşırı fazla seçenek mi? Bu özgürlük değil, sadece düpedüz sorumsuzluk.
Framework’lerin rahat olmasıyla React’in kendi içinde CRA’den vazgeçmesi bence tamamen farklı düzeyde meseleler. Güncellenen React belgelerinde pat diye Next kurmanızı söyleyince biraz tuhaf hissetmiştim; demek ki bunu hisseden sadece ben değilmişim.
Vercel ile React geliştirme ekibinin ayrı olduğunu sanıyordum ama aslında aralarındaki bağ daha derinmiş.
React ile yalnızca UI etkileşimleri, iç durum hesaplama ve durum gösterimi gerektiren oyun prototiplemesi yapıyorum. Birkaç yıl önce
create-react-appresmi belgelerden çıkarılmak üzereyken olan dönemle karşılaştırınca, son zamanlarda resmi belgelere bakarak kurulum yapmanın biraz daha zor olduğunu hissettim. O zaman yazdığım yazı bununla biraz ilgili olabilir.RSC’nin en başından beri Next.js tabanlı olarak geliştirildiği gerçeği pek de farklı görünmüyor.
Buna bir de Next.js’in Vercel dışındaki ortamlarda giderek daha fazla tökezlemesini ekleyince
React ekibinin kendi içinde ne düşündüğünü bilmiyorum ama mantık akışı "RSC gelecektir! Ama RSC’yi çalıştırmak için Next.js’i öneriyoruz ve Next.js’i de Vercel’de kullanın" noktasına geliyor; bunun Vercel’in çıkarlarıyla ilgisi yok mu derseniz, hmm...
Ne kadar bunun bir yanlış anlama olduğunu söyleseler de, sonuçta insanlar Vercel’in React’i ele geçirdiğini düşünmekten kendini alamıyor ve bu yanlış anlamayı gidermek için de hızlı bir şekilde harekete geçmediler, değil mi?
Şu anda bile React’in resmi sitesi, Meta tarafındaki sunucularda değil, Vercel üzerinde çalışıyor.
Katılıyorum.
Aynı şekilde Vercel’in yatırım yaptığı Svelte’in de ölçeği daha küçük olduğu için mi bilmiyorum ama böyle bir vendor lock-in durumunun yaşandığını hiç hissetmedim; aradaki farkın ne olduğunu da merak ediyorum.
Svelte yalnızca Vercel tarafından destekleniyor; Vercel tarafından yönlendirilmiyor. Buna karşılık Next ise doğrudan Vercel tarafından yönlendiriliyor.
GitHub deposu açısından da Next, Vercel organizasyonunun altında yer alırken Svelte öyle değil.
Ayrıca Next.js’in resmi sitesinin footer kısmındaki telif hakkı ibaresinde Vercel yer alıyor, ancak Svelte’de böyle bir şey yok.
Vercel'in Rich Harris'i işe alması meğer sponsorluk niteliğindeymiş.
https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Evet, bu daha çok sponsorluk niteliği ağır basan bir istihdam. Yani Svelte geliştirmesine tam zamanlı odaklanabilmesi için maaş ödüyorlar. Vercel tarafı da Svelte'in hâlâ bağımsız bir proje olduğunu açıkça belirtti.