HTMX, Tolong Coba Sekali Saja

(pleasejusttryhtmx.com)

21 poin oleh GN⁺ 2025-12-19 | 8 komentar | Bagikan ke WhatsApp

Dalam pengembangan web modern, dikotomi palsu antara HTML dan framework JavaScript besar mendorong developer ke kompleksitas yang tidak perlu
HTMX menangani request AJAX, pembaruan parsial, dan transisi animasi hanya dengan atribut HTML, sehingga HTML yang dikembalikan server bisa langsung diterapkan ke tampilan
Strukturnya memungkinkan adopsi bertahap tanpa perubahan besar pada codebase yang ada, mengurangi kompleksitas frontend sekaligus meningkatkan produktivitas dan kemudahan perawatan
Dibanding SPA berbasis React, peningkatan besar pada jumlah kode, dependensi, waktu build, dan kecepatan loading telah terbukti di produksi nyata
Dibanding memilih framework secara berlebihan, pendekatan sederhana berbasis hypermedia lebih menguntungkan untuk produktivitas dan maintainability jangka panjang

Mengangkat masalah: pilihan palsu dalam pengembangan web

Dalam diskusi pengembangan web, yang terus diulang hanyalah pilihan ekstrem antara memakai HTML saja atau framework besar seperti React
HTML murni kuat dalam fitur dasar seperti link, form, dan dialog, tetapi punya keterbatasan dalam pembaruan parsial dan respons instan
Saat memilih React·Vue·Angular, yang ikut datang adalah ratusan dependensi, build lambat, dan perdebatan rumit soal state management
Bahkan untuk app CRUD sederhana, dashboard, dan aplikasi yang berpusat pada form, kenyataannya tooling yang berlebihan tetap dipakai

Konsep inti HTMX

HTMX adalah alat yang menambahkan atribut khusus pada elemen HTML untuk melakukan komunikasi asinkron dengan server
- Misalnya, atribut hx-get dan hx-post mengirim request lalu menyisipkan respons ke area DOM tertentu
Diperluas sehingga setiap elemen HTML bisa menjadi pengirim request HTTP
Server mengembalikan fragmen HTML apa adanya, bukan JSON, lalu HTML yang diterima akan diganti atau disisipkan secara otomatis ke lokasi yang ditentukan
Perilaku didefinisikan hanya lewat deklarasi atribut HTML tanpa perlu menulis JavaScript secara langsung
Ukuran library sekitar 14kb(gzip) sehingga sangat ringan
Bisa langsung diterapkan ke dokumen HTML yang sudah ada tanpa build tool atau konfigurasi framework terpisah
Strukturnya cocok dengan pendekatan pengembangan web tradisional yang berpusat pada server-side rendering

Fitur utama

Menangani request AJAX: menjalankan request GET dan POST hanya dengan atribut HTML
Pembaruan DOM: HTML yang dikembalikan server otomatis diterapkan ke elemen yang ditentukan
Penanganan event: menghubungkan event pengguna seperti klik dan input dengan pemanggilan ke server
Manajemen history: terintegrasi dengan aksi back dan forward di browser

Contoh penerapan nyata dan angkanya

Contexte memigrasikan SaaS berbasis React ke Django + HTMX
- Total baris kode turun 67% (21,500 → 7,200)
- Dependensi JavaScript turun 96% (255 → 9)
- Waktu build berkurang 88% (40 detik → 5 detik)
- Kecepatan loading halaman meningkat 50~60%
Dua pertiga codebase dihapus, dan aplikasinya justru menjadi lebih baik
Tanpa pemisahan frontend dan backend, semua developer bisa bekerja full-stack

Ringkasan terhadap sanggahan yang umum

"Bukankah perlu state management client yang kompleks?"
- Pada praktiknya, kebanyakan hanya sebatas form, list, dan elemen yang muncul saat diklik, dan itu cukup ditangani HTMX
- Untuk tool kolaborasi real-time seperti Google Docs memang pengecualian, tetapi kebanyakan orang melebih-lebihkan kompleksitas app CRUD
"Bagaimana dengan keuntungan ekosistem React?"
- Ekosistem yang besar juga berarti node_modules berukuran gigabyte, pilihan tanpa akhir, dan debat state management
- Ekosistem HTMX selesai hanya dengan satu bahasa server-side yang dipilih
"Bukankah SPA terasa lebih cepat?"
- Di awal, harus melewati download, parsing, eksekusi, dan hydration JavaScript berukuran besar
- HTMX cepat sejak loading awal, dan setelah itu juga menjaga respons cepat dengan hanya mengganti bagian yang berubah
Iklan
"Bagaimana jika fitur React tertentu memang dibutuhkan?"
- Dalam beberapa kasus, React memang bisa lebih cocok
- Namun dalam praktiknya, sering kali orang secara kebiasaan memilih alat yang sebenarnya hanya dibutuhkan untuk sebagian kecil dari keseluruhan masalah
Mengapa memilih HTMX?
- Tim gagal bukan karena salah framework, tetapi karena memilih framework secara berlebihan
- HTMX bertaruh pada kesederhanaan, dan dalam jangka panjang kesederhanaan memberi keuntungan pada maintainability dan produktivitas

