Turbopack, Vercel'in Next.js 13 ile tanıttığı, Rust tabanlı yeni nesil bundler. Webpack'in yerini alacak şekilde konumlandırılan bu araç, özellikle dev server başlama süresi ve HMR (Hot Module Replacement) hızı konusunda ciddi iddialarla geldi. "Webpack'ten 700x hızlı" gibi başlıklar teknik dünyada ses getirdi; ancak bu rakamların gerçek projelerdeki karşılığı çok daha karmaşık bir tablo ortaya koyuyor.

Webpack onlarca yıldır büyük ekosistemin omurgası oldu. Konfigürasyon esnekliği, zengin plugin desteği ve topluluk birikimi açısından hâlâ rakipsiz sayılır. Ama bu avantajlar beraberinde bir maliyet taşır: büyük projelerde cold start süresi dakikaları bulabilir, her değişiklikte yeniden derleme bekleme süresini önemli ölçüde uzatır. Turbopack tam da bu acı noktaları hedef alarak tasarlandı; Rust'ın düşük seviyeli performansı ve paralel işleme kapasitesini bundling sürecine entegre etmeye çalıştı.

Turbopack büyük Next.js projelerinde cold start ve HMR'de öne çıkar; production build ve framework dışı kullanımda beklenen kazancı vermez. Doğru beklentiyle yapılan bir geçiş zaman kazandırır; yanlış beklentiyle yapılan hayal kırıklığı ve geri dönüş maliyeti yaratır.

Dev Server Başlama Süresi: Asıl Fark Büyük Projelerde Beliriyor

Webpack, dev server'ı başlatırken projedeki tüm modülleri tarar, bağımlılık grafiğini oluşturur ve hepsini birlikte derler. Küçük projelerde bu işlem saniyeler içinde biter; fark belirsizdir. Ancak proje 500-1000 modülün üzerine çıktığında cold start süresi belirgin biçimde uzar. Yapılandırma ve loader karmaşıklığına göre bu süre 20-60 saniye arasına taşınabilir; TypeScript, SASS ve büyük bağımlılık ağaçlarıyla birleşince 90 saniyeyi geçen durumlar da görülür.

Turbopack farklı bir strateji izler: talep edilene kadar derlemez. Dev server'ı ayağa kaldırması birkaç saniye sürer çünkü tarayıcı ilk sayfayı isteyene kadar hiçbir modülü derlemeye sokmaz. İlk sayfa yüklendiğinde yalnızca o sayfanın gerektirdiği modüller işlenir; geri kalanlar gerektiğinde devreye alınır. Lazy compilation olarak bilinen bu yaklaşım başlangıç süresini dramatik biçimde kısaltır, çünkü büyük bir uygulamanın yalnızca küçük bir dilimini derlemiş olursunuz.

Fark, proje büyüklüğüyle orantılı biçimde açılır. 50 modüllük bir uygulama zaten hızlı başlar; Turbopack'in avantajı burada kaybolur. 300'ün üzerinde sayfası olan, ağır bağımlılıklar içeren bir Next.js uygulamasında ise başlama sürelerindeki fark çoğu durumda 4x-8x bandında gözlemlenir. 700x başlıklı karşılaştırmalar genellikle sentetik testlere ya da çok küçük modüllere dayanır ve üretim projelerinde bu rakamlara ulaşmak nadirdir.

İlk sayfa yüklendiğinde kısa bir gecikme olabileceği de not edilmeli. Turbopack o an için gerekli modülleri derler; bu işlem birkaç saniye sürebilir. Webpack'in her şeyi başta derleme yaklaşımına göre toplam derleme miktarı azalır, ama ilk sayfa yanıt süresi anlık olarak biraz uzayabilir. Geliştirme ortamında bu genellikle kabul edilebilir bir değiş tokuştur.

HMR: Değişikliğin Anlık Yansıma İddiası

HMR, bir dosyada değişiklik yapıldığında tüm sayfayı yenilemeden yalnızca değişen modülün güncellenmesini sağlar. Webpack'in HMR mekanizması işlevseldir; ama bağımlılık grafiği büyüdükçe etkilenen modülleri hesaplamak ve yeniden paketlemek zaman alır. Orta büyüklükteki bir uygulamada tek bir bileşeni değiştirmek 150-400ms sürebilir; bu süre birikince gün içinde anlamlı bir kayıp oluşur.

