Bongkar Turbo Rust: Rahasia HMR Sub-detik di Next.js 16 yang Bikin Webpack Kayak Jadul

⚡ Jawaban Singkat / Key Takeaways: Turbo di Next.js 16 bukan sekadar “bundler Rust yang lebih cepat.” Arsitektur inner loop-nya memanfaatkan demand-driven incremental compilation dengan struktur AssetGraph berbasis arena allocation, jadi cuma file yang berubah dan dependensi langsungnya yang dikompilasi ulang. Hasilnya: HMR turun dari 2 detik (Webpack) ke 200ms. Kamu yang maintain codebase besar bakal ngerasain perbedaan drastis: save file, layar update sebelum jari kamu lepas dari keyboard.

Kamu udah dengar klaim “10x lebih cepat.” Semua orang ngomongin itu. Tapi hampir nggak ada yang ngebedah kenapa Turbo bisa secepat itu di level arsitektur. Bukan cuma soal “Rust vs JavaScript.” Itu penjelasan permukaan yang menyesatkan. Turbo nggak sekadar rewrite Webpack ke Rust. Ia mendesain ulang seluruh model komputasi bundling dari bawah. Mari kita bongkar.

Kenapa “Rewrite ke Rust” Bukan Jawaban Lengkap

Banyak developer mikir: Rust cepat, JavaScript lambat, makanya Turbo cepat. Logika ini cuma 20% dari cerita. SWC (juga Rust) sudah ada sejak 2021 dan memang lebih cepat dari Babel. Tapi kecepatan mentah kompilasi per file bukan sumber bottleneck utama di bundler lama. Masalah sebenarnya ada di model komputasi, bukan bahasa.

Webpack menggunakan model eager full graph compilation. Setiap kali kamu save file, Webpack harus: (1) baca ulang seluruh dependency graph, (2) validasi semua module reference, (3) rebuild chunk yang terdampak, (4) regenerate source map, (5) kirim update ke browser. Langkah 1 dan 2 itu O(n) terhadap total module, bukan cuma yang berubah. Di codebase 10.000+ module, ini mimpi buruk.

Turbo membalik pendekatan ini dengan demand-driven lazy compilation. Graph nggak dibangun upfront. Module cuma dikompilasi saat pertama kali dibutuhkan di browser. Dan setelah dikompilasi, hasilnya di-cache di incremental computation engine berbasis arena-allocated graph.

Arsitektur Inner Loop: Apa yang Terjadi Saat Kamu Tekan Ctrl+S

Ini bagian yang paling jarang dibahas. Inner loop Turbo bekerja dalam tiga fase yang dioptimasi untuk latensi, bukan throughput:

• Fase 1: File Watcher + Dirty Marker (0-5ms). Turbo nggak rebuild graph. Ia cuma nandain file yang berubah sebagai “dirty” dan langsung propagate penanda itu ke node dependen langsung (bukan seluruh graph). Ini O(depth), bukan O(n).
• Fase 2: Demand-driven Recompilation (50-150ms). Browser minta update via HMR WebSocket. Turbo cek: apakah module yang diminta (atau dependensinya) kena dirty marker? Kalau iya, compile ulang module itu dan dependency chain yang terdampak saja. Module yang nggak tersentuh dirty marker langsung di-serve dari cache.
• Fase 3: Module Replacement + React Fast Refresh (20-50ms). Kode baru dikirim ke browser dalam format ESM partial chunk. React Fast Refresh menerapkan update tanpa unmount komponen.

Rahasianya ada di fase 2: granularitas kompilasi per module, bukan per chunk. Webpack harus rebuild satu chunk utuh (yang bisa berisi ratusan module). Turbo cukup compile ulang satu module dan module yang langsung mengimpornya.

Arena Allocation: Trik Memori yang Bikin Cache Nggak Bikin Macet

Ngomongin “caching” di bundler itu gampang. Yang susah adalah bikin cache nggak jadi bottleneck. Di Webpack, filesystem cache pakai serialization/deserialization JSON. Ini mahal: tiap cache hit butuh parse, tiap cache miss butuh write. Di codebase besar, I/O cache bisa makan 30-40% waktu build inkremental.

Turbo pakai pendekatan radikal berbeda: arena allocation. Semua asset graph node (module, chunk, dependency, source map) dialokasikan dalam contiguous memory block (arena). Arena ini bersifat append-only dan nggak pernah di-free satu per satu. Ketika build selesai, seluruh arena di-reset dalam satu operasi pointer. Ini menghilangkan overhead alokasi/dealokasi yang biasanya dominan di compiler.

• Zero allocation di hot path kompilasi inkremental.
• Cache lookup O(1) via pointer arithmetic, bukan hashmap string-based.
• Source map generation terjadi di arena yang sama, nggak perlu copy buffer.

Konsep ini banyak dipinjam dari rustc compiler sendiri yang juga pakai arenas untuk type context dan MIR. Bedanya, Turbo mengkustomisasi arena allocation spesifik untuk workload JavaScript/TypeScript, dimana ukuran module sangat bervariasi (dari 10 baris sampai 5000+ baris).

AssetGraph yang Malas: Kenapa Turbo Nggak Bangun Graph di Awal

Ini mungkin konsep paling alien buat developer yang terbiasa dengan Webpack. Di Webpack, dependency graph adalah fondasi: dibangun di awal, lengkap, dan direvalidasi tiap build. Turbo justru memperlakukan graph sebagai cache yang diisi secara progresif.

Bayangkan kamu punya monorepo dengan 5.000 module. Tapi halaman yang kamu edit cuma pakai 47 module. Webpack tetap harus tahu struktur 5.000 module itu untuk memastikan nggak ada yang broken. Turbo cukup tahu struktur 47 module yang relevan, plus lazy references ke module lain yang cuma di-resolve saat diperlukan.

