React Compiler Kini Native di Vite: Lompatan 17 Kali Lebih Cepat

Build JavaScript yang makin lambat sering jadi keluhan utama developer React, terutama saat codebase udah tembus ribuan file. Kabar baiknya, ada perubahan besar di ekosistem ini: compiler React sekarang bisa jalan native di Vite dengan backend Rust, dan hasilnya jauh lebih cepat dari pendekatan berbasis Babel yang selama ini dipakai.

Perubahan ini dimulai dari rilis dukungan resmi oxc untuk Rust React Compiler pada 4 Agustus 2026. Tim di balik oxc, proyek toolchain JavaScript yang ditulis murni dalam Rust, akhirnya menghadirkan compiler React yang bukan lagi sekadar transpile lewat Babel. Boshen, pimpinan proyek oxc, menyebut hasil benchmark awal mereka lebih dari 10 kali lebih cepat dibanding Babel. Angka itu bukan cuma klaim marketing: ada tim nyata yang sudah membuktikannya di production.

17,6 Kali Lebih Cepat di Codebase 1.036 File

Salah satu adopter awal yang paling terdokumentasi adalah Master.dev. Mereka menjalankan Outlyne, sebuah website builder, dengan codebase React Router berisi 1.036 file. Setelah beralih ke dukungan resmi Rust React Compiler, bagian compiler dari proses build mereka melonjak dari 14,3 detik pakai Babel menjadi 0,81 detik secara native. Itu artinya speedup sekitar 17,6 kali lipat untuk bagian compiler saja, dan dihitung dalam mode single-threaded.

Penting untuk dipahami bahwa kecepatan itu hanya berlaku untuk bagian compiler dari proses build. Satu codebase biasanya punya banyak pekerjaan lain di luar kompilasi React, seperti bundling asset, menjalankan proses CSS, atau langkah optimisasi lain. Di kasus Master.dev, total waktu build turun dari 22,1 detik menjadi 9,3 detik, atau sekitar 2,4 kali lebih cepat. Tetap signifikan, tapi nggak seekstrem angka 17,6 kali yang berlaku khusus di segmen compiler.

Buat tim yang deploy-nya sering dan CI-nya jalan terus, penghematan ini langsung terasa di dompet. Master.dev sendiri menyoroti bahwa dengan makin cepatnya pengembangan berbantuan agen AI, pemakaian GitHub Actions minutes jadi cost center yang nyata. Setiap detik yang dipangkas dari build berarti lebih sedikit menit CI yang harus dibayar, dan developer nggak perlu nunggu lama cuma buat lihat hasil pekerjaannya.

Cara Mengaktifkannya di Vite

Buat proyek Vite standar, cara paling gampang adalah lewat rilis v6.1.0 dari @vitejs/plugin-react. Versi ini membawa dukungan experimental untuk native React Compiler yang bisa diaktifkan cukup dengan menambahkan opsi compiler ke konfigurasi plugin:

import react from '@vitejs/plugin-react'

export default {
  plugins: [react({ compiler: true })]
}

Dengan satu baris opsi itu, Vite bakal memakai React Compiler berbasis Rust untuk mengompilasi komponen-komponen lo, menggantikan jalur Babel yang sebelumnya dipakai. Karena masih berstatus experimental di rilis tersebut, wajar kalau lo mau menguji di branch terpisah dulu sebelum menerapkannya ke seluruh pipeline.

Namun, nggak semua orang bisa langsung pakai plugin React bawaan Vite. Tim yang memakai React Router dalam framework mode, misalnya, punya pipeline build yang berbeda. Buat kasus seperti ini ada plugin minimal bernama @acusti/vite-plugin-react-compiler yang dirancang khusus untuk React-compile codebase apa pun tanpa peduli sisa pipeline build-nya. Jadi baik lo pakai setup standar atau framework mode, tetap ada jalur untuk mencicipi compiler Rust ini.

Perbaikan yang Ikut Datang

Selain kecepatan, alasan lain untuk pindah adalah versi terbaru React Compiler sudah memperbaiki sejumlah keterbatasan JavaScript yang masih ada di v1.0 compiler berbasis Babel. Ada tiga pola yang sebelumnya bikin compiler menyerah alias bailout, dan sekarang sudah didukung penuh.

Pertama, dukungan untuk logika kondisional apa pun di dalam blok try/catch. Ini blocker besar buat banyak tim di rilis stabil 1.0, karena pola try/catch dengan percabangan di dalamnya cukup umum di kode production. Kedua, reassignment prop komponen yang sudah di-destructure lalu dipakai di dalam nested closure. Pola seperti mengganti nilai default prop dengan fallback lalu menggunakannya di event handler kini bisa dikompilasi dengan benar. Ketiga, computed object property keys, seperti membangun nama class dinamis berbasis nilai prop.