Turbopack bu hesaplamayı farklı bir granülaritede yapar. Dosya düzeyinde değil, fonksiyon ve ifade düzeyinde bağımlılıkları takip eder. Bir bileşende yalnızca bir satır değiştiyse, teorik olarak yalnızca o fonksiyonla ilgili kısım yeniden hesaplanır. Pratik etkisi şudur: küçük değişiklikler için HMR süresi webpack'e kıyasla belirgin biçimde kısalır ve çoğu durumda tek haneli milisaniyelere düşer.

Hızlı. Gerçekten hızlı.

Fark yine koşula bağlıdır. Uygulama state yönetimi için ağır kütüphaneler kullanıyorsa, değişiklik birçok modülü etkiliyorsa ya da özel webpack loader'ları varlığını sürdürüyorsa HMR avantajı daralır. Turbopack'te de modüller arası etki yayılımı yaşanır; avantajı bu yayılımı minimize etme kapasitesinden gelir, yayılımı tamamen ortadan kaldırma kapasitesinden değil. Bileşen ağaçlarının derinliği ve state güncelleme mekanizmaları da sonucu etkiler.

Sık sık UI bileşenlerini düzenleyen biri için HMR hız farkı gün içinde birikerek anlamlı kazanım sağlar. Büyük refactoring veya yapısal değişiklikler yapan biri için HMR hızı daha az belirleyicidir; orada bottleneck genellikle derleme değil, düşünme ve test etme sürecinin kendisidir.

Next.js Dışında Turbopack: Şimdilik Kapalı Bir Kapı

Turbopack şu an için yalnızca Next.js ekosistemi içinde kullanılabiliyor. Next.js 13 ile deneysel olarak başlayan entegrasyon, 14 ve 15 sürümlerinde olgunlaştı; next dev --turbo komutuyla etkinleştiriliyor. Vite, Remix, create-react-app veya tamamen özel webpack konfigürasyonları kullanan projeler Turbopack'e henüz erişemiyor. Vercel'in yol haritasında bağımsız kullanım var, ancak bugün itibarıyla bu bir gerçeklik değil, bir vaat.

Bu kısıt hem avantaj hem dezavantaj taşır. Next.js için özelleştirilmiş entegrasyon, framework'ün iç yapısıyla uyumlu optimizasyonlara imkan verir; Turbopack'in Next.js içindeki performansı kısmen bu derin entegrasyondan beslenir. Farklı bir framework'e ya da özel bir yapıya geçildiğinde Turbopack yanına alınamaz. Araç seçimini framework seçimine bağlamak, sonraki geçişte ciddi bir kilitlenme riski taşır.

Vite bu tabloda farklı bir konum tutuyor. Next.js dışındaki React uygulamaları, Svelte, Vue ya da vanilla JavaScript projeleri için Vite çok daha olgun ve yaygın bir alternatif olmayı sürdürüyor. Turbopack'i değerlendirirken "Next.js kullanıyor muyum?" sorusu başlangıç noktası olmalı; değilse tartışma pratikte anlamsız kalır.

Production Build: Turbopack Henüz Devrede Değil

Dev server ve HMR hızındaki gelişmeler etkileyici görünse de production build için tablo farklı. Next.js 15 itibarıyla Turbopack yalnızca geliştirme ortamında (next dev) aktiftir; production derleme (next build) hâlâ webpack tabanlı SWC pipeline'ını kullanır. Yani CI/CD süreçlerinde, deployment sürelerinde ya da bundle boyutunda Turbopack'in doğrudan bir etkisi bulunmuyor.

Production build desteği Vercel'in gündeminde; bazı deneysel bayraklarla sınırlı testler yapılıyor. Ancak kararlı sürümde production build Turbopack'e geçene kadar karşılaştırma yalnızca geliştirici deneyimi boyutunda kalır. Bu, küçümsenmesi gereken bir boyut değildir - geliştirici döngüsünü hızlandırmak gerçek bir değer taşır - ama deployment sürelerini ya da son kullanıcı performansını henüz etkilemiyor.

