Dunia pengembangan web menghabiskan sebagian besar dekade untuk meyakinkan dirinya sendiri bahwa browser harus melakukan pekerjaan berat

Dunia pengembangan web menghabiskan sebagian besar dekade terakhir untuk meyakinkan diri sendiri bahwa browser harus melakukan pekerjaan berat. Kita mulai dengan dokumen dan formulir, lalu secara bertahap memindahkan setiap operasi yang dapat dibayangkan ke sisi klien. Routing, manajemen state, pengambilan data (data fetching), logika rendering, bahkan orkestrasi kueri database melalui GraphQL — semuanya berpindah ke dalam bundle JavaScript yang semakin berat pada setiap rilisnya.

Pergeseran tersebut menyelesaikan masalah nyata. Halaman yang dirender di server dengan sedikit sentuhan jQuery kesulitan memberikan transisi mulus layaknya aplikasi yang diharapkan pengguna. Single Page Application memberi kita navigasi instan, state yang persisten, dan interaksi yang kaya. Namun, biayanya terus menumpuk. Tim sekarang harus mengelola penyimpanan state sisi klien yang kompleks, mengurus bundle JavaScript yang masif, memelihara lapisan sinkronisasi data yang rumit, dan men-debug pipeline build yang terkadang terasa seperti pekerjaan penuh waktu tersendiri. Kita menukar satu set masalah dengan masalah lainnya, dan banyak pengembang kini bertanya-tanya apakah setiap aplikasi perlu membayar "pajak" tersebut.

Dua perkembangan membuat pertanyaan tersebut lebih mudah dijawab.

HTMX dan Kembalinya Hypermedia

Yang pertama adalah HTMX. Di permukaan, ia tampak seperti library kecil, tetapi implikasi arsitekturalnya sangat besar. HTMX memperlakukan HTML sebagai format asli untuk logika aplikasi, alih-alih memperlakukannya sebagai cangkang statis yang harus dihidupkan oleh JavaScript.

Berikut adalah apa yang berubah dalam praktiknya. Secara tradisional, ketika pengguna mengklik tombol untuk memuat lebih banyak komentar, frontend mengirimkan permintaan fetch, menerima payload JSON, menormalisasinya ke dalam client-side store, menjalankannya melalui template komponen, melakukan diff pada virtual DOM, dan akhirnya melakukan patch pada halaman. HTMX memotong rantai tersebut. Tombol itu sendiri berisi atribut yang memberi tahu browser ke mana harus mengirim permintaan dan elemen halaman mana yang harus diganti. Server mengembalikan fragmen HTML — hanya komentar baru, yang dibungkus dalam sebuah div. Browser kemudian menukarnya. Tidak ada JSON, tidak ada frontend state tree, tidak ada algoritma rekonsiliasi, dan tidak ada JavaScript imperatif untuk menjaga UI tetap sinkron dengan server.

Ini bukanlah penolakan terhadap pengembangan modern. Ini adalah penolakan terhadap abstraksi yang tidak perlu. HTMX membuktikan bahwa hypermedia, gaya arsitektur yang menggerakkan web awal, masih dapat mendukung antarmuka yang canggih jika dipasangkan dengan ergonomi modern. Elemen apa pun dapat mengajukan permintaan, tidak hanya formulir dan tautan. Peristiwa (event) apa pun dapat memicu pembaruan. Server tetap menjadi sumber kebenaran (source of truth) baik untuk data maupun presentasi.

Chrome’s Declarative Partial Updates

Pergeseran kedua lebih baru dan berada di dalam browser itu sendiri. Chrome memperkenalkan Declarative Partial Updates, atau DPU. Fitur ini memungkinkan browser untuk melakukan streaming HTML dan memasukkannya secara langsung ke bagian halaman yang ditargetkan saat byte-byte tersebut tiba.

Sebelum DPU, jika Anda ingin melakukan streaming data langsung ke halaman web, Anda umumnya menggunakan WebSockets, Server-Sent Events, atau long-polling yang dipasangkan dengan manipulasi DOM secara manual. Frontend harus mengelola koneksi, mengurai (parse) payload, dan memutuskan secara tepat bagaimana dan di mana menyuntikkan markup. DPU mengubah persamaan tersebut dengan membuat prosesnya menjadi deklaratif. Pengembang menentukan kontainer target, dan browser menangani sisanya: menerima stream, mengurai fragmen, dan menempatkannya tepat di tempat yang seharusnya, bahkan sebelum respons lengkap ditutup.

Bayangkan dashboard pemantauan yang menampilkan log server atau antrean dukungan yang diperbarui secara real-time. Dengan DPU, backend mengirimkan potongan (chunk) HTML biasa saat dihasilkan. Browser melakukan streaming potongan tersebut ke dalam body tabel atau kontainer feed tanpa satu baris pun logika streaming sisi klien. Perakitan terjadi secara native.

The Server-First Model

Gabungkan HTMX dan DPU, dan Anda akan mendapatkan arsitektur yang koheren di mana server memiliki state dan menghasilkan UI, sementara browser menangani tampilan dan input pengguna. Framework backend seperti Rails, Laravel, Django, Go templates, atau ASP.NET menjadi lapisan antarmuka utama lagi. Frontend bukanlah aplikasi terpisah yang mengonsumsi API. Ia adalah antarmuka hypermedia yang dihasilkan oleh server.

This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.

The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.

What About React and Heavy Clients?

None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.

But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.

The Pendulum Finds a Balance

The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.

You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.

For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.