Blog'a Dön

Vue 3.6 RC ile Vapor Mode Tamamlandı, Nuxt 3'ün Ömrü On İki Gün

Vue 3.6 RC, Vapor Mode'u tamamlıyor. Nuxt 4.5, Vite 8'e geçiyor ve deneysel SSR streaming getiriyor. Nuxt 3 ise 31 Temmuz'da end-of-life oluyor. Ben önce şunlara bakardım.

Umut Korkmaz

Yayın tarihi: 4 dk okuma

18 Temmuz'da çıkan iki sürüm, Vue ekiplerinin dikkatle okuması gereken türden. Vue, v3.6.0-rc.1 sürümünü yayınladı. Ekibe göre bu sürümle Vapor Mode için planlanan özellik seti tamamlandı. Nuxt ise Vite 8 üzerine kurulu ve deneysel bir SSR streaming modu getiren v4.5.0 sürümünü çıkardı. Nuxt'ın sürüm notlarında bu iki özellikten de önemli bir tarih var: Nuxt 3, 31 Temmuz 2026'da end-of-life oluyor.

Vue 3.6 RC gerçekte neler getiriyor

3.6'da birbirinden ayrı iki şey var. İlki, @vue/reactivity paketinin alien-signals üzerine kurulan büyük bir refactor'ü. Sürüm notlarına göre bu değişiklik reaktivite sisteminin performansını ve bellek kullanımını ciddi ölçüde iyileştiriyor.

İkincisi Vapor Mode. Bu, single-file component'ler için daha küçük bir temel bundle boyutu ve daha iyi performans hedefleyen yeni bir derleme modu. Tamamen opt-in, üstelik her component için ayrı ayrı açılıyor:

<script setup vapor>
// template-only SFCs and <script setup> are supported; Options API is not
</script>

Tamamen Vapor component'lerinden oluşan bir uygulama createVaporApp() ile başlatılabiliyor ve Virtual DOM runtime'ını hiç yüklemiyor. createApp() ile oluşturulmuş mevcut bir uygulama ise ikisini birlikte kullanmak için vaporInteropPlugin'i kuruyor. Ekip, Vapor'un üçüncü taraf benchmark'larda Solid ve Svelte 5 ile aynı seviyeye geldiğini söylüyor. Yine de şu anki önerileri temkinli: mevcut bir uygulamadaki performans açısından kritik bir sayfa ya da tamamen Vapor ile yazılmış küçük, yeni bir uygulama.

vapor eklemeden önce okunması gereken ince ayrıntılar

Vapor, bilinçli bir tercihle Vue'nun yalnızca bir alt kümesini destekliyor. VNode'lara ya da component public instance proxy'sine dayanan her şey kapsam dışında. Sürüm notlarındaki liste şöyle:

  • Options API ve app.config.globalProperties
  • Vapor component'lerinde null döndüren getCurrentInstance()
  • v-memo ve element bazlı @vue:xxx lifecycle event'leri
  • Component template ref'lerindeki $el, $props, $attrs, $slots ve $refs

Asıl can yakması muhtemel olan, eksik API'lerden çok üç davranış farkı. Vapor, uygun event'leri document'e delege ediyor. Dolayısıyla bir üst element stopPropagation() çağırırsa delege edilen handler hiç çalışmıyor. Slot içeriğini incelemek için slots.default() çağırmak da Vapor'da zararsız bir deneme sayılmaz. Bu çağrı slot'un render mantığını gerçekten çalıştırıyor. DOM oluşturabiliyor, effect kaydedebiliyor, hydration sırasında SSR DOM'unu sahiplenebiliyor. Custom directive'ler ise fonksiyon tabanlı yeni bir arayüze geçiyor. Render function ya da JSX ile yazılan component'ler VDOM component'i olarak kalıyor. Ekip, VDOM tabanlı component kütüphanelerinin Vapor içinde hâlâ pürüzler çıkarabileceği konusunda uyarıyor. Tavsiyeleri de iç içe karışık kullanım yerine her render modu için ayrı bölgeler oluşturmak.

Aynı soruya iki farklı cevap

Günlük stack'im React ve Next.js olduğu için bunu React Compiler ile kıyaslayarak okudum. React Compiler'ın dokümantasyonu, onu memoization'ı otomatik uygulayan ve component'lerin yalnızca gerektiğinde yeniden render edilmesini sağlayan, build-time'da çalışan stabil bir araç olarak tanımlıyor. Kademeli geçişin ne kadar rahat olacağı da kod tabanının Rules of React'e ne kadar uyduğuna bağlı. Benim okumama göre React component modelini koruyor ve hangi işin atlanacağına compiler karar veriyor. Vue ise farklı bir bahse giriyor: yazım modelini koruyor ama compiler'ın her component için farklı türde bir çıktı üretmesine izin veriyor. Bunun bedelini de daha dar bir API yüzeyiyle ödüyor.

Bu fark, ekip olarak vereceğiniz kararı da şekillendiriyor. React Compiler'ı benimsemek büyük ölçüde kademeli yayabileceğiniz bir kod hijyeni meselesi. Vapor ise bir mimari mesele. Hangi sayfalar bir render modu sınırını haklı çıkaracak kadar kritik, ve o component'ler yukarıdaki özellikler olmadan yaşayabilir mi?

