Kamu membuat satu halaman web, di layarmu tampilannya rapi sempurna, dan rasanya puas. Lalu seorang teman membuka halaman yang sama di browser berbeda, atau di ponsel yang sudah agak tua, dan ada yang aneh: tombolnya melenceng, animasinya tidak pernah jalan, atau seluruh halaman cuma diam saja seperti rusak. Padahal kodenya tidak kamu ubah sama sekali. Lalu apa yang terjadi?
Yang terjadi adalah “web” itu bukan satu program tunggal. Web adalah sekumpulan aturan bersama yang dicoba diikuti oleh banyak browser berbeda, di banyak perangkat berbeda, pada banyak titik waktu yang berbeda pula. Begitu kamu paham cara kerjanya, misterinya hilang, dan kamu bisa mulai menulis halaman yang berperilaku baik untuk hampir semua orang. Itulah yang akan kita bahas di artikel ini.
Satu web, banyak browser
Browser adalah program yang dipakai seseorang untuk membuka halaman web: Chrome, Firefox, Safari, Edge, dan lainnya. Masing-masing dibuat oleh tim yang berbeda, dan masing-masing punya mesin internalnya sendiri yang membaca HTML, CSS, dan JavaScript milikmu lalu mengubahnya menjadi sesuatu yang bisa dilihat dan diklik.
Inti idenya begini: semua mesin itu berusaha mengikuti standar yang sama, yang sudah diterbitkan secara terbuka, tetapi mereka tidak mendukung hal yang persis sama pada waktu yang persis sama. Sebuah fitur CSS yang baru bisa saja sudah jalan di Chrome versi terbaru hari ini, baru tiba di Safari beberapa bulan kemudian, dan masih belum ada sama sekali di browser yang sudah dua tahun tidak diperbarui oleh penggunanya.
Kamu menulis: ┌─────────────────────────────┐
HTML/CSS/JS → │ Mesin browser membacanya │
│ dan menentukan apa aksinya │
└─────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Mesin Chrome Mesin Safari Browser lama
"Fitur itu "Aku dukung "Aku tidak pernah
aku dukung" sebagian besar" dengar fitur itu"Jadi halaman yang sama bisa menghasilkan tiga hasil berbeda, bukan karena kodemu salah, melainkan karena setiap mesin menafsirkannya dengan kumpulan kemampuan yang sedikit berbeda. Di sinilah akar dari hampir semua cerita “di komputerku jalan, tapi di komputernya tidak” yang ada di dunia web.
Apa arti “dukungan fitur” yang sebenarnya
Ketika orang bilang sebuah browser “mendukung” suatu fitur, maksudnya adalah mesin browser itu tahu cara menangani instruksi spesifik tersebut. Fitur bisa berupa properti CSS (misalnya alat tata letak tertentu), elemen HTML, atau fungsi JavaScript.
Dukungan bukan saklar ya/tidak untuk seluruh browser. Ia diputuskan per fitur, dan terus berubah seiring browser merilis versi baru. Itu memberimu beberapa situasi nyata yang perlu kamu antisipasi:
| Situasi | Artinya buat kamu |
|---|---|
| Fitur lama, didukung luas | Aman dipakai hampir di mana saja |
| Fitur baru, didukung browser terkini | Jalan untuk pengguna yang update, hilang untuk yang tidak |
| Fitur eksperimental | Mungkin jalan hari ini, bisa berubah atau dihapus |
| Fitur usang atau non-standar | Hindari; bisa rusak kapan saja |
Kamu tidak perlu menghafal browser mana mendukung apa. Tugas seorang pengembang justru adalah tidak berasumsi apa pun, dan menggantinya dengan pertanyaan untuk tiap fitur penting, “apakah ini cukup aman untuk orang-orang yang kuperkirakan akan berkunjung?” Ada alat yang menampilkan data dukungan untuk fitur apa pun, dan kamu memeriksanya seperti seorang tukang memeriksa apakah suatu bahan layak untuk iklim setempat.
Kenali audiensmu dulu
“Apakah ini akan jalan di mana saja?” adalah pertanyaan yang keliru untuk terlalu dikhawatirkan. Pertanyaan yang lebih baik adalah “apakah ini akan jalan untuk pengunjung saya?” Situs untuk desainer yang memakai Mac terbaru bisa lebih berani memakai fitur baru ketimbang layanan pemerintah yang wajib mendukung perangkat yang sangat tua.
Progressive enhancement: membangun dari dasar yang kokoh
Ada dua cara klasik untuk memikirkan dukungan terhadap beragam browser, dan keduanya paling mudah dipahami kalau disandingkan.
Yang pertama adalah progressive enhancement. Kamu mulai dari versi dasar halaman yang jalan untuk semua orang, bahkan dengan browser yang sangat terbatas, lalu kamu menumpuk fitur-fitur yang lebih bagus di atasnya untuk browser yang mampu menanganinya. Bagian yang mewah itu bonus, bukan kewajiban.
Bayangkan sebuah tangga dengan jalur landai (ramp) di sampingnya. Semua orang bisa sampai ke atas lewat jalur landai itu (versi dasar). Orang yang sanggup menaiki tangga (browser modern) sampai lebih cepat dan lebih nyaman, tetapi tidak ada yang ditinggal terdampar di bawah.
Contoh sederhana dalam kata-kata: bayangkan sebuah formulir kontak. Versi dasarnya adalah HTML biasa yang bisa dikirim dan jalan di browser mana pun. Di atasnya, browser modern bisa menambah validasi langsung, animasi mulus, dan umpan balik instan. Kalau tambahan-tambahan itu gagal, formulirnya tetap bisa dikirim. Tugas intinya tidak pernah terancam.
Graceful degradation: bangun penuh, lalu tangani celahnya
Pendekatan kedua adalah graceful degradation, dan arahnya berlawanan. Kamu membangun pengalaman modern yang lengkap lebih dulu, lalu memastikan bahwa ketika suatu fitur tidak ada, halamannya turun menjadi sesuatu yang masih bisa dipakai, bukannya ambruk.
Istilah klasiknya adalah “gagal dengan anggun”. Pemutar video yang tidak bisa memainkan format canggih kembali ke format yang lebih sederhana. Tata letak yang tidak bisa memakai fitur penataan posisi yang baru kembali ke susunan lama yang lebih polos. Pengguna mungkin mendapat hasil yang kurang halus, tetapi tidak pernah halaman yang rusak.
| Pendekatan | Titik awal | Arah |
|---|---|---|
| Progressive enhancement | Versi dasar yang jalan untuk semua | Tambah fitur ke atas |
| Graceful degradation | Versi modern yang lengkap | Sediakan cadangan ke bawah |
Di proyek nyata, dua ide ini sering berbaur jadi satu. Tujuan bersama di balik keduanya sama: tidak ada pengunjung yang boleh menemui jalan buntu hanya karena browsernya lebih tua atau berbeda.
Apa itu polyfill
Sekarang kita sampai ke kata yang ada di judul. Polyfill adalah sepotong kode yang menambahkan fitur yang hilang ke browser yang belum memilikinya. Namanya berasal dari gagasan “mengisi celah” — seperti dempul yang kamu pakai untuk menambal lubang di tembok agar permukaannya kembali rata.
Idenya bisa dijelaskan dengan gamblang. Misalkan browser modern punya fungsi bawaan bernama, katakanlah, niceThing(), tetapi sebagian browser lama tidak pernah kebagian fungsi itu. Tanpa bantuan, memanggil niceThing() di browser lama akan memicu error. Polyfill memeriksa apakah fitur itu sudah ada, dan kalau tidak ada, ia mendefinisikannya dalam kode biasa yang bisa dijalankan browser lama. Setelah itu, halamanmu boleh memanggil niceThing() di mana saja dan percaya bahwa itu jalan.
// Polyfill, secara prinsip: tambahkan fitur hanya jika belum ada
if (!window.niceThing) {
window.niceThing = function () {
// versi buatan tangan yang melakukan pekerjaan sama
// memakai kode lama yang didukung luas
};
}Bagian terpentingnya adalah pemeriksaan if. Polyfill yang baik tidak pernah menimpa fitur yang sudah dimiliki browser. Ia hanya turun tangan saat sesuatu tidak ada, sehingga browser modern memakai versi bawaannya yang cepat dan browser lama meminjam penggantinya. Biasanya kamu tidak menulis polyfill sendiri; kamu menyertakan polyfill yang sudah teruji dan dirawat orang lain, dan hanya untuk fitur tertentu yang kamu butuhkan.
Polyfill bukan tanpa ongkos
Setiap polyfill adalah kode tambahan yang harus diunduh dan dijalankan pengunjungmu, dan ada fitur yang memang tidak bisa ditiru ulang dengan setia. Tambahkan polyfill secara sadar, hanya untuk fitur yang penting dan audiens yang memang membutuhkannya — bukan “untuk jaga-jaga” pada segala hal.
Transpiler: menulis ulang kode modern jadi kode lama
Polyfill menambahkan fitur yang hilang saat halaman berjalan. Transpiler melakukan sesuatu yang berkaitan tapi berbeda: sebelum situsmu dirilis, ia menulis ulang kode sumber modernmu menjadi gaya yang lebih lama yang dipahami lebih banyak browser.
Istilahnya adalah perpaduan dari “translate” dan “compile”. Kamu menulis kode memakai sintaks terbaru yang paling nyaman. Transpiler berjalan di komputermu dan menghasilkan versi setara yang memakai sintaks lama yang diterima mesin-mesin tua. Perilakunya sama; hanya cara penulisannya yang diterjemahkan turun ke bentuk yang lebih luas dipahami.
Kode modern yang kamu tulis → [ transpiler ] → Kode bergaya lama
(sintaks terbaru) jalan sebelum dikirim ke browser
kamu publikasikan (lebih banyak yang paham)Cara cepat membedakan keduanya:
| Alat | Apa yang diperbaiki | Kapan berjalan |
|---|---|---|
| Polyfill | Fitur yang hilang (fungsi, objek) | Di browser, saat halaman dimuat |
| Transpiler | Sintaks baru yang tak bisa dibaca mesin lama | Di komputermu, sebelum publikasi |
Dalam praktiknya keduanya bekerja sebagai tim. Transpiler menangani tata bahasa modern, dan polyfill menangani fitur modern. Bersama-sama keduanya membuatmu bisa menulis kode kekinian yang nyaman sambil tetap menjangkau orang di browser lama. Sebagian besar penyiapan build modern merangkai keduanya untukmu sekali saja, jadi kamu jarang memikirkan mekanismenya sehari-hari.
Cara berpikir soal “apakah ini akan jalan di mana saja?”
Kamu tidak akan menguji di setiap browser yang ada — tidak ada yang melakukannya. Sebaliknya, kamu membangun kebiasaan berpikir, dan caranya lebih sederhana daripada kedengarannya:
- Tentukan untuk siapa kamu membangun. Alat untuk pengembang yang niche dan bank nasional punya audiens yang sangat berbeda dan kewajiban yang sangat berbeda.
- Pakai dasar yang kokoh. Mulai dari HTML dan CSS yang jalan secara luas, supaya konten inti dan aksi utama tidak pernah bergantung pada fitur yang paling mewah.
- Periksa sebelum mengandalkan sesuatu yang baru. Untuk fitur apa pun yang penting, cari tahu dukungannya alih-alih menebak. Kalau dukungannya tipis, siapkan cadangan.
- Tambahkan polyfill dan transpiling secara sadar, untuk celah spesifik yang benar-benar dimiliki audiensmu — bukan menjaring semua browser yang pernah dibuat.
- Uji di lebih dari sekadar layarmu sendiri. Coba browser lain, satu ponsel, koneksi yang lebih lambat. Kejutan biasanya muncul di sana, bukan di komputer tempat kamu membangunnya.
Pola pikir yang paling penting
Kamu bukan mengejar halaman yang identik piksel demi piksel di setiap browser — itu tidak mungkin dan tidak perlu. Kamu mengejar halaman di mana setiap pengunjung bisa membaca kontennya dan menyelesaikan tugas utamanya. Kesetaraan pengalaman yang jadi tujuan, bukan kesamaan tampilan.
Rangkuman
Mari kita ikat semua benangnya. Halaman yang sama bisa berperilaku beda karena setiap browser punya mesinnya sendiri, dan mesin-mesin itu mendukung fitur pada waktu yang berbeda — jadi dukungan adalah sesuatu yang kamu periksa per fitur, bukan kamu asumsikan. Untuk menangani rentang itu, progressive enhancement mulai dari dasar yang jalan untuk semua orang lalu menambah tambahan di atasnya, sementara graceful degradation mulai dari versi modern dan turun dengan rapi saat suatu fitur tidak ada. Polyfill adalah kode yang memasok fitur yang hilang ke browser yang tidak memilikinya, dan transpiler menulis ulang sintaks modern menjadi bentuk yang lebih lama sebelum kamu publikasikan. Dipakai bersama, dan diarahkan ke audiens yang benar-benar kamu miliki, alat-alat ini membuatmu bisa menulis kode kekinian yang tetap melayani orang di browser lama atau berbeda.
Dari sini, langkah lanjut yang wajar adalah melihat lebih dekat bagaimana sebuah browser sebenarnya mengubah HTML dan CSS-mu menjadi halaman yang dirender, dan bagaimana alat pengembang (developer tools) bawaan di setiap browser membuatmu bisa memeriksa dan men-debug persis apa yang sedang dilakukan tiap mesin. Di situlah ide-ide ini berhenti menjadi abstrak dan mulai menjadi sesuatu yang bisa kamu saksikan terjadi.
