React Server Components ile 50 bin satır kodu taşımadan önce bilseydik iyi olurdu denenler

 (mux.com)
1 puan yazan GN⁺ 2023-09-03 | 1 yorum | WhatsApp'ta paylaş
  • Mux, mux.com ve docs.mux.com'u React Server Components'a taşırken, sunucu ile istemci yürütme sınırlarını ayırmanın bundle boyutunu ve hydration maliyetini doğrudan etkilediğini gördü
  • RSC, bileşenlerin veriyi doğrudan sunucuda alıp sonucu streaming ile iletmesini sağlayarak, yavaş veri çağrıları olsa bile ekranın bir bölümünün önce gösterilebilmesine imkân verir
  • Gerçek geçişteki en büyük engeller CSS-in-JS desteğinin olmaması, Server Components'taki React Context kısıtları ve sunucu/istemci sınırını sürekli izlemek zorunda olmanın karmaşıklığıydı
  • Next.js 13'ün app directory'sinde varsayılan Server Component'tır; kökteki use client ifadesini kademeli olarak aşağı taşımak yoluyla aşamalı benimseme mümkündür
  • Suspense, loading.js, yalnızca sunucuya özel kütüphaneleri koruma ve server-only gibi kalıplar, yalnızca performans kazanımının gerekli olduğu yerlerde dikkatle uygulanmalı; ekibin bilişsel maliyeti de hesaba katılmalıdır

Mux'ın RSC'ye taşıdığı kapsam

  • Mux, dokümantasyon sitesini yeniden yapılandırıp marka yenilemesi yaparken mux.com ve docs.mux.com'u Server Components'a taşıdı
  • React Server Components gerçek kod tabanlarında da uygulanabilir ve kullanmaya değer olabilir, ancak beraberinde kısıtlar ve karmaşıklık da getirir
  • Bu deneyim; RSC'nin neden gerekli olduğu, nerelere uygun olduğu, hangi durumlarda zorlayıcı olduğu ve gerçek bir kod tabanına nasıl kademeli olarak dahil edilebileceği etrafında özetleniyor

CSR, SSR/SSG sonrasında RSC'nin hedeflediği sorun

  • İlk sunucu render etme yaklaşımlarında PHP gibi teknolojilerle veri sunucuda alınır, ağır CPU işleri işlenir ve istemciye hafif HTML gönderilirdi
  • CSR/SPA, render kodunu JavaScript olarak istemciye gönderip etkileşimlerin hızlı işlenmesini sağladı; ancak arama motorlarının JavaScript çalıştırmadığı, sırların sunucuda tutulması gerektiği veya düşük performanslı cihazlar ve yavaş bağlantılarla karşılaşıldığı durumlarda zayıflıkları ortaya çıktı
  • SSR/SSG, Next.js ve Gatsby gibi araçlarla sunucuda HTML ve JavaScript'i birlikte üretip istemciye gönderme yöntemidir
    • Kullanıcı HTML'i hemen görebilir
    • JavaScript yüklendiğinde site etkileşimli hale gelir
    • Arama motorları da HTML'i okuyabilir
  • Mevcut SSR/SSG'de de maliyetler kalır
    • Sayfayı üretmekte kullanılan JavaScript'in büyük kısmını istemciye göndermek ve istemcinin bunu yeniden çalıştırarak HTML ile birleştirmesi, yani hydration, gerekir
    • Sunucu render etme, yavaş veritabanı çağrıları veya çok miktarda kod yürütme nedeniyle uzun sürerse kullanıcı beklemek zorunda kalır

React Server Components'ın değiştirdiği nokta

  • React Server Components, istemcide değil sunucuda çalışan React bileşenleridir
  • RSC destekleyen framework'ler kodun nerede çalışacağını açıkça ayırmaya imkân tanır
    • Server Components: yalnızca sunucuda çalışması gereken kod
    • Client Components: istemcide çalışması gereken kod
  • Çalışma konumu ayrıldığında istemciye gönderilen JavaScript azalır ve hydration sırasında yapılması gereken iş de azalır
  • Server Component, bileşenin içinde doğrudan veri alabilir
    • Node kütüphaneleri veya fetch kullanılabilir
    • Sayfa düzeyinde getServerSideProps ile veriyi topluca alıp props olarak sürekli aşağı aktarma biçimi azaltılabilir
    • useEffect ile karmaşık loading durumları yönetilen vakalar da azalır
  • Veri alma işi biten Server Component, sonucu istemciye streaming ile iletebilir
    • Yavaş bir bileşeni beklerken sitenin geri kalanı önce gösterilebilir
  • İstemci tarafındaki kullanıcı eylemlerine yanıt olarak sunucuda veri alıp yanıtı streaming ile iletmek de mümkündür; ancak bu, kesin anlamda RSC değil React Actions kapsamına girer