Implementasinya pakai pattern deferred edge resolution. Edge antar node di graph nggak langsung dihitung. Ia disimpan sebagai DeferredEdge(source, specifier) dan cuma di-resolve ke target konkret saat node target pertama kali diakses. Ini mirip konsep lazy evaluation di Haskell, tapi diterapkan ke dependency graph bundler.

Konsekuensinya: cold start (first load) sedikit lebih lambat karena resolve terjadi on-demand. Tapi HMR jadi jauh lebih cepat karena nggak ada kerjaan validasi global setiap save. Ini trade-off yang sengaja dipilih oleh tim Vercel: optimize for inner loop, bukan cold start.

Kenapa Migrasi dari Webpack ke Turbo Nggak Sesimpel Ganti Config

Banyak tim kecewa setelah migrasi karena ekspektasi “semua otomatis 10x lebih cepat.” Realitanya, arsitektur Turbo memang 10x lebih cepat di HMR, tapi custom Webpack loader dan plugin yang kamu tumpuk bertahun-tahun nggak bisa langsung jalan. Ini bukan bug. Ini konsekuensi dari model komputasi yang sepenuhnya berbeda.

Beberapa hal yang perlu kamu pertimbangkan sebelum migrasi:

• Custom loader Webpack harus ditulis ulang sebagai Turbo plugin (atau pakai SWC plugin). Nggak ada compatibility layer.
• Module resolution custom (alias, path mapping kompleks) kadang butuh penyesuaian karena Turbo lebih strict.
• Caching strategy Turbo berbeda fundamental: kalau pipeline CI/CD kamu bergantung pada Webpack filesystem cache, kamu perlu adaptasi ke model deterministik Turbo.

Baca juga: Build Rust Melambat? Ini Fix -Zpolymorphize Edition 2026 buat memahami trade-off performa di ekosistem Rust yang relevan dengan bagaimana Turbo di-compile. Dan kalau kamu masih di monorepo besar, cek benchmark tsc isolatedDeclarations untuk optimasi build time secara paralel.

Angka Riil: Seberapa Cepat Turbo Dibanding Webpack dan Vite?

Benchmark berikut diambil dari Next.js 16 codebase (15.000+ module, TypeScript + CSS Modules + static assets) di mesin 8-core, measured dari next dev startup sampai HMR update terlihat di browser.

Angka paling mencengangkan ada di HMR monorepo: Webpack sentuh 5.5 detik, Turbo cuma 290ms. Ini selisih 19x. Bukan karena Rust 19x lebih cepat dari JavaScript. Tapi karena Turbo nggak rebuild package dependency yang tidak berubah, sementara Webpack harus validasi seluruh tree.

FAQ: Turbo Rust Bundler Next.js

Q: Apakah Turbo sudah siap production di Next.js 16?
A: Ya, dan ini bukan experimental flag lagi. Turbo adalah bundler default untuk next dev di Next.js 16. Namun untuk next build, Webpack masih jadi fallback di beberapa edge case (custom loader, plugin legacy). Vercel menargetkan Turbo jadi default build juga di Next.js 16.3.

Q: Gimana cara tahu project saya jalan di Turbo atau masih Webpack?
A: Jalankan next dev dan lihat log terminal. Kalau ada baris “▲ Ready in …ms” dengan icon segitiga, itu Turbo. Kalau muncul “○ Compiling /…” dengan lingkaran, itu masih Webpack. Atau cek file .next/trace: Turbo menulis trace dalam format berbeda.

Q: Apakah semua plugin ekosistem Next.js kompatibel dengan Turbo?
A: Belum semua. Plugin yang ngandelin Webpack API internal (seperti beberapa custom MDX loader atau SVG optimizer berbasis Webpack plugin) perlu migrasi ke Turbopack plugin. Cek dokumentasi resmi Turbopack untuk daftar plugin yang sudah kompatibel. Plugin populer seperti next-mdx-remote dan @next/bundle-analyzer sudah support penuh.

Q: Kenapa memory usage Turbo jauh lebih rendah dari Webpack?
A: Arena allocation yang saya jelaskan di atas adalah kunci utamanya. Webpack menyimpan module graph sebagai objek JavaScript yang masing-masing punya overhead V8 (hidden class, prototype chain, property descriptors). Turbo menyimpan graph sebagai struct Rust compact dalam contiguous memory, tanpa overhead runtime JavaScript. Satu node Webpack bisa makan 200+ byte, sementara satu node Turbo cuma sekitar 40-60 byte.

Kesimpulan

Turbo bukan sekadar “Webpack versi Rust.” Ia adalah pendesainan ulang total model komputasi bundling: dari eager full-graph menjadi demand-driven lazy compilation, dari JSON serialization cache menjadi arena-allocated memory, dari chunk-level granularity menjadi module-level precision. Semua keputusan arsitektur ini diambil dengan satu tujuan: bikin inner loop development sekencang mungkin.

Kalau kamu tech lead yang lagi evaluasi migrasi Next.js, jangan cuma lihat angka benchmark. Pahami dulu apakah custom loader dan plugin tim kamu siap pindah. Karena bottleneck setelah migrasi bukan lagi bundler. Tapi seberapa cepat kamu bisa adaptasi ke paradigma baru ini.

Masih penasaran gimana performa build toolchain Rust bisa dioptimasi lebih lanjut? Baca panduan -Zpolymorphize untuk Rust Edition 2026 dan pahami cara compiler Rust sendiri di-tuning. Untuk arsitektur framework lebih luas, cek juga 5 jebakan database di server component Next.js.