</> Htmx – The Fetch()ening

• htmx 4.0 adalah versi rebuild besar yang sepenuhnya mengganti arsitektur lama berbasis XMLHttpRequest menjadi arsitektur asinkron berpusat pada fetch()
• Cara pewarisan atribut berubah dari implisit menjadi deklarasi eksplisit :inherited, sehingga meningkatkan kejelasan kode dan kemudahan pemeliharaan
• Cache riwayat disederhanakan dari penyimpanan snapshot lokal menjadi mekanisme pemulihan berbasis permintaan jaringan, sehingga keandalannya meningkat
• Berbagai fitur baru seperti streaming response, SSE, DOM morphing, tag ``, dan antrean View Transition diintegrasikan ke dalam core
• Dalam jangka panjang, penyederhanaan codebase dan peningkatan skalabilitas dituju, sambil tetap mendukung pengguna 2.0 yang sudah ada

---

Ikhtisar htmx 4.0

• htmx 4.0 menulis ulang keseluruhan arsitektur lama, dengan mencerminkan pengalaman pengembangan fixi.js dan pelajaran dari 5 tahun pemeliharaan
• Perubahan utamanya diringkas menjadi 3 perubahan inti: migrasi ke fetch(), pewarisan atribut eksplisit, dan penyederhanaan cache riwayat

The fetch()ening

• XMLHttpRequest diganti dengan fetch() untuk memodernisasi infrastruktur Ajax
  • Untuk sebagian besar kasus penggunaan, dampaknya tidak besar, tetapi model event berubah mengikuti sifat asinkron fetch()
• Peralihan ini menjadi landasan untuk penyederhanaan kode dan perluasan fitur di masa depan

Pewarisan atribut eksplisit

• Alih-alih pewarisan implisit sebelumnya, kini digunakan modifier :inherited untuk deklarasi eksplisit
  • Contoh:

    
        Like
        Dislike
    
    

  • Jika hx-target tidak dinyatakan eksplisit, elemen turunannya tidak akan mewarisinya
• Bagi sebagian besar pengguna, ini adalah perubahan upgrade terbesar

Penyederhanaan cache riwayat

• Cache snapshot DOM lokal di htmx 2.0 tidak stabil karena modifikasi pihak ketiga, state tersembunyi, dan sebagainya
• Di 4.0, mekanismenya diubah menjadi pemulihan melalui permintaan jaringan
  • Perluasan cache disediakan sebagai opsi opt-in
• Ini menyederhanakan codebase sekaligus meningkatkan keandalan perilaku default

Elemen yang tetap dipertahankan

• API inti seperti hx-get, hx-post, hx-target, hx-boost, hx-swap, dan hx-trigger tetap sama
• Selain penambahan :inherited, sebagian besar proyek dapat berjalan dengan kode yang ada
• Pemeliharaan jangka panjang dan stabilitas diperkuat

Kebijakan upgrade

• Pengguna 2.0 perlu melakukan proyek upgrade, tetapi 2.0 akan tetap didukung secara permanen
• 4.0 akan dirilis berdampingan dengan 2.x, dan perpindahan latest diperkirakan pada awal 2027
• Akan disediakan extension untuk memulihkan perilaku 2.0

Ringkasan fitur baru

Integrasi streaming response dan SSE

• Memanfaatkan dukungan Readable Streams pada fetch() untuk memungkinkan penggantian DOM parsial
• SSE (Server Sent Events) diintegrasikan kembali sebagai fitur inti, mendukung pembaruan konten secara bertahap

Morphing Swap

• Berdasarkan algoritme Idiomorph, penilaian saat menggabungkan DOM untuk mempertahankan atau menghapus node menjadi lebih baik
• Swap morphInner dan morphOuter disertakan dalam core

Dukungan tag ``

• Menyederhanakan sintaks yang sebelumnya rumit pada Out-of-band swap
• `` adalah elemen template yang dapat menggunakan atribut standar seperti hx-target dan hx-swap
• Out-of-band swap kembali menjadi penggantian sederhana berbasis id

