Cara Browser Menangani JavaScript

Saat sebuah halaman web melakukan sesuatu yang interaktif — menu yang terbuka mulus, formulir yang mengingatkan kamu ada kolom yang belum diisi, angka di dashboard yang berubah tanpa halaman dimuat ulang — perilaku itu datang dari JavaScript. Tapi JavaScript sendiri hanyalah teks. Ada sesuatu yang harus membaca teks itu, memahaminya, lalu benar-benar menjalankan instruksinya. Sesuatu itu adalah browser.

Artikel ini membahas peran browser sebagai pihak yang menjalankan skripmu. Kita tidak akan mengajarkan bahasa JavaScript-nya di sini — tidak ada perulangan, variabel, atau sintaks. Yang kita lihat justru apa yang terjadi di balik layar: bagaimana browser mengubah satu berkas penuh kode menjadi halaman yang hidup, kenapa ia sebenarnya cuma bisa mengerjakan satu hal dalam satu waktu, dan bagaimana cara kamu memuat skrip ikut menentukan apa yang dilihat pengunjung dan kapan.

Apa yang sebenarnya menjalankan JavaScript-mu

Di dalam setiap browser modern ada satu perangkat lunak bernama engine JavaScript. Anggap saja ia gabungan penerjemah dan pekerja: ia membaca JavaScript yang kamu tulis lalu mencari cara agar komputer benar-benar mengerjakannya.

Tiap browser memakai engine yang berbeda. Chrome dan banyak browser yang dibangun di atas inti yang sama memakai engine bernama V8. Firefox memakai SpiderMonkey. Safari memakai JavaScriptCore. Kamu tidak memilih engine ini — ia sudah tertanam di dalam browser — tapi penting tahu bahwa ia ada, karena engine inilah “otak” yang melakukan pekerjaan berat.

Begini kira-kira perjalanan sebuah skrip dari teks menjadi aksi:

  berkas .js milikmu (teks biasa)
          │
          ▼
   1. PARSING   → engine membaca kode dan menyusun
                   peta terstruktur tentang artinya
          │
          ▼
   2. KOMPILASI → peta itu diubah menjadi instruksi
                   tingkat mesin yang cepat
          │
          ▼
   3. EKSEKUSI  → instruksi dijalankan; halaman bereaksi
                   (DOM berubah, data dimuat, dan seterusnya)

Mari kita bedah ketiga langkah itu dengan bahasa sederhana.

Parsing: membaca dan memahami kode

Parsing adalah saat engine membaca kodemu karakter demi karakter dan memastikan semuanya masuk akal. Ia mengelompokkan teks menjadi bagian-bagian yang bermakna — ini sebuah fungsi, ini sebuah nama, ini sebuah nilai — lalu menyusun sebuah pohon internal yang menggambarkan struktur program. Kalau kamu pernah lupa menutup kurung lalu muncul pesan “syntax error”, itulah parser yang memberi tahu bahwa ia tidak bisa memahami apa yang kamu tulis.

Kompilasi: mengubah kode jadi sesuatu yang cepat

Prosesor komputer tidak mengerti JavaScript. Ia berbicara dalam bahasa yang jauh lebih rendah tingkatnya. Maka setelah parsing, engine mengompilasi kodemu — menerjemahkan versi terstruktur tadi menjadi instruksi yang bisa dijalankan mesin dengan cepat.

Engine modern cukup pintar soal ini. Mereka memakai pendekatan yang sering disebut kompilasi just-in-time, artinya kode dikompilasi tepat sebelum dibutuhkan, dan bagian yang sering dipakai terus dioptimalkan. Kamu tidak perlu melakukan apa pun untuk memicunya; ini terjadi otomatis tiap kali halaman dimuat.

Eksekusi: membuat halaman bekerja

Akhirnya engine menjalankan instruksi yang sudah dikompilasi. Di sinilah aksi yang terlihat terjadi: sebuah skrip bisa membaca apa yang kamu ketik, mengubah teks di halaman, mengambil data baru dari server, atau memulai animasi. Menjalankan JavaScript juga yang membuat halaman tetap “hidup” setelah pertama kali dimuat.

Engine itu bagian dari browser, bukan halaman

Engine JavaScript tertanam di dalam browser, seperti aplikasi kalkulator yang sudah jadi bagian dari ponselmu. Sebuah halaman web hanya menyerahkan kode ke browser; engine milik browser-lah yang membaca dan menjalankannya. Inilah kenapa skrip yang sama bisa berperilaku sedikit berbeda di browser yang berbeda — engine-nya memang tidak sama.