Di codebase Master.dev, perbaikan-perbaikan ini memperluas kompatibilitas compiler ke tujuh fungsi tambahan: lima berkat perbaikan try/catch dan dua berkat computed object property keys. Artinya makin banyak komponen yang benar-benar teroptimasi, bukan cuma dilewati compiler karena pola yang belum didukung.

Meski begitu, masih ada batasan yang perlu diketahui. Dua pola yang sampai sekarang masih bikin compiler skip sebuah komponen atau hook adalah throw dari dalam blok try dan logical assignment operators seperti ??=, &&=, atau ||=. Kabar baiknya, karena sekarang lo ada di compiler Rust yang terus berkembang, perbaikan untuk pola-pola ini bakal datang. Nasibnya beda kalau lo masih nyangkut di compiler berbasis Babel yang sudah mentok dan nggak dikembangkan lagi.

Konsistensi Toolchain Tanpa Celah

Salah satu keuntungan yang sering dilupakan dari pindah ke compiler Rust adalah konsistensi antaralat. Di ekosistem oxc, linter dan compiler sekarang berbagi mesin transform yang sama, yaitu oxc-transform-react. Sebelumnya, bisa terjadi anomali membingungkan: komponen nggak teroptimasi saat build, tapi linter juga nggak kasih peringatan apa pun, sehingga lo mengira ada disconnect antara linter dan output compiler.

Kisah nyatanya: ada yang melaporkan bug ke oxc berdasarkan perilaku bailout yang ternyata bukan bug sama sekali. Masalahnya cuma versi yang beda. Oxlint waktu itu memakai oxc-transform-react v0.145.0 yang sudah mendukung pola tersebut, sedangkan build yang diuji masih di v0.144.0. Setelah linter dan build memakai versi compiler React yang persis sama, anomali kayak gini hilang. Yang lo lihat di linter, itu juga yang terjadi di build. Konsistensi ini bikin debugging jauh lebih mudah karena nggak ada lagi dua sumber kebenaran yang bisa saling bertentangan.

Kenapa Ini Penting untuk Developer Indonesia

Buat developer React di Indonesia, perubahan ini relevan dalam beberapa hal. Pertama, biaya CI. Tim yang develop di VPS murah atau pakai GitHub Actions berbayar akan langsung merasakan penghematan kalau build-nya bisa dipangkas sampai separuhnya. Kedua, developer experience. Build yang cepat berarti feedback loop yang pendek, dan itu berdampak langsung ke produktivitas harian, apalagi buat tim yang codebase-nya sudah besar.

Ketiga, soal performa runtime. React Compiler bekerja dengan mengoptimasi ulang-render secara otomatis, mengurangi kerja memoization manual yang selama ini harus dijaga developer. Dengan compiler yang makin matang dan mendukung lebih banyak pola JavaScript, makin banyak aplikasi yang bisa dapat benefit ini tanpa harus nulis ulang komponen.

Buat yang baru mau mulai, saran praktisnya: coba dulu di proyek kecil atau branch terpisah, ukur waktu build sebelum dan sesudah, lalu bandingkan apakah ada komponen yang ke-skip karena pola yang belum didukung. Kalau semua mulus, baru terapkan ke codebase utama. Perpindahan ini nggak wajib, tapi buat tim yang build-nya udah jadi bottleneck, opsi ini layak banget dicoba.

Kesimpulan

React Compiler yang kini native di Vite dengan backend Rust adalah lompatan nyata dalam kecepatan build ekosistem React. Data dari Master.dev menunjukkan speedup 17,6 kali pada bagian compiler dan 2,4 kali pada total build di codebase 1.036 file. Ditambah perbaikan dukungan pola JavaScript yang sebelumnya bikin compiler menyerah, plus konsistensi linter dan compiler dalam satu mesin transform, ini argumen kuat untuk pindah dari jalur Babel yang sudah mentok.

Ekosistem toolchain JavaScript memang sedang bergerak masif ke Rust, dan React Compiler jadi salah satu titik paling terlihat. Buat developer yang sehari-hari berurusan dengan build lambat dan biaya CI, sekarang saat yang tepat untuk mencoba dan mengukur sendiri dampaknya di proyek lo.

Kenapa Rust untuk Toolchain JavaScript