RSC'nin zorlayıcı yanları

  • CSS-in-JS şu anda Server Components'ta çalışmaz
    • Mux'ın RSC geçişinde styled-components'tan Tailwind CSS'e geçmek en büyük payı oluşturdu
    • CSS-in-JS'e yoğun bağımlı bir kod tabanı için ayrı bir geçiş çalışması gerekir
  • React Context yalnızca Client Components'tan erişilebilir
    • Server Components arasında props olmadan veri paylaşmak için büyük olasılıkla normal modüller kullanmak gerekir
    • React uygulamasının belirli bir alt ağacıyla veriyi sınırlamak için Server Components'ta iyi bir mekanizma yoktur
  • Mux dokümantasyon sitesinde Context kullanılan alanlar etkileşimi yoğun olduğu için zaten istemciye gönderilmek zorundaydı; bu yüzden büyük bir sorun olmadı
  • Pazarlama sitesinde tema paylaşımı sorun oldu
    • pre-footer'daki her bileşenin yeşil bir arka plan üzerinde olduğunu bilmesi gerekiyordu ki koyu yeşil kenarlık kullanabilsin
    • Context yerine CSS custom properties yoğun şekilde kullanılarak bu aşıldı
  • RSC, yürütme konumu ve veri alma biçimi konusunda esneklik sağlar; ancak aynı ölçüde karmaşıklığı da artırır
    • Yeni geliştiricilerin “neyin sunucuda, neyin istemcide çalıştığını” sürekli kontrol etmesi gerekir
    • Her PR'da gereksiz yere istemciye gönderilen kodla ilgili geri bildirimler oluşur
    • Geliştirme sırasında log'un sunucudan mı tarayıcıdan mı geldiğini anlamak için sık sık console.log eklenirdi
    • Caching de ayrı bir karmaşıklık ekler

Next.js 13'te RSC kullanmanın temel yolu

  • Yazının yazıldığı an itibarıyla production'a hazır RSC implementasyonu, Next.js 13'ün app directory'sidir
  • Next.js 13 app directory'de yazılan bileşenler varsayılan olarak Server Component'tır
    • Varsayılan durumda sayfa kodu istemciye gönderilmez
    • İstemciye yalnızca HTML iletilir
  • Server Component'a async eklerseniz bileşenin içinde veri alabilirsiniz
  • Yavaş veri alma yapan Server Component React.Suspense ile sarılabilir
    • İstemcide önce fallback UI gösterilir
    • Sunucu veriyi alıp render etmeyi tamamladığında sonuç bileşeni streaming ile iletilir
  • Suspense boundary, veri streaming'inin yanı sıra kullanıcı etkileşimlerine göre belirli alanların hydration önceliğini ayarlayan selective hydration için de kullanılabilir
  • İstemcide çalışması gereken kodlarda dosyanın en üstüne "use client" eklenir
    • onClick listener'ı veya useState gibi istemci durumuna ve etkileşime ihtiyaç duyan bileşenlerde kullanılır
    • "use client" eklenmiş bileşenin import ettiği tüm bileşenler de istemciye gönderilir
  • RSC desteklemeyen kütüphaneler Client Component'ta import edilerek istemci bundle'ına dahil edilebilir
    • Örnek, @mux/mux-player-react'i saran ClientMuxPlayer bileşenidir

Server Component ve Client Component seçme kriterleri

  • Server Components, istemciye gönderilmesi gerekmeyen kodlar için uygundur
    • Blog yazısı gövdesinin render edilmesi
    • Kod bloğu syntax highlighting gibi maliyetli işler
    • Veri alma
  • Client Components, kullanıcı girdisine tepki veren veya zamanla durumu değişen arayüzler için uygundur
    • useState
    • Event listener'ları
    • İstemci tarafı etkileşimler
  • Tüm uygulamayı Client Components olarak yapmak, mevcut SSR framework'lerine benzer şekilde çalışır
  • Tüm uygulamayı tek seferde Server Components'a dönüştürmek gerekmez; en fazla fayda sağlayan noktalardan başlayarak kademeli benimsenebilir

Gerçek kod tabanına kademeli olarak dahil etmek için 3 adım

  • Mux'ın kullandığı playbook üç adımdan oluşur
    • Uygulama köküne "use client" yönergesi eklemek
    • Yönergeyi render ağacında mümkün olduğunca aşağı taşımak
    • Performans sorunları ortaya çıktığında ileri düzey kalıpları uygulamak
    1. adımda, Next.js 13'ün en üst düzey page.tsx dosyasına "use client" eklenerek uygulamanın eskisi gibi çalışması sağlanır
  • Sunucu tarafı veri alma gerekiyorsa Client Component'ın ebeveyni olarak Server Component eklenir
    • Server Component veriyi alır
    • Alınan veriyi props olarak Client Component'a geçirir
    • Mevcut getServerSideProps rolünün yerini alabilir
    1. adımda "use client", en üst düzey bileşenden alt bileşenlere taşınır
    • İstemci koduna ihtiyaç duymayan <Title /> üzerinden yönerge kaldırılıp saf HTML olarak gönderilebilir
    • İstemci kodu gerektiren <Player /> hata vereceği için "use client" korunur
  • Bu yöntem, yeni bileşenlerde ve mevcut refactoring hedeflerinde Server Components'ın düşünülmesini sağlar ve bundle boyutunu bir miktar azaltmaya yardımcı olur