Satu per satu: jalur utama yang tunggal

Ini salah satu gagasan terpenting yang perlu dipahami pemula: di sebuah halaman web, JavaScript-mu biasanya berjalan di satu jalur utama (main thread). “Thread” itu sekadar satu antrean kerja yang diikuti komputer. Satu jalur berarti hanya ada satu antrean, dan tiap tugas harus menunggu gilirannya.

Analogi yang membantu: bayangkan toko kecil dengan satu kasir. Pelanggan (tugas) mengantre. Kasir menuntaskan satu pelanggan sampai selesai, baru memanggil yang berikutnya. Kasirnya gesit, jadi biasanya terasa seketika — tapi kalau satu pelanggan butuh sesuatu yang lama, semua yang di belakangnya ikut menunggu.

Kasir itu adalah jalur utama halamanmu. Dan ia punya tugas kedua: jalur yang sama ini juga bertanggung jawab menggambar halaman dan menanggapi klik. Jadi kalau JavaScript-mu memulai tugas berat yang lama dan tak kunjung selesai, halaman akan membeku — tombol berhenti merespons, scroll tersendat — karena si pekerja tunggal sedang sibuk dan tidak bisa mengurus hal lain.

Kenapa halaman bisa membeku

Halaman yang membeku atau tidak responsif hampir selalu pertanda JavaScript sedang menguasai jalur utama dengan tugas yang terlalu lama. Karena jalur yang sama juga mengurus penggambaran dan klik, tidak ada yang bisa berjalan sampai tugas itu tuntas. Menjaga setiap pekerjaan tetap kecil dan cepat itulah yang membuat halaman terasa mulus.

Event loop: cara satu jalur menangani banyak hal

Kalau pekerjanya cuma satu, bagaimana sebuah halaman bisa mengerjakan banyak hal sekaligus — menunggu data, menanggapi klik, sambil menjalankan timer — tanpa berantakan? Jawabannya sistem bernama event loop.

Idenya sederhana. Sebagian tugas memang lama, tapi tidak butuh jalur utama selama prosesnya — misalnya meminta data ke server, atau menunggu tiga detik sebelum melakukan sesuatu. Browser menyerahkan tugas-tugas ini untuk dikerjakan di tempat lain dan membiarkan jalur utama terus berjalan. Begitu salah satu tugas itu selesai, pekerjaan lanjutannya ditaruh di sebuah antrean — barisan tunggu. Event loop adalah bagian yang mengawasi barisan ini: kapan pun jalur utama menganggur, ia mengambil item berikutnya dari antrean lalu menjalankannya.

  Jalur utama:  [ jalankan kode ] → [ nganggur? ] ──┐
                                                    │ ya
  Antrean:      [ tugas ][ tugas ][ tugas ] ────────┘ ambil berikutnya
                   ▲
                   │ kerja latar yang selesai menaruh tugas baru di sini
        (server membalas, timer berbunyi, kamu mengeklik sesuatu)

Jadi di jalur utama, halaman tidak pernah benar-benar mengerjakan dua hal pada saat yang persis sama — ia hanya berpindah antar pekerjaan kecil begitu cepat sampai, bagi kamu, terasa serentak. Inilah kenapa halaman yang dibuat dengan baik bisa memuat data di latar belakang sambil tetap langsung menanggapi scroll dan klikmu.

Kamu tidak perlu mengatur event loop sendiri; ia sudah jadi bawaan browser. Tapi memahami bahwa ia ada menjelaskan banyak hal — misalnya kenapa sesuatu yang kamu minta untuk dikerjakan “nanti” baru berjalan setelah tugas yang sekarang selesai.

Bagaimana cara memuat skrip memengaruhi halaman

Sekarang mari hubungkan JavaScript dengan apa yang benar-benar dilihat pembaca. Untuk menampilkan halaman, browser membaca HTML dari atas ke bawah dan membangun struktur halaman sambil jalan. Saat ia bertemu tag <script>, ia harus mengambil keputusan — dan keputusan itu mengubah seberapa cepat halamanmu muncul.

Ada tiga cara umum menyertakan skrip, dan perbedaannya penting:

