Baseline: Rahasia Mengirim JavaScript Jauh Lebih Sedikit

Baseline: Rahasia Mengirim JavaScript Jauh Lebih Sedikit

Ingat masa-masa enak zaman jQuery? Kamu tinggal taruh file 90KB ke project, tiba-tiba `$(document).ready()` bikin semuanya terasa mulus. Lalu kita mulai lebih pintar, bundle dipecah-pecah, dan jQuery ditukar dengan React, Vue, plus lemari penuh micro-library untuk kebutuhan-kebutuhan kecil.

Tapi ada satu hal yang sering banget saya lakukan: mengambil library format tanggal sebesar 20KB, padahal browser yang saya targetkan sudah punya API native buat hal yang sama. Gratis. Tanpa network request. Tanpa update versi. Tanpa perlu dipelihara ke depannya.

Di sinilah **Baseline** masuk.

Kalau kamu belum pernah dengar, Baseline itu inisiatif yang didukung W3C. Dia kasih kita label universal yang simpel untuk pertanyaan: “kapan fitur ini aman dipakai?” Baseline menjawab pertanyaan paling menyebalkan di dunia web development dengan satu kata: **hari ini**. Dengan bantuan Baseline untuk tahu apa yang platform web sudah bisa lakukan, kamu bisa mengecilkan JavaScript yang kamu kirim secara drastis. Mari kita bahas.

Apa Sebenarnya Baseline Itu?

Baseline adalah kesepahaman bersama soal dukungan browser di semua pemain besar: Chrome, Edge, Firefox, Safari, dan Opera. Daripada cek matriks “works in 97% of browsers,” Baseline bilang fitur itu **available**—artinya sudah bisa dipakai di browser versi sekarang—atau **newly available**—artinya baru saja hadir di versi terbaru. Ide utamanya: buang tebak-tebakan.

Anggap saja Baseline itu “caniuse, tapi vonisnya lebih ramah.” Ketika sebuah fitur sudah berstatus Baseline, artinya semua browser di ekosistem umum mendukung fitur itu. Itu lampu hijau kamu.