Performans sorunu olduğunda uygulanan kalıplar

  • Mux dokümantasyon sitesi çoğunlukla statik olarak üretilir, ancak changelog sidebar'ı CMS'ten alınır
  • Sidebar Suspense ile sarılırsa CMS fetch bitene kadar uygulamanın geri kalanının beklemesi gerekmez
  • Next.js 13'ün loading.js konvansiyonu da içeride Suspense ve streaming kullanır
  • Büyük kütüphaneleri sunucuda tutmak için Client Components ve Server Components yerleşimini ayarlamak gerekir
    • Örnek olarak syntax highlighting kütüphanesi Prism sunucuda tutulur

Client Component içine Server Component karıştırma yolu

  • Client Component'ın import ettiği bileşenler onunla birlikte Client Component olur
  • Server Component'ı Client Component'ın çocuğu olarak tutmak istiyorsanız import etmeyip children veya props olarak geçirmeniz gerekir
    • Server Component sunucuda render edilir
    • Serileştirilmiş sonuç Client Component'a iletilir
  • Yanlış yöntem, Client Component dosyasından Server Component'ı doğrudan import etmektir
  • Doğru yöntem, en yakın üst Server Component'a çıkıp Server Component'ı Client Component'a çocuk veya prop olarak vermektir

Tek dosyayı yarı sunucu/yarı istemci diye bölemezsiniz

  • Bir dosyanın yarısını Server Component, yarısını Client Component yapmak mümkün değildir
  • Mux, özelliği iki dosyaya ayıran kalıbı sık kullandı
    • CodeBlock.server.js: büyük syntax highlighting kütüphanesini import eder ve sunucuda render eder
    • CodeBlock.client.js: useState ve onClick kullanarak kullanıcının kod örnekleri arasında geçiş yapmasını sağlar
  • Sunucuda render edilen örnekler props olarak Client Component'a geçirildiği için sunucuya özel işler istemci bundle'ına taşınmaz
  • index.js içinde CodeBlock.server.js yeniden export edilirse kullanıcılar yalnızca CodeBlock import ederek içerideki sunucu/istemci ayrımını düşünmek zorunda kalmaz

Yalnızca sunucuda çalışmasını garanti etme yolu

  • Başlarda geliştirme sırasında log'un sunucudan mı tarayıcıdan mı geldiğini anlamak için console.log eklenirdi
  • Sunucuya özel kodun bundle'a dahil edilmediğini garanti etmek için server-only package import edilebilir
  • server-only, büyük kütüphanelerin veya gizli anahtarların yanlış konuma taşınmasını önlemek için yararlıdır
  • Next.js, ortam değişkenlerinin yanlışlıkla tarayıcı bundle'ına dahil edilmesini engelleyen koruma mekanizmaları sağlar
  • Dosyanın en üstündeki server-only bakım açısından da yardımcı olur
    • Bakımı yapan kişi, ilgili dosyanın sunucuda çalıştığını hemen anlayabilir

Benimseyip benimsememeye karar verirken maliyet ve faydalar

  • React Server Components ücretsiz elde edilen bir özellik değildir
  • Maliyetler CSS-in-JS ve React Context kısıtlarının yanı sıra şunları da içerir
    • Sunucu ve istemci yürütme konumunu anlama
    • Hydration'ı anlama
    • Altyapı maliyeti
    • Client Components ile Server Components'ın karıştırılmasından doğan kod karmaşıklığı
  • Karmaşıklık, bug'ların girebileceği ve kodun bakım yapılabilirliğinin düşebileceği yüzeyi artırır
  • Framework'ler karmaşıklığı azaltır ama ortadan kaldırmaz
  • Beklenebilecek faydalar şunlardır
    • Daha küçük bundle boyutu
    • Daha hızlı yürütme
    • SEO için önemli performans iyileştirmeleri
    • Karmaşık ve veri yoğun siteler için ileri düzey veri loading kalıpları
  • Ekip ek bilişsel maliyeti kaldırmaya hazırsa ve performans kazanımı yeterliyse RSC uygun olabilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-03
