HTMX begitu keren sampai saya membuatnya sendiri (2024)

• HTMX adalah pendekatan yang berfokus pada HTML hasil render server untuk meningkatkan frontend secara progresif, berkembang dari cara sebelum UI JavaScript modern ala React membesar berlebihan
• Saat refaktor server untuk podcast web app self-hosted mengganti SvelteKit dengan DinoSsr, muncul masalah perpindahan halaman memutus pemutaran audio, dan dengan HTMX hanya area `` yang diperbarui sehingga komponen audio bisa dipertahankan
• HTMX didistribusikan sebagai library frontend, tetapi sebagian besar implementasinya berada di template backend dan konfigurasi server, dan request HTTP yang mengembalikan HTML pada dasarnya berperan sebagai API HTMX
• Atribut hx-*, contoh `` yang bisa diklik, dan contoh lanjutan dengan banyak JavaScript inline menunjukkan keterbatasan template atribut deklaratif serta beberapa keluhan pada dokumentasinya
• Implementasi mini buatan sendiri menggunakan caching 304, History API, penggantian ``, dan preload berbasis pointer event sebagai elemen utama, dengan hasil akhir mengurangi JavaScript di browser sehingga codebase menjadi lebih kecil dan sederhana

---

Posisi HTMX

• HTMX menolak UI JavaScript modern dan lebih menyukai HTML hasil render server, sebuah pendekatan yang berkembang dari cara sebelum frontend membesar berlebihan dengan React
• Infinite scroll dan hasil pencarian real-time adalah contoh HTMX yang populer; HTMX memang terlihat terbatas dan tidak menyelesaikan semua masalah yang ingin diselesaikan React dan sejenisnya, tetapi dalam batasan itu ia adalah alat yang sangat bernilai
• HTMX bukan “magic bullet”, dan inti pandangannya adalah bahwa sebagian ide di balik HTMX lebih penting daripada HTMX itu sendiri

Eksperimen

• Membaca dokumentasi saja tidak cukup, jadi penulis menguji pemakaian nyata, dan sasaran penerapan HTMX adalah refaktor server untuk podcast web app self-hosted
• Implementasi sebelumnya menggunakan SvelteKit, dan walau SvelteKit adalah alat favorit, framework itu bisa terasa berat untuk situs web kecil
• Penggantinya adalah DinoSsr yang dibuat sendiri; proyek yang sama juga dipakai untuk build situs statis dan menyajikan blog bookmark
• DinoSsr terutama berbasis server-side dan dapat menyediakan komponen sebagai frontend “islands”, tetapi strukturnya tidak menyediakan interaksi seluruh halaman
• Komponen audio player harus tetap bertahan saat berpindah halaman, dan jika perpindahan halaman memuat ulang seluruh halaman maka pengalaman pemutaran akan cepat terputus
• SvelteKit menangani pembaruan UI dan routing frontend, tetapi pada build baru hanya komponen audio player yang memakai JavaScript frontend, dan DinoSsr sengaja tidak mencoba routing sisi klien
• Beberapa halaman hanya berbeda pada bagian `` sehingga, jika tautan ditingkatkan secara progresif dengan HTMX dan hanya area ini yang diperbarui, komponen audio dapat dipertahankan tanpa memuat ulang seluruh halaman
• Penerapan HTMX bekerja dengan baik, tetapi tidak lama kemudian HTMX dihapus dan diganti dengan versi mini buatan sendiri yang memakai ide yang sama

Beberapa pemikiran tentang HTMX

• Dalam eksperimen ini HTMX menjadi pengganti Svelte di frontend, tetapi bukan pengganti yang bisa langsung disisipkan seperti React, melainkan perubahan cara berpikir yang besar
• HTMX didistribusikan sebagai library JavaScript untuk meningkatkan frontend secara progresif, tetapi sebagian besar implementasinya dilakukan di backend, dengan template server dan konfigurasinya harus disiapkan sendiri
• Request HTTP yang menyajikan HTML pada dasarnya berperan sebagai API HTMX, dan detail penetapan header HTTP penting untuk caching yang benar
• Sudah ada atribut standar data-* dan dataset, jadi penggunaan atribut berprafiks nonstandar hx-* menjadi keluhan kecil
• Dokumentasi HTMX banyak memuat contoh ``; contoh di bawah ini menunjukkan struktur saat pengguna mengklik div, mengirim request PUT ke /messages, lalu memuat respons ke div tersebut

    Put To Messages

• Contoh yang mengharuskan pengguna mengklik elemen `` dikritik sebagai sesuatu yang tidak diinginkan
• Beberapa contoh HTMX lanjutan yang menggunakan JavaScript inline menjadi agak berantakan dan menunjukkan batasan template atribut deklaratif
• Terlepas dari kritik itu, HTMX tetap menyediakan kumpulan fitur yang terbatas tetapi berguna, dan merupakan alat yang dapat meningkatkan banyak pola desain web umum

Membuat sendiri

• Tepat setelah berhasil menambahkan HTMX, penulis malah menghapusnya dan membuat implementasi versi mini sendiri dengan ide yang sama
• Untuk memungkinkan request fetch yang di-cache, digunakan header HTTP last-modified, if-modified-since, dan respons 304
• Untuk integrasi riwayat dasar digunakan pushState dan popstate
• Ditambahkan kode untuk mengekstrak dan mengganti elemen ``, serta preload bawaan berbasis pointer event yang terinspirasi dari HTMX preload extension
• Preload berbasis pointer event memulai request fetch sebelum event click terjadi, memberi peningkatan performa kecil
• Kode sumber eksperimen ini sangat dasar, tetapi menunjukkan bahwa JavaScript yang benar-benar dibutuhkan browser sebenarnya sedikit
• Dengan HTMX atau pendekatan “we have HTMX at home”, hasilnya codebase menjadi jauh lebih kecil dan sederhana

JavaScript frontend

• Template dan komponen pada praktiknya diperlukan untuk organisasi kode dan reuse, kecuali mungkin pada situs web yang sangat kecil, dan bisa diimplementasikan di server-side dengan PHP, Ruby, Go, JavaScript, dan lainnya
• Struktur seperti ini tidak perlu diduplikasi ke browser atau diimplementasikan hanya di browser, tetapi popularitas React dan sejenisnya membuat banyak developer berhenti mempertanyakan hal itu
• Kelelahan terhadap JavaScript frontend itu nyata, dan berkaitan dengan pengalaman lebih menyukai template server lama sambil tetap terlalu merekayasa UI JS
• Bahkan jika HTMX sendiri tidak dianggap sangat hebat, filosofinya tetap merupakan pendekatan yang cukup kuat hingga bisa membuat developer JavaScript modern merasa malu

[GN⁺]

Opini Lobste.rs

• Sedikit mengada-ada sih, tapi saya kurang suka penggunaan atribut HTML berawalan hx-* di tempat yang seharusnya memakai data-* Htmx sudah lama mendukung prefiks data- Soal jangan membuat pengguna mengklik elemen `` , cara terbaik adalah memakai hx-boost milik htmx pada tag anchor dan form. Karena tag-tag ini akan ditingkatkan secara otomatis dengan cara yang benar, jadi bisa menghindari div yang bisa diklik Ini proyek yang menunjukkan betapa sedikit JavaScript yang sebenarnya dibutuhkan browser, dan ke depannya perawatannya kemungkinan minim serta hampir tidak butuh patch keamanan. Patut diberi selamat

• Karena HTMX merender semuanya, bukankah itu membebani server? Rasanya mirip dengan masalah CGI yang dulu pernah kita alami

  • Hampir pasti tidak. Masalah CGI utamanya adalah biaya menjalankan banyak proses yang berumur pendek, dan itu sudah diselesaikan dengan hal seperti FastCGI Pembuatan HTML bukan pekerjaan yang terlalu mahal, dan sulit juga mengatakan bahwa itu lebih mahal daripada membuat JSON dalam jumlah serupa pada pendekatan alternatif
  • Saya tidak paham maksud “kita”. Blog saya berbasis CGI, server merender HTML, dan tidak ada JavaScript sama sekali Sejak 1999 tidak ada masalah, dan seperti biasa, untuk tahu bottleneck yang sebenarnya ada di mana, harus dicek lewat profiling
  • Biasanya ini disebut server-side rendering, tapi sebenarnya lebih dekat ke pembuatan HTML mentah di server. Rendering yang sesungguhnya dan pembuatan DOM tetap dilakukan browser, dan memang selalu begitu Bahkan kalau PHP dimasukkan ke kategori CGI, berarti kita melewatkan kira-kira satu setengah dekade pengembangan web saat pendekatan seperti ini adalah hal yang umum Benar bahwa ini membuat server bekerja lebih banyak, tetapi menurut saya alasan utama banyak pemrosesan dipindahkan ke klien selama ini lebih merupakan risiko yang diperhitungkan demi penghematan biaya. Banyak pengguna akhir tidak menyadari browser melakukan lebih banyak pekerjaan, tetapi pada perangkat lama atau berperforma rendah, pengalaman sampai sekarang—terutama di awal—justru memburuk Meski begitu, HTMX tidak sama dengan server-side rendering penuh. Alih-alih API mengirim data sebagai JSON lalu klien merendernya menjadi HTML, server mengirim data yang sama sebagai fragmen HTML. Jadi kalau server sampai kewalahan, kemungkinan besar itu bukan karena pendekatan ini pada dasarnya lebih boros sumber daya daripada REST API, melainkan karena faktor lain
  • Sulit memastikan tanpa benchmark, tapi rasanya akan mirip. Dalam kedua kasus, pada akhirnya yang dikirim tetap tumpukan teks; bedanya hanya apakah merender teks lebih mahal atau membuat JSON lebih mahal Dari pengalaman saya, saat memakai JSON biasanya yang diserialisasi justru lebih banyak, tapi saya juga tidak yakin bagaimana cara membandingkannya dengan benar
  • Dalam aplikasi server-side, hampir tidak pernah tahap rendering HTML itu sendiri yang menjadi bottleneck; biasanya bottleneck ada di proses sebelum itu

• Karena alasan serupa, saya memakai alpine-ajax yang sangat mirip dengan htmx

  • Saya juga sangat suka alpine-ajax. Kalau saya memulai lagi dengan tujuan “mendapatkan kelebihan SPA dari SSR”, mungkin saya akan memilih itu Soalnya untuk fitur reaktif di klien, saya memang sudah memakai alpine. Hanya saja sekarang sudah banyak htmx di repositori, dan saya juga tidak punya keluhan terhadap htmx
  • Saya memakai datastar, dan pengalaman mengerjakannya cukup menyenangkan