Build System Comparison Webpack vs Vite: Mana yang Lebih Cepat?
Kamu pernah nunggu dev server nyala sambil ngopi, balik lagi, dan masih loading? Itu bukan koneksi internet kamu — itu Webpack lagi bundling semua file dari awal setiap kali kamu mulai kerja.
Gue pernah di titik itu. Project React dengan ~400 modul, cold start 45 detik, HMR kadang 3–5 detik. Produktivitas ancur. Waktu itu gue belum tahu Vite ada.
Artikel ini adalah build system comparison webpack vs vite yang jujur: bukan benchmark marketing, tapi pengalaman langsung pakai keduanya di project nyata. Kita bahas arsitektur, konfigurasi, gotcha, dan kapan kamu harus pakai yang mana.
Kenapa Webpack Terasa Lambat di 2025
Webpack lahir 2012. Waktu itu JavaScript module system belum standar — CommonJS di Node, AMD di browser, dan ES Modules belum exist. Webpack hadir untuk menyatukan semuanya dengan cara bundle everything: semua file dikumpulkan, diproses, dan dijadikan satu (atau beberapa) bundle besar.
Arsitek ini masuk akal di 2012. Di 2025, ini jadi bottleneck.
Setiap kali kamu jalankan webpack serve, dia:
- Baca seluruh dependency graph dari entry point
- Transform semua file (Babel, TypeScript, CSS, dll)
- Bundle semuanya ke memori
- Baru mulai serve
Dengan 500+ modul, proses ini bisa makan 30–60 detik. Dan setiap HMR (Hot Module Replacement), Webpack perlu re-evaluate chunk yang terpengaruh — bukan file individual.
Webpack config-nya juga verbose. Ini config minimal untuk project React + TypeScript:
// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
entry: './src/index.tsx',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash].js',
clean: true,
},
resolve: {
extensions: ['.tsx', '.ts', '.js'],
},
module: {
rules: [
{
test: /\.tsx?$/,
use: 'ts-loader',
exclude: /node_modules/,
},
{
test: /\.css$/,
use: ['style-loader', 'css-loader'],
},
],
},
plugins: [
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
devServer: {
port: 3000,
hot: true,
},
};
Ini belum termasuk config untuk environment variables, path alias, image optimization, atau source maps. Bisa jadi 100+ baris dengan mudah.
Vite: Pendekatan yang Berbeda Secara Fundamental
Vite (dibuat Evan You, kreator Vue) mengambil pendekatan berlawanan: jangan bundle saat development.
Vite memanfaatkan native ES Modules yang sudah didukung semua browser modern. Saat dev server nyala:
- Vite langsung serve file as-is via native ESM
- Browser yang request modul satu per satu sesuai kebutuhan
- Vite hanya transform file yang di-request, saat di-request
Hasilnya? Cold start hampir instan karena tidak ada bundling di awal. HMR cepat karena hanya file yang berubah yang di-invalidate.
Config minimal Vite untuk project yang sama:
// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
server: {
port: 3000,
},
resolve: {
alias: {
'@': '/src',
},
},
});
Selesai. TypeScript, JSX, CSS modules — semua sudah handle out of the box. Tidak perlu install ts-loader, babel-loader, style-loader secara terpisah.
Untuk production build, Vite pakai Rollup di balik layar — bukan ESM serve. Jadi output production tetap ter-bundle dengan baik untuk performa.
Benchmark Nyata: Cold Start dan HMR
Gue test keduanya di project yang sama: React 18 + TypeScript + ~280 komponen, mesin M2 MacBook Air.
Cold start (dev server):
| Tool | Waktu |
|---|---|
| Webpack 5 (tanpa cache) | 28.4 detik |
| Webpack 5 (dengan cache) | 6.2 detik |
| Vite 5 | 0.6 detik |
HMR (edit satu file komponen):
| Tool | Waktu |
|---|---|
| Webpack 5 | 1.8–3.2 detik |
| Vite 5 | 40–120 ms |
Production build:
| Tool | Waktu |
|---|---|
| Webpack 5 | 22.1 detik |
| Vite 5 (Rollup) | 18.7 detik |
Katanya production build Vite lebih cepat, tapi selisihnya tidak sedramatik dev experience. Yang bikin Vite unggul jelas adalah dev workflow — kamu save file, langsung lihat hasilnya di browser. Untuk insight lebih dalam tentang performa hosting dan kecepatan loading, kamu bisa cek benchmark kecepatan loading hosting Indonesia yang membahas metrik performa secara detail.
Gotcha yang Harus Kamu Tahu
Gotcha #1: CommonJS modules di Vite
Vite native ESM artinya library yang masih pakai CommonJS bisa bikin error. Contoh:
Error: require is not defined in ES module scope
Solusinya, tambahkan package tersebut ke optimizeDeps:
// vite.config.ts
export default defineConfig({
optimizeDeps: {
include: ['nama-package-cjs'],
},
});
Vite akan pre-bundle package itu ke ESM. Tapi kalau kamu kerja di codebase lama yang penuh require() di kode sendiri, migrasi ke Vite butuh effort lebih.
Gotcha #2: Environment variables
Webpack pakai process.env.REACT_APP_* (Create React App convention). Vite pakai prefix VITE_* dan diakses via import.meta.env:
// Webpack / CRA
console.log(process.env.REACT_APP_API_URL);
// Vite
console.log(import.meta.env.VITE_API_URL);
Kalau kamu migrate project dari CRA ke Vite, semua env vars harus di-rename dan semua referensinya di-update. Gue kena ini dan butuh sekitar 2 jam buat bersihin semuanya.
Gotcha #3: Dynamic imports dengan variabel
Vite (dan Rollup) punya keterbatasan dengan dynamic import yang pakai variabel murni:
// Ini bermasalah di Vite
const module = await import(`./pages/${pageName}`);
// Ini lebih aman — kasih hint pattern
const module = await import(`./pages/${pageName}.tsx`);
Tambahkan ekstensi file di string template supaya Vite bisa analisis kemungkinan modul yang di-import.
Gotcha #4: Webpack masih lebih mature untuk edge cases
Kalau kamu butuh:
- Module Federation (micro-frontend)
- Custom chunk splitting yang sangat spesifik
- Integrasi dengan legacy build pipeline
- Support browser lama (IE11)
Webpack masih lebih capable. Ekosistemnya lebih mature dan dokumentasinya lebih lengkap untuk kasus-kasus edge.
Konfigurasi Lanjutan: Path Alias dan Proxy
Dua hal yang hampir semua project butuhkan: path alias dan API proxy. Ini perbandingannya:
Webpack:
// webpack.config.js
module.exports = {
resolve: {
alias: {
'@components': path.resolve(__dirname, 'src/components'),
'@utils': path.resolve(__dirname, 'src/utils'),
},
},
devServer: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true,
pathRewrite: { '^/api': '' },
},
},
},
};
Vite:
// vite.config.ts
export default defineConfig({
resolve: {
alias: {
'@components': '/src/components',
'@utils': '/src/utils',
},
},
server: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, ''),
},
},
},
});
Sintaksnya mirip, tapi Vite lebih TypeScript-friendly karena defineConfig kasih autocomplete yang proper.
Kapan Pakai Webpack, Kapan Pakai Vite
Ini bukan soal mana yang "menang" — ini soal konteks.
Pakai Vite kalau:
- Project baru dari nol
- Stack modern: React 18+, Vue 3, Svelte, Solid
- Kamu solo developer atau tim kecil yang butuh iterasi cepat
- Library-mu semua support ESM
- Kamu pakai framework yang sudah bundle Vite (Nuxt 3, SvelteKit, Astro, Remix via adapter)
Tetap pakai Webpack kalau:
- Project lama yang sudah jalan dan migration cost terlalu tinggi
- Kamu butuh Module Federation untuk micro-frontend
- Ada dependency yang CJS-only dan tidak bisa di-convert
- Tim kamu sudah punya Webpack expertise yang dalam dan config yang stabil
- Target browser yang tidak support native ESM
Untuk project baru di 2025, default ke Vite. Bukan karena hype, tapi karena dev experience yang lebih baik langsung berdampak ke produktivitas harian.
Yang Gue Lakuin Sekarang
Semua project baru gue pakai Vite. Setup-nya:
# Project React + TypeScript
npm create vite@latest my-project -- --template react-ts
cd my-project
npm install
npm run dev
Dev server nyala dalam hitungan detik. Tidak ada config tambahan untuk TypeScript. HMR instan.
Untuk project lama yang masih Webpack, gue tidak buru-buru migrate. Kalau Webpack-nya stabil dan timnya nyaman, biaya migrasi belum tentu worth it. Tapi kalau cold start sudah di atas 30 detik dan tim mulai complain, itu sinyal waktunya evaluasi.
Satu langkah praktis yang bisa kamu coba sekarang: buat project Vite baru paralel dengan project Webpack yang ada. Jalankan keduanya, rasakan perbedaan HMR-nya. Itu biasanya cukup untuk bikin keputusan.
Build system comparison webpack vs vite ini bukan tentang memilih yang "terbaik" secara absolut — tapi tentang memilih yang paling sesuai dengan constraint dan kebutuhan kamu hari ini. Untuk membantu keputusan teknis lainnya, this guide on WordPress hosting uptime reliability bisa memberikan perspektif tentang bagaimana infrastruktur mempengaruhi performa aplikasi secara keseluruhan.