Pergeseran React Compiler ke Rust bukan kejadian yang berdiri sendiri. Dalam beberapa tahun terakhir, hampir semua toolchain JavaScript yang berat mulai ditulis ulang dalam Rust. Esbuild, yang ditulis dalam Go, membuka era bundler cepat. SWC, yang ditulis dalam Rust, membawa kecepatan itu ke transpilasi JavaScript dan TypeScript. Kini oxc melengkapi gambaran dengan parser, linter, dan transformer yang semuanya native Rust.

Kenapa Rust yang dipilih, bukan bahasa lain? Ada tiga alasan utama. Pertama, performa: Rust menghasilkan binary native tanpa garbage collector, sehingga waktu eksekusinya bisa diprediksi dan cepat, faktor penting untuk tool yang dijalankan jutaan kali di CI developer di seluruh dunia. Kedua, keamanan memori: compiler Rust memastikan tidak ada use-after-free atau data race di level bahasa, dan untuk tool yang memproses kode yang belum tepercaya, ini mengurangi satu kelas bug yang bisa dieksploitasi. Ketiga, ekosistem: kargo dan crates.io memudahkan berbagi komponen antarproyek, sehingga oxc, SWC, dan lainnya bisa saling memakai pustaka parser yang sama.

Untuk React Compiler, keputusan menulis ulang di Rust berarti memanfaatkan parser dan transformer oxc yang sudah terbukti cepat, daripada mempertahankan jalur Babel yang ditulis dalam JavaScript dan berjalan lewat Node. Hasilnya seperti yang terlihat di benchmark: kecepatan yang satu atau dua orde lebih baik, plus fondasi yang lebih sehat untuk pengembangan ke depan.

Apa Artinya Buat Arsitektur Tooling

Pergeseran ini mengubah cara berpikir tentang arsitektur tooling frontend. Selama bertahun-tahun, rantai alat JavaScript disusun dari komponen yang masing-masing berjalan di proses Node terpisah: Babel untuk transform, ESLint untuk linting, webpack atau Rollup untuk bundling. Tiap lapisan mem-parsing file yang sama berulang kali, dan tiap lapisan punya overhead startup sendiri.

Dengan toolchain native seperti oxc, batas antaralat mulai kabur. Parser yang sama bisa dipakai linter, compiler, dan bundler. AST yang sudah dihasilkan bisa dipakai ulang, bukan dibuang dan dibuat ulang di lapisan berikutnya. Inilah yang membuat konsistensi yang dibahas sebelumnya jadi mungkin: linter dan compiler memakai mesin transform yang sama, sehingga tidak ada lagi perbedaan perilaku antara apa yang diperingatkan linter dan apa yang dilakukan compiler.

Ke depan, tren ini kemungkinan berlanjut ke bundler, minifier, dan alat lain di rantai build. Rolldown, bundler Rust yang dikembangkan sebagai penerus Rollup, adalah salah satu contoh yang sudah dalam perjalanan. Semakin banyak lapisan yang berbagi infrastruktur native, semakin cepat dan semakin konsisten seluruh pipeline build frontend.

Langkah Praktis Memulai

Buat tim yang ingin mencoba tanpa risiko besar, ada beberapa langkah yang bisa diikuti. Pertama, ukur dulu baseline: catat waktu build saat ini dan identifikasi berapa besar porsi compiler React di dalamnya. Kedua, buat branch percobaan dan aktifkan compiler native lewat opsi compiler: true di plugin React, atau plugin @acusti kalau lo di framework mode. Ketiga, jalankan seluruh suite tes dan bandingkan output build. Keempat, pantau log untuk melihat apakah ada komponen yang ke-skip karena pola yang belum didukung, dan putuskan apakah pola itu muncul di codebase lo.

Yang juga perlu diperhatikan adalah versi. Karena ekosistem oxc bergerak cepat, pastikan lo memakai versi terbaru dari plugin dan compiler, karena perbaikan dukungan pola JavaScript terus ditambahkan. Catat versi yang lo pakai supaya kalau ada anomali, lo bisa melaporkannya dengan informasi yang cukup, seperti kasus oxc-transform-react v0.144.0 versus v0.145.0 yang sempat membingungkan pengguna sebelumnya.

Terakhir, jangan lupa bahwa angka speedup yang paling dramatis hanya berlaku untuk bagian compiler. Kalau total build lo masih didominasi langkah lain, seperti kompresi gambar atau bundling asset besar, keuntungannya akan terasa lebih kecil. Ukur, jangan berasumsi, dan biarkan data di codebase lo sendiri yang menentukan apakah migrasi ini layak.