Cara	Apa yang dilakukan browser	Efek ke halaman
`<script>` biasa	Berhenti membangun halaman, mengambil skrip, menjalankannya, baru melanjutkan	Halaman bisa tampak kosong atau macet selama skrip dimuat — ini “render-blocking”
`<script async>`	Terus membangun halaman; menjalankan skrip begitu tiba, bahkan di tengah proses	Lebih cepat, tapi urutan jalannya skrip bisa tak tertebak
`<script defer>`	Terus membangun halaman; menunggu lalu menjalankan skrip secara berurutan setelah halaman jadi	Halaman muncul cepat, skrip jalan berurutan — biasanya paling aman

Begini tampilannya dalam HTML:

<!-- Render-blocking: pembangunan berhenti di sini sampai selesai -->
<script src="app.js"></script>

<!-- Async: diambil bersamaan dengan halaman, dijalankan saat siap -->
<script async src="analytics.js"></script>

<!-- Defer: diambil bersamaan dengan halaman, jalan berurutan setelah jadi -->
<script defer src="app.js"></script>

Intinya dalam bahasa sederhana: sebuah <script> biasa di tengah halaman bisa membuat pengunjung memandangi layar yang belum jadi, karena browser berhenti menata halaman demi mengurus skrip dulu. Memakai defer (atau menaruh skrip di paling akhir halaman) membuat konten muncul lebih dulu, baru JavaScript-nya berjalan. Untuk pemula, defer adalah pilihan yang andal di sebagian besar situasi.

Satu patokan sederhana

Kalau sebuah skrip mengubah tampilan atau cara kerja halaman dan urutannya penting, defer biasanya pilihan paling bersahabat: halaman muncul cepat dan skripmu tetap berjalan sesuai urutan penulisanmu. Pakai async terutama untuk skrip yang berdiri sendiri dan tidak saling bergantung, seperti analitik.

JavaScript bisa mengubah halaman setelah dimuat

Halaman tidak membeku begitu ia muncul. Di balik layar, browser menyimpan satu model halaman yang hidup di memori bernama DOM (Document Object Model) — pada dasarnya representasi terstruktur dari setiap elemen di halaman. JavaScript bisa membaca dan mengubah model ini kapan saja.

Ketika sebuah skrip menambah paragraf, menyembunyikan menu, atau memperbarui harga, ia sedang menyunting DOM. Browser menyadari perubahan itu lalu menggambar ulang bagian halaman yang terdampak sehingga kamu melihat hasilnya. Inilah alasan utama satu halaman bisa terasa seperti aplikasi: strukturnya digambar sekali, dan JavaScript terus menyuntingnya sebagai tanggapan atas apa yang kamu lakukan.

Hal ini terhubung langsung dengan jalur rendering browser — urutan langkah yang diikuti browser untuk mengubah HTML dan gaya menjadi piksel di layar. JavaScript berada di dalam jalur itu: ia bisa mengubah struktur atau gaya, yang memaksa browser menghitung dan menggambar ulang. Melakukannya terus-menerus tanpa hati-hati adalah salah satu penyebab umum halaman terasa berat, karena tiap perubahan meminta browser bekerja menggambar lagi.

  HTML + CSS  →  browser menggambar halaman  →  kamu melihatnya
                          ▲
                          │  JavaScript menyunting DOM
                          │  (menambah, menghapus, mengubah elemen)
                          └──  browser menggambar ulang yang berubah

Rangkuman singkat

Di awal artikel ini kamu melihat JavaScript sebagai perilaku misterius di sebuah halaman. Sekarang kamu bisa melihat mesin di baliknya:

Engine JavaScript di dalam browser melakukan parsing, kompilasi, dan eksekusi kodemu — mengubah teks biasa menjadi aksi nyata.
Skripmu berjalan di satu jalur utama, jadi tugas harus menunggu giliran; tugas yang lama bisa membekukan halaman karena jalur yang sama juga menggambar dan mendengarkan klik.
Event loop membuat satu jalur itu sanggup menangani banyak pekerjaan dengan mengantrekan kerja latar yang sudah selesai lalu menjalankannya saat jalur menganggur.
Cara kamu memuat skrip — biasa, async, atau defer — mengubah seberapa cepat halaman muncul, dan defer adalah pilihan aman secara default.
JavaScript menjaga halaman tetap hidup dengan menyunting DOM, sehingga browser menggambar ulang bagian yang berubah.

Langkah berikutnya yang wajar adalah bahasa JavaScript-nya sendiri — variabel, fungsi, dan logika yang benar-benar kamu tulis, yang dibahas terpisah di topik frontend. Dengan gambaran dari artikel ini, kamu akan paham bukan cuma apa yang dikatakan kode itu, tapi juga bagaimana browser menghidupkannya.