Hydration is Over: Mengenal Resumability di Framework Frontend Generasi Terbaru
Hydration is Over: Mengenal Resumability di Framework Frontend Generasi Terbaru
Dalam satu dekade terakhir, kita telah menerima satu kebenaran pahit dalam pengembangan web: Hydration adalah pajak yang harus kita bayar untuk aplikasi yang interaktif. Namun, di tahun 2026, paradigma ini resmi digugat. Munculnya konsep Resumability menjanjikan akhir dari era heavy-bundle dan awal dari era aplikasi web yang benar-benar instan.
Masalah Fundamental: Apa itu "Hydration Tax"?
Untuk memahami mengapa Hydration mulai ditinggalkan, kita harus melihat apa yang terjadi di balik layar saat kita menggunakan framework seperti React, Vue, atau Svelte dalam mode Server-Side Rendering (SSR).
Proses Hydration terdiri dari tiga langkah yang mahal:
- Download: Browser mengunduh semua JavaScript (JS) yang diperlukan untuk halaman tersebut.
- Parse & Compile: Browser memproses kode JS yang diunduh.
- Execution (Reconciliation): Framework menjalankan ulang seluruh logika aplikasi di sisi klien untuk mencocokkan event listener dengan DOM yang sudah dirender server.
Masalahnya, proses ini bersifat redundant. Server sudah tahu persis struktur aplikasinya, namun ia "membuang" pengetahuan itu dan memaksa browser untuk menghitung ulang semuanya dari nol. Pada perangkat dengan spesifikasi rendah atau koneksi tidak stabil, hal ini menyebabkan Total Blocking Time (TBT) yang tinggi—halaman terlihat sudah siap, tapi tidak bisa diklik.
Memperkenalkan Resumability: Eksekusi Tanpa Pengulangan
Resumability adalah kemampuan sebuah aplikasi untuk melanjutkan (resume) eksekusi tepat di titik di mana server berhenti, tanpa perlu mendownload atau menjalankan ulang kode JS di awal. Konsep ini dipelopori oleh framework seperti Qwik.
Bagaimana Resumability Bekerja secara Teknis?
Berbeda dengan Hydration yang mengandalkan eksekusi kode di awal, Resumability mengandalkan tiga pilar utama:
1. Serialisasi State ke dalam HTML
Dalam framework resumable, semua informasi tentang aplikasi—mulai dari data komponen hingga event listener—disimpan langsung di dalam atribut HTML.
Jika sebuah tombol membutuhkan fungsi klik, HTML-nya akan terlihat seperti ini:
Browser tidak perlu menjalankan JS untuk mengetahui bahwa tombol ini bisa diklik; informasi itu sudah ada di dalam DOM.
2. Fine-Grained Lazy Loading (Code Splitting Atomik)
Framework ini memecah kode menjadi bagian-bagian yang sangat kecil (atom). Kode untuk sebuah fungsi onClick dipisahkan dari definisi komponennya. Kode tersebut tidak akan pernah diunduh oleh browser sampai pengguna benar-benar mengklik tombol tersebut.
3. Global Event Listener
Alih-alih mendaftarkan ribuan event listener saat halaman dimuat (seperti yang dilakukan React), framework resumable hanya mendaftarkan satu listener global di level document. Ketika sebuah aksi terjadi (misal: klik), listener ini akan melihat atribut pada elemen HTML, mengunduh potongan kecil JS yang dibutuhkan, dan menjalankannya secara instan.
Perbandingan Teknis: Hydration vs. Resumability
| Futur | Hydration (React/Next.js) | Resumability (Qwik/Generasi Baru) |
|---|---|---|
| Boot-up Time | Bergantung pada ukuran bundle JS. | Instan (Zero-effort). |
| Eksekusi JS | Menjalankan ulang semua komponen. | Hanya menjalankan kode yang dipicu user. |
| Data Transfer | Mengirim HTML + Bundle JS Besar. | Mengirim HTML + State Ter-serialisasi. |
| Interactivity | "Palsu" sampai JS selesai loading. | Langsung interaktif sejak detik pertama. |
Mengapa "Zero Bundle" Menjadi Nyata?
Secara teori, Resumability memungkinkan apa yang disebut sebagai Zero-JS-by-default. Saat pertama kali halaman dimuat, jumlah JavaScript yang dikirim ke browser mendekati 0kb (hanya skrip kecil sekitar 1kb untuk manajemen event).
Ini adalah lompatan besar bagi SEO dan User Experience. Skor Lighthouse dan Core Web Vitals (khususnya INP - Interaction to Next Paint) akan secara konsisten menyentuh angka 100 karena main-thread browser tidak lagi tercekik oleh proses rekonsiliasi JS yang berat.
Tantangan dan Masa Depan
Apakah ini berarti React akan mati? Tidak dalam waktu dekat. Migrasi ke Resumability membutuhkan perubahan cara berpikir pengembang dalam menulis kode (misal: semua data harus bisa diserialisasi).
Namun, tren menunjukkan arah yang jelas: Kecepatan bukan lagi sebuah fitur, melainkan standar. Resumability bukan sekadar optimasi; ini adalah arsitektur ulang tentang bagaimana web seharusnya bekerja. Kita akhirnya berhenti memperlakukan browser sebagai mesin yang harus merakit ulang semuanya, dan mulai memperlakukannya sebagai perpanjangan tangan dari server.