Nuxt 4.5: yeni bir build katmanı ve bir streaming anahtarı

Nuxt 4.5, Vite 8'e ve onun Rolldown tabanlı altyapısına geçiyor. Rspack builder'ı Rspack 2'ye yükseltip @rsbuild/core üzerine yeniden inşa ediyor, ayrıca unhead v3 ve unctx v3'ü benimsiyor. Notlar üç kontrol noktasına dikkat çekiyor: custom Vite plugin'leri ve config'i, custom Rspack config'i ve useHead tiplerinin sıkılaştırılmasından kaynaklanabilecek breaking type değişiklikleri.

Benim ilk test edeceğim özellik experimental.ssrStreaming. Nuxt, HTML iskeletini hemen gönderiyor ve Vue render ettikçe body'yi stream ediyor. İşin püf noktası da açıkça yazılmış: status ve header'lar ilk byte ile birlikte kesinleşiyor. Yani <script setup> içindeki bir setResponseStatus() ya da middleware sırasında yapılan bir cookie yazımı istemciye ulaşamıyor. redirect, cache, isr, swr, noScripts veya ssr: false kuralı olan route'lar buffered render'a geri dönüyor. Bot'lar tamamen render edilmiş HTML alıyor, development ortamında ise düşürülen değişiklikleri adıyla belirten bir uyarı log'lanıyor. Özellik varsayılan olarak kapalı.

Nuxt 3'ün on iki günü kaldı

End-of-life tarihi 31 Temmuz. Ekip, 4.5.0 ile birlikte uyumlu düzeltmelerin backport edildiği v3.21.9'u da yayınladı. Ancak Vite 8, Rspack 2 ve unhead/unctx major sürümleri yalnızca v4'te kalıyor. Roadmap'inizde "sonra" başlığı altında bekleyen bir Nuxt 3 uygulaması varsa, o "sonra"nın artık bir tarihi var.

Pazartesi için listeme yazacaklarım

  • Nuxt 3 uygulamaları: Patch'i npx nuxt@latest upgrade --dedupe --channel=v3 ile alın, ardından v4'e geçişi ayrı bir iş olarak planlayın. Bunu tek bir PR içinde 4.5'in major güncellemeleriyle birleştirmeyin.
  • Nuxt 4 uygulamaları: 4.5'e geçmeden önce custom Vite plugin'lerinizin envanterini çıkarın ve unjs bağımlılıklarının birlikte güncellenmesi için npx nuxt upgrade --dedupe kullanın.
  • Streaming: Herhangi bir yerde açmadan önce middleware'lerde setResponseStatus ve cookie yazımlarını arayın, işe bir içerik route'uyla başlayın.
  • Vapor: Kritik bir sayfa seçin ve üzerinde kabaca bir ön kontrol yapın:
rg -n "getCurrentInstance|globalProperties|v-memo|@vue:|stopPropagation|slots\.default\(" src/

Hâlâ bir release candidate olduğu için Vapor'u production'a almak yerine, ölçümleriyle birlikte bir branch'te tutardım. Şu sıralar certificates.dev'in Vue ve Nuxt eğitimlerini ilerletiyorum. Bu da uzun zamandır sadece okumakla yetinmeyip ölçmek istediğim ilk Vue değişikliği.

Kaynaklar

Bu yazıda yararlanılan birincil kaynaklar.

  1. github.com/vuejs/core/releases/tag/v3.6.0-rc.1 (yeni sekmede açılır)
  2. github.com/nuxt/nuxt/releases/tag/v4.5.0 (yeni sekmede açılır)
  3. react.dev/learn/react-compiler/introduction (yeni sekmede açılır)

Yazar hakkında

Umut Korkmaz

Lead Yazılım Mühendisi

İstanbul'da kıdemli yazılım mühendisi olarak çalışıyorum. Burada, bizzat canlıya aldığım araçları ve sürümleri, sahada öğrendiklerimle birlikte yazıyorum.

Ortak konulara göre seçildi.

  • 4 dk okuma

    Next.js 16.3: Ücretsiz Gelenler ve Taşıma Gerektirenler

    Next.js 16.3'ün getirdikleri ikiye ayrılıyor: sadece sürümü yükselterek elde ettiğiniz kazanımlar ve isteğe bağlı Instant Navigations geçişi. İkisini nasıl planlardım, yeni AGENTS.md bloğu ekipler için ne anlama geliyor, bu yazıda anlatıyorum.

    • Next.js
    • React
    • Performans
  • 7 dk okuma

    Beş Yapay Zekâ Ajanının Portföyümü Yeniden Tasarlamasına İzin Vermek

    Portföyümün projeler bölümü on altı kartlık bir duvara dönüşmüştü. Onu yeniden tasarlamak için beş terminal kodlama ajanını izole çalışma dizinlerinde paralel çalıştırdım. Üçü aynı cevaba yakınsadı, ikisi faturalandırma ve kimlik doğrulamada çöktü ve yakınsama asıl mesele oldu.

    • Yapay Zekâ Ajanları
    • Tasarım
    • Portföy