Dan bagian terbaiknya? Baseline sudah tertanam di tempat-tempat yang mungkin selama ini kamu pakai. Buka tabel kompatibilitas di MDN, cari sebuah fitur, dan kamu akan lihat badge Baseline di sebelahnya. Atau cek [web.dev/baseline](https://web.dev/baseline) untuk melihat dashboard fitur apa saja yang siap dipakai hari ini.

Kenapa Ini Penting untuk Ukuran Bundle Kamu

Jarak antara “kamu butuh library untuk ini” dan “browser sudah bisa ini” terus mengecil. Setiap tahun, browser menambahkan API yang dulu butuh polyfill, helper library, atau utility function. Kalau kamu masih mengirim `moment-timezone` untuk urusan timezone atau `lodash` untuk `_.debounce()`, kamu sebenarnya membayar sesuatu yang platform web sudah sediakan—baik itu dalam bentuk byte maupun kompleksitas.

Saya kasih tiga contoh praktis di mana Baseline bisa bantu kamu memangkas beban mati.

Skenario 1: Format Tanggal Tanpa Dependency 50KB

Dulu saya pernah mengerjakan project yang mengimpor `date-fns` cuma untuk memformat beberapa tanggal di dashboard. Padahal app-nya cuma dashboard statis. Kami mengirim 16KB fungsi tanggal lokal cuma buat render teks seperti “Aug 9, 2026.”

Tapi coba eksperimen kecil: buka console browser kamu sekarang, lalu ketik:

```js
new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date())
```

Selesai. **Tanpa import, tanpa npm install, tanpa pinning versi.** Object `Intl` sudah jadi fitur Baseline bertahun-tahun. Dia bisa handle format sesuai locale, timezone, bahkan format waktu relatif ala date-fns dengan `Intl.RelativeTimeFormat`.

Mau seluruh bundle hilang? Petakan fungsi date-fns ke padanan native-nya:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (atau `new Date()` dengan hati-hati)
- `zonedTimeToUtc` → `Intl` dengan opsi `timeZone`

Ya, edge case selalu ada. Tapi untuk 90% project, API `Intl` native sudah cukup. Dan ini sudah Baseline available, jadi semua browser modern menjalankannya.

Skenario 2: Ganti Lodash dengan DOM

Saya masih sering lihat `lodash.debounce` di beberapa codebase. Lima kilobyte cuma buat bikin fungsi nunggu sebentar sebelum jalan. Padahal browser sudah punya ini:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

Atau kalau kamu se-malas saya, pakai `setTimeout` biasa di event listener sudah cukup untuk kebanyakan kasus. Sama halnya dengan `_.throttle`, `_.clamp`, `_.range`—semuanya bisa ditulis cuma beberapa baris JavaScript vanilla.

Tapi sebenarnya masih lebih dalam lagi. Pernah pakai `_.forEach`? Prototype Array sudah punya `forEach`, `map`, `filter`, `reduce`—semuanya Baseline. `_.get` untuk akses properti bersarang dengan aman? Optional chaining sudah jadi fitur Baseline sejak 2020. `_.unique`? Itu cuma `Set`.

DOM-nya sendiri juga harta karun: `classList.toggle()` menggantikan `_.toggleClass`, `Element.matches()` menggantikan selector `_.is()`, dan `IntersectionObserver` native menggantikan seluruh library scroll-spy. Lain kali sebelum nambah dependency, tanya ke diri sendiri: “Ini cuma bungkus cantik dari sesuatu yang `document.querySelectorAll` sudah kasih?”

Skenario 3: Request HTTP Tanpa axios

Axios itu library yang keren. Tapi di 2026, API `fetch` native sudah Baseline dan hampir semua use case bisa dia tangani. Streaming? `fetch` punya `response.body.getReader()` untuk itu. Autentikasi? Kamu bisa set headers, credentials, dan interceptor cukup dengan wrapper kecil. Aborting? Ada `AbortController`, juga Baseline.

Untuk project kecil, saya ganti axios sepenuhnya dengan helper 20 baris:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

Tanpa npm, tanpa node_modules bengkak, tanpa peringatan circular dependency. Cepat, native, dan reliable.

Cara Audit Dependency Pakai Baseline

Kamu sudah yakin. Terus sekarang apa? Ini proses praktis yang bisa kamu lakukan sore ini juga.

1. Daftar Runtime Dependency Kamu

Jalankan `npm ls --production` atau lihat saja `package.json`. Tandai hal-hal yang bukan framework atau state management library. Package utility kecil-kecil itu target utama.

2. Cocokkan Satu per Satu dengan Baseline

Untuk setiap library di daftar, tanya dua hal:

- Masalah apa yang library ini selesaikan?
- Bisakah saya selesaikan dengan web API yang statusnya Baseline available?

Cari fiturnya di MDN. Kalau kamu lihat badge hijau “Baseline available,” kamu aman. Kalau statusnya “Newly available” dan target kamu cuma browser modern, masih layak dipertimbangkan. Kalau merah “Limited,” mungkin biarkan dulu library-nya.

Tips cepat: buka developer tools di Chrome, Safari, atau Firefox dan coba API-nya langsung. Kalau jalan tanpa flag, itu pertanda bagus.

3. Grep Kode Kamu untuk Cari Tanda-tanda

Cari pola seperti `import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'`, atau `from 'jquery'`. Lalu lihat seberapa sering fungsi-fungsi itu benar-benar dipakai. Kadang kamu baru sadar cuma pakai tiga method dari library yang isinya 200 method. Itu peluang yang jelas.

4. Ganti dan Bandingkan

Lakukan migrasi satu library per satu. Pisahkan dalam satu PR khusus supaya kamu bisa mengukur perubahan ukuran bundle. Pakai size report dari build tool, atau cek ukuran file di devtools. Saya sarankan jalankan Lighthouse sebelum dan sesudah. Melihat “JavaScript execution time” turun itu rasanya puas banget.

Sisi Manusiawi dari Mengirim Lebih Sedikit JavaScript

Kenapa kita peduli, di luar kepuasan kecil dari bundle yang lebih ramping? Karena JavaScript adalah resource paling mahal yang kita kirim ke browser. Setiap byte harus diunduh, di-parse, di-compile, dan dieksekusi. Setiap API yang bisa dihemat artinya halaman lebih cepat kebuka di HP Android murah dengan koneksi 3G yang naik-turun. Bukan semua orang pakai MacBook Pro yang nyambung ke fiber.

Mengirim lebih sedikit JavaScript juga berarti mengurangi beban pikiran kamu sebagai developer. Setiap dependency itu bisa jadi celah keamanan, sumber pusing saat migrasi, dan sumber bug aneh ketika maintainer-nya memutuskan pensiun. API native dirawat oleh vendor browser. Artinya dia akan terus diperbarui, didokumentasikan, dan didukung bertahun-tahun ke depan.

Ada juga manfaat yang lebih dalam: kamu mulai memahami platform web itu sendiri. Saat kamu pakai `Intl`, `URL`, `Promise`, `Map`, `Optional Chaining`, dan `fetch` secara langsung, kamu jadi developer web yang lebih baik. Kamu bukan cuma pemakai abstraksi. Kamu builder yang paham serat kayunya.

Ada Peringatan? Ya. Jangan Konyol.

Baseline bukan tongkat ajaib. Beberapa API tingkat lanjut masih terlalu baru untuk status Baseline available di mana-mana. Contohnya, Popover API atau View Transitions API itu “newly available,” tapi belum benar-benar hadir di semua browser. Kalau kamu bikin situs publik untuk audiens luas, lebih baik tunggu sebentar atau siapkan graceful fallback.

Selain itu, menghapus library nggak selalu berarti nulis lebih sedikit kode. Kadang kamu justru harus nulis vanilla JS lebih banyak buat mendapat perilaku yang sama. Tapi hei, beberapa baris kode sendiri lebih mudah dirawat daripada utility library raksasa yang tidak kamu pahami sepenuhnya.

Dan yang terakhir, jangan jadi “fanatik API native.” Kalau sebuah library benar-benar mengubah produktivitas dan bikin hidup lebih mudah, pakai saja. Poin dari Baseline bukan untuk mempermalukanmu karena pakai library bagus. Fungsinya untuk bantu kamu membuat keputusan yang lebih bijak. Asal jangan kirim `safe-password-generator` padahal `crypto.getRandomValues()` sudah Baseline sejak 2015.

Bonus: Cara Tetap Update dengan Baseline

Platform web berkembang cepat. Biar tetap update soal apa yang baru saja jadi Baseline available, saya melakukan dua hal:

1. Cek dashboard **Web Platform Features** di [web.dev/baseline](https://web.dev/baseline) kira-kira sebulan sekali.
2. Baca bagian berita **MDN Baseline**, yang merilis daftar fitur baru yang tersedia tiap bulan.

Kamu juga bisa ikuti repo GitHub WebDX community group di [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline). Di situ tempat sihirnya terjadi.

Pertanyaan yang Sering Ditanyakan

Apa sebenarnya arti “Baseline available”?

Artinya fitur itu didukung di versi sekarang dan versi terbaru dari semua browser utama—Chrome, Edge, Firefox, Safari, dan Opera. Kamu bisa pakai tanpa polyfill atau fallback untuk browser-browser tersebut.

Apa Baseline sama dengan “caniuse.com”?

Tidak, tapi mereka masih kerabat dekat. Caniuse memberi tabel kompatibilitas yang detail, termasuk versi-versi lama. Baseline menyederhanakan data itu menjadi label “siap” atau “belum siap.” Baseline juga memastikan informasinya sesuai konteks—hanya karena sesuatu jalan di Chrome 120 bukan berarti jalan juga di Safari 12.

Bagaimana kalau saya masih harus mendukung browser jadul seperti IE11?

IE11 sudah mati. Bahkan sebelum mati pun dia pengecualian. Baseline secara eksplisit mengecualikan browser lawas seperti IE11. Kalau kamu benar-benar harus mendukung lingkungan sekuno itu, kamu perlu cek tabel individual dan mungkin menambahkan polyfill untuk API yang kamu pilih. Tapi di 2026, nggak ada salahnya bertanya: kenapa masih support IE11? User kamu yang memutuskan bertahan di teknologi lama, dan kamu yang bayar harganya.

Bagaimana cara meyakinkan tim untuk mulai pakai Baseline?

Tunjukkan angkanya. Pilih satu dependency, perkirakan ukuran bundle dan biaya maintenance-nya, lalu perlihatkan pengganti native-nya lewat prototipe cepat. Saya pernah melakukan ini dengan `lodash` di pekerjaan sebelumnya. Begitu lead saya lihat diff-nya—utility 5KB diganti dua baris vanilla JS—langsung setuju. Sekalian kasih lihat postingan ini. 😉

Kesimpulannya

Baseline bukan sekadar alat kompatibilitas—ini perubahan cara berpikir. Daripada bertanya “library apa yang harus saya pakai untuk ini?” kamu mulai bertanya “apa yang browser sudah bisa lakukan untuk saya?” Begitu pergeseran itu terjadi, JavaScript yang bengkak mulai menciut.

User kamu dapat website yang lebih cepat. Kamu di masa depan dapat codebase yang lebih bersih. Dan web jadi sedikit lebih ringan untuk semua orang.

Sekarang buka devtools, lihat bundle project kamu, dan cari apa yang bisa dipotong. Browser kamu mungkin sudah menunggu dengan jawabannya.