Create React App’ten Neden Vazgeçildi?
Herkese merhaba,
Bugün CRA (Create React App)’dan neden vazgeçildiği ve alternatiflerinin neden kullanılması gerektiğinden bahsedeceğim.
Başlamadan önce bazı şeylerden bahsedelim…
React’ın yeni dökümasyon sitesi yakın zamanda yayına alındı ve birçok kişi değişen dökümanla birlikte şaşkına döndü. Böyle bir şeyi çoğu kişi beklemiyordu ancak JavaScript dünyası dünle bugünün savaşı. Haliyle Create React App(CRA)’in geri plana atılması aslında beklenebilecek bir durumdu. Çok fazla seçenek oluşmaya ve geliştirilmeye başlandı ve bu değişimler bir nevi aslında buna sebep oldu diyebiliriz.
React’ın artık kendi blog yazısından da anlayacağımız üzere CRA’ya yer verilmiyor bunun yerine Next(web), Gatsby(web), Remix(web) ve Expo(native) gibi frameworklerden yararlanılması öneriliyor. 3 seçenek görüyoruz ancak 4ncü seçenek araya gizlenmiş :) bundan da zaten bahsedeceğim(Vite).
Ancak bunları belki kullanmak istemeyebilirsiniz. Benim de çok severek ve zevk alarak kullandığım Vite bir alternatif veya ek bir alternatif olarak Percel bizlere eşlik edebilir. Zaten sizlerle paylaşacağım bu yazı dizisinde Vite’ın önemi oldukça vurgulanmakta ve ben CRA , Vite ve Next karşılaştırması yaparak ilerleyeceğim. Böylelikle Vite’ı da bu yazı dizisinde biraz da olsa anlayacağız.
Gelin hep beraber konunun derinliklerine inmeye başlayalım.
React Nedir?
React, etkileşimli kullanıcı uygulamaları oluşturmak için internetin en popüler web kitaplığıdır ve React gibi çerçevelerin nasıl kullanılacağına ilişkin bilgi, her web geliştiricisinin araç kutusunun temel parçasıdır(ben dahil). Yani yoldan(internet) geçen kime sorsanız React ismini, logosunu görmüştür ve bir çoğu React ile geliştirme yapmıştır.
“React kullanılarak bir uygulama nasıl oluşturulur” dendiğinde ilk akla gelen create-react-app değil midir?
Bu sorunun cevabı kesinlikle “Evet”tir ki ilerleyen süreçlerde bile birçoğumuzun aklına create-react-app gelecektir diye düşünüyorum. Çünkü, React’i anlamadan frameworklerini anlamaya çalışmak biraz zor. Çalışma mantığı, VDOM, mimarisi vb. konuları kavramadan SSG veya SSR destekli bir framework kullanmaya çalışmak, öğrenim sürecinde 2 katı zor olacaktır.
Zaten internette bulunan eğitim ve üretilen içeriklerin ilk/tek yanıtı npx create-react-app’tir(CRA) ve hepsi CRA ile başlar. Tabi alternatiflerinin de oldukça eğitimi fazla ancak ilk kez öğrenen birisi için karmaşık gelebilir. Ancak temel farklı olsa da hemen hemen çoğu adım aynı. Tabi performans farklılıkları, ortam değişikliği ya da production ortamı değişebilir. Bunlar buradan sonraki adımlardır.
Şimdi asıl konumuza gelelim…
Peki bu sorunun cevabı CRA iken neden bu şekilde bir hamle geldi ve neden CRA’dan vazgeçildi? Bu gibi sorulara sizle birlikte cevap bende aradım ve hem kendim bildiklerim hem de internetten kazanmış olduğum bilgileri sizler için derleyeceğim. Bu yazı içerisinde sizinle CRA’nın neden kullanılmaması gerektiğini ve benim de severek kullandığım Vite’ı sizinle paylaşacağım.
Create React App Neden Var?
Yapısı
Create React App, JavaScript dosyalarını bir araya getirmek için Client Side Rendering (CSR) kullanır ve tümünü istemcide işlemek için tek bir dosya oluşturur. React’in varsayılan yapılandırmasında Server Side Rendering (SSR) erişimi olmadığı için, tüm bunlar kullanıcının tarayıcısına indirilir ve burada çalıştırılır. Yani yük son kullanıcıya yansıtılır.
Create React App, bir projenin içindeki her şeyi ve kullanılmakta olan tek bağımlılığı soyutlar; yeni başlayanlar içinreact-scripts harikadır ancak endişe edilecek bir şeyleri ortadan kaldırır(!) Bu nedenle, yaygın soyutlamadan yola çıkarak; Create React App’teki çok sayıda aşırı basitleştirmeyle uğraşmak, JavaScript’in hayati kısımlarını anlamada bazı sorunlara yol açabilir. Bir acemi hangi compiler(Babel) veya bundler(Webpack) kullanıldığını bilmiyor olabilir.
Bu makaleyi okuyarak yukarıdaki paragrafı kendiniz için daha anlaşılır kılabilirsiniz.
Ancak endişelenmezine gerek yok bunlar JavaScript ile web geliştirme döngüsünün çok önemli yapı taşlarıdır ve zamanla hem doğrudan kendilerini hem de alternatiflerini öğreneceksiniz.
Babel ve Webpack ile ilgili bilgi edinmek için tıklayın.
React geliştirme ortamı hakkında bilgi edinmek için tıklayın.
Konuyu çok daha uzatmadan ve daha detaylı olarak React’in geliştiricilerinden olan Dan Abramov’dan bu konu ile alakalı bir alıntıyı sizinle paylaşmak isterim.
…
Bu tartışmaya tarihsel bir bağlam sağlamak için Create React App’in hikayesini yeniden gözden geçirmek ve gelişimini izlemek istiyorum.
Create React App’i 2016'da yayınladığımızda, tooling landscape parçalara ayrılmıştı ve entegre değildi. Mevcut bir uygulamaya React ekliyorsanız, bir <script> etiketi veya npm’den bir içe aktarma ekliyor ve ardından mevcut derleme aracı yapılandırmanızı ayarlıyordunuz. Ancak sıfırdan sadece React ile oluşturulmuş yeni bir uygulama oluşturuyorsanız, bunu yapmanın net bir yolu yoktu.
Create React App’ten önce, bir dizi araç yüklemeniz ve bunları birbirine bağlamanız, JSX’i kullanmak için doğru presets(ön ayarları) sağlamanız, bunları geliştirme ve üretim ortamları için farklı şekilde yapılandırmanız, varlık önbelleğe alma için doğru ayarları sağlamanız, linter’ı yapılandırmanız vb. gerekiyordu. Bunu doğru bir şekilde yapmak çok zordu. İnsanlar bununla, klonlayabileceğiniz “boilerplate” repositories (depoları) oluşturarak ve paylaşarak başa çıktılar. Ancak, bu farklı bir sorun yarattı: Şablonunu klonladıktan ve projeniz için ayarladıktan sonra, güncellemeleri çekmek zordu. Proje kurulumunuz eskiyor ve güncellemekten vazgeçiyor ya da tüm araçların yeniden birlikte çalışması için çok çaba harcıyordunuz. Hızlı hareket eden bir ekosistemde bu çok zordu.
Create React App bunu, çeşitli araçları tek bir paket altında birleştirerek, makul bir varsayılan yapılandırma seçerek ve ardından araçlar arasındaki tüm küçük uyumsuzlukları gidererek çözdü. Artık React ile yeni bir proje başlatmak istiyorsanız, bunu yapmanın önerilen tek ve net bir yolu vardı! Daha sonra, arada bir bu paketi güncelleyecek ve tüm temel araç güncellemelerini “ücretsiz” olarak alacaktınız. Bu model o kadar popüler oldu ki bugün bu şekilde çalışan bir araç kategorisi var. Vite gerçekten de benzer bir vizyonu paylaşan ve bazı açılardan bunu daha da ileri götüren en iyi araçlardan biri.
Create React App’in amacı, React kullanıcılarının çoğunluğu için yeni bir React web uygulaması başlatmanın en iyi yolunu sağlamaktı. Birlikte çalışan, seçilmiş bir dizi özelliği destekliyordu. Zamanla, kutudan çıktığı haliyle sunduklarının “temel çizgisi”, doğru tradeoff (ödünleşimleri) buldukça genişleyecekti. Örneğin, runtime (çalışma zamanı) hataları için bir error boundary (kaplama) ekledik. Farklı stil seçenekleri için destek ekledik. Bileşeninizin kodunu kaydetmenize ve durumu kaybetmeden değişiklikleri görmenize olanak tanıyan Hızlı Yenileme özelliğini varsayılan olarak ekledik. Bu, varsayılan React geliştirici deneyimi için büyük bir dönüm noktasıydı. Genel olarak, Create React App compilation pipeline (derleme işlem hattı) üzerinde tam kontrole sahip olduğundan, herkes için derleme ile ilgili özellikler eklemek kolaydı.
Bunun gibi seçilmiş bir kuruluma sahip olmak ekosistem için değerli olmaya devam ediyor. React Hooks çıktığında, React Hooks lint kurallarını varsayılan kuruluma ekledik. Create React App, bir projeye başlamanın kolay bir yolu olmasının yanı sıra, React ekibinin önemsiz olmayan araç değişikliklerini (Fast Refresh desteği, React Hooks lint kuralları) mümkün olan en geniş kitleye dağıtmasına da olanak tanıdı. React ekibi tarafından seçilmiş popüler bir şablon olmasaydı, bu araç değişikliklerini bu kadar geniş bir kitleye yaymak zor olurdu.
….
CRA olmadan bir React web uygulaması nasıl oluşturulur tıklayarak bilgi edinebilirsiniz.
Neden Vazgeçildi?
Yavaş ve Hantal
CRA’nın en büyük sorunu aslında bu iki kelime. Çok aşırı yavaş ve hantal kalıyor, haliyle bu onu bir çok araca göre geride bırakıyor. Ayrıca proje büyüklüğü, deployment süreçleri gereğinden oldukça fazla uzun sürüyor. Hatta bir projeyi localinizde bile ayağa kaldırmanız, dev ortamında geliştiriyor olmanız bile bunun bir göstergesi. CRA’yı yeni kullanmaya başlayanlara bu uzun süreçler belki normal gelebilir ancak emin olun öyle değil.
İlk projenizi localinizde oluşturmaya başladığınızdaki süreç ki bu süre internet hızınıza, bilgisayarınızın özelliklerine göre 5–15 dakika veya daha fazlasına ihtiyaç duyuyor. Zamanla büyüyen projelerinizin bir kopyasını bilgisayarınıza kurmaya çalıştığınızda bu süre varolanın bazen 2 katına bile çıkabiliyor. Developer ortamındaki compile süreleri büyüyen proje ile 2 katı yavaşlıyor. Böyle böyle daha çok hantallaştığını ve aşırı yavaşladığını zamanla gözlemliyorsunuz.
Peki bu kadar büyük ve büyüyen proje yapısı?
CRA’nın dependencies (bağımlılıklar) klasörüne node_modules dikkatlice baktığımızda, klasör boyutunun büyük olduğunu gözlemleyebilirsiniz. Gözünüze azmış gibi gelebilir ancak başlangıç için büyük bir boyut ve ilerleyen vakitlerde siz projenize package (paket) ekledikçe Gigabyte’larca bağımlılığınız olmaya başlıyor.
Şuan localimde kurulu ve bir kaç sayfa ve bir kaç paket barındıran projenin boyutu: 1,02 GB
CRA’nın tonlarca başka paket(ler)e gereksiz yere güvendiğini ve bu güvenin yıllar içerisinde arttığını geçmişine bakarak gözlemleyebilirsiniz. CRA geliştiricileri, bağımlılıkları kontrol etmek ve gerçekten ihtiyaç duyulanı seçmek yerine mevcut olanların üzerine ekleyerek ve ekleyerek devam etti. Bu durum daha boş bir projenin yüksek boyutlu bağımlılıklara ve güvensiz hatta yayından kalkmış paketleri bile dahil ettiğini gösterdi.
Sıfırdan kurulmuş bir React uygulaması 235,6 Megabyte bağımlılık barındırıyor, bu durum yaptığınız veya yapacağınız bir proje ortamını can sıkıcı hale getiriyor. Basit bir React uygulaması için bu boyutlar çok fazla.
Vite ile oluşturulmuş bir projenin bağımlılık klasör boyutu:
Burada Vite ile oluşturulmuş bir React uygulamasının bağımlılık klasörüne bakıyorsunuz ve boyutu sadece 33,9 Megabyte. Aralarında neredeyse 7 kat fark var :).
Daha küçük bağımlılıklar yalnızca daha hızlı yükleme ve başlatma süreleri anlamına gelmez: daha az bağımlılık aynı zamanda daha az şişkinlik ve karmaşıklık anlamına gelir; bu da geliştirme sırasında daha hızlı güncelleme süreleri, üretim sırasında daha hızlı oluşturma süreleri ve son kullanıcılarımız için daha hızlı ön uçlar anlamına gelir.
Next ile oluşturulmuş bir projenin bağımlılık klasör boyutu:
Next için de durum üzücü :/
Not: Yukarıdaki boyutlar işletim sistemine göre bir kaç Megabyte değişiklik gösterebilir.
Eskimiş(Modası Geçmiş) ve Güvenli Değil
“96 vulnerabilities (85 moderate, 11 high)” diyerek cümleme başlamamda sorun yok sanırım. Hepimiz renkli terminal görmeyi severiz ancak 11'i kırmızı 85'i sarı line ile dolu dolu açık bulunduran paketleri görmek kimse istemez sanırım? CRA 3–5 aya bir (yılın çeğreğinde bile değil bazen) küçük güncellemeler alır, büyük güncellemeler ise yılda bir kez yapılır. Haliyle bu da CRA’yı güvensiz kılar.Ancak merak etmeyin(!) CRA 5.0'dan sonra biraz daha işler değişti! Bazen araştırmaya düştüğünüzde bu paketlerin kullanımdan kaldırıldığını bile gözlemleyebilirsiniz.
Plugin Uyumluluğu Berbat
Bir örnek üzerinden gidecek olursak; TailwindCSS.
TailwindCSS’i CRACO kullanmadan projemizde kullanamıyorduk. Düşünsenize ardı önü bir stillendirme kütüphanesi neden gereksiz ve ek paketlere ihtiyaç duyuyor? CRA 5.0 sürümüyle birlikte bu sorunu aştı ancak tarihe CRA adına kötü bir iz kaldı.
Tamamen İstemci(Client) Odaklı
CRA’nın CSR odaklı olduğunu biliyoruz. CSR’ın bizim için ne kadar çok güzel yanları olsa da, bir web uygulamasının tamamen istemci tarafında çalışması pekte isteyeceğimiz bir durum değil. Çünkü;
- SEO Sorunları: Tamamen CSR yapısı, arama motoru optimizasyonu (SEO) için sorunlar yaratabilir. Arama motorları, uygulamanın içeriğine erişemediği için, uygulamanın SEO’sunu düşürebilir. Bu sorun, özellikle büyük ölçekli e-ticaret siteleri için ciddi bir sorun teşkil edebilir.
- İlk Yükleme Süresi: Tamamen CSR yapısı nedeniyle, uygulamanın ilk yükleme süresi artabilir. Çünkü, uygulamanın tamamı tarayıcıda oluşturulduğu için, sayfa yükleme süresi daha uzun olabilir. Bu durum, kullanıcıların uygulamayı kullanmaya başlamadan önce beklemelerine neden olabilir.
- Güvenlik Açıkları: CSR yapısı, uygulamada güvenlik açıklarına neden olabilir. Özellikle, uygulamanın kullanıcıdan gelen verileri işlediği durumlarda, kötü amaçlı kullanıcıların saldırılarına karşı daha savunmasız hale gelebilir.
- Bellek Problemleri: CSR yapısı, uygulamanın bellek yönetimini zorlaştırabilir. Uygulamanın tüm front-end kısmı, tarayıcıda çalıştığı için, bellek tüketimi daha yüksek olabilir. Bu durum, daha eski tarayıcıların performansını düşürebilir ve düşük donanımlı cihazlar için sorun teşkil edebilir.
Geliştirme Ortamı Eksiklikleri
CRA, geliştirme ortamı için bazı eksikliklere sahiptir. Örneğin, CRA, özelleştirilmiş bir yapılandırma gerektiren projeler için uygun olmayabilir. Ayrıca, CRA, altta yatan Webpack ve Babel yapılandırmalarını yönetir, ancak bu yapılandırmalara tam kontrole sahip değilsinizdir. Bu nedenle, geliştirme sürecinde bazı sorunlar yaşayabilirsiniz.
Bu konuya daha fazla açık getirmesi adına tekrar Dan Abramov’dan alıntıyı sizinle paylaşıyorum.
…
Create React App, tasarımı gereği tamamen istemci taraflı bir uygulama üretir. Bu, onunla oluşturulan her uygulamanın boş bir HTML dosyası ve React ile uygulama paketinizi içeren bir <script> etiketi içerdiği anlamına gelir. Boş HTML dosyası yüklendiğinde, tarayıcı React kodunun ve tüm uygulama paketinizin indirilmesini bekler. Düşük bant genişliğine sahip bağlantılarda bu işlem biraz zaman alabilir ve bu sırada kullanıcı ekranda hiçbir şey görmez. Ardından, uygulama kodunuz yüklenir. Şimdi tarayıcının tümünü çalıştırması gerekir ki bu da güçsüz cihazlarda yavaş olabilir. Nihayet, bu noktada kullanıcı ekranda bir şeyler görür — ancak genellikle bazı verileri de yüklemeniz gerekir. Yani kodunuz bazı verileri yüklemek için bir istek gönderir ve kullanıcı bunun geri gelmesini bekler. Sonunda veriler yüklenir, bileşenler verilerle birlikte yeniden oluşturulur ve kullanıcı nihai sonucu görür.
Bu oldukça verimsizdir, ancak React’i yalnızca istemci üzerinde çalıştırırsanız daha iyisini yapmak zordur. Bunu Rails gibi bir sunucu çerçevesi ile karşılaştırın: bir sunucu veri getirme işlemini hemen başlatır ve ardından tüm verileri içeren sayfayı oluşturur. Ya da Jekyll gibi statik bir derleme zamanı çerçevesini ele alalım, bu da aynı şeyi yapar, ancak derleme sırasında statik bir barındırmaya dağıtabileceğiniz bir HTML+JS+CSS paketi üretir. Her iki durumda da kullanıcı, betiklerin yüklenmesini bekleyen boş bir dosya yerine tüm bilgileri içeren HTML dosyasını görecektir. HTML web’in temel taşıdır — öyleyse neden bir “React uygulaması” oluşturmak boş bir HTML dosyası üretiyor? Neden web’in en temel özelliğinden, yani tüm etkileşimli kodlar yüklenmeden önce içeriği hızlı bir şekilde görebilme özelliğinden faydalanmıyoruz? Neden verileri yüklemeye başlamak için istemci tarafındaki tüm kodların yüklenmesinin bitmesini bekliyoruz?
Create React App sorunun yalnızca bir tarafını çözdü. İyi bir (o zamanlar!) geliştirme deneyimi sağladı, ancak iyi bir kullanıcı deneyimi için web’in güçlü yanlarından yararlanmanıza yardımcı olacak yeterli yapıyı dayatmadı. Bu sorunları kendiniz çözmeyi deneyebilirdiniz, ancak bu, kurulumunuzu “çıkarmayı” ve önemli ölçüde özelleştirmeyi içerirdi, bu da Create React App’in amacını ortadan kaldırırdı. Gerçekten verimli her React kurulumu özeldir, farklıdır ve Create React App ile başarılamaz.
Bu kullanıcı deneyimi sorunları Create React App’e özgü değildir. Hatta React’e özgü bile değiller. Örneğin, Preact, Vue, Lit ve Svelte için Vite ana sayfa şablonlarından oluşturulan uygulamalar da aynı sorunlardan muzdariptir. Bu sorunlar, statik site oluşturma (SSG) veya sunucu tarafı oluşturma (SSR) içermeyen tamamen istemci tarafı uygulamaların doğasında vardır.
Her ne kadar Facebook.com’un Hack/XHP rendering’den React’e yeniden yazılması SSR olmadan gerçekleştirilememiş olsa da (ki bu performans açısından kritik bir öneme sahipti), yukarıda açıklanan sorunlar Facebook gibi büyük uygulamaları benzersiz bir şekilde etkilemez. Tam tersine! Tamamen React’te geliştirilen birçok uygulamayı düşünürseniz, SSG veya SSR’den faydalanabilecek her türlü içerik odaklı uygulamayı bulabilirsiniz. Portföyler, bloglar, gazeteler, e-ticaret mağazaları — boş HTML dosyaları sunmak onlar için mantıklı değil. Bu nedenle içerik odaklı siteler için her zaman SSG özellikli React framework’lerini kullanmayı öneriyoruz.
…
Dan Abramov’dan alıntı yapmış olduğum GitHub Issues’un tamamının çevirisi;
Herkese merhaba.
Bunun bir süredir bir sorun olduğunu biliyoruz ve bunu ele almak için bir teklif üzerinde çalışıyoruz. Bu Pull Request bir tartışma başlatmayı amaçladığından, Create React App’in geleceği hakkındaki düşüncelerimiz hakkında biraz arka plan sağlamak için iyi bir zaman gibi görünüyor. Gerekçelerimiz ve düşündüğümüz tradeoffs hakkında net olmak istiyoruz, bu nedenle bu birkaç bölümden oluşan uzun bir yorum olacak. Sabırsız hissediyorsanız, ileriye dönük önerimiz için son bölüme kaydırın.
React Uygulaması Neden Var?
Bu tartışmaya tarihsel bir bağlam sağlamak için Create React App’in hikayesini yeniden gözden geçirmek ve gelişimini izlemek istiyorum.Create React App’i 2016'da yayınladığımızda, tooling landscape parçalara ayrılmıştı ve entegre değildi. Mevcut bir uygulamaya React ekliyorsanız, bir <script> etiketi veya npm’den bir içe aktarma ekliyor ve ardından mevcut derleme aracı yapılandırmanızı ayarlıyordunuz. Ancak sıfırdan sadece React ile oluşturulmuş yeni bir uygulama oluşturuyorsanız, bunu yapmanın net bir yolu yoktu.
Create React App’ten önce, bir dizi araç yüklemeniz ve bunları birbirine bağlamanız, JSX’i kullanmak için doğru presets(ön ayarları) sağlamanız, bunları geliştirme ve üretim ortamları için farklı şekilde yapılandırmanız, varlık önbelleğe alma için doğru ayarları sağlamanız, linter’ı yapılandırmanız vb. gerekiyordu. Bunu doğru bir şekilde yapmak çok zordu. İnsanlar bununla, klonlayabileceğiniz “boilerplate” repositories (depoları) oluşturarak ve paylaşarak başa çıktılar. Ancak, bu farklı bir sorun yarattı: Şablonunu klonladıktan ve projeniz için ayarladıktan sonra, güncellemeleri çekmek zordu. Proje kurulumunuz eskiyor ve güncellemekten vazgeçiyor ya da tüm araçların yeniden birlikte çalışması için çok çaba harcıyordunuz. Hızlı hareket eden bir ekosistemde bu çok zordu.
Create React App bunu, çeşitli araçları tek bir paket altında birleştirerek, makul bir varsayılan yapılandırma seçerek ve ardından araçlar arasındaki tüm küçük uyumsuzlukları gidererek çözdü. Artık React ile yeni bir proje başlatmak istiyorsanız, bunu yapmanın önerilen tek ve net bir yolu vardı! Daha sonra, arada bir bu paketi güncelleyecek ve tüm temel araç güncellemelerini “ücretsiz” olarak alacaktınız. Bu model o kadar popüler oldu ki bugün bu şekilde çalışan bir araç kategorisi var. Vite gerçekten de benzer bir vizyonu paylaşan ve bazı açılardan bunu daha da ileri götüren en iyi araçlardan biri.
Create React App’in amacı, React kullanıcılarının çoğunluğu için yeni bir React web uygulaması başlatmanın en iyi yolunu sağlamaktı. Birlikte çalışan, seçilmiş bir dizi özelliği destekliyordu. Zamanla, kutudan çıktığı haliyle sunduklarının “temel çizgisi”, doğru tradeoff (ödünleşimleri) buldukça genişleyecekti. Örneğin, runtime (çalışma zamanı) hataları için bir error boundary (kaplama) ekledik. Farklı stil seçenekleri için destek ekledik. Bileşeninizin kodunu kaydetmenize ve durumu kaybetmeden değişiklikleri görmenize olanak tanıyan Hızlı Yenileme özelliğini varsayılan olarak ekledik. Bu, varsayılan React geliştirici deneyimi için büyük bir dönüm noktasıydı. Genel olarak, Create React App compilation pipeline (derleme işlem hattı) üzerinde tam kontrole sahip olduğundan, herkes için derleme ile ilgili özellikler eklemek kolaydı.
Bunun gibi seçilmiş bir kuruluma sahip olmak ekosistem için değerli olmaya devam ediyor. React Hooks çıktığında, React Hooks lint kurallarını varsayılan kuruluma ekledik. Create React App, bir projeye başlamanın kolay bir yolu olmasının yanı sıra, React ekibinin önemsiz olmayan araç değişikliklerini (Fast Refresh desteği, React Hooks lint kuralları) mümkün olan en geniş kitleye dağıtmasına da olanak tanıdı. React ekibi tarafından seçilmiş popüler bir şablon olmasaydı, bu araç değişikliklerini bu kadar geniş bir kitleye yaymak zor olurdu.
React Uygulaması Oluşturma ile ilgili sorunlar
Yıllar geçtikçe, Create React App durgunlaştı. Birçok kişi bu başlıkta alternatiflerinden daha yavaş olduğunu ve insanların bugün kullanmak istediği bazı popüler araçları desteklemediğini belirtti. Prensip olarak bu sorunları çözebiliriz. Örneğin, daha hızlı bir paketleyici kullanmak veya hatta Vite’ı dahili olarak kullanmak için Create React App’in iç kısımlarını güncelleyebiliriz. Ya da insanlara Create React App’ten Vite gibi bir şeye geçmelerini önerebiliriz. Ancak, ele almak istediğimiz çok daha derin bir sorun var.
Create React App, tasarımı gereği tamamen istemci taraflı bir uygulama üretir. Bu, onunla oluşturulan her uygulamanın boş bir HTML dosyası ve React ile uygulama paketinizi içeren bir <script> etiketi içerdiği anlamına gelir. Boş HTML dosyası yüklendiğinde, tarayıcı React kodunun ve tüm uygulama paketinizin indirilmesini bekler. Düşük bant genişliğine sahip bağlantılarda bu işlem biraz zaman alabilir ve bu sırada kullanıcı ekranda hiçbir şey görmez. Ardından, uygulama kodunuz yüklenir. Şimdi tarayıcının tümünü çalıştırması gerekir ki bu da güçsüz cihazlarda yavaş olabilir. Nihayet, bu noktada kullanıcı ekranda bir şeyler görür — ancak genellikle bazı verileri de yüklemeniz gerekir. Yani kodunuz bazı verileri yüklemek için bir istek gönderir ve kullanıcı bunun geri gelmesini bekler. Sonunda veriler yüklenir, bileşenler verilerle birlikte yeniden oluşturulur ve kullanıcı nihai sonucu görür.
Bu oldukça verimsizdir, ancak React’i yalnızca istemci üzerinde çalıştırırsanız daha iyisini yapmak zordur. Bunu Rails gibi bir sunucu çerçevesi ile karşılaştırın: bir sunucu veri getirme işlemini hemen başlatır ve ardından tüm verileri içeren sayfayı oluşturur. Ya da Jekyll gibi statik bir derleme zamanı çerçevesini ele alalım, bu da aynı şeyi yapar, ancak derleme sırasında statik bir barındırmaya dağıtabileceğiniz bir HTML+JS+CSS paketi üretir. Her iki durumda da kullanıcı, betiklerin yüklenmesini bekleyen boş bir dosya yerine tüm bilgileri içeren HTML dosyasını görecektir. HTML web’in temel taşıdır — öyleyse neden bir “React uygulaması” oluşturmak boş bir HTML dosyası üretiyor? Neden web’in en temel özelliğinden, yani tüm etkileşimli kodlar yüklenmeden önce içeriği hızlı bir şekilde görebilme özelliğinden faydalanmıyoruz? Neden verileri yüklemeye başlamak için istemci tarafındaki tüm kodların yüklenmesinin bitmesini bekliyoruz?
Create React App sorunun yalnızca bir tarafını çözdü. İyi bir (o zamanlar!) geliştirme deneyimi sağladı, ancak iyi bir kullanıcı deneyimi için web’in güçlü yanlarından yararlanmanıza yardımcı olacak yeterli yapıyı dayatmadı. Bu sorunları kendiniz çözmeyi deneyebilirdiniz, ancak bu, kurulumunuzu “çıkarmayı” ve önemli ölçüde özelleştirmeyi içerirdi, bu da Create React App’in amacını ortadan kaldırırdı. Gerçekten verimli her React kurulumu özeldir, farklıdır ve Create React App ile başarılamaz.
Bu kullanıcı deneyimi sorunları Create React App’e özgü değildir. Hatta React’e özgü bile değiller. Örneğin, Preact, Vue, Lit ve Svelte için Vite ana sayfa şablonlarından oluşturulan uygulamalar da aynı sorunlardan muzdariptir. Bu sorunlar, statik site oluşturma (SSG) veya sunucu tarafı oluşturma (SSR) içermeyen tamamen istemci tarafı uygulamaların doğasında vardır.
Her ne kadar Facebook.com’un Hack/XHP rendering’den React’e yeniden yazılması SSR olmadan gerçekleştirilememiş olsa da (ki bu performans açısından kritik bir öneme sahipti), yukarıda açıklanan sorunlar Facebook gibi büyük uygulamaları benzersiz bir şekilde etkilemez. Tam tersine! Tamamen React’te geliştirilen birçok uygulamayı düşünürseniz, SSG veya SSR’den faydalanabilecek her türlü içerik odaklı uygulamayı bulabilirsiniz. Portföyler, bloglar, gazeteler, e-ticaret mağazaları — boş HTML dosyaları sunmak onlar için mantıklı değil. Bu nedenle içerik odaklı siteler için her zaman SSG özellikli React framework’lerini kullanmayı öneriyoruz.
React Frameworklerinin yükselişi
Bazı insanlar tamamen React’te oluşturmamayı tercih edebilir ve bu geçerli bir seçenektir. Örneğin, HTML sayfalarını sunucuda veya derleme sırasında Jekyll veya Astro gibi farklı bir araçla oluşturabilirsiniz. Bu, boş HTML dosyaları sorununu çözer, ancak iki işleme teknolojisini karıştırmanız gerekir (örneğin, sayfanın “dış” kısmı için Jekyll şablonları ve “iç” kısmı için React bileşenleri). Zamanla daha fazla etkileşim eklemek istediğinizde, bu teknolojik bölünme daha belirgin hale gelir.
Bu bölünme yalnızca geliştirici deneyimine zarar vermekle kalmaz, kullanıcı deneyimleri de zarar görür. Tamamen HTML merkezli olan ve React’ten tam olarak yararlanmayan araçlarla, her sayfa gezintisi tam sayfa yeniden yüklemeye dönüşür ve tüm istemci tarafı durumunu ortadan kaldırır. Günümüzde pek çok kullanıcı, 90'lar tarzı tam sayfa yeniden yüklemeler yerine sorunsuz uygulama içi gezinme (doğru ve erişilebilir bir şekilde yapıldığını varsayarak) beklemektedir. Benzer şekilde, birçok geliştirici uygulamalarını iki farklı render modelini karıştırmak yerine tek bir render modeli kullanarak oluşturmayı tercih ediyor. İnsanlar tüm uygulamalarını React ile oluşturmak istiyor. Biz de onlara bunu sağlamak istiyoruz.
Tüm uygulamaları React ile oluşturuyorsanız, SSG/SSR kullanabilmek önemlidir. Create React App’te bunlar için destek eksikliği göze çarpıyor. Ancak Create React App’in geride kaldığı tek alan bu değil. Ekosistemde yıllarca süren yeniliklerin ardından, diğer birçok sorunun artık React için olgun çözümleri var. Örneğin, network waterfalls (ağ şelalelerine) ve paket boyutuna bakalım.
Uygulamanız SSG veya SSR’den içerik odaklı siteler kadar faydalanmasa bile, muhtemelen network waterfalls (ağ şelalelerinden) muzdariptir. “onMount (Bağlandığında)” fetch(getirme) yapıyorsanız, ilk veri getirme işleminiz tüm kod yüklenene ve bileşenleriniz oluşturulana kadar başlamaz bile. Bu bir waterfall (şelaledir) — eğer uygulamanız kod hala yüklenirken veri getirmeye nasıl başlayacağını “biliyorsa” paralel olarak yapılabilir. Navigasyonda, bir üst ve bir alt bileşenin her ikisinin de bir şey getirmesi gerekiyorsa, bu daha da kötü waterfall (şelaleler) yaratır. React performansı hakkında konuştuğumuzda, pek çok uygulama için waterfall (şelalelerin) performans darboğazı olduğu gerçeğinden kaçış yoktur. Bu waterfall(şelaleleri) çözmek için veri getirmeyi routing (yönlendirme) ile entegre etmeniz gerekir ki Create React App bunu yapmaz.
Sabit bir paket boyutuna sahip olan React’in aksine, uygulama kodunuz eklediğiniz her yeni özellik ve ekstra bağımlılıkla büyümeye devam eder. Sık sık deploy(dağıtım) yapıyorsanız, uygulamanız her kullanımda çok yavaş yüklenebilir çünkü her zaman tüm kodu yüklemek zorunda kalacaktır. Bu sorunu çözmenin birkaç yolu vardır. Özelliklere “hayır” diyebilirsiniz, ancak bu her zaman işe yaramaz. Bazı kodları sunucuda veya derleme sırasında çalıştırmak üzere taşıyabilirsiniz (araçlarınız buna izin veriyorsa). İdeal olarak, kodu (route) rotaya göre de bölersiniz: bir gösterge tablosu sayfasının bir grafik oluşturması gerekiyorsa, bu grafiğin tüm uygulamasını hesap faturalandırma sayfasına yüklemenize gerek yoktur. Ancak, kod bölme işlemini manuel olarak yapmaya çalışırsanız, genellikle performansı daha da kötüleştirirsiniz. Örneğin, grafiği lazy load (tembelce yüklerseniz), ancak grafik verilerini “onMount (montaj sırasında)” yüklerse, başka bir waterfall (ağ şelalesi) daha oluşturmuş olursunuz. Bunu iyi bir şekilde çözmek, veri getirmeyi yönlendirme ve paketlemeyle entegre etmeyi gerektirir ki Create React App bunu yapmaz.
React’in kendisi yalnızca bir kütüphanedir. Routing (Yönlendirmenin) veya data fetching (veri getirmenin) nasıl yapılacağını dikte etmez. Create React App de öyle. Ne yazık ki bu, ne React’in tek başına ne de Create React App’in başlangıçta tasarlandığı gibi bu sorunları çözemeyeceği anlamına gelir. Gördüğünüz gibi, bu tek bir eksik özellik ile ilgili değil. Bu özellikler — sunucu tarafı işleme ve statik oluşturma, veri getirme, paket oluşturma ve yönlendirme — birbirine bağlıdır. Create React App çıktığında, React çok yeniydi ve bu özelliklerin en iyi şekilde nasıl bir araya getirileceği bir yana, her birinin tek başına nasıl çalışması gerektiği konusunda bile hala çözülmesi gereken çok şey vardı.
Zaman değişti. Artık bu özelliklere sahip olmamaya kilitlendiğiniz bir çözüm önermek giderek zorlaşıyor. Hepsini hemen kullanmasanız bile, ihtiyaç duyduğunuzda sizin için kullanılabilir olmalıdırlar. Bunlardan yararlanmak için farklı bir şablona geçmeniz ve tüm kodunuzu yeniden yapılandırmanız gerekmemelidir. Benzer şekilde, tüm veri getirme veya kod bölme işlemlerinin route-based (rota tabanlı) olması gerekmez. Ancak çoğu React uygulaması için mevcut olması gereken iyi bir varsayılandır.
Tüm bu parçaları kendiniz entegre edebilseniz de, bunu iyi bir şekilde yapmak zordur. Tıpkı Create React App’in derleme ile ilgili çeşitli endişeleri entegre etmesi gibi, Next.js, Gatsby ve Remix gibi araçlar daha da ileri giderek derlemeyi işleme, yönlendirme ve veri getirme ile entegre etti. Derleme, işleme, yönlendirme ve veri getirmeyi entegre eden bu araç kategorisi “frameworkler (çerçeveler)” olarak bilinir. (Ya da React’in kendisini bir çerçeve olarak adlandırmayı tercih ederseniz, bunlara “metaframeworks” diyebilirsiniz). Bu çerçeveler, çok daha iyi bir kullanıcı deneyimi sağlamak için uygulamanızı yapılandırma konusunda bazı görüşler dayatır. Pek çok geliştirici de bu çerçeveleri kullanmayı ergonomik bulmaktadır.
Bir mimari olarak React
React’in esnekliğini seviyoruz. React’i tek bir düğme oluşturmak için kullanabileceğiniz gibi tüm bir uygulamayı oluşturmak için de kullanabilirsiniz. Yirmi yıllık bir Perl web sitesinin içinde dahili bir gösterge tablosu oluşturmak için kullanabilir veya her şey için React kullanarak hibrit bir SSG/SSR e-ticaret web sitesi yapabilirsiniz. Bu esneklik çok önemli ve kullanıcılarımızın da bunu sevdiğini biliyoruz. Bundan vazgeçmeyeceğiz.
Bununla birlikte, tamamen React ile oluşturulmuş yeni uygulamalar için mümkün olan en iyi varsayılanları teşvik etmek istiyoruz. React uygulamaları oluşturmak için önerilen varsayılan yolun SSG ve SSR, otomatik kod bölme, istemci-sunucu waterfall (şelaleleri olmaması), rota ön getirme, istemci kullanıcı arayüzü durumunu koruyan gezinme ve harika bir kullanıcı deneyimi sağlayan diğer özellikler gibi özellikleri desteklemesi güzel olurdu. En azından, React uygulamaları oluşturmak için önerilen varsayılan yol, bunları etkinleştirmek için doğru endişeleri entegre etmeyen, doğası gereği yalnızca istemciye yönelik bir mimari nedeniyle bu özelliklerin tamamen dışında bırakılmamalıdır.
Bu bir fırsattır. Frameworks (Çerçeveler) için zorluk, bu kaygıları mükemmel performans ve ergonomi ile entegre etmektir. Ancak React için de bir zorluk söz konusuydu. React framework’lerinin harika kullanıcı deneyimleri sunmasına yardımcı olabilmemizin en iyi yolunun React’in temelindeki ilkellere odaklanmak olduğunu fark ettik. React’in kendisinin render katmanında yapabildiği ve framework’lerin diğer tüm katmanlarda yapabildiklerini güçlendiren benzersiz şeyler var. Örneğin, <Suspense> örneğinde olduğu gibi, tek bir React API’si, perde arkasında bir framework için bir dizi framework optimizasyonunun kilidini açabilir.
Bu nedenle React’i iki şey olarak düşünmeyi faydalı buluyoruz.
React bir kütüphanedir. Bu kütüphane, bileşenleri tanımlamanıza ve bir araya getirmenize olanak tanıyan bazı API’ler sağlar. React aynı zamanda bir mimaridir. Framework yazarlarının render modelinden tam olarak yararlanmasını sağlayan yapı taşlarını sağlar. React’i bir framework olmadan da kullanabilirsiniz. Ancak bir framework ile kullandığınızda, framework’ün React’in kendisinden en iyi şekilde yararlanabileceğinden emin olmak istiyoruz. Son birkaç yıldır geliştirdiğimiz özelliklerin çoğu (<Suspense>, useTransition, renderToPipeableStream gibi akış API’leri ve deneysel Sunucu Bileşenleri) framework odaklıdır. Frameworks (Çerçevelerin), paketlemeyi, yönlendirmeyi ve veri getirmeyi entegre ederek React’ten tam olarak yararlanmasını sağlarlar.
Bu özelliklerden bazılarının Next 13, Gatsby 5 ve Remix 1.11'de benimsendiğini görebilirsiniz. Hala yapılacak çok şey var ve bu çalışmaların bazıları deneysel aşamadan çıkma sürecinde (bu nedenle dokümantasyon hala seyrek). Yine de, yıllarca süren çabalarımızın sonuç verdiğini görmekten ve React çerçevelerini (ve kullanıcılarını) varsayılan olarak daha hızlı uygulamalar göndermeleri için güçlendirmekten heyecan duyuyoruz.
Bu da bizi bir sonraki noktaya getiriyor.
Bir kütüphane, birçok çerçeve
Tek bir React çerçevesinden daha fazlası var. Ve bu iyi bir şey.
Çalkantı konusundaki endişelere rağmen, React ekosistemi birçok oyuncuya sahip olduğu için daha iyi. Birbiriyle rekabet eden birden fazla veri getirme çözümü ve yönlendirme çözümü var. Seçenekler her yıl daha da iyi hale geliyor. Yönlendirme, veri getirme, işleme ve derlemeyi entegre eden birden fazla çözümün, yani birden fazla React çerçevesinin olması da şaşırtıcı olmamalı.
Bu şekilde kalmasını istiyoruz. Bununla birlikte, mümkün olduğu ve React ekosistemine fayda sağladığı durumlarda yakınsamayı da teşvik etmek istiyoruz. Örneğin, farklı çerçeveler veri yüklemek için farklı mekanizmalar kullanabilir. Bununla birlikte, hepsi göstergeleri yüklemek için <Suspense>’i benimserse, <Suspense>’in üstündeki üst düzey özelliklerimiz tüm çerçevelerle çalışacaktır. Çerçeveler için API’leri son haline getirmek ve belgelemek için hala çalışıyoruz, ancak React’ten en iyi şekilde yararlanmaları için onları güçlendirmek istiyoruz.
Bazı projeler hiçbir zaman herhangi bir popüler framework’ün kalıbına uymayacaktır ve bu sorun değildir. Belki de bir PHP sitesiyle entegre olması gereken dahili bir gösterge tablosu geliştiriyorsunuz ve hiçbir framework bunu kolayca yapmanıza izin vermiyor. Bu, Parcel gibi daha düşük seviyeli bir araç veya tamamen istemci tarafı Vite şablonları için harika bir kullanım alanıdır. Belki de uygulamanız bir çizim editörüdür, rotanız yoktur ve SSG’den bile çıkmak istiyorsunuzdur. Bunu her zaman destekledik ve destekleyeceğiz. React’i bir çerçeve mimarisinden ziyade bir kütüphane olarak kullanmaya devam etmek geçerli. Biz sadece bunun çoğu yeni web uygulaması için doğru varsayılan olmadığını savunuyoruz.
Çoğu React uygulaması için en iyi yol bir framework ile başlamaksa, hangi framework’ü önermeliyiz? Birini seçmeli miyiz? Hangisini seçeceğimize nasıl karar vereceğiz? Ya zaman içinde durgunlaşırsa? Teşviklerle ilgili daha hassas bir soru da var. Popüler ve bakımı iyi yapılan çerçeveler genellikle doğrudan ya da dolaylı olarak kendileriyle ilgili bazı ticari tekliflere sahiptir. Bu teklifler söz konusu çerçevelerin geliştirilmesini finanse edebilir, ancak insanları örneğin yalnızca belirli bir barındırma platformuyla çalışan bir ürüne doğru itmekten kaçınmak isteriz.
Bu da bizi bu başlıktaki soruya getiriyor.
Create React App ile ne yapmalıyız?
Create React App’in orijinal hedefleri şunlardı:
Yapılandırma olmadan yeni bir React projesi başlatmak için kolay bir yol sağlamak.
Kolayca yükseltilebilir olması için derleme ile ilgili bağımlılıkları entegre etmek.
React ekibinin araç güncellemelerini mümkün olduğunca geniş bir şekilde dağıtmasına izin vermek (örneğin, Fast Refresh (Hızlı Yenileme) desteği, Hooks lint kuralları).
Ancak, artık bir React uygulaması oluşturmanın en iyi yolu olma hedefini karşılamıyor. Çıtayı yükselterek ve derlemeyi işleme, yönlendirme ve veri getirme ile entegre ederek, çerçeveler kullanıcılarının aşağıdakileri yapan React uygulamaları oluşturmasına olanak tanır:
İster küçük ister büyük olsun, varsayılan olarak hızlı uygulamalar ve siteler sunmak için web API’lerinden tam olarak yararlanın.
React’in kendisinden ve framework (çerçeve) düzeyindeki özelliklerinden tam olarak yararlanma.
Geliştiricilerin “pit of success (başarı çukuruna)” düşmesine izin veren yönlendirme ve veri getirme sağlayın.
React ekosistemi, web’in ve React’in kendisinin tüm avantajlarından yararlanabilecek varsayılan bir önerilen yaklaşımı hak ediyor. Bu, mutlaka bir Node.js sunucusuna bağlı olmak anlamına da gelmiyor. Birçok popüler framework bir sunucu gerektirmez ve SSG modunda çalışabilir, böylece “tamamen statik” kullanım durumlarına da hitap edebilirler. Bir framework’ün (çerçevenin) avantajı, daha sonra SSR’ye ihtiyaç duyarsanız, geçiş yapmanıza gerek kalmamasıdır. Diğer şeyler gibi bu da mevcuttur (örneğin Remix out of the box (kutudan çıkar çıkmaz) bir mutation (mutasyon) API’si sunar).
Bu vizyona nasıl ulaşabiliriz? Birkaç seçenek görüyoruz.
Seçenek 1: Sıfırdan yeni bir çerçeve oluşturmak
Create React App’i veri getirme, yönlendirme, paketleme ve SSG/SSR’yi entegre eden bir framework (çerçeve) olarak yeniden tasarlamayı deneyebiliriz. Bu endişelerin kesiştiği noktada yüksek kaliteli yeni bir çerçeve oluşturmak büyük bir girişimdir, çok fazla uzmanlaşmış ekosistem uzmanlığı gerektirir ve bunu başarmak için diğer projeleri durdursak bile, Create React App’in kendisi gibi zaman içinde durgunlaşacağı konusunda önemli bir risk vardır. Ayrıca, gerçek kullanıcısı olmamasına rağmen resmi olarak önerilen başka bir framework ile ekosistemi daha da parçalayacaktır. Bu seçeneğin şu anda pratik olduğunu düşünmüyoruz.
Seçenek 2: Create React App’i kullanımdan kaldırın, Vite şablonunu koruyun
Create React App’i kullanımdan kaldırabilir ve bunun yerine kendi Vite şablonumuzu sürdürebiliriz. Belirtilen hedeflere ulaşmak için bu şablonun çok sofistike olması gerekir. Aslında, bir React çatısı kadar sofistike olması ve yönlendirme, veri getirme vb. hakkında görüşler dayatması gerekir. Bu da aynı soruna yol açar: başka bir çerçeve oluşturmuş oluruz.
Seçenek 3: Create React App’i kullanımdan kaldırın, React framework’lerini önerin
Create React App’i bir araç olarak önemsizleştirebilir veya kullanımdan kaldırabilir ve React framework’lerini daha aktif bir şekilde vurgulayabiliriz. Bu, React ile bir framework kullanmak zorunda olacağınız anlamına gelmez, ancak çoğu uygulama için bunlardan birini kullanmanızı önereceğimiz anlamına gelir. Bunun dezavantajı, artık bir React uygulaması oluşturmak için tarafsız bir şekilde markalanmış bir CLI “network pipiline (ağ geçidine)” sahip olmayacağız: ilgili çerçevenin dokümanlarında doğru olanı bulmanız gerekecek. Doğrudan kullanımdan kaldırmak da yıkıcıdır. Komutu uzun süre çalışır durumda tutmamız gerekir — bu da marka açısından kafa karıştırıcıdır (“React uygulaması oluşturmak neden kullanımdan kaldırılıyor?”)
Seçenek 4: React Uygulaması Oluştur’un tek bir çerçeve kullanmasını sağlayın
Belirlenmiş tek bir framework seçebilir ve Create React App’i varsayılan olarak bu framework ile uygulamalar oluşturacak şekilde değiştirebiliriz. Bu yaklaşımla ilgili temel sorun, diğer çözümlerin rekabet etmesini çok zorlaştırmasıdır — özellikle de biraz farklı tradeoff (ödünleşimlere) sahiplerse, ancak popülerlik, özellik seti ve kalite açısından kabaca aynılarsa. Böyle bir davranış değişikliğinin oldukça yıkıcı olması da gerekir çünkü tüm eski eğitimler açık olmayan bir şekilde bozulacaktır.
Seçenek 5: Create React Uygulamasını bir başlatıcıya dönüştürün
Create React App’i bir komut olarak tutabilir, ancak onu bir başlatıcıya dönüştürebiliriz. Önerilen çerçevelerin bir listesini önerir, ardından “klasik” çerçevesiz yaklaşım son seçenek olur. Bu son “klasik” yaklaşım, CRA’nın şu anda yaptığı gibi (eğitimleri bozmaktan kaçınmak için) yalnızca istemciye yönelik bir uygulama üretecek, ancak sonunda kaputun altında Vite’a geçebilecektir.
Seçilmiş çerçeveler listesine girmek için, bir React framework (çerçevesinin) belirli kriterleri karşılaması gerekir — bu dokümantasyon sayfasında fiilen olana benzer. Topluluktaki popülerliği ve benimsenmeyi (listeyi kısa tutmak için), özellik setini, performans özelliklerini, web platformundan ve React’in kendisinden tam olarak yararlanma yeteneğini, aktif olarak bakımının yapılıp yapılmadığını ve çeşitli barındırma hizmetleri ve ortamlarında nasıl barındırılacağının açık olup olmadığını (herhangi bir satıcı kilitlenmesini önlemek için) dikkate almamız gerekir. Her bir çerçeve için başlangıç şablonu, tutarlı tasarım ve markalamaya sahip olduklarından, ticari hizmetlere bağlantı vermediklerinden ve benzer şekilde yapılandırıldıklarından emin olmak için React ekibi tarafından korunacaktır. Seçimlerimize nasıl ulaştığımızı topluluğa açıkça bildirmemiz gerekecek ve bunları periyodik olarak yeniden değerlendireceğiz.
Bizim teklifimiz
Şu anda 5. seçeneğe (“Create React App’i bir başlatıcıya dönüştürün”) yönelmiş durumdayız.
React App Oluştur’un asıl amacı, React kullanıcılarının çoğu için yeni bir React web uygulaması başlatmanın en iyi yolunu sağlamaktı. Bunu bir başlatıcı olarak yeniden tasarlamanın, çoğu yeni web uygulaması için en iyi olduğunu düşündüğümüz şeydeki bir değişimi açıkça iletirken, aynı zamanda eski iş akışları için bir kaçış kapağı bırakmasını seviyoruz. Seçenek 3'ün aksine, “React uygulaması oluşturmanın” bir şekilde kullanımdan kaldırıldığı algısını önlüyor. Biraz seçime ihtiyaç duyulduğu gerçeğini kabul ediyor, ancak artık aralarından seçim yapabileceğiniz gerçekten harika seçenekler var.
Bu noktaları açıklayan daha ayrıntılı bir RFC önerisi üzerinde çalışacağız. Bu arada, bu noktalar hakkındaki geri bildirimlerinizi duymak isteriz. Bunun uzun bir yorum olduğunu biliyorum, ancak tüm düşünce sürecini göstermek ve bu fırsatı React ile çerçeveler arasındaki ilişkiyi netleştirmek için kullanmak istedim. Takip eden sorulara burada yanıt vermek için elimden geleni yapacağım.
Okuduğunuz için teşekkür ederim! (by Dan Abramov Alıntı) .
Bu gibi nedenlerden ötürü artık Create React App aramızdan bu gün yarın ayrılacak ve geride onunla yapılmış projeler bırakacak. Kendinizi daha çok geliştirmek adına; Mutlaka Vite, Next, Gatsby, Remix ve Percel ile en az bir uygulama geliştirin.
Ayrıca şiddetle tavsiye ettiğim UI kütüphanleri arasından SolidJS’i mutlaka ziyaret edin. Buraya tıklayarak SolidJS ile tanışabilirsin :).
Yukarıda bir çok konuya değindiğimi düşünüyorum ancak buradaki yazanlar elbet yeterli değil ama benim bu yazı dizisine ayıracağım konu(lar) bunlar. Yolunuzu aramaya devam edin :). Bir sonraki yazımda görüşmek dileğiyle :).
