Rust Dalgası ve 2025–2026 Sürüm Haritası: Rolldown, Oxc, Rspack, Turbopack, Lightning CSS ve Araç Seçimi

Sürüm notu: Bu yazıdaki örnekler Vite 8.3 (Rolldown 1.2), Rolldown 1.3, esbuild 0.28, Rspack 2.3, webpack 5.112, Angular CLI 22.2, TypeScript 7.0 ve Node.js 24 ile denenmiştir; tarayıcı ölçümleri Playwright 1.65'in Chromium'uyla alınmıştır. Süreler yazarın kendi makinesinden alındı; mutlak değerlere değil, araçlar arasındaki orana bak.

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'un (bir online kitapçı) "kitap bul" widget'ını bu seride dört araçla build ettik: Vite, esbuild, webpack ve bu yazıda eklediğimiz Rspack. Duyurulara göre Rspack webpack'ten kat kat hızlı, Rolldown ise Rust ile yazılan en yeni bundler. Widget'ın production build'ini her aracın kendi CLI'ıyla, aynı makinede, beşer kez çalıştırıp medyanları karşılaştırıyoruz. Sence sıralama nasıl çıkar? En hızlı araç en yavaşından kaç kat hızlıdır? Aynı dört aracı 2000 module'lük bir projede çalıştırınca sıralama değişir mi?

Bu yazı Build Araçları serisinin son yazısı. 2025 ortasından 2026 sonuna kadar build araçlarında olanları bir sürüm haritasında topluyoruz: Rolldown ve Oxc ile Vite'ın değişimi, Rspack ve Rsbuild 2.0, webpack ve esbuild'in durumu, Lightning CSS ve Turbopack. Sonra bu seride kullandığımız ölçümleri kendi projende nasıl tekrarlayacağını ve hangi durumda hangi aracı seçeceğini konuşuyoruz.

2025–2026 Sürüm Haritası

Tarihleri npm kayıtlarından ve projelerin kendi duyurularından aldık:

Tablonun ortak teması belli: JavaScript ile yazılmış araçların (Rollup, Terser, Babel, PostCSS tabanlı zincirler) yerini Rust ve Go ile yazılmış araçlar alıyor. Ama bu araçların çoğu tek başına kullanılmıyor; Vite, Angular CLI ve Next.js gibi daha üst seviyedeki araçların içine giriyor. Bir uygulama geliştiricisi olarak Rolldown'ı doğrudan çağırmazsın; Vite 8'e ya da Angular 22.1'e yükseltirsin ve Rolldown gelir.

Rolldown ve Oxc: Vite'ın Yeni Motoru

Rolldown, Rollup'ın plugin API'siyle uyumlu, Rust ile yazılmış bir bundler. Vite'ın neden ona ihtiyaç duyduğunu serinin Vite yazısında gördük: Vite 7'ye kadar dev tarafında esbuild, production'da Rollup vardı ve iki araç aynı kodu farklı davranışlarla işleyebiliyordu. Vite 8 ikisini Rolldown ile değiştirdi. Rolldown 1.0'ın Mayıs 2026'da çıkmasıyla API'si de kararlı hâle geldi; yazım anında son sürüm 1.3.2, Vite 8.3.8 ise 1.2.19'u kullanıyor.

Oxc (JavaScript Oxidation Compiler; Rust ile yazılmış JavaScript araçları) aynı ekibin parser, transformer, resolver, minifier ve linter'dan oluşan araç seti. Rolldown TypeScript ve JSX (JavaScript içinde HTML benzeri syntax) dönüşümünü Oxc'ye yaptırıyor; Vite 8'in JavaScript minifier'ı da Oxc. Angular CLI da aynı yöne gidiyor: serinin Angular CLI yazısında gördüğümüz gibi 22.1'de advanced optimization dönüşümleri, 22.2'de Angular linker Babel'den oxc-parser'a geçti. Oxc'nin linter'ı oxlint, ESLint kurallarının büyük kısmını çok daha hızlı çalıştırmayı hedefliyor; bu tarafı Statik Analiz serisinde ele alıyoruz.

Lightning CSS ise CSS tarafındaki karşılık: Rust ile yazılmış bir CSS parser'ı, transformer'ı ve minifier'ı. Vite 8'de CSS minification'ı varsayılan olarak o yapıyor; serinin ilk yazısında CSS nesting'in hedef tarayıcılara göre düzleştirildiğini gördüğümüzde arka planda çalışan araç oydu.

Rspack ve Rsbuild 2.0: webpack Uyumlu Rust

Rspack, webpack'in config biçimini, loader ve plugin API'sinin büyük kısmını koruyan, Rust ile yazılmış bir bundler. Büyük bir webpack mirasın varsa, Vite'a geçmek bütün build'i yeniden yazmak demek; Rspack'e geçmek ise çoğu zaman config'i uyarlamak. Bunu denemek için widget'ın webpack config'ini Rspack'e taşıdık:

import path from "node:path";
import { defineConfig } from "@rspack/cli";
import { rspack } from "@rspack/core";

// webpack.config.mjs'teki widget'ın aynısı; Rspack'in yerleşik SWC loader'ı, CSS'i ve HTML plugin'iyle
export default defineConfig((env, argv) => {
    // Content hash yalnız production'da: dev'de CSS hot update eski dosya adını arıyor
    const hash = argv.mode === "development" ? "" : ".[contenthash:8]";
    return {
    entry: { index: "./src/main.ts" },
    // Hedef verilmezse SWC ve runtime eski syntax'a döner (async/await generator yardımcılarına dönüşür)
    target: ["web", "es2022"],
    output: {
        path: path.resolve(import.meta.dirname, "dist-rspack"),
        filename: `[name]${hash}.js`,
        cssFilename: `[name]${hash}.css`,
        clean: true,
    },
    resolve: { extensions: [".ts", ".js"] },
    module: {
        rules: [
            { test: /\.ts$/, loader: "builtin:swc-loader", options: { jsc: { parser: { syntax: "typescript" } }, env: { targets: ["chrome 111", "edge 111", "firefox 114", "safari 16.4"] } }, type: "javascript/auto" },
            { test: /\.css$/, type: "css/auto" },
        ],
    },
    plugins: [
        // index.html Vite için /src/main.ts'i yüklüyor, bu yüzden Rspack kendi küçük sayfasını alıyor
        new rspack.HtmlRspackPlugin({
            title: "Bookstore book finder",
            templateContent: '<!doctype html><html lang="en"><head><meta charset="utf-8"><title>Bookstore book finder</title></head><body><div id="book-finder"></div></body></html>',
        }),
    ],
    };
});

Farklar küçük: TypeScript için ts-loader yerine Rspack'in içindeki, SWC (Rust ile yazılmış bir JavaScript ve TypeScript derleyicisi) tabanlı builtin:swc-loader, CSS için ayrı loader yerine css/auto module tipi, HTML için html-webpack-plugin yerine yerleşik HtmlRspackPlugin. webpack config'imizdeki HTML entry'yi (webpack 5.10x'in yeni özelliği) Rspack'te kullanmadık, sayfayı plugin üretiyor. Taşırken bir hataya da düştük. İlk config'te dosya adlarında hep [contenthash:8] vardı; rspack serve ile CSS'i değiştirince tarayıcı konsolunda şu satırlar çıktı ve stil güncellenmedi (port, Rspack'in varsayılanı 8080 olarak yazıldı):

Refused to apply style from 'http://localhost:8080/index.c1db4833.css?hmr=...' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
[HMR] Update failed: Loading css hot update chunk index failed.

Hot update, CSS'in eski hash'li adını istiyor, dev server o adı bulamayıp HTML dönüyor. Hash'i yalnız production'a bırakınca CSS değişikliği sayfa yenilenmeden uygulandı. İkinci sürpriz çıktı boyutundaydı: ilk Rspack build'inin JavaScript dosyası 8.26 kB, webpack'inki 3.77 kB'tı. Dosyayı açınca sebebi gördük: async/await, generator tabanlı yardımcı fonksiyonlara çevrilmişti. builtin:swc-loader'a ve Rspack'in target'ına hedef verilmediğinde kod eski syntax'a dönüştürülüyor. Vite'ın Baseline hedefindeki tarayıcıları verince dosya 3.44 kB'a indi; webpack çıktısında ise async/await zaten olduğu gibi duruyordu. Rspack 2.0'ın kendi paketlerini yalnız ESM olarak yayımladığını da hatırlatalım; config'i .mjs yazmamız bu yüzden sorunsuz.

Rsbuild ise Rspack'in üzerine kurulu, Vite'a benzer biçimde varsayılanları hazır gelen bir build aracı; Rspack 2.0 ile aynı gün 2.0 sürümüne geçti. Yeni bir projede Rspack'i doğrudan yapılandırmak yerine Rsbuild'le başlamak, webpack tarzı config'in esnekliğini isteyip ayrıntıyla uğraşmak istemeyenler için daha kısa yol.

webpack, esbuild ve Turbopack: Diğerleri Ne Durumda?

webpack ölmedi. 5.107 ile 5.112 arasında native CSS, HTML entry ve yerleşik TypeScript desteği core'a girdi; 2026 roadmap'i webpack 6'yı daha az ayarla çalışan bir sürüm olarak tarif ediyor. Serinin webpack yazısında bunları ayrıntılı gördük. Ama Angular 22.0 webpack builder'larını deprecated yaptı, Next.js 16 varsayılanı Turbopack'e çevirdi; webpack'in en büyük iki kullanıcısı ondan uzaklaşıyor. Yeni bir proje için webpack'i seçmenin tek güçlü sebebi kalıyor: Module Federation gibi, ekosistemi webpack etrafında kurulmuş bir ihtiyaç. O durumda bile Rspack aynı API'yi daha hızlı sunuyor.

esbuild hâlâ birçok aracın içinde çalışıyor: Angular CLI'ın uygulama kodunu bundle'layan araç o. 0.28.0 (Nisan 2026) metin dosyalarını with { type: 'text' } ile import etmeyi ve kurulumun yedek indirme yoluna bütünlük kontrolünü getirdi; derlendiği Go sürümü 1.26 oldu. Serinin esbuild yazısındaki sınırlar (HMR, yani sayfayı yenilemeden değişen module'ü değiştirme desteği yok, code splitting yalnız ESM'de) değişmedi; esbuild küçük ve tek amaçlı işlerde hâlâ en sade seçenek.

Turbopack ise Next.js'in kendi bundler'ı. Next.js 16 ile hem next dev hem next build onu varsayılan kullanıyor; eski yola next build --webpack ile dönülebiliyor. Turbopack bağımsız bir araç olarak değil, Next.js'in parçası olarak geliştiriliyor; Angular ya da Vite projesinde seçebileceğin bir şey değil. Next.js kullanmıyorsan bu sürüm haritasında yalnız bir eğilimin işareti: framework'ler bundler'ı kendileri seçiyor.

Kendi Ölçümün: Production Build

Duyurulardaki performans rakamları o ekiplerin seçtiği projelerden geliyor. Serinin Vite yazısında Vite ekibinin Linear, Ramp ve Beehiiv rakamlarını aktarmış, kendi ölçümümüzü bu yazıya bırakmıştık. Önce tahmin sorusundaki ölçüm: widget'ın production build'i, her aracın kendi CLI'ıyla, bir warm-up ve beş ölçüm turu:

// Her aracın production build'ini kendi CLI'ıyla çalıştırır (1 warm-up + 5 tur), medyanı, en hızlıya oranı
// ve üretilen JS ve CSS'in gzip boyutunu yazar.
const tools = {
    "vite (Rolldown)": { args: ["node_modules/vite/bin/vite.js", "build"], out: "dist" },
    "esbuild": { args: ["esbuild.config.mjs"], out: "dist-esbuild" },
    "rspack": { args: ["node_modules/@rspack/cli/bin/rspack.js", "build"], out: "dist-rspack" },
    "webpack": { args: ["node_modules/webpack-cli/bin/cli.js", "--mode", "production"], out: "dist-webpack" },
};

npm run bench:build

vite (Rolldown)    2.2x  2.17 KiB gzip (JS + CSS)
esbuild            1.2x  2.26 KiB gzip (JS + CSS)
rspack             1.0x  1.91 KiB gzip (JS + CSS)
webpack            5.3x  1.97 KiB gzip (JS + CSS)

Sıralama çoğu kişinin tahmin ettiği gibi değil: bu küçük projede en hızlı Rspack, Vite ondan yaklaşık iki kat yavaş. Sebep ölçtüğümüz şeyde. Widget'ın yirmi kadar module'ü var; build'in kendisi milisaniyeler sürüyor ve toplam sürenin çoğu Node.js sürecinin açılması, CLI'ın ve config'in yüklenmesi. Vite her açılışta vite.config.ts'i önce derleyip sonra yüklüyor, Rspack'in CLI'ı ise native binding'ine hızla geçiyor. webpack'in yaklaşık 5 katlık farkının bir kısmı da JavaScript ile yazılmış araç zincirini yüklemekten geliyor. Çıktı boyutları birbirine yakın; Vite'ınki modulepreload polyfill'ini içerdiği için biraz büyük.

Proje büyüyünce tablo değişiyor. Serinin esbuild yazısındaki ölçüm script'ine Rspack'i ekledik ve script'i, birbirini import eden N tane küçük module üretecek şekilde genişlettik. Burada araçlar aynı Node.js sürecinde, JS API'leriyle çalışıyor; süreç açılışı ölçüme girmiyor:

npm run bench:scale -- 1000
npm run bench:scale -- 2000

1000 modules
  esbuild     1.2x
  rolldown    1.0x
  rspack      3.6x
  webpack    71.9x
2000 modules
  esbuild     1.3x
  rolldown    1.0x
  rspack      5.6x
  webpack   137.6x

Rolldown ve esbuild birbirine yakın ve module sayısı artınca oranları değişmiyor. Rspack 1000 module'de yaklaşık 3.6, 2000'de 5.6 kat yavaş; webpack ise 70 ile 140 kat arasında ve bu oran turdan tura oynuyor (aynı 2000 module'lük ölçümün bir önceki koşusunda 196 kattı). webpack'in süresinin nereye gittiğine baktık: 2000 module'lük build'de minification'ı kapatınca süre yaklaşık 28'de birine indi. Farkın çoğu, webpack'in varsayılan minifier'ı olan ve JavaScript ile yazılmış Terser'dan geliyor; scope hoisting ile tek bir dev scope'a toplanan kodu minify etmek Terser için ağır bir iş. Bu yüzden webpack projelerinde ilk ve en ucuz iyileştirme, minifier'ı esbuild ya da SWC tabanlı bir minifier'la değiştirmek; bundler'ı değiştirmek ikinci adım.

Bir uyarı: üretilen module'ler gerçek bir uygulamaya benzemiyor; hepsi aynı kalıpta, CSS ve asset yok. Bu ölçüm araçların ölçeklenme eğilimini gösteriyor, senin projendeki süreyi değil.

Kendi Ölçümün: Dev Server ve HMR

Geliştiricinin gün içinde en çok beklediği şey production build değil, dev server'ın açılması ve kaydettiği değişikliğin ekrana gelmesi. Bunu da Playwright ile ölçtük (widget'a playwright devDependency olarak eklendi; ilk çalıştırmadan önce npx playwright install chromium gerekiyor). Script her dev server'ı boş bir portta başlatıyor, widget Chromium'da görünene kadar geçen süreyi alıyor, sonra styles.css'te bir rengi ve finder.ts'te placeholder metnini üçer kez değiştirip değişikliğin sayfada görünmesine kadar geçen süreyi ölçüyor:

async function timeUntil(page, edit, check, expected) {
    const start = performance.now();
    edit();
    for (;;) {
        try {
            // Tam sayfa yenilemesi bekleme sırasında context'i yok eder; o zaman yeniden bekleriz
            await page.waitForFunction(check, expected, { timeout: 30_000, polling: 10 });
            return performance.now() - start;
        } catch (error) {
            if (performance.now() - start > 30_000) {
                throw error;
            }
        }
    }
}

npm run bench:dev

tool      first render  CSS change  TS change
vite              1.4x        1.0x       1.5x
rspack            1.0x        1.4x       1.0x
webpack           3.0x        2.3x       1.1x

İlk açılışta Rspack önde; Vite yaklaşık 1.4, webpack 3 kat sürüyor. CSS değişikliğinde sıralama tersine dönüyor: en hızlı Vite, Rspack 1.4, webpack 2.3 kat. Burada mutlak değere de bakmak gerekiyor: bu makinede üç araçta da CSS değişikliği 100 ms'nin altında ekrana geldi; kullanıcı aradaki farkı hissetmez. TypeScript değişikliğinde üç araç da sayfayı tamamen yeniliyor, çünkü serinin Vite yazısında gördüğümüz gibi widget'ta bir HMR sınırı yok. Burada Vite 1.5 kat yavaş; muhtemel sebep, yenilenen sayfada Vite'ın her module'ü ayrı bir istekle sunması, bundle'layan araçların ise tek dosya vermesi. Ölçümler arası oynama da büyük: aynı script'in önceki koşularında Rspack'in CSS oranı 1.4 ile 4.7 arasında değişti. Yirmi module'lük bir projede bu farklar araç seçimini belirleyecek kadar büyük değil; büyük bir projede ölçümü kendi kodunla tekrarlaman gerekir.

Karar Tablosu

Bu seride gördüklerimizi bir karar tablosunda topluyoruz:

MPA satırı, her sayfası sunucudan ayrı HTML olarak gelen Bookstore.Web'in durumu: Razor sayfasına gömülen widget için Vite'ı seçtik, çünkü HMR ve manifest entegrasyonu istedik; yalnız tek bir script'i küçültmek isteseydik esbuild yeterdi.

Üretimde Dikkat

Ölçümü CI'da tekrarla, tek seferlik yapma. Bir bundler güncellemesi build süresini ya da çıktı boyutunu değiştirebilir; bench:build'in çıktısını release'ler arasında karşılaştırmak bunu görünür yapar. Mutlak süreyi değil, aynı makinedeki oranları ve eğilimi izle.

Bir araç değişikliğini önce çıktı üzerinden doğrula. Bu seride gördüğümüz gibi araç değişince davranış da değişebiliyor: moment'in dil dosyaları webpack'te bundle'a giriyor, esbuild'de girmiyordu; Vite 8'e geçişte esbuild.drop sessizce etkisiz kalıyordu. Çıktı dosyalarının listesini, boyutlarını ve uygulamanın tarayıcıdaki davranışını eski build ile karşılaştır.

Native binding'lere dikkat et. Rolldown, Rspack, Oxc ve Lightning CSS platforma özel ikili paketlerle geliyor (Windows'ta win32-x64). CI'da npm ci farklı bir işletim sisteminde çalışıyorsa ya da --omit=optional ile kurulum yapılıyorsa bu paketler eksik kalabilir; hata genelde "binding bulunamadı" biçiminde gelir.

Sık Düşülen Tuzaklar

Birincisi, duyurudaki performans rakamını kendi projene taşımak. Rakamlar o ekiplerin seçtiği projelerden geliyor; küçük bir projede süreç açılışı, büyük bir projede minifier ya da type check baskın olabilir.

İkincisi, yanlış şeyi ölçmek. CLI ile ölçmek süreç açılışını da katar, JS API ile ölçmek katmaz; ikisi farklı soruların cevabı. Hangi süreyi kısaltmak istediğini önce belirle: CI'daki production build mi, geliştiricinin her kayıtta beklediği HMR mı?

Üçüncüsü, "Rust ile yazılmış, o hâlde her şeyde hızlı" diye düşünmek. Bizim ölçümümüzde Rspack küçük projede en hızlı, büyük projede Rolldown ve esbuild'in gerisindeydi; webpack'in yavaşlığının çoğu da bundler'dan değil minifier'dan geliyordu.

Dördüncüsü, framework'ün yönettiği build'e müdahale etmek. Angular ve Next.js bundler'ı kendileri seçiyor; Angular projesine ayrı bir Vite ya da Rspack config'i eklemek, CLI'ın verdiği garantileri kaybetmek demek.

Beşincisi, araç değiştirirken eski config'i olduğu gibi taşımak. Rspack'teki contenthash hatasında gördüğümüz gibi, bir araçta sorunsuz çalışan bir ayar diğerinde HMR'ı bozabiliyor.

Küçük Bir Deneme

★☆☆ snapshot/08/widget'ta npm run bench:build'i üç kez çalıştır. Oranlar turdan tura ne kadar değişiyor? Sonra webpack config'inde optimization.minimize'ı kapatıp ölçümü tekrarla.

★★☆ bench/scale.mjs'e Vite'ın kendisini (JS API'sindeki build fonksiyonuyla) beşinci araç olarak ekle. Vite'ın Rolldown'a göre ek maliyeti 1000 ve 2000 module'de ne kadar?

★★★ Bookstore'un Angular uygulaması için benzer bir ölçüm kur: ng build'in soğuk (.angular/cache silinmiş) ve sıcak sürelerini, NG_BUILD_OPTIMIZE_CHUNKS açık ve kapalıyken karşılaştır. Chunk optimization'ın toplam sürenin ne kadarını aldığını NG_BUILD_DEBUG_PERF=1 çıktısıyla doğrula.

Serinin sonuna geldik. Kaynak kodun tarayıcıya giden yolunu module graph'tan source map'e kadar izledik: webpack'in loader zinciri, esbuild'in hızı, Vite'ın dev server'ı, Angular CLI'ın builder'ı, bundle analizi ve source map'ler. Bundle'ı küçültmenin sayfa hızına etkisini ölçmek ise ilerideki Web Performansı serisinin konusu; orada bu serideki Bookstore uygulamasını LCP (sayfadaki en büyük içeriğin ekrana gelme süresi) ve INP (kullanıcı etkileşimine sayfanın tepki süresi) üzerinden ölçeceğiz.