Hacker News yorumları

  • Sunucu tarafı işlemede istemci, doğrudan görebileceği HTML’i alır
    Bunu ben de fark ettim; sunucuya düz metin bir dosya koyarsanız tarayıcıya epey hızlı iletiliyor
    .css ile biten başka bir düz metin dosyası koyarsanız tarayıcı bunu nasıl işleyeceğini bildiğinden ilk ekrandaki öğeler hareket edebilir ve oldukça iyi görünebilir
    Güzel bir numara ama ilk ekranda okunabilen yararlı içerik yanında hâlâ ikincil kalıyor

    • Kardeşim bu yıl web geliştirme öğrenmeye başladı; ona HTML’in HTTP üzerinden gönderilebildiğini söyleyince çok şaşırdı
    • Tarayıcı aslında hipermetin istemcisi olarak başladı, ama bir noktada içinde özel hipermetin istemcisi gibi şeyler bile uyguladığımız bir uygulama platformuna evrildi
      “Hipermetni daha güçlü kılacak özellikler ekleyelim” nasıl “Artık bu büyük ve tutarsız özellik yığınıyla işe yarar uygulamayı kendiniz uygulayın” noktasına geldi, bilmiyorum
    • Sırada, her sayfa için kod çalıştıran metin dosyaları da gönderebileceğimizi mi söyleyeceksin?
    • Böyle bir teknolojinin kaybolduğunu sanıyordum

  • RSC’ye dalmadan önce biraz durup düşünmek iyi olur
    Ne inşa etmeye çalışıyor olursanız olun, gerçek bir full-stack framework ya da klasik bir web framework’üyle bunu çok daha kolay, hızlı ve ölçeklenebilir biçimde yapmak mümkün
    Rails/Django/Laravel/… üzerine Turbolinks/Htmx/… ekleyebilir ya da sadece biraz istemci tarafı JavaScript serpiştirebilirsiniz
    Elixir/Phoenix biliyorsanız birkaç avantajı bir arada da elde edebilirsiniz
    Ne kadar çok kişi tweet atarsa atsın, RSC yolunda daha da aşağı inmemek gerek
    Sektörde 10 yıldan az deneyimi olanlar, eski vanilla PHP sitelerinde yaşanan temel sorunları yeniden yaşayacak; React bileşenlerinin içine satır içi SQL hook’ları konduğunu bile gördüm
    Bu sefer üstüne çok daha fazla tesadüfi karmaşıklık da eklenmiş durumda
    Aklınızı koruyun, gerçek ürünü hızlıca çıkarın ve Lamborghini parasını kazanın

    • RSC bana CORBA’yı hatırlatıyor
      CORBA, yerel bileşenlerle uzak bileşenleri karıştıran bir yaklaşım; olgunlaşmıştı ve birçok dilde çalışıyordu
      Peki neden herkes kullanmıyor? Bugün çoğu geliştirici adını bile duymamıştır
      Bir başka dağıtık bileşen mimarisi yapmak istiyorsanız CORBA’nın ve ardıllarının neden yaygın biçimde yerleşemediğini incelemelisiniz
      İpucu şu: gizli bileşen sınırları gizli karmaşıklık yaratır
      Öte yandan “sunucuda render edilen HTML” ve “istemcide render edilen HTML” kamplarının ikisi de iyi işliyor
      Her web projesinde bu iki seçeneğin de kullanılabiliyor olmasını büyük şans sayıyorum
      Umarım RSC çalışmaları, saf istemci tarafında render edilen uygulamalara yönelik React desteğini bulanıklaştırmaz
      1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
    • Elixir/Phoenix biliyorsanız bu gerçekten doğru
      Tam anlamıyla aşamalı zengin bir frontend uygulamasına kesinlikle ihtiyacınız yoksa, çoğu şeyi LiveView asgari JavaScript ile sunucu tarafı bileşenler üzerinden hallediyor
      Üstelik her kullanıcıya sunucu tarafında bir thread bağlanıyor; böylece açık JavaScript handler’ları yazmadan değişiklikleri kullanıcının frontend’ine aktif olarak itebiliyorsunuz
    • Gerçekten de bu söz doğru
      Sektör 10 yıllık döngüler halinde hafıza kaybına uğruyor gibi
      Sunucuda render edilen UI’dan uzaklaşmanın gayet geçerli nedenleri vardı
      Elbette arama motoru optimizasyonu argümanı hep var; ama derdiniz buysa, sadece geleneksel sunucu şablonlu bir site yapın
      Tek sayfa uygulamaların büyük çoğunluğu SSR’a ve onun karmaşıklığına hiç ihtiyaç duymuyor
    • Mux çalışanıyım; ilginç bir bilgi olarak, Elixir başından beri altyapımızın temel bileşenlerinden biriydi
      İlk dashboard arayüzlerinin tamamı Phoenix ile render ediliyordu ve yalnızca gerçekten gelişmiş istemci etkileşimi gerektiren sayfalara tek tek React dahil ediyorduk
      İlk ürünümüz analiz dashboard’u olduğu için bu durum kısa sürede neredeyse tüm dashboard’a yayıldı ve müşterilere sunduğumuz API’den yararlanarak tamamen tek sayfa uygulamaya geçmek doğal hale geldi
      O zaman 2016’ydı, yani LiveView yoktu; ama bugün o ürünü yeniden yapsak farklı bir karar verir miydik, emin değilim
      Blog yazısı, herkese açık pazarlama sitesini çalıştıran uygulamayla ilgili ve gereksinimleri epey farklı; yine de bizim de Elixir/Phoenix kullandığımızı ve sevdiğimizi söylemek istedim

  • Yaşlandığımı hissediyorum
    Günümüz framework’leri fazla büyük ve karmaşık
    Basit bir web “Hello world”ü için bile devasa bir build ve derleme pipeline’ı gerekiyor; artık buna sunucu tarafı bileşenler de eklendi
    Overhead’in ne kadar olduğunu gerçekten merak ediyorum
    Bir Hello world örneğini çalıştırmak için frontend ve backend framework kodlarının kaç katmanından geçildiğini bilmiyorum
    Ben F5’e basınca yeniden build edilen 10KB’lık basit bir bileşen framework’üne geri dönerim

    • Bu framework’ler basit bir Hello world uygulamasını çözmek için yapılmadı
    • Birçok web sitesinin yalnızca HTML ve CSS ile yapıldığında her açıdan daha iyi olacağını düşündüğüm için sinir bozucu
      Belki ileride gerekebilecek gösterişli özellikler için fazlasıyla erken optimizasyon yapmak gibi
      Kümes yapmadan önce karot örneği alıp sismik modelleme yapmak için mühendis tutmanız gerektiğini söylemeye benziyor
    • Karmaşıklıktan uzaklaşma hareketini tam da bu yüzden görüyoruz
      Genç geliştiriciler artık bunu görmeye başladı
      Biz SOAP ve XML gibi berbat şeyleri bırakıp daha basit ve kullanımı kolay teknolojilere geçtiğimiz gibi, bu nesil de karmaşıklığın zararlı olduğunu yeniden öğreniyor
      Belki yeni nesil tekrar ortalığı karıştırmadan önce birkaç yıl boyunca yazılım geliştirmek yeniden eğlenceli hale gelir
    • Bu bakış açısı gerçekten sinir bozucu
      Pipeline, belirli kullanım senaryosuna göre gerektiği kadar karmaşık ya da basit olabilir
      Sadece statik dosyalarla da yapılabilir, tek bir esbuild komutu kullanan küçük bir Makefile ile de; 30 eklentili devasa bir Webpack yapılandırmasıyla da mümkün
      Yapmak istediğiniz şeyin gereksinimlerine ve karmaşıklığına göre istediğiniz gibi seçim yapabilirsiniz
      Ayrıca araçları basit bir Hello world yapmanın kolay olup olmadığına göre değerlendirmek, yalnızca işiniz gerçekten böyle uygulamalar yapmaksa faydalıdır
    • Bu blog yazısı SSR’yi gördüğüm çoğu yazıdan daha iyi ele almış
      SSR veya türevleri konuşmaya girdiğinde, bunun gereksiz yere daha karmaşık hale gelip gelmediğini hep kendime soruyorum
      React sunucu render bileşenleri fazla ileri gitmiş gibi geliyor ve doğal geliştirici deneyimi akışına ters düşüyor
      Uygulama karmaşıklığı ikiye katlanıyor, kodlama tuzakları artıp geliştiricileri yavaşlatıyor ve kafalarını karıştırıyor; karşılığında yalnızca küçük bir performans artışı alınıyorsa buna değip değmediğinden şüpheliyim
      Eski PHP siteleri ve tek sayfa uygulamasız Rails uygulamaları da uzun süre gayet iyi çalıştı

  • Next.js ve yeni app dizin yapısıyla yeni bir uygulama geliştirirken bunları yaşadım
    Birincisi, neyin sunucuda neyin istemcide gerçekleştiğini akıl yürütmek zor
    Anlamak için araştırmak gerekiyor ama hızlı kod yazarken çoğu zaman buna fazla dikkat etmiyorsunuz
    Küçük bir değişiklikle sayfanın büyük bir kısmının bir anda sunucudan istemciye taşınmaya çalışması çok kolay
    Nihai yayından önce sayfa sayfa dikkatli ve zaman alan doğrulama yapmam gerekeceğini biliyorum ve bu hoşuma gitmiyor
    İkincisi, mevcut React kütüphanelerinin önemli bir kısmı hook kullandığı için istemcide çalıştığını varsayıyor
    Bu yüzden kod istemciye çekilebiliyor
    Yeni paradigmaya katlanmanın amacı hızlı yükleme ve arama motoru optimizasyonu için sunucu tarafı render ise, içe aktarılan kütüphane iyi uyum sağlamazsa bu tamamen boşa gidiyor
    Üçüncüsü, yeni Next.js app dizini paradigmasında bug’lar var
    Hâlâ yeni ve çok karmaşık olduğu için dinamik route’lar, paralel route’lar ve bunların etkileşimleri tamamen bozulabiliyor
    Bizzat Next.js GitHub’ına issue açtım ve çok sayıda “bende de öyle” yorumu geldi
    Kullandığım yaklaşımlardan birini yakın zamanda bir Vercel geliştiricisi düzeltti, ama ben o sırada etrafından dolaşmak için zaten başka bir yaklaşım seçmiştim
    En sinir bozucu olan şey, geliştirme ortamının lazy loading ve caching sihri kullanması
    Sayfa farklarını hesaplayıp web soketi gibi bir şeyle kısmi güncellemeler göndermeye çalışıyor gibi, ama tamamen bozularak kurtarılamaz bir duruma gelebiliyor
    Bazen yeniden derleme, sunucudan istemciye bir tür iletişimi tetikliyor; Chrome sekmesine geri döndüğümde sekme tamamen donuyor ve süreci Chrome Görev Yöneticisi’nden öldürmek zorunda kalıyorum
    Genel olarak hâlâ çok yeni ve pürüzlü kenarları bol bir aşamada

    • “Mevcut React kütüphanelerinin önemli bir kısmı hook kullandığı için istemcide çalıştığı varsayılır” kısmında hook değil de context mi kastedilmiş?
      Birçok hook sunucu tarafında da çalışır ve aslında değerleri başlatmak dışında hiçbir şey yapmaz

  • PHP ile JavaScript’in aslında neredeyse aynı sözdizimine sahip olması ilginç
    Fark aşağı yukarı $ simgesi ya da var anahtar sözcüğü kadardı; NodeJS ise “biz sunucuda JS çalıştırmak istiyoruz” dedi
    Ve 15 yıl sonra JavaScript sonunda yetişti, fiilen PHP’ye benzer hâle geldi; sadece kısaltmaları daha fazla, öğrenme eğrisi daha dik
    Elbette Suspense ile sunucudan istemci bileşenlerine veri akıtmak harika
    NextJS 13 kullanıyorum; SSR’ı PHP’de her zaman mümkün olduğu kadar kolay hâle getirmesini seviyorum ve şiddetle tavsiye ederim

    • Adil olmak gerekirse PHP 7 öncesi, döneme bağlı olarak ya bir çöplük ya da daha tehlikeli bir şeydi
      İnsanlar ona “kötü tasarımın fraktalı” dediğinde bunu %100 hak ediyordu; sorunu çözmek için başka yerlere bakmaları da makuldü
      Bugün PHP çok daha iyi bir dil ve yeniden bakmaya değer, ama eskiden de bugünkü kadar iyiymiş gibi davranmamak gerekir
      Ayrıca NodeJS’i React ekosistemine göre yargılamamak gerekir
      React tabanlı sistemleri çalıştırmak için gereken inanılmaz miktardaki API ve wrapper React topluluğunun sorumluluğu
      Tipik Stockholm sendromu
    • PHP’de client-side rendering yok, bu yüzden tuhaf bir karşılaştırma
    • Tarayıcıların kendisinin de büyük ölçüde iyileştiği sık sık göz ardı ediliyor
      Pek çok modern gelişmenin mümkün olmasının nedeni de önce tarayıcıların daha iyi hâle gelmesi
      Tam bir tur atmış olmaktan ziyade, çok uzaktan bakınca daire gibi görünen bir yığına daha yakın
    • NodeJS’i hiç sevmedim
      Bir yandan eşzamanlılık modeli sayesinde daha hızlı backend’ler yapabilmek açısından yenilikçiydi, ama Java veya PHP gibi mevcut backend dillerindeki birçok özellik eksikti; bu yüzden pek çok kalıp yeniden icat edildi
      Dilin kendisinin de Java’nın zaten sahip olduğu ve PHP’nin yöneldiği “güvenlik” seviyesine ulaşması yıllar aldı
      XML ve onun sağlayabildiği sözleşmesel güvenceler gibi doğrulanmış ve standartlaşmış teknolojiler de ağır olduğu, JSON’ın insan tarafından okunup yazılmasının kolay olduğu gibi gerekçelerle terk edildi
      XML’i terk ederek çok zaman ve emek kaybettiğimizi düşünüyorum
      REST/JSON API dokümantasyonu hâlâ acı verici
      20–25 yıl önce XML payload’larından veri modeli ve parser zaten üretebiliyorduk
      XML’in nesi bu kadar sorunluydu hâlâ bilmiyorum
      Hat üzerinde JSON’dan biraz daha ağırdı, ama sıkıştırma kullanarak ya da EXI(https://www.w3.org/TR/exi/) ile ikili protokole çevirerek çözülebilecek bir sorundu
      EXI gerçekten tutundu mu bilmiyorum, ama o dönemde ne kadar çok XML dolaştığını bildiğim için oldukça umutluydum
    • NodeJS’in ortaya çıkmasının asıl nedenlerinin önemli bir kısmı unutulmuş gibi
      O dönemde non-blocking I/O büyük performans artışı sağlıyordu
      Ama modern geliştiricilerin kafasında JSON döken ya da toolchain barındıran aptal bir araç seviyesine itilmiş gibi görünüyor

  • Alıştıkları şeyi kullanıyorlardır, ama bir dokümantasyon sitesi için önbelleklemesi olan hazır bir statik site üreticisi ya da CMS yerine React kullanmak israf gibi görünüyor
    Geliştirici açısından React daha eğlenceli olabilir

    • Harika dokümantasyon sitelerinde ufak tefek dinamik kısımlar çoktur
      Stripe, içinde hesap API anahtarının bulunduğu kod parçacıkları gösterip hemen test etmeyi mümkün kılan akımı başlattı
      Frontend dokümantasyon sitelerinde neredeyse her zaman dokümanın içinde doğrudan kurcalanabilen çalıştırılabilir örnekler bulunur
    • Bunu sık duyuyorum ama pek anlayamıyorum
      Yeni bir projeyi bootstrap etmek çok kolay ve hızlı; kelimenin tam anlamıyla saf HTML projesi başlatmaktan daha kolay
      Neyi kaçırıyorum?
      Ayrıca eksi oy verenlerin bakış açısını gerçekten merak ediyorum
    • Katılıyorum
      Statik içerik sonuçta; neden arama kutusu için biraz JavaScript eklenmiş HTML olarak üretilmediğini anlamıyorum
    • Zaten statik olarak üretiliyor
      React kullanma nedeni frontend genelinde tek bir dil kullanmak
      Birinin bir sitede React, diğerinin Gatsby/Hugo kullanması gibi bölünmelerden kaçınılabiliyor
      Next.JS, Gatsby/Hugo ile aynı işleri yapabilirken daha fazla özelliğe sahip ve React tabanlı
    • “Geliştirici açısından daha eğlenceli” olması aslında hem yazılım geliştiricilere hem de işverenlere inen bir lanet

  • Sunucunun her şeyi render ettiği, CSS ve Javascript'in de render edilmiş sayfayı zenginleştirmek için kullanıldığı günleri hatırlayacak kadar yaşlıyım
    Web çok karanlık ve aşırı mühendislik yapılmış bir yer hâline geldi
    İnanması neredeyse güç
    Bu yüzden uygulama geliştirme tarzım önce sunucuda render etmek, sonra zenginleştirmek yönünde

    • Büyük ölçüde katılıyorum
      Katlanabilir dropdown'lar ya da jQuery sürükle-bırak güzel özellikler ama js/jQuery döneminin durum yönetimi cehennemini de net hatırlıyorum; oraya dönmek istemem
    • JavaScript mi kullanıyorsun?
      Şaka bir yana, ilk Geocities sayfam ziyaretçi sayacı ya da marquee gibi şeylerden ibaret HTML'di
      Okulda yaptığım ilk PHP uygulaması/projesi de henüz JS kullanmıyordu; statik menüler ve header'lar için frame kullanıyor, veriyi de sadece form submit ile backend'e gönderiyorduk
      Öyle zamanlar vardı
      Üniversite programının parçası olan ilk bir yıllık stajımda Java backend, sunum katmanında JSX şablonları ve dialog ya da animasyonlu akordeon gibi şeyler için PrototypeJS kullandık
      O zaman animasyon, “bu öğenin yüksekliğini saniyede birkaç kez değiştirmek” demekti
      İlk işimde sepete ekleme, görsel carousel gibi sayfayı zenginleştiren JS'yi bolca kullandım; bu da jQuery dönemiydi
      Sonraki işimde, müşteri destek çalışanlarının SAP benzeri şeylere baktığı bir UI'ı BackboneJS ile berbat şekilde yaptık
      Ondan sonraki iş de müşteriye dönük yatırım bankacılığı frontend'ini BackboneJS ile yeniden yapmaktı
      Bu, o zamanlar tek sayfa uygulaması denen şeye çok uygun bir kullanım örneğiydi
      Arama motoru optimizasyonuna gerek yoktu, saf frontend render yeterince hızlıydı, API merkezliydi ve insanların web ile mobilde aynı API'yi kullanabileceklerini fark ettiği dönemdi
    • Başka bir açıdan, CSS ve Javascript'in icat edildiği zamanları da hatırlıyorum ve o dönemden beri web siteleri yapıyorum
      Bana göre web geliştirme araçları hiç bugünkünden daha iyi olmadı; kullanıcı deneyimi de yıllar içinde muazzam şekilde gelişti
      AJAX dediğimiz şey, temiz bir ek oyuncaktan istemci bileşenleri ve tek sayfa uygulamaları biçiminde günlük varsayılan bir yapı taşına dönüştü
      Sunucu, isterseniz hâlâ güçlüdür; ama dashboard'lar, haritalar, oyunlar, forumlar, ofis uygulamaları, çevrimiçi IDE'ler gibi etkileşimli uygulamalarda güçlü istemci tarafı yetenekler iyidir
      Bu sayede günlük uygulamalar, her işletim sistemine özel masaüstü uygulamalarından tüm dizüstü ve masaüstlerini kapsayan genel amaçlı bir platforma büyük ölçekte taşınabildi
      Elbette bu güç daha fazla karmaşıklık gerektirdi
      HTML/CSS ile blog ya da landing page yazmakla tam bir web uygulaması yazmak çok farklı şeyler
      Angular ve React, JS runtime'ı ile dilin kendisinin o dönemin sunucu tarafı dillerine kıyasla çok daha ilkel olduğu bir zamanda, eskisinden katbekat daha karmaşık uygulamalar geliştirmeye yardımcı olmak için oluşturuldu
      2010'ların sonlarında, çeşitli JS framework'lerinin sorunun yalnızca çok küçük parçalarını çözdüğü gerçekten sancılı bir dönem vardı
      Bugünlerde daha az böyle
      Next kazandı ve varsayılan hâline geldi; bunu da hak ediyor
      Orta karmaşıklıktaki uygulamalar için uygun bir soyutlama düzeyi sunuyor ve sunucu tarafı render ile istemci tarafı sayfaları iyi harmanlamayı sağlıyor
      React server components bu ayrımı daha temiz, birinci sınıf bir kavram hâline getiriyor
      Ancak bu yalnızca belli bir karmaşıklık eşiğinin üzerinde anlamlı
      İhtiyacınız yoksa kullanmazsınız
      Çoğunlukla statik bir blog ya da dokümantasyon sitesiyse daha basit mimariler var
      Hâlâ HTML yazıp gerektiği kadar birkaç satır JS serpiştirebilirsiniz; çoğu küçük işletme için WordPress ya da Wix de kullanılabilir
      Ama daha karmaşık uygulamalar geliştiriyorsanız, en ufak etkileşim için sunucuya gidip gelerek UI'ı yeniden hesaplayan ve her seferinde tüm HTML sayfasını gönderen yaklaşıma kıyasla React gerçekten rüya gibi
      O yaklaşım bağlamı, sayfadaki konumu, yarım doldurulmuş formları kaybettiriyordu; form verisini durum olarak kullanmaya teşvik ediyordu ve yanlışlıkla geri tuşuna basınca ya da kolay bulut ölçeklemesi çıkmadan önceki sık sunucu arızalarında iş kaybetmek yaygındı
      Bana göre yalnızca yanlış uygulandığında aşırı mühendisliktir
      Doğru kullanım örneğinde bu araçlar gerçekten faydalı, hatta bazen zorunlu
      Üzücü olan, gerekmediği ya da hatta zararlı olduğu durumlarda bile bunların çok fazla öğretilmesi ve kullanımının teşvik edilmesi olabilir
      Sonuçta işe uygun aracı kullanmak gerekir
      React'i Vue, Svelte, HTMX'in önüne koymaya çalışmıyorum; demek istediğim, istemci tarafı karmaşıklığın da bir işe yaradığı
    • Tam olarak bu yaklaşım, yani server components bunun için var

  • React'in daha modern, kolay, hızlı ve ucuz alternatiflere yetişmeye çalıştığı izlenimini alıyorum
    Ama temel sorun olan yeniden render, sık sık gereken memoization ve sızdıran soyutlamaları düzeltmek yerine React daha karmaşık hâle geliyor
    Nihai sonuç harika olsaydı bu çabayı anlardım ama değil
    React gerçek dünyada benchmark'ların gösterdiğinden daha yavaş; Next daha da kötü
    Son dönemde Next ile yapılmış çok yavaş web siteleri gördüm
    Gerçekten anlamıyorum
    React ekibi React'i iyileştirmek istiyorsa çekirdeği düzeltmeli

    • Bunu düzeltemezler
      Artık ekosistem bağımlılıkları o kadar fazla ki kırılır
      Target.com, Walmart.com, Microsoft Teams ve sayısız site React kullanıyor
      Devasa bir bileşen ekosistemi ve onun üzerine kurulmuş şirketler de var
      Temel kavram bozuk, ama düzeltmek geri kalan her şeyi kırmak anlamına gelebilir
      Zaten her şeyi kıracaksanız başka bir şey kullanmak daha iyi
      Şu an bağımlılık kütlesi yüzünden React'e bağlı kalarak ilerlemekten başka yol yok
      React yeniden render'ı varsayılan alıp çıkma yöntemiyle çalışırken, Vue, Solid, Preact, Svelte'nin hepsi gerekli yerlere dahil olma yöntemiyle çalışıyor
      Doğru kullanmayı zorlaştıran ve belirli tür bug'lara açık hâle getiren temel nedenlerden biri bu
      Dışarıdan sıradan JavaScript gibi görünse de sürekli çıkmanız gerekip gerekmediğini düşünmek zorundasınız; diğer framework'lerde bu tür bug'lar nadir ya da neredeyse yok
    • Yeniden render ve sık gereken memoization konusunda şu çalışma var
      https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...

  • Neden şimdi kalkıp arka uçta React kullanarak HTML render ettiğimizi anlamıyorum
    10 yıl öncesine mi dönüyoruz?

    • “O ortamda” bir şablon sistemi olması gerçekten çok değerli
      Son zamanlarda Svelte ile Django şablonları arasında sık gidip geliyorum; Svelte’in DOM’u bilmesi bile deneyimi çok daha iyi hale getiriyor
      JS olmayan bir şablon sisteminde böyle bir şey gördüğümü hatırlamıyorum
      PHP ve jQuery gibi şeyleri de deneyimledim
    • React’in programlama modeli insanlara çekici geliyor ve React, HTML gibi öngörülebilir çıktısı olan problemlere iyi uyuyor
      Üstelik ön uç React ise tüm HTML üretimini tek yerde tutmak çok daha kolay
    • 25 yaşındaki “kıdemli” geliştiricilerin egolarını beslemek için küçümseyecek eski bir teknolojiye ihtiyacı vardı; hedef PHP oldu
    • Çünkü Vercel arka ucunuzu barındırmak istiyor ve React’e el uzatıyor
    • Diğer şablon sistemlerinin çoğundan daha iyi; etkileşim eklemek istediğinizde bunu tek bir dil ve paradigma ile halledebilmeniz güzel
      Üstüne statik tip desteği de var

  • RSC’nin ya da React’in tüm zamanların en iyi çözümü olduğunu savunmaya çalışmıyorum, ama buradaki karşı argümanların bir kısmı yeterince olgun değil
    React/RSC’nin faydaları, sunucunun HTML/CSS ve biraz JavaScript döndürmesiyle teknik olarak aynı şey değil
    Hâlâ tek bir uygulama söz konusu; SSR/hydration ile karşılaştırıldığında istemci/sunucu sınırını daha akıllıca ele alan bir yaklaşım
    React’in kendini tasarımsal olarak bir çıkmaz sokağa mı soktuğu, çıkış yolunun ne olduğu konusunda daha bilgili karşı argümanları seve seve okurum; ama PHP’ye geri dönmek cevap değil

    • Bugünlerde HN, iyi bilen bir ön uç bakış açısı edinmek için iyi bir yer değil
      React öğrenmesi o kadar da zor bir şey değil; geliştirici olmayanların bile birkaç haftalık bootcamp ile temellerini öğrenebilmesinin bir nedeni var
      JSX, Django, PHP ve Rails’in şablon sistemlerinden nesnel olarak daha üstün
      Gelişigüzel ortaya atılan karşı argümanların yarısını söyleyenlerin, kendi projelerini Lighthouse gibi araçlarla benchmark bile etmemiş olduğunu düşünüyorum