13 puan yazan GN⁺ 2026-03-14 | 5 yorum | WhatsApp'ta paylaş
  • Mevcut esbuild + Rollup ikili yapısı, Rust tabanlı bundler Rolldown ile birleştirilerek 10 ila 30 kata kadar daha hızlı build performansı elde edildi
  • Yeni plugin registry duyuruldu; Vite, Rolldown ve Rollup plugin’leri aranıp yönetilebiliyor
  • Vite Devtools, TypeScript yol çözümleme, Wasm SSR, console forwarding gibi geliştirici deneyimini iyileştiren özellikler eklendi
  • Bu sürüm, Vite ekosistemindeki en büyük yapısal değişim olarak, gelecekteki entegre toolchain gelişiminin temelini oluşturuyor

Rolldown tabanlı Vite 8

  • Vite 8, mevcut esbuild (geliştirme için) ve Rollup (prodüksiyon için) ikili bundler yapısını tek bundler olan Rolldown altında birleştiriyor
    • Rolldown, Rust ile yazılmış yüksek performanslı bir bundler ve Rollup ile aynı plugin API’sini destekliyor
    • Mevcut Vite plugin’lerinin büyük bölümü ek değişiklik gerektirmeden çalışıyor
  • Performans, Rollup’a kıyasla 10 ila 30 kat daha hızlı; ayrıca modül düzeyinde caching, esnek chunk bölme, Module Federation gibi gelişmiş özellikleri destekliyor

Rolldown’a geçiş süreci

  • Başlangıçta rolldown-vite paketiyle teknik önizleme sunularak topluluk geri bildirimi toplandı
    • Çeşitli gerçek kod tabanlarında test edilerek uyumluluk sorunları çözüldü
    • Başlıca plugin ve framework’ler için özel CI test sistemi kuruldu
  • 2025 Aralık’ta Vite 8 beta yayımlandı ve Rolldown tam olarak entegre edildi
    • Beta sürecinde Rolldown, Release Candidate aşamasına ilerleyerek kararlılık kazandı

Gerçek performans iyileştirme örnekleri

  • Birçok şirket build süresinde kısalma bildirdi
    • Linear: 46 saniye → 6 saniye
    • Ramp: %57 kısalma
    • Mercedes-Benz.io: %38’e kadar kısalma
    • Beehiiv: %64 kısalma
  • Proje büyüdükçe etki daha belirgin hale geliyor ve Rolldown’ın sürekli iyileştirilmesi planlanıyor

Entegre toolchain ve teknoloji yığını

  • Vite 8, Vite (build aracı), Rolldown (bundler) ve Oxc (compiler) bileşenlerinin yakın iş birliğiyle uçtan uca bir toolchaine dönüşüyor
    • Parse, dönüştürme ve optimizasyon süreçlerinin tamamında tutarlılık sağlanıyor
    • Oxc’nin semantik analizi kullanılarak tree shaking optimizasyonu mümkün oluyor
    • Yeni JS standartlarının daha hızlı benimsenebileceği bir yapı sunuluyor

Ek özellikler

  • Vite Devtools: geliştirme sunucusunda proje durumunu görsel olarak analiz etmeyi sağlıyor
  • TypeScript yol (alias) çözümleme otomasyonu ve emitDecoratorMetadata için yerleşik destek
  • Wasm SSR: sunucu tarafı render ortamında .wasm?init import desteği
  • Tarayıcı console forwarding: tarayıcı hatalarını terminale ileterek debugging verimliliğini artırıyor
  • @vitejs/plugin-react v6: Babel kaldırıldı, Oxc tabanlı React Refresh uygulandı, kurulum boyutu azaltıldı

