Next.js'e İhtiyacınız Yok - Neden Next'ten React'e Geçtik

• ComfyDeploy panosunu Next.js'ten React'e taşıyarak elde edilen sonuçlar:
  • Derleme süresi 3 dakikadan 18 saniyeye indi
  • Hot reload 200 ms'nin altına iyileşti
  • Ekip üyeleri çok daha memnun kaldı
• Başlangıçta Next.js kullanan bir full-stack uygulamayla yola çıkıldı; Drizzle ve Server Actions sayesinde tip güvenliği ve temiz kodla sistem iyi çalışıyordu, ancak şu sorunlar ortaya çıktı:
  • Belirli bir kullanıcı nedeniyle Vercel'de 2.000 dolarlık yüksek API maliyeti oluştu
  • API testlerinin karmaşıklığı arttı: Server Actions ile API route'ları iç içe geçti
  • Yavaş derleme süreleri ve verimsiz yerel geliştirme ortamı
  • Küçük değişikliklerde bile tüm SSR yeniden yükleniyordu
• Sorunlar
  • Next.js karmaşıklığının artması: Next.js'in hepsi bir arada (full-stack) yaklaşımı, uygulama büyüdükçe geliştirme karmaşıklığı yarattı
  • Panomuz esas olarak React tabanlı ve Next.js'in sunucu özelliklerine ihtiyaç duymuyor
• Next.js'ten React'e geçiş
  • TanStack Router ve Rspack kullanılarak Next.js'ten React'e geçildi
    • Geliştirme sunucusu başlangıcı: 2 saniyenin altında
    • Vercel derleme süresi: 18 saniye
  • API kurulumu iyileştirildi, gereksiz bağımlılıklar kaldırıldı, kod sadeleştirildi ve üretkenlik arttı
• Performans karşılaştırması
  • Next.js 15 (Turbo modu kullanılarak)
    • İlk sayfa derlemesi: 10,4 saniye
  • React + TanStack Router + Rspack
    • Route hesaplaması: 200 ms'nin altında
    • İlk bundle derlemesi: 1,67 saniye
• Trade-off'lar
  • Kaybedilenler
    • Frontend ve backend kodunun co-location'ı: Frontend ile backend ayrılınca sınırlar daha net hale geldi
    • Next.js'in caching özellikleri: Çok sayıda gerçek zamanlı veri güncellemesi olduğu için bunun yerine özel caching kullanıldı
    • Önceden render etme ve ilk yükleme: Static Generation yerine daha iyi bir UX uygulandı - artık devre dışı düğmeler gösterilmiyor
    • Sunucu bileşenleri ve action'lar: Sunucu bileşenlerinin "sihri" kaybedildi, ancak daha bilinçli API tasarımıyla iyileşme sağlandı
  • Kazanılanlar
    • API sözleşmesi tasarımının güçlenmesi
    • Caching'in yalnızca gereken yerlerde uygulanması
    • Veri akışı ve durum yönetiminin dikkatle tasarlanması
• Sonuç
  • Next.js, landing page'ler ve SEO gibi işler için uygun olsa da, çoğu ürün için gereğinden fazla karmaşıklık yaratıyor
  • Landing page ve SEO işleri için hâlâ Next.js kullanılıyor
  • Pano, Pure React + TanStack Router + Rspack'e geçirildi
  • API, Google Cloud Run üzerinde çalışan ve gerektiğinde otomatik ölçeklenen bir Python FastAPI sunucusunda çalışıyor
• Doğru aracı seçmek önemli; bizim için Next.js gereğinden ağır bir seçimdi

[zerocyber]

Şirketimizde front-end’i next.js ile standartlaştırma/geçiş hazırlıkları yaptığımız bir dönemde böyle bir yazıya denk gelince insanı epey düşündürüyor....

[nemorize]

Biz yalnızca mobil "uygulama" öncelikli olabilen hizmetler işletiyoruz, bu yüzden SEO gereken alanlarda React'i (veya ona benzer şeyleri) hiç kullanmıyor, yapıyı son derece hafif tutuyoruz.
Web'i yalnızca SEO amaçlı kullanıyor, kullanıcıları uygulamaya yönlendiriyoruz...

[beenzinozino]

"Doğru aracı seçmek önemli ve bizim için Next.js gereğinden fazla bir tercihti"

Sanırım kilit nokta son cümle.

Doğru aracı seçebilmek için böyle çeşitli başarısızlıkları bolca deneyimlemenin de önemli olduğunu düşünüyorum.

[iolothebard]

SEO gerektiği, içeriğin temel olduğu anlamına gelir,
ama asıl ağırlığı UI bileşenleri(?) ve durum yönetimi kaplayınca… SSR, ISR, Hydrate… gibi tuhaf bir yaratık ortaya çıkıyor…

[schang124]

Oldukça katıldığım bir içerik. SEO gerektiren bir durum olmadığı sürece ben asla Next.js kullanmıyorum. Yukarıdaki yazıda olduğu gibi yalnızca React kullanmanın birçok avantajı var:

• Next.js’e özgü gereksiz karmaşıklık ve kalıplar ortadan kalkıyor.
  • Bakım daha sade hale geliyor
• Gereksiz SSR maliyetlerinden kurtuluyorsunuz
• Router, bundler gibi FE altyapısına giren kütüphanelerde seçim özgürlüğü artıyor

[jhj0517]

Tam emin değilim ama görünüşe göre build sürelerinde epey fark var.

[bichi]

Görünüşe göre React'in diğer framework'lere kıyasla birçok açıdan daha yavaş olduğunu hâlâ bilmiyorsunuz.

[slowandsnow]

Hız önemli değil. Hız önemli olsaydı expressjs hâlâ kullanılmıyor olurdu. Topluluk ve kütüphane ekosistemi ezici derecede büyük.

[devheerim]

Sanırım odak noktası Next'ten React'e geçiş yapmak gibi görünüyor, haha.

[bbulbum]

React topluluğu erken aşamada CRA'yı bırakıp framework'lere geçtiği için, buna karşı çıkmanın kolay bir seçim olup olmadığından emin değilim.

[sacru2red]

Çoğunlukla vite'a geçildi ve framework'leri ihtiyaçlara göre kullanıyoruz; şu anda da öyle.

[bbulbum]

react.dev sitesinde, yeni bir uygulamayı veya sitenin tamamını React ile oluşturuyorsanız bir framework kullanmanızı önerdiğini söylüyorlar.

O yüzden~

[kandk]

İlginç. React'e kıyasla Next daha mı ağır?
Next'te sadece proje kurulumu yaptım ama proje kurmak ve geliştirmeye başlamak inanılmaz derecede kolaydı.

[cichol]

"Basitçe" <= bunu başarmak için pek çok trade-off yaratan sihir(?) gizlidir.

[beenzinozino]

Katılıyorum. Next.js'in altında inanılmaz derecede çok bağımlılık gizli...

[GN⁺]

Hacker News görüşleri

• Birçok insan, fikirlerin milyarlarca kullanıcıya ölçeklenip ölçeklenemeyeceğine fazlasıyla odaklanıyor. Bu yüzden, sitesine sadece 5 kişi girse bile Kubernetes kullananlar var. Öğrencilerin de Next.js kullanarak, aslında basitçe HTML + CSS ile yazabilecekleri web siteleri yaptıklarını gördüm

• Next.js ile bir proje kurdum ama kullanımı karmaşık geldi. İstemci ve sunucu arasında çerez erişim API'leri farklı, ortam değişkenlerine de process.env.NEXT_PUBLIC_* ile erişmek gerekiyor; bunlar kafa karıştırıcı. İstemci ve sunucuda en az değişiklikle çalışan kod yazmak istedim ama öyle olmadı. Next.js'in sunduklarına kıyasla, öğrenme maliyeti ve ek yük buna değmiyor gibi hissettirdi

• Kod tabanı sadeleşti ve sayfa render etme hızı arttı. Topluluğun gereksiz yere bu tür framework'lere itilmesi üzücü. Çoğu insanın ihtiyacı olan tek şey npx rsbuild init. rspack ve rsbuild kullanarak basit bir router ve hoş bir sadelik elde ettik

• Next.js v14 çıktığından beri kullanıyorum ve çok memnunum. RSCs sayesinde istemci tarafı JS kapalı olsa bile uygulamanın büyük bir kısmı gayet iyi çalışıyor. PHP uygulamalarının basit gücüne sahip; aynı zamanda tip sistemi ile etkileşimli, durum tabanlı istemci bileşenlerini görünüm ağacının "yaprak seviyesine" sorunsuzca dahil edebiliyor

• Rails ve Hotwire sayesinde React ekosistemindeki karmaşadan kurtulabildim. Durum yönetimi kütüphaneleri, meta framework'ler, veri çekme kütüphaneleri derken çok fazla seçenek var. Sunucudan gelen veriyi sayfada göstermek gibi basit bir işi karmaşık hale getirmeye gerek yok

• NextJS kullanan bir CMS'te (PayloadCMS) çalışıyorum ve NextJS, kullandığım teknolojiler arasında açık ara en kötüsü

• Next.js, React, Vue gibi ağır frontend framework/kütüphanelerini kullanan neredeyse tüm projeler için, backend'de şablon işleyen bir kütüphane kullanmak daha iyi olurdu. Bazen EJS üzerinden istemci tarafı render mantıklı olabilir. Neden framework kullanıldığı gerçekten sorgulanmalı

• SEO ve crawl optimizasyonu için Next.js kullanıyorum. Sayfaların crawl edilmesine gerek yoksa (örneğin giriş yapıldıktan sonraki dashboard), Next.js'e gerek yok; saf React daha basit olur

• Next.js'in varsayılan başlangıç seçeneği haline gelmesine şaşırıyorum. 2-3 yıl öncesiyle kıyaslayınca büyük bir değişim gibi geliyor

• NextJS uygulamasının yerine Vike kullanmayı deniyorum ve memnunum. Dikkatim dağılmadan, istediğim şekilde geliştirebiliyorum

[aer0700]

5 ziyaretçili bir uygulama için k8s... inanılmaz.