React
CRA (Create React App) Neden Sonlandırıldı (Bir Nevi Öldürüldü) ?
React’ın yeni dokümantasyon sayfası devreye alındı ve burada React Uygulaması oluşturmak için CRA yerine React Framework’ lerinden Next, Remix, Gatsby ve Expo faydalanılması gerektiği öneriliyor ? Bir nevi React ekibi CRA öldürüyorüyor. Neden ?
Bu blog yazısında https://react.dev/learn/start-a-new-react-project sitesinde artık CRA (Create React App) ile uygulama geliştirmek yerine Production-grade React frameworks ile ;
- Next.js
- Remix
- Gatsby
- Expo (Native Apps)
kullanmalarını eğer bu framework’lerden birisini kullanmıyor iseniz
- Vite veya Parcel kullanabileceğiniz üzerine.
https://twitter.com/kentcdodds/status/1636733655556194305
Ama Neden CRA’ dan vazgeçildi ?
Bunun bir kaç nedeni var. Bunları React takımındaki kişiler ve Dan Abramov’dan farklı farklı React Server Component’s videolarında dinledim. Ama en açıklayıcı olanı GitHub açılan bir Issue Dan Abramov verdiği cevap
Bu yazı ingilizce olduğu için daha iyi anlaşılması ve ve kendimce zaman kaybetmemek adına DeepL ile aşağıda türkçe’ye çevirdim. Tabi orjinalinden okumanız daha faydalı. 😃
Not: Bazı kısımlardaki çevirilerin Türkçe karşılığı kavramsal olarak tam olmadığı için bunları ingilizce bıraktım.
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ı)
Görüşler
Tabi bunun yanında farklı görüşte olan Kent C. Dodds gibi kişiler olabiliyor. CRA dökümantasyonlarda bahsetmiyor olmanın CRA ölmüş olduğu anlamına gelmeyeceğini söylüyor.
Ben buna tam olarak katılmıyorum. Bence şu andan itibaren React Legacy olan (reactjs.org → react.dev) olarak artık aşağıdaki Class Components ve CRA dokümantasyondan kalktı.
- Class Components → Hooks
- CRA → Framework
Legacy yazılmış uygulamalar dışında tüm uygulamaların artık bu yeni yapıyla gideceğini artık eskilerin belli bir zaman içerisinde kullanılmayacağını veya bunlar ile ilgili dökümantasyon bulanamadığı için kendiliğinden yok olup gideceğini düşünüyorum.
2nci bir düşüncem de React bir UI kütüphanesinden MetaFramework kütüphanesine dönüşme isteği Frontend (ClientSide) ile başladıkları yolculuğa;
- Frontend
- Backend
- Mobile
- vb.. ortamlarıda katarak uygulama geliştirmenin yapıtaşı olmak istiyor.
Tabi burada şu soru işareti. Next.js çok baskın bir Framework olursa ileride React Next.js mi olur ? biz marka değeri olarak React yerine Next.js mi diyeceğiz o kısmın nasıl olacağını göreceğiz. Zaten yukarıda bahsedilen öneride 5nci şık yani CRA yı bir başlatıya dönüştürmek miş. Ama şu anda gördüğüm kadarı ile 3 seçenek seçişmiş ve 4ncü seçenek aralara gizlenmiş 😃
Eskilerde Sun Microsystems, Oracle tarafından satın alınması ve Java ortamının kontrolünün Oracle geçtiğini gördük (Acquisition of Sun Microsystems by Oracle Corporation)
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