Gelecek geliştirme yönü

  • Full Bundle Mode (deneysel): geliştirme sırasında da bundling yaparak 3 kat daha hızlı sunucu başlangıcı, %40 daha hızlı reload, 10 kat daha az ağ isteği sağlıyor
  • Raw AST aktarımı ve Native MagicString dönüşümü ile Rust ve JS arasındaki performans farkı azaltılıyor
  • Environment API kararlılığı için ekosistem çapında iş birliği sürüyor

Kurulum boyutundaki değişim

  • Vite 8, Vite 7’ye göre yaklaşık 15MB daha büyük
    • lightningcss (yaklaşık 10MB): varsayılan CSS sıkıştırma işlevi sunuyor
    • Rolldown binary’si (yaklaşık 5MB): hız optimizasyonu için boyut artışı getiriyor
  • Gelecek sürümlerde boyut optimizasyonunun sürmesi planlanıyor

Geçiş kılavuzu

  • Çoğu proje ayar değişikliği olmadan yükseltilebiliyor
    • Mevcut esbuild ve rollupOptions ayarları otomatik dönüştürülüyor
  • Büyük projeler için iki aşamalı geçiş öneriliyor
    • Önce Vite 7’den rolldown-vite’a geçip ardından Vite 8’e yükseltme
  • Ayrıntılı adımlar resmi Migration Guide ve Changelog içinde bulunabiliyor

Rollup ve esbuild’e teşekkür

  • Rollup, Vite’ın plugin ekosisteminin temelini sağladı; Rolldown da bu API’yi devralıyor
  • esbuild, hızlı geliştirme deneyimini mümkün kılan temel teknoloji oldu ve Rust/Go tabanlı tooling’in gelişimine zemin hazırladı
  • Her iki projenin katkısı da Vite’ın DNA’sına derinden işlemiş durumda

Topluluk ve iş birliği

  • Vite 8’in geliştirilmesi, sapphi-red ve Vite ekibi, Rolldown ekibi ve çok sayıdaki topluluk katkıcısının iş birliğiyle tamamlandı
  • VoidZero, Bolt, NuxtLabs başlıca partnerler olarak yer aldı