Kapan HTMX tidak cocok

Tool editing kolaboratif real-time (Google Docs, Figma)
Aplikasi yang membutuhkan komputasi client berskala besar (editor video, tool CAD)
Arsitektur offline-first (meski tentu beberapa pendekatan bisa digabungkan)
Kasus yang benar-benar membutuhkan state UI yang kompleks

Tetapi, apakah Anda benar-benar sedang membangun hal seperti itu?
- Bukankah yang Anda buat sebenarnya hanya dashboard lain, panel admin, situs e-commerce, blog, atau app SaaS yang terdiri dari form, tabel, dan daftar?
- Untuk hal-hal seperti itu, HTMX benar-benar sangat bagus, sampai membuat Anda ingin berkata: "Kenapa dulu dibuat serumit ini?" dan "Ya ampun, selama ini terlalu banyak waktu terbuang"
Iklan

Jadi, cobalah sekali

Anda sudah pernah memakai React, pernah memakai Vue, dan mungkin pernah mencoba Angular lalu menyesal, bukan?
- Bahkan meta-framework yang sedang tren minggu ini di Hacker News pun mungkin sudah sempat Anda sentuh
Coba saja HTMX sekali
- Luangkan sekitar satu hari di akhir pekan
- Pilih satu side project
- Atau pilih internal tool yang tidak terlalu diperhatikan siapa pun
- Atau keluarkan lagi sesuatu yang sudah lama Anda tunda untuk dibuat ulang
Tambahkan satu tag <script> dan tulis satu atribut hx-get, lalu lihat sendiri bagaimana ia bekerja
Dalam skenario terburuk, Anda hanya kehilangan satu hari di akhir pekan, jadi risikonya tidak besar
- Tetapi kemungkinan besar Anda tidak akan membencinya
- Malah bisa jadi Anda akan bertanya-tanya kenapa pengembangan web sampai dibuat serumit ini

8 komentar

ryj0902 2025-12-22

Saya pernah mendengar presentasi terkait ini di PyCon, dan saya ingat pembicaranya juga mengatakan bahwa mereka sendiri belum sempat menggunakannya di pekerjaan nyata.

aer0700 2025-12-21

Rust, tolong coba sekali saja?

bbulbum 2025-12-20

Saya pernah mencoba Alpine.js, dan sebagian besar waktu saya tetap membutuhkan manajemen state...
Kalau sejak awal tidak dirancang agar state dikelola di backend, saya ingat cukup merepotkan untuk menangani state per langkah, state kondisional, dan semacamnya.

roxie 2025-12-20