Peningkatan View Transition

• Antrean transisi (queue) diperkenalkan untuk mencegah benturan visual
• Transisi CSS tetap menggunakan cara lama, sementara runtime asinkron disederhanakan
• Belum diputuskan apakah akan diaktifkan secara default

Stabilisasi urutan event

• Dengan arsitektur asinkron berbasis fetch(), urutan event lebih mudah dijamin
• Diperkenalkan aturan penamaan event baru: htmx::[:]
  • Contoh: htmx:before:request

Peningkatan skalabilitas

• Berbasis async, disediakan extension untuk preload dan optimistic update
• Siklus request/response/swap dibuka untuk pengembang extension, dan implementasi fetch() dapat diganti
• Perilaku yang diinginkan dapat diwujudkan tanpa hack

Peningkatan hx-on

• Mengadopsi sintaks terstandarisasi hx-on:
• Dengan dukungan API asinkron, scripting DOM sederhana menjadi mungkin

  
      Get A Response Then Remove It 3 Seconds Later
  
  

• Tetap berfungsi di lingkungan dengan eval() dinonaktifkan, meski beberapa fungsi terbatas

Arah keseluruhan

• htmx 4.0 bertujuan mengurangi bug dan meningkatkan fitur sambil mempertahankan pengalaman penggunaan yang mirip dengan 2.0
• Melalui penyederhanaan kode, struktur yang eksplisit, dan skalabilitas berbasis asinkron, htmx menjadi lebih stabil dan modern

Jadwal pengembangan

• Versi alfa (htmx@4.0.0-alpha1) sudah dirilis saat ini
• Rilis resmi 4.0.0 dijadwalkan pada awal hingga pertengahan 2026
• Awal 2027 dijadwalkan sebagai waktu perpindahan ke latest
• Perkembangan pengembangan dapat dilihat di branch GitHub four dan four.htmx.org

---

[GN⁺]

Opini Hacker News

• Akhirnya berubah pikiran dan memutuskan untuk merilis versi mayor baru htmx
  Namun, untuk menepati janji bahwa “tidak akan ada 3.0”, versi berikutnya diberi nama htmx 4.0
  Mereka menanggapi dengan nada bercanda bahwa secara teknis itu tetap benar

  • Solusi yang lucu, tetapi bisa juga membingungkan pengguna seperti PHP 6 yang dulu sempat hilang
    Mungkin akan lebih baik kalau jujur saja merilisnya sebagai 3.0
  • Ada juga yang bercanda agar langsung lompat ke htmx 4.1 dan membuat “xhtmx 1.0”
  • Katanya ini terasa seperti Leisure Suit Larry 4: The Missing Floppies
  • Untungnya mereka tidak bilang “versi ketiga tidak ada”, jadi masih ada ruang untuk bermain dengan pilihan kata

• htmx 2.0 akan didukung secara permanen, jadi sama sekali tidak ada tekanan untuk upgrade
  Di era sekarang saat perubahan API sering terjadi, pendekatan seperti ini patut diapresiasi

• Ada yang merasa orang-orang yang mengejar stabilitas sering mengambil pelajaran yang keliru
  Daripada menumpuk perubahan besar sekaligus seperti Python 3.0, mereka berpendapat strategi rilis bertahap lebih baik
  Misalnya, perubahan diperkenalkan lewat 2.1, 4.0, 5.0, dan seterusnya agar jauh lebih mudah dikelola
  Mereka merekomendasikan pendekatan seperti Django yang mempertahankan tahap kompatibilitas di beberapa versi