5 yorum

 
GN⁺ 2026-03-14
Hacker News yorumları
  • Sektörün “build zaten uzun sürer” diyerek hiç sorgulamadan kullandığı verimsiz araçlar yüzünden ne kadar çok hesaplama kaynağını boşa harcadığımızı yeniden düşündürüyor
    O yavaş build’lere göre takvim yaptık, molaları şaka konusu haline getirdik, hatta cache katmanları bile kurduk
    Vite bakımcılarına alkışlar

    • Yavaş JS bundle’larının boşa harcadığı kaynaklardan da büyük olan şey, verimsiz runtime’lar ve soyutlamalar yüzünden oluşan maliyet
      Çoğu production yazılımı, gerekenden onlarca kat daha yavaş
      Electron uygulamalarının GB’larca RAM kullanırken 40 yıl önceki yazılımlardan daha takılarak çalışması bunun kanıtı
    • Ben de aynı fikirdeyim. ESLint ya da Prettier gibi araçlar da Oxc'yi öğrendikten sonra benzer bir israf gibi gelmeye başladı
    • İleride matris çarpımı konusunda da bu tür israfı dönüp sorgulayacağımız bir gün gelecek gibi
    • Build performansı uzun zamandır ilgi alanımdı
      14 yıl önce, build beklerken boşa giden zamanı fark edip bu sorunun özellikle Java ekosisteminde ciddi olduğunu düşünmüştüm
      Eskiden bir Ruby projesinde entegrasyon testleri her seferinde DB’yi yeniden oluşturduğu için 10 dakika sürüyordu
      Kotlin/Spring Boot da yavaş derleniyor, Rust derleyicisi de hızlı sayılmaz
      Ama testler bizim kontrol edebildiğimiz alan. Unit testlerin milisaniyeler içinde bitmesi gerekir; entegrasyon testlerinde ise paralelleştirme ve veri randomizasyonu büyük iyileşme sağlayabilir
      Ben MacBook Pro’da Redis, DB ve Elasticsearch içeren yüzlerce Spring entegrasyon testini 40 saniyenin altında çalıştırıyorum
      Böyle bir ayarı bir kez yaptıktan sonra hızlı geri bildirim döngüsü oluşuyor ve geliştirme keyfi geri geliyor
  • Vite 8’e katkım, Wasm SSR desteği oldu
    .wasm?init import’unun SSR ortamında da çalışmasını sağlayacak şekilde genişlettim
    Süreç yavaştı ama ekibin her ayrıntıda yardımcı olması ve hatta dokümantasyon eklemesi etkileyiciydi

    • Böyle perde arkası hikâyeler duymak işi daha da ilginç kılıyor
      Vite ekibinin sadece araç yapmakla kalmayıp katkıcı eğitimi ve iş birliği konusunda da gerçekten ciddi olduğu hissediliyor
  • Electron çağında böyle performans artışları görmek gerçekten sevindirici
    Uzun süredir bakımını yaptığım bir projede (React hooks öncesinden geliyor) eskiden Webpack tabanlı react-scripts ile build 2 dakika sürüyordu
    Şimdi Vite 8 ile 1 saniyede bitiyor. Ne kadar çok kaynağı boşa harcamış olduğumuzu gösteren bir örnek

    • Şimdi de AI modellerinin üstüne makinelerin kullanabileceği arayüzleri zorla eklediğimiz yeni bir kâbus başlıyor gibi
    • İşin ironik yanı, Vite ana sayfası A55 ya da S23FE’de bile kasıyor
    • Aslında JS baştan beri build süreci gerektirmeyen bir dildi
      Tarayıcının onu doğrudan çalıştırabilmesi gerekiyordu ve TypeScript de sadece tipler kaldırıldığında hemen çalışacak şekilde tasarlanmıştı
      Bu tür build araçlarının varlığı bile sanki yanlış yöne gidildiğini düşündürüyor
  • Ekibimizde Vite 8’e geçtikten sonra build süresi 4 dakikadan 30 saniyeye indi
    Neredeyse drop-in replacement düzeyindeydi, Vite ekibine teşekkürler

    • Bizde de 10 saniyeden 1 saniyeye düştü. Ana sebep Rolldown
      Vite’a entegre edilmeden önce de kullanıyordum, gerçekten harika
    • 4 dakika mı? Uygulamanın ne kadar büyük olduğunu merak ettim
      Next’ten daha hızlı deniyor ama bu kadarsa epey büyük olmalı
    • Projelerimizden biri 12 dakikadan 2 dakikaya indi. Gerçekten inanılmaz bir değişim
  • Belirli bir framework’e bağlı olmayan bir açık kaynak bundling çözümü geliştiren Vite ekibine teşekkürler
    (hafifçe öksürerek Turbopack demek)

  • Harika haber. Ama Next.js bu topluluğun başarılarından yararlanamayacak gibi görünüyor
    Sebebi Vercel’in NIH sendromu

    • Vercel’in tarzı hep yıllarca yarım kalmış preview’leri çalıştırmak oldu
      Next 13’te Turbopack alpha’yı başlattılar, ancak Next 16’da varsayılan yaptılar
      2022’de Vite ile yapılan karşılaştırma benchmark’ları da çarpıtılmıştı
      Cache sorunları, yavaş performans, RSC güvenlik açıkları, kafa karıştırıcı app router, Vercel dışı hosting’in zahmetli olması gibi nedenlerle
      Next.js seçmek bir risk
      İlgili bağlantılar: karşılaştırma tartışması, cache geçmişi, performans analizi, güvenlik CVE’si, OpenNext
    • Birkaç yıl sonra React’e geri döndüm ama Next’in varlık sebebini anlamakta zorlanıyorum
      Resmî dokümanlarda bile Next’in varsayılan gibi sunulması tuhaf
      React’i SPA olmayan bir şekilde kullanmanın neden gerekli olduğunu bilmiyorum
    • Next.js, çeşitli enterprise SaaS partnerleri ile entegrasyonlar nedeniyle resmî SDK olarak öne itiliyor
      Örnek: Sitecore Cloud, Sanity, Contentful vb.
    • Bu arada Cloudflare Vinext de var (kendim denemedim)
  • Vite+, Void Cloud, Void Framework derken
    şimdi sıra Vercel ile Void arasındaki mücadeleye geliyor gibi
    Özellikle PRC(Server Functions) demosu ilginç — DB’den UI’a kadar uçtan uca tip güvenliği gösteriyor
    Biz de Telefunc(tRPC alternatifi) ile RPC tasarımını araştırıyoruz ve Void ekibiyle iş birliği yapmayı umuyoruz
    İlgili bağlantılar: PRC demo videosu, Telefunc, Vike

    • İlginç olan, Vercel’in dolaylı olarak Void yatırımcısı olduğu yönünde söylentiler var
      Void Cloud’un Cloudflare Workers üstünde kurulu olduğu anlaşılıyor, şu an bilgi az
      Yine de Vite+’ın MIT açık kaynak olarak yayımlanacak olması çok cesaret verici
      Eğer Bun, Anthropic desteğine fazla odaklanıp OSS tarafını ihmal ederse rekabet avantajını kaybedebilir
      Not: Void Cloud
  • JS ekosistemi ne kadar karmaşık olursa olsun, Vite sürekli olarak güçlü DX ve production kalitesi sunuyor
    Entegre Rolldown bundler ile daha hızlı ve esnek bir temel olacak
    1998’den beri web geliştirme yapan biri olarak gerçekten hayranıyım

  • Uzun vadeli bakımı önemsediğim için esbuild’i doğrudan kullanıyorum
    Vite gibi wrapper’lar iç değişiklikler yüzünden her bozulduğunda düzeltmek zorunda kalmaktan hoşlanmıyorum

    • Ben de benzer şekilde esbuild + basit bir RPC katmanı kullandım
      Tip doğrulamayı Zod ile yaptım, yalnızca Postgres tipleri için codegen kullandım
      Bir sonrakinde muhtemelen Kysely kullanırdım
    • esbuild, yıllar geçse de bozulmayan tek JS aracı oldu
    • Ama hâlâ code splitting tarafı zayıf
    • Ayrıca top-level await desteklemiyor ve live reloading, HMR’den çok daha yavaş
  • Yerleşik tsconfig paths desteği gerçekten iyi bir QoL iyileştirmesi
    Ayar tekrarını azaltabilir

    • Güzel haber ama Node.js import alias da denenebilir
      Projeye göre daha basit olabilir
 
aer0700 2026-03-14

Aslında JS başlangıçta derleme süreci gerektirmeyen bir dildi; tarayıcının onu olduğu gibi çalıştırabilmesi gerekiyordu ve TypeScript de yalnızca tipler kaldırıldığında doğrudan çalışacak şekilde tasarlanmıştı. Bu tür derleme araçlarının varlığı başlı başına yanlış bir yön gibi görünüyor -> bunu nasıl yeniden normalleştirebiliriz;

 
carnoxen 2026-03-17

Tarayıcıda çalışan şeyi artık doğrudan sunucuda da çalıştırmaya başladıklarına göre, sanırım bu kaçınılmaz bir gidişattı.

 
ahiou 2026-03-15

Bunun, web uygulamaları gelişip karmaşıklaştıkça ortaya çıkan doğal bir olgu olduğunu düşünüyorum.

 
savvykang 2026-03-14

Belki de Flash’ı bıraktığımız gibi tarayıcı JS’sini de bırakmamız gerekiyor, değil mi? Ama JS’nin bırakılacağına dair hiçbir işaret görünmüyor.