Saya setuju dengan semua yang dikatakan, tapi entah kenapa saya tetap tidak tertarik memakai htmx :(

GN⁺ 2025-12-19

Opini Hacker News

Saya adalah pencipta htmx. Saya berterima kasih karena mendapat perhatian berkat artikel yang berlebihan seperti ini, tetapi saya sebenarnya tidak terlalu suka hype seperti ini
Ada banyak cara untuk membangun web app, dan masing-masing punya kelebihan serta kekurangan. Saya merangkum kekuatan dan kelemahan htmx di tulisan ini
Saya juga sangat merekomendasikan untuk mencoba Unpoly, library berorientasi hypermedia lain yang sangat bagus
(Tambahan) Setelah melihat lagi isi artikelnya, ternyata lebih bagus dari yang saya kira. Meski begitu, saya tetap berharap htmx dibahas dengan nada yang lebih tenang
- Jika Anda terbiasa dengan cara membuat web app seperti di awal 1999-an, HTMX memudahkan penambahan fitur interaktif dengan sedikit usaha
  Memperbarui field lewat dropdown, membuat modal, kotak pencarian autocomplete, semuanya sederhana
  Namun, kompleksitas frontend RIA ada pada bagaimana frontend diperbarui saat data berubah.
  Akan lebih baik jika ada sedikit penyesuaian di backend dan struktur yang bisa menangani beberapa partial update sekaligus
- Ada juga tulisan berjudul HTMX Sucks. Sudut pandangnya menarik
- Unpoly terlihat sangat keren. Saya belum memakai HTMX, tetapi saya suka karena ia meringankan masalah UX pada framework seperti Django atau Rails
  Saat ini saya mengerjakan side project dengan Rails + Stimulus, dan Stimulus justru terasa berlebihan. Saya penasaran kapan sebaiknya memilih Inertia atau Stimulus
- Sebagai informasi, saya adalah CEO htmx, dan saya sangat suka artikel yang dilebih-lebihkan seperti ini
- Dokumentasi Unpoly juga bagus, tetapi terasa agak rumit. Untuk kasus yang lebih sederhana, saya memakai Alpine AJAX.
  Ini adalah plugin Alpine.js yang menambahkan fungsi AJAX dasar ke tautan dan form
Saya lelah dengan tulisan yang mengklaim lebih baik dari React hanya lewat contoh “Hello World”
Pada contoh sederhana, apa pun akan terlihat bagus. Namun di dunia nyata, kebanyakan kasus punya backend dengan banyak dependency dan UI yang kompleks
- Ketakutan para developer terhadap framework yang terlalu sederhana pada akhirnya muncul saat mereka menabrak batas skalabilitas
  Demo dasar memang bagus, tetapi harus ditunjukkan juga bagaimana ia bisa berkembang ketika fitur yang lebih kompleks ditambahkan
  Orang ingin tahu di mana harus menambahkan JS, apakah perlu build step, dan seberapa terikat pada paradigma htmx
- Ada juga aplikasi seperti Fizzy yang dibuat 37signals dengan Hotwire.
  Ini bukan soal lebih baik dari React, melainkan hanya pendekatan lain
- Intranet kami berjalan dengan kombinasi Python + HTMX. Sampai sekarang belum ada hal yang tidak bisa kami lakukan
  Paradigma mengganti sebagian DOM sangat sederhana dan intuitif
- Sebaliknya, ada juga teknologi yang terlalu kompleks sehingga “Hello World” pun sudah sulit
  Contoh: effect-ts memang kuat, tetapi bahkan output sederhana pun rumit
- Ada aplikasi planning poker real-time yang dibuat dengan Go + Htmx. Implementasinya sekitar 500 baris kode
Startup kami sempat mengadopsi HTMX, tetapi akhirnya sedang beralih ke React
HTMX punya kompleksitas tinggi dalam menangani respons, dan setiap endpoint harus mengembalikan beberapa potongan HTML
Dokumentasi serta contoh kasusnya kurang, dan juga belum ada best practice skala besar.
React lebih matang, dan juga lebih cocok dengan AI coding. HTMX cocok untuk proyek sederhana, tetapi sulit untuk lebih dari itu
- Saya menemukan pola arsitektur yang mulus dengan HTMX
  Setiap endpoint hanya menjalankan satu peran, dan dengan Optimistic UI respons bisa langsung terasa
  Penanganan error dibuat sederhana, dan hx-swap-oob digunakan seminimal mungkin
  Inti dari pemilihan teknologi adalah meminimalkan trade-off
- Bahwa frontend dan backend harus sepakat untuk semua skenario itu memang wajar.
  Karena itu saya menempatkan validasi yang berpusat di backend, dan frontend hanya bertugas menampilkan
- Buku Hypermedia Systems memberi penjelasan yang lebih menyeluruh
- Memilih solusi niche yang tidak dipahami lalu pindah lagi ke hal rumit lain hanyalah mengulangi trade-off
- Memilih teknologi karena alasan “cocok untuk AI coding” itu agak menyedihkan
Saya tidak menginginkan SSR. Backend cukup menyediakan JSON API, dan frontend mengonsumsinya
Saya menganggap SSR itu terlalu dibesar-besarkan. Rasanya seperti strategi untuk mendorong penjualan layanan cloud
Contoh Demo 3 Live Search punya masalah scroll jank yang cukup parah.
Hasilnya tampaknya disisipkan langsung ke dalam dokumen sehingga layout terus dihitung ulang
React sebenarnya sudah cukup bagus. Bahkan untuk proyek sederhana pun tidak ada alasan kuat untuk mempelajari paradigma lain
- React pada akhirnya juga dirender menjadi HTML, jadi HTML/CSS tetap harus dipelajari. Hanya saja ada abstraksinya
- Ekosistem React terlalu luas sehingga menimbulkan kelelahan karena harus terus belajar lalu melupakan
  Sebaliknya, konsep HTMX bisa dipahami dalam 15 menit, lalu tetap berguna selama 10 tahun
- React atau Angular adalah struktur MVC di atas MVC. Terlalu rumit tanpa perlu
- Menggunakan solusi berat di mana-mana itu tidak efisien.
  Secara historis, paradigma yang ringan justru menang di pasar. React pun dulu pernah seperti itu
- Alasannya sederhana — kinerja
Saya justru benar-benar jatuh cinta pada Alpine.js
Konsep enhance terhadap HTML yang dirender server terasa sangat masuk akal
Dropdown, show/hide, dan sebagainya semuanya intuitif, dan tidak memerlukan build step
- Alpine juga punya plugin Alpine AJAX yang menyediakan fungsi mirip HTMX
- Saya juga memakai Alpine.js, dan frontend kembali terasa menyenangkan
  Intuitif dan mudah dikelola bahkan pada proyek besar
- Tetapi untuk proyek komersial, Alpine bisa menjadi mimpi buruk
  Jika JS ditaruh inline di HTML, pemeliharaan jadi sulit dan state management pun menjadi implisit
  Rasanya Hotwire atau Stimulus jauh lebih baik untuk skala organisasi
- Pendekatan deklaratif adalah jawaban yang benar
Jika HTMX dipakai pada aplikasi berskala besar, saya penasaran soal beban server dan biaya
Karena HTML dirender di server, rasanya throughput akan lebih besar dibanding JSON
- Namun belum tentu begitu. Rendering template sangat cepat
  Kadang malah lebih efisien daripada serialisasi JSON, dan di sisi klien juga ada biaya deserialisasi
  HTMX juga bisa dipakai bersama alat seperti Alpine.js agar state yang kompleks tetap mudah ditangani
  Ini memang tidak cocok untuk semua situasi, tetapi sangat bekerja dengan baik dalam banyak kasus
Menginjili framework adalah budaya terburuk dalam ekosistem web
Kalau memang solusi itu bagus, pada akhirnya orang akan mengadopsinya. Tidak perlu bertindak seperti penginjil
Serangan terhadap npm juga dibesar-besarkan. htmx pada akhirnya juga tetap bisa memakai npm
- htmx adalah satu file tanpa dependency, jadi npm sebenarnya tidak wajib
- Kalimat “solusi yang bagus akan diadopsi dengan sendirinya” itu salah.
  Di dunia ini ada banyak solusi buruk yang diadopsi karena marketing dan pengenalan merek
- Popularitas, anggaran, dan inersia menentukan adopsi teknologi.
  Kalau ingin menjaga craftsmanship yang sejati, kita harus melawan bias seperti ini
HTMX terlihat seperti menggabungkan kekurangan dari dua dunia
SSR itu kohesif, CSR itu strukturnya terpisah, sedangkan HTMX mencampur keduanya sehingga muncul keterikatan implisit
Jika data yang sama ingin ditampilkan dalam format berbeda, saya bertanya-tanya apakah backend harus membuat dua endpoint
- Kita perlu lepas dari anggapan bahwa state frontend itu selalu wajib
  Sebagian besar aplikasi cukup dengan state backend, dan selain peningkatan UX, tidak banyak manfaat besarnya
- Jika melihat tulisan Splitting Your APIs, justru itu bisa dianggap kelebihan
- Jika memakai template server seperti Jinja, satu kali rendering bisa menangani berbagai format presentasi
  Jika seluruh halaman disusun di server, datanya sudah ada di dalamnya

iolothebard 2025-12-20

Tahun lalu saya pernah membuat presentasi seperti ini. Tapi sepertinya hampir tidak ada yang mendengarkannya^^
https://www.slideshare.net/slideshow/htmx-2024/274315966

Di level PoC, saya juga pernah membuat hal seperti ini
https://github.com/iolo/hx

Tapi tetap saja tidak ada yang memakai htmx hehe

shakespeares 2025-12-21

Sayang sekali, setelah situasi yang sudah telanjur terasa nyaman dan ekosistem berskala besar yang sudah terbentuk sebanyak itu, semuanya jadi mengakar dan tampaknya tidak ada lagi dorongan untuk berinovasi.