- Next.js 15.1.8'den itibaren metadata işleme biçimi değişti ve Vercel dışındaki dağıtım ortamlarında ciddi sorunlar ortaya çıktı
- Metadata artık doğrudan HTML head içine render edilmiyor; bunun yerine "metadata streaming" adı verilen yöntemle ayrı olarak gönderiliyor
- Arama motoru JavaScript çalıştırmıyorsa metadata hiç görünmüyor ve bu da SEO'yu kritik biçimde bozuyor
- İstisna olarak crawler tespiti (
htmlLimitedBots) uygulanıyor, ancak kusursuz değil
- Vercel dışındaki Netlify, Cloudflare, AWS gibi platformlar OpenNext ile uyumluluk sağlamaya çalışsa da, pratikte Next.js Vercel altyapısına fazla sıkı bağlı olduğu için port etmek zor ve hatalarla dolu
- Statik build'de bile metadata HTML head içine dahil edilmiyor; yapı, tüm dağıtım ortamlarını karmaşık crawler tespiti/JS çalıştırmaya zorlayacak şekilde değişti
- Güvenlik sorunu (Mart 2025'te açıklanan kritik açık)
- Metadata streaming'den kaçınmak için eski sürümde kalmak, ciddi güvenlik açıklarına maruz bırakıyor (yama yalnızca 15.2.3'te sunuldu)
- Metadata streaming gerçekte sayfa performansı sorunlarını gizliyor ve SEO'yu da olumsuz etkiliyor
- Sonuç:
Next.js açık kaynak gibi görünse de fiilen Vercel bağımlılığı çok ağırlaşmış bir framework'e dönüştü; bu nedenle yeni projelerde başka seçenekleri değerlendirmek daha akıllıca
Genel bakış
- Next.js 15.1.8 sürümünden itibaren Vercel dışındaki ortamlarda metadata işleme konusunda ciddi sorunlar yaşanıyor
- Bu durum, Next.js'in özünde Vercel altyapısına bağımlılığının derinleşmesine, arama motoru optimizasyonunun (SEO) zayıflamasına ve hatta güvenlik tehdidine yol açıyor
Sorunun başlangıcı: metadata streaming'in devreye alınması
- 2024'te Vercel, metadata streaming adlı deneysel bir özelliği devreye aldı
- Önceki yöntemin aksine metadata (
title, description, Open Graph vb.) HTML `` içine doğrudan render edilmiyor; bunun yerine ilk sayfa yüklemesinden sonra ayrı olarak gönderiliyor
- Bu özellik JavaScript çalıştırılmasını gerektiriyor
Vercel'in teknik açıklaması ve pratikteki sorunlar
- Devreye alma gerekçesi: metadata üretimindeki hesaplama darboğazını gidermek
- Ancak gerçekte metadata çoğu zaman statik ve küçük hacimli (1KB'den az) veriden oluşuyor
- Sunucu round-trip maliyeti, inline işlemeye göre daha yüksek
- Dinamik metadata yalnızca çok sınırlı sayıdaki istisnai durumda gerekli
- Metadata streaming'in uygulama karmaşıklığı ve yarattığı karışıklık artıyor
Performans sorununun arka planı
- Bazı geliştiriciler, harici API entegrasyonları gibi durumlarda metadata üretim gecikmesi kaynaklı performans sorunları yaşadı
- Vercel bu sorunu çözmek için streaming yaklaşımını geliştirdi
Arama motoru crawler'ları ve SEO etkisi
- JavaScript çalıştırmayan arama motorları metadata'yı okuyamıyor
- Bu nedenle SEO üzerinde ciddi olumsuz etki oluşuyor
- Çözüm olarak Vercel, sunucu crawler tespit ettiğinde streaming'i atlayıp metadata'yı HEAD içine yerleştiren htmlLimitedBots özelliğini sunuyor
Diğer bulut sağlayıcılarının sınırları
- Netlify, Cloudflare, AWS gibi sağlayıcılar da Next.js ile uyumluluk için OpenNext adlı bir adapter projesi geliştirdi
- Ancak Next.js Vercel'e çok sıkı bağlı olduğu için, başka ortamlara taşınırken reverse engineering gerekiyor
- OpenNext'in kalite sorunları nedeniyle pratikte düzgün çalışmıyor
Statik build bile eksik
- Statik site build'inde bile metadata artık HTML head içine dahil edilmiyor
- React Server Components ile birlikte bundle edildiği için JavaScript çalıştırılması gerekiyor
- Temel HTML metadata'sı için bile crawler tespit mantığını doğrudan kendiniz uygulamanız gereken mantıksız bir durum ortaya çıkıyor
Kritik güvenlik açığı ve güncelleme sorunu
- 21 Mart 2025'te kritik bir açık (güvenlik puanı 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927) açıklandı
- Bu açık, belirli header manipülasyonlarıyla middleware'in kimlik doğrulama güvenliğinin aşılmasına izin veriyor
- Açığın yaması Next.js 15.2.3 sürümünde yayınlandı; ancak metadata streaming'den kaçınmak için 15.1.8'de kalmak güvenlik açısından çok riskli
Streaming'in getirdiği olumsuz sonuçlar
- Metadata streaming gizli performans sorunlarını daha da görünmez hale getiriyor
- Sayfa metadata işleme geciktiğinde gerçek kullanıcı bunu fark etmiyor
- Arama motoru crawler'ları ise yavaş yanıtlara bağlı olarak SEO puan cezası verebiliyor
Sonuç
- Next.js, açık kaynak framework kılığına girmiş bir Vercel vendor lock-in yapısına dönüşmüş durumda
- Bir sonraki projede teknoloji yığını seçerken Next.js yerine başka framework'leri değerlendirmek daha akıllıca
5 yorum
O zaman alternatif
remixoluyor, değil mi?Metinde de belirtildiği gibi, aşırı vendor lock-in, fazlasıyla black box hissettiren davranışlar ve sezgisel olmayan API'ler var. Üstelik React tarafı da sunucuda render edilen bu geliştirme tarzını sanki React'in standart geliştirme yaklaşımıymış gibi açık açık pazarlıyor. Çoğu uygulama için Vite tabanlı bir SPA'nın yeterli olduğunu düşünüyorum.
Vendor lock-in yaşanmasını bir ölçüde kabul ediyorum ama Next.js teknolojisinin kendisine dair görüşler de, sadece bakınca "Ben yazıyı okumak istemiyorum" seviyesinden pek öteye geçmiyor gibi görünüyor.
Eskiden beri sürekli açıkmış gibi yapıp kapalı bir çizgi izliyorlardı; sonunda neredeyse kapıyı tamamen kilitlediler.
Hacker News görüşleri
Next kullanmayı kesinlikle tavsiye etmem. Geliştirici deneyimi berbat, vendor lock-in çok ağır ve belgelenmemiş tuhaf konvansiyonlar yüzünden CRUD ağırlıklı basit bir B2B SaaS değilse her yerde mayın varmış gibi hissettiriyor. Özellikle aynı sayfadaki bir webgl sahnesinin FPS'ini 2'ye düşüren bir Next <Image /> etiketi vakası yaşadım
Vercel'in sıradan React kullanıcılarını vendor lock-in'e nasıl yavaş yavaş alıştırdığını merak ediyorum. React, Meta'nın açık kaynağı vurguladığı bir projeydi ve açık kaynağın vendor lock-in'i engellemesini umuyordum; ama pratikte öyle olmadığını görmek hayal kırıklığı yaratıyor
Kesinlikle katılıyorum. Kısa süre önce uzun zaman sonra tekrar Next kullandım ve geliştirme deneyimi çok hayal kırıklığı yarattı. Dokümantasyon belirsizdi, aradığımı bulmak zordu ve uygulamanın kendisi de varsayılan olarak yavaş hissettiriyordu. Docker ile AWS'ye dağıtmaya çalışırken Vercel'in sunduğu örnek Dockerfile yüzünden sayısız zorluk yaşadım
<Image /> sorununu bizzat analiz edip etmediğini, yoksa bunun NextJs'in sorunu olduğunu mu varsaydığını merak ediyorum. Ben NextJs, <Image> ve RTF kombinasyonuyla çalışıyorum ama böyle bir sorunla hiç karşılaşmadım
Son 3 yıldır işte Next.js kullanıyorum ve gerçekten acı verici hissettiriyor. Vercel'de host ettik ve şirket neredeyse Vercel'in tüm servislerini benimsedi; yani tam anlamıyla vendor lock-in yaşadık. Daha önce Dan'in RSC hakkında HN'de yazdığı gönderinin altında kötü deneyimlerimi paylaşmıştım ve tespitlerinin çok doğru olduğunu düşündüm. "RSC'nin kendisi artık epey sağlam ama Next.js gibi framework'ler hâlâ biraz ham" sözü gibi, genel olarak React de artık ortalamanın altında hissettiriyor ve Next.js bunu daha da kötü bir üne hızlandırıyor gibi. Uzak durmak en iyisi
Vercel bu hatayı düzeltecektir ama artık bu tür küçük sorunların birikmesi Next.js'ten bıktırdı. Örneğin middleware içinde prefetch tespit etme yöntemi haftalardır, belki aylardır bozuk. Bu tarz ufak sorunlar durmadan birikiyor, bu yüzden Next.js yorgunluğu yaşıyorum. Ama JS ekosisteminin kendisini hâlâ seviyorum
Next.js'ten çıkıp Astro'ya geçtim. Temellere dönmek istiyordum ama route/template/static asset/build'i kendim kurmakla uğraşmak istemedim. Astro bunların hepsini hallediyor ve varsayılan olarak SSR sunuyor. React/Vue'yu baştan amaçlandığı gibi etkileşim katmanı olarak üzerine ekliyormuşsun gibi hissettiriyor; bu da JS framework'lerinin aslında ne kadar gereksiz olabildiğini fark ettiriyor. Next giderek daha sihirli hale geliyor, server action'lar tuhaf hissettiriyor ve çok fazla "NextJS usulü" uygulama vardı
Şu anda hem işte hem yan projelerde Next.js kullanıyorum ama eskiden keyifli ve üretken bir araçken, pages'den app router'a geçişten sonra yönü beni hayal kırıklığına uğrattı
15.1.8 sürümünden sonra bazı kütüphaneler1 bozuldu ve yazarın bahsettiği güvenlik açığı olan sürüme geri dönmek zorunda kaldık
Katılıyorum. Bundan sonra Next.js'i yalnızca statik siteler veya önceden derlenmiş SPA'lar için kullanmayı planlıyorum
Next neredeyse bir şakaya dönüştü. Remix'in anlaşılmaz bir şekilde react-router'a dönüşmesinden sonra, düzgün React framework'ü neredeyse kalmamış gibi geliyor. Sonunda plain vite ve tanstack router kombinasyonuna geri döndüm
Hacker News'te böyle eleştirel bir yazının kalabilmesine şaşırdım. Geçmişte Remix ile daha basit yapılabildiğine dair bir yazı paylaşmıştım; ardından birkaç Vercel çalışanı bana yazıp kaldırmamı ya da toplantı yapmamızı istemişti. Aynı anda birden fazla sosyal medya hesabı üzerinden iletişime geçtiler
Rebrand'den sonra artık Remix kullanmadığını mı söylüyorsun, yoksa framework olmadığı anlamında mı? RR7 (React Router 7) da framework olarak gayet çalışıyor1. 15 yıllık backend geçmişinden sonra yakın zamanda full-stack'e geçtim; iyi bir arkadaş tavsiyesiyle RR7 kullanıyorum ve her gün etkileniyorum
Yeni bir projede TanStack Router denedim ve o kadar hoşuma gitti ki TanStack Query ve TanStack Form'u da ekledim
Alternatif olarak en iyi seçeneğin ne olduğunu ve neden Vite kullandığını merak ediyorum. Ben küçük projelerde Next kullanıyorum; en büyük avantajının SEO olduğu söylenmişti. Sonuçta statik dosyaları üretip S3'e yüklüyorsun, değil mi; artık durum bu değil mi diye merak ediyorum
Remix'in react-router'a dönüşmesinde tam olarak sorunun ne olduğunu merak ediyorum. Bana göre sadece bir yeniden markalama gibi görünüyor
Yıllardır, Vercel gibi şirketlerin yön verdiği React, Next, Svelte vb. teknolojilere çok daha temkinli yaklaşmak gerektiğini söylüyorum. Hedefleri Heroku gibi olmak ama çok daha saldırgan şekilde tüm yığında (dil-runtime-makine) tam lock-in yaratmak. Başka şirketlerin de sorunları var. Örneğin Cloudflare'ın CLI dağıtım aracı yalnızca macOS 13.5+ destekliyor; bu sürüm daha iki yılı biraz geçti ve neden böyle olduğu belirsiz. İki yıl önce çıkan bir işletim sisteminin eski sayılması üzücü. Eski wrangler sürümlerini kullanmak mümkün ama dokümantasyonla özellikler uyuşmuyor ve nasıl olsa daha da kötüleşecek gibi. Bir gün uyumluluk da kesilebilir. Öte yandan başka araçlar (vim, neovim, emacs vb.) hâlâ eski OS X sürümlerinde çalışıyor. Bence bunun nedeni bu açık araçlarda lock-in teşvikinin olmaması
Next ve RSC, frontend'de şimdiye kadar uğraştığım en bunaltıcı şeyler. Frontend zaten yeterince baş ağrıtıcıyken bir de Next'in "sihri" ekleniyor ve üstüne Vercel vendor lock-in'i geliyor. Ekip olarak bu hafta tanstack router ve vite'a geçip sade bir CSA yapmayı planlıyoruz; bunun için heyecanlıyım
Herkesin, Next.js geliştirme modunda route derlemenin 10 saniye sürmesi sorununu çok daha fazla konuşması gerekiyor. Rust derleyicisi köşede sigara molası veriyormuş gibi kalıyor
Kullanılamaz düzeyde. Yaşadığım en kötü devx buydu. En son bu kadar nefret ettiğim stack, bir keresinde Sharepoint sitesi işine yardım ettiğim zamandı
Artık basit bir script dili olan JS bile defalarca build/compile aşamasından geçiyor ve şimdi C++ derleyicisinden daha uzun sürüyor. Neredeyse tarayıcıya Clang koysan daha iyi deneyim olur. Bu arada işte PHP de kullanıyoruz ve orada da aynı sorun var. Script dili diye daha basit olur sanıyorsun ama PHP'nin kendi performans sınırları yüzünden ayrıca kod ön üretimi ve composer build aşamaları gerekiyor. Ama bu build de yavaş çünkü muhtemelen GCC'yi yapanlar değil, PHP geliştiricileri yaptı
Garip olan şu ki next dev —-turbo seçeneği de şirketimizin codebase'inde daha hızlı değil
Rust derleyicisi gerçekten derleme yapıyor; Next.js derleyicisinin de gerçekten bu kadar karmaşık bir iş yapıp yapmadığını merak ediyorum
Next.js'in geldiği hale üzülüyorum. Hâlâ kullanıyorum ama ancak fork'layıp patch'leyerek. next.config.js varsayılan davranışı değiştirebileceğin zorlu bir kaçış kapağı gibi ve bence bu tür ayarlar gerçek genişletme noktaları olarak sunulmalıydı, bir "feature flag" arkasına saklanmamalıydı. Şu haliyle neredeyse tam bir spagetti kod, D notluk bir framework
NextJS değilse, tüm stack açısından önerilen kombinasyon ne olur diye soruyorum. 15 yıllık backend geliştiricisiyim ama frontend tarafında AngularJS'ten beri ilk kez bir şey yapıyorum. Son zamanlarda bir yan proje için full-stack uygulama yapmaya çalışırken hem Gemini hem de resmi dokümanlar NextJS önerdi. Henüz çok başındayım; bu yüzden alternatifleri öğrenmek isterim. Her şeyi Docker ile bir VPS üzerinde kendim çalıştırmayı planlıyorum, dolayısıyla Vercel/Netlify'dan kaçınıyorum
Server-side rendering gerekmiyorsa framework'süz React ve Vite1 kombinasyonunu öneririm. Geliştirme sırasında Vite ile çalışırsın; production build çıktısı sadece HTML + JS dosyaları olur, onları da S3 gibi statik hosting'e yüklersin ve biter. Bunu 10 yılı aşkın süredir kullanıyorum ve sorun yaşamadım. Backend'de kendine rahat geleni kullan; ben bu aralar çoğunlukla PostgREST2 kullanıyorum. İstemcide API çağrıları için de react-query3 tavsiye ederim
Nasıl bir proje geliştirdiğini merak ediyorum. Ben tipik bir SaaS web uygulaması yapıyorum ve React/Refine.dev/Vite kombinasyonu bende oldukça iyi sonuç verdi. Refine.dev sayesinde CRUD sayfalarıyla uğraşmadan doğrudan özellik geliştirmeye odaklanabiliyorum
Bu konunun abartıldığını düşünüyorum. React'te streaming'in nasıl çalıştığını bilen biri için HTML'in satır satır stream edilemeyeceği zaten açık. Metadata yüzünden ilk paint'i (HTML, JS değil) engellememek gerekiyor. Bu davranışta bazı user-agent'lara istisna tanımak mantıklı. Çünkü trafiğin büyük kısmında amaç mümkün olduğunca hızlı görüntüleme sağlamak. Ama metadata yüklenmesi uzun süren kullanıcılar varsa bunun nasıl çözüleceğini merak ediyorum