• Penjelasan atribut hx-target terasa membingungkan
  Dibanding “inherited”, “inheritable” atau “inherit” terdengar lebih alami

  • Ada yang bilang ia membacanya sebagai “diwarisi oleh anak”, dan mengusulkan istilah seperti “pass-down” agar lebih jelas
  • “inherited” dianggap kata yang kurang tepat, sementara “inherit” lebih singkat dan bagus
    Sebagai lelucon, ada juga yang menambahkan bahwa “bequeath” mungkin bisa dipakai
  • Mereka mengatakan masih mempertimbangkan berbagai pilihan istilah dan terbuka menerima masukan
  • Alternatif lain seperti “heritable” atau “cascade” juga diajukan

• Mereka menilai ide HTMX dan filosofi Hypermedia sangat keren
  Setelah keluar dari lingkungan SPA dan memilih Datastar, mereka merasa skalabilitasnya lebih besar dibanding investasi belajar yang dibutuhkan
  Dengan mendorong sinyal langsung dari server ke browser, mereka bisa menghapus kode polling, dan kompleksitas pun berkurang drastis
  Ketergantungan pada Alpine.js juga dihilangkan sehingga kodenya lebih sederhana, dan pembaruan seluruh tampilan berbasis streaming juga bekerja efisien berkat kompresi
  Jika datang dari dunia SPA, mereka menyarankan mencoba Datastar maupun HTMX

• Peralihan ke fetch() untuk memanfaatkan Readable Stream dianggap menarik
  Mereka sudah cukup banyak memakai HTMX, tetapi akhir-akhir ini lebih menyukai streaming berbasis SSE milik Datastar

• Meski senang melihat HTMX berkembang, ada yang merasa Datastar menawarkan API yang lebih ramah standar dan fleksibel
  Dalam paket kecil, ia memuat Fetch, SSE, declarative signals, DOM morphing, dan berbagai fitur lain
  Karena itu, mereka pun bertanya, “kenapa harus memakai HTMX?”

  • Ada yang menyoroti bahwa Datastar Pro bukan open source, sehingga ada risiko kepercayaan
  • Disebut juga ironis bahwa pembuat Datastar dulu pernah mencoba memasukkan fitur seperti ini ke HTMX
  • Dijelaskan bahwa kekuatan HTMX ada pada antarmuka sederhananya yang dioptimalkan untuk paradigma request/response
    Datastar berpusat pada event stream sehingga cocok untuk dashboard real-time atau game, tetapi untuk kebanyakan web app, kesederhanaan HTMX lebih menguntungkan
    Referensi terkait: esai Datastar, Less HTMX is More
  • HTMX mendukung pengelolaan riwayat URL browser dengan mudah, sedangkan Datastar disebut membatasi fitur ini ke versi berbayar (Pro)

• Ada yang menyindir bahwa dari pernyataan “sudah sempurna sehingga tidak akan ada versi mayor lagi”, akhirnya diakui juga perlunya evolusi
  Mereka mengutip bagian “sekarang kami akan mengubah standar penamaan event” sebagai sindiran terhadap upaya menghindari JavaScript

  • “Pada akhirnya, demi tidak menulis JavaScript, mereka malah membuat sintaks kustom yang ditafsirkan dengan JS,” kata seseorang dengan nada sinis
    Meski begitu, mereka tetap mengakui bahwa mengekspresikan niat lewat HTML punya nilai tersendiri
  • Ada juga yang bercanda, “mungkin ini benar-benar versi terakhir”
  • Sebagian menerimanya dengan positif: “tetap lebih baik daripada menulis JavaScript langsung”
  • Ada pula yang menyoroti nada kritik itu dengan bertanya, “memangnya apa masalahnya kalau penulis mengubah pikirannya?”

• Tulisan ini dinilai sangat jelas dan banyak mengajarkan filosofi desain API

• Seseorang membuat xhr-fetch-proxy untuk memakai fetch bersama HTMX,
  dan merasa perubahan kali ini akan membuka lebih banyak kemungkinan
  Tautan proyek

  • Di 4.0, siklus request dibuka sepenuhnya, sehingga implementasi fetch dapat diganti untuk setiap request
    Mereka menambahkan bahwa ide ini dipelajari dari fixi.js