Bir ekibin günde onlarca küçük değişiklik yaptığı aktif bir geliştirme döneminde Turbopack'in HMR ve başlama hızı birikimli kazanım sağlar. Aylık birkaç kez konfigürasyon değişikliği yapan, büyük refactoring'i baskı altında yapan bir ekip için aynı tablo geçerli değildir. Kullanım örüntüsü kazanımın gerçek değerini belirler.

700x İddiası: Rakamın Arkasındaki Koşullar

Vercel'in ilk duyurusunda Turbopack'in webpack'ten 700x, Vite'tan 10x hızlı olduğunu belirten rakamlar hızla yayıldı. Bu rakamlar gerçek bir karşılaştırmaya dayanıyordu; ancak koşullar dikkatli okunduğunda neden pratikte bu seviyelere ulaşılamadığı anlaşılır.

Test senaryosu 30.000 React bileşeni oluşturmayı ve onları değiştirmeyi içeriyordu. Bu senaryoda Turbopack'in incremental computation motoru devreye girdiğinde, değişikliğin yalnızca etkilenen küçük kısmı yeniden hesaplandı; webpack ise değişikliğin tüm grafiği nasıl etkilediğini yeniden çözmek zorunda kaldı. 30.000 bileşenli bu sentetik test, ölçek farkını uç noktada göstermek için tasarlanmıştı. Gerçek projelerin büyük çoğunluğu bu ölçeğe ulaşmaz; 500-2000 modüllük bir uygulamada fark gerçek ama çok daha mütevazı bir büyüklüktedir.

Bağımsız performans testleri ve topluluk raporları, Next.js tabanlı büyük uygulamalarda dev server başlama süresinde 3x-6x aralığında tutarlı kazanımlar ortaya koyuyor. HMR için küçük değişikliklerde bu fark bazen daha belirgin görünür; ama karmaşık bağımlılık yapılarında daralır. 700x rakamı bir başlık için etkileyicidir; uygulamada beklenti olarak tutmak hayal kırıklığı yaratır.

Geçiş Kararı: Ne Zaman Erken, Ne Zaman Mantıklı

Next.js 14 veya üstü kullanan ve geliştirme ortamında yavaşlıktan şikayet eden bir proje için Turbopack'i denemek risk almak değildir. next dev --turbo komutu mevcut konfigürasyonu değiştirmez; webpack'e geri dönmek tek komutla olur. Deneme maliyeti düşüktür.

Ama bazı koşullarda geçiş sorun çıkarır. Özel webpack loader'larına bağımlı konfigürasyonlar Turbopack ile çalışmayabilir; loader uyumluluk listesi genişlese de webpack ekosisteminin tamamını karşılamıyor. SASS, CSS Modules, SVG transform ve bazı özel plugin'ler zaman zaman hata üretir ya da beklenen davranışı göstermez. Üretim ortamına taşımadan önce geliştirme ortamını Turbopack'le bir süre çalıştırmak ve testlerin geçtiğini teyit etmek gerekir.

Webpack'ten tamamen kopup Turbopack'e geçmeyi planlayanlar için şimdi doğru zaman değildir. Araç hâlâ aktif geliştirme altında; production build desteği tamamlanmadı, ekosistem uyumluluğu genişliyor ama henüz tam değil. Next.js dışı kullanım için ise geçiş seçeneği bugün mevcut değil. Birkaç yıl içinde tablo değişebilir; ancak şu an için webpack ve Vite olgun ve kararlı alternatifler olmayı sürdürüyor.

Turbopack, özellikle büyük Next.js projelerinde geliştirici deneyimi üzerinde ölçülebilir bir iyileştirme sunuyor. Dev server başlama süresi ve HMR hızındaki kazanımlar gerçek; ancak bu kazanımları çok daha geniş bir iddiaya dönüştürmek yanıltıcı olur. Production build desteği gelmediği sürece deployment sürecine dokunmuyor, Next.js ekosistemi dışına çıkmıyor ve her ölçekteki projede aynı etkiyi yaratmıyor.

Yeni araçları değerlendirirken en işe yarayan soru şudur: benim projem için hangi darboğaz gerçekten var? Dev server'ı dakikalarca beklemek günlük rutini bozuyorsa Turbopack deneyelim; HMR süresinden değil, başka nedenlerden dolayı yavaşlık yaşanıyorsa önce o nedeni bulmak daha verimlidir. Araç, sorunu doğru tanımlayanın elinde değer kazanır.