Mengapa Beralih dari HTMX ke Datastar

 (everydaysuperpowers.dev)
10 poin oleh GN⁺ 2025-10-11 | 2 komentar | Bagikan ke WhatsApp
  • Saat menggunakan HTMX, jumlah kode bisa dikurangi sekitar 70%, tetapi muncul masalah sinkronisasi antar-UI sekaligus meningkatnya kompleksitas manajemen state frontend
  • Setelah mengadopsi Datastar, pengembangan aplikasi multiuser real-time menjadi lebih ringkas tanpa WebSockets dan lebih mudah dipelihara
  • Sementara HTMX menyebarkan logika perilaku ke atribut-atribut HTML, Datastar meningkatkan konsistensi dan kemudahan pemeliharaan melalui model pembaruan yang dikendalikan server
  • API Datastar terasa memiliki lebih sedikit atribut, sehingga keterbacaan kode dan produktivitas meningkat
  • Datastar secara aktif memanfaatkan teknologi web native seperti Server-Sent Events(SSE), Web Components, dan CSS View Transitions untuk memungkinkan kolaborasi real-time dan struktur komponen yang dapat digunakan ulang

Pengantar dan motivasi

Masalah yang memicu perpindahan

  • Saat menyiapkan presentasi FlaskCon 2025, penulis mencoba menyinkronkan UI dengan menggabungkan HTMX dan AlpineJS, tetapi menghadapi masalah sinkronisasi UI
    • Kedua library dibuat oleh pengembang yang berbeda sebagai alat yang terpisah, sehingga tidak bisa saling berkomunikasi dan pengembang harus menangani integrasinya sendiri
    • Dalam proses menginisialisasi komponen di berbagai waktu dan mengoordinasikan event, ternyata dibutuhkan jauh lebih banyak kode dan waktu debugging dari perkiraan
  • Penulis lalu tertarik mencoba Datastar karena ia menggabungkan fungsi kedua library itu sambil tetap hadir dengan ukuran di bawah 11KB
    • Ini menguntungkan untuk meningkatkan performa pemuatan halaman bagi pengguna perangkat mobile

Desain API Datastar yang lebih baik

  • API Datastar terasa jauh lebih ringan dibanding HTMX, dan jumlah atribut tambahan yang diperlukan untuk mendapatkan hasil yang diinginkan lebih sedikit
  • HTMX membutuhkan banyak atribut untuk sebagian besar interaksi
    • Definisi URL, penentuan elemen target, dan cara menangani respons masing-masing harus diatur lewat atribut terpisah
    • Umumnya perlu 2~3 atribut setiap kali, dan kadang harus menelusuri rantai pewarisan untuk memahami cara kerja atribut tersebut
    <a hx-target="#rebuild-bundle-status-button"  
   hx-select="#rebuild-bundle-status-button"  
   hx-swap="outerHTML"  
   hx-trigger="click"  
   hx-get="/rebuild/status-button"></a>
  • Datastar umumnya dapat mewujudkan fungsi yang sama hanya dengan satu atribut saja 
    <a data-on-click="@get('/rebuild/status-button')"></a>
    • Bahkan beberapa bulan kemudian saat melihat lagi kodenya, cara kerjanya tetap mudah dipahami

Perbedaan cara kerja

  • HTMX adalah library frontend yang bertujuan memperluas spesifikasi HTML, sedangkan Datastar adalah library yang dikendalikan server yang bertujuan membangun aplikasi pembaruan real-time web native berperforma tinggi
  • HTMX mendefinisikan perilaku dengan menambahkan atribut pada elemen yang memicu request, sehingga meskipun yang diperbarui adalah elemen yang jauh di tempat lain di halaman, logikanya tetap tersebar di beberapa lapisan
  • Datastar membuat server yang menentukan apa yang harus diubah, sehingga seluruh logika pembaruan terpusat di satu tempat

  • Contoh HTMX

    <div>  
  <div id="alert"></div>  
    <button hx-get="/info"   
            hx-select="#info-details"   
            hx-swap="outerHTML"  
            hx-select-oob="#alert">  
        Get Info!  
    </button>  
</div>
    • Saat tombol ditekan, request GET dikirim ke /info, tombol diganti dengan elemen ber-ID info-details dari respons, dan elemen ber-ID alert di halaman juga diganti dengan elemen dengan ID yang sama dari respons
    • Elemen tombol harus mengetahui terlalu banyak hal, dan karena harus tahu sebelumnya informasi apa yang akan dikembalikan server, prinsip "locality of behavior" milik HTMX pun melemah

  • Pendekatan Datastar yang ditingkatkan

    <div>  
    <div id="alert"></div>  
    <button id="info-details"  
    data-on-click="@get('/info')">  
        Get Info!  
    </button>  
</div>
    • Server mengembalikan string HTML yang berisi dua elemen root dengan ID yang sama 
      <p id="info-details">These are the details you are looking for…</p>  
<div id="alert">Alert! This is a test.</div>
    • Sederhana dan memiliki performa yang baik

Berpikir di level komponen

  • Pendekatan yang lebih baik adalah memperlakukan HTML sebagai komponen
  • Pahami esensi komponen tersebut
    • Cara pengguna mendapatkan informasi tambahan tentang item tertentu
    • Saat pengguna menekan tombol, informasi ditampilkan atau error dirender jika informasi tidak ada; dalam kedua kasus itu, komponen masuk ke state statis

  • Memisahkan komponen berdasarkan state

    • State placeholder: 
      <!-- info-component-placeholder.html -->  
<div id="info-component">  
    <button data-on-click="@get('/product/{{product.id}}/info')">  
        Get Info!  
    </button>  
</div>
    • State tampilan informasi: 
      <!-- info-component-get.html -->  
<div id="info-component">  
    {% if alert %}<div id="alert">{{ alert }}</div>{% endif %}  
    <p>{{product.additional_information}}</p>  
</div>
    • Saat server merender HTML, Datastar akan memperbarui halaman secara otomatis
    • Berpikir di level komponen mencegah masuk ke state yang salah atau kehilangan state pengguna

Memperbarui beberapa komponen sekaligus

  • Salah satu hal yang mengesankan dari presentasi David Guillot adalah ketika aplikasi memperbarui jumlah item favorit, komponen yang berubah dan elemen penghitung yang letaknya sangat jauh juga ikut diperbarui
    • Di HTMX, ini memicu event JavaScript, yang kemudian memicu komponen jarak jauh untuk mengirim request GET
  • Datastar memungkinkan memperbarui beberapa komponen sekaligus bahkan di dalam fungsi sinkron

  • Contoh keranjang belanja

    • Komponen tambah ke keranjang: 
      <form id="purchase-item"  
      data-on-submit="@post('/add-item', {contentType: 'form'})">"  
>  
  <input type=hidden name="cart-id" value="{{cart.id}}">  
  <input type=hidden name="item-id" value="{{item.id}}">  
  <fieldset>  
    <button data-on-click="$quantity -= 1">-</button>  
    <label>Jumlah  
      <input name=quantity type=number data-bind-quantity value=1>  
    </label>  
    <button data-on-click="$quantity += 1">+</button>  
  </fieldset>  
  <button type=submit>Tambahkan ke keranjang</button>  
  {% if msg %}  
    <p class=message>{{msg}}</p>  
  {% endif %}  
</form>
    • Komponen tampilan jumlah keranjang: 
      <div id="cart-count">  
    <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">  
        <use href="#shoppingCart">  
    </svg>  
    {{count}}  
</div>
    • Di Django, dua komponen diperbarui dalam request yang sama: 
      from datastar_py.consts import ElementPatchMode  
from datastar_py.django import (  
    DatastarResponse,  
    ServerSentEventGenerator as SSE,  
)  

def add_item(request):  
    # pembaruan state penting dihilangkan  
    return DatastarResponse([  
        SSE.patch_elements(  
            render_to_string('purchase-item.html', context=dict(cart=cart, item=item, msg='Item added!'))  
        ),  
        SSE.patch_elements(  
            render_to_string('cart-count.html', context=dict(count=item_count))  
        ),  
    ])

Filosofi web native

  • Melalui komunitas Datastar di Discord, penulis memahami bahwa Datastar bukan sekadar skrip helper, melainkan filosofi membangun aplikasi dengan memanfaatkan primitive dasar web
  • Jika HTMX ingin mengembangkan spesifikasi HTML, Datastar lebih tertarik mendorong adopsi fitur web native
    • CSS view transitions
    • Server-Sent Events
    • Web Components, dll.
  • Penulis berhasil mencapai hasil besar dengan me-refactor komponen AlpineJS yang kompleks menjadi web component sederhana yang bisa diekstrak dan digunakan ulang di banyak tempat
  • Ini adalah pola yang sangat baik untuk mencapai locality of behavior dan reusabilitas tinggi melalui pembuatan elemen HTML kustom, bahkan tanpa alat seperti React

Pembaruan real-time untuk aplikasi multiuser

  • Aplikasi yang menjadikan kolaborasi sebagai fitur kelas satu berbeda dari aplikasi lain, dan Datastar menjawab tantangan ini
  • Sebagian besar pengembang HTMX mengambil informasi dari server dengan polling atau menulis kode WebSocket kustom, yang menambah kompleksitas
  • Datastar menggunakan teknologi web sederhana bernama Server-Sent Events(SSE) untuk mendorong pembaruan dari server ke klien yang terhubung
    • Saat pengguna menambahkan komentar atau state berubah, server langsung memperbarui browser dengan kebutuhan kode tambahan yang minimal
    • Dashboard real-time, panel admin, dan alat kolaborasi dapat dibangun tanpa JavaScript kustom
  • Jika koneksi klien terputus, browser akan otomatis mencoba terhubung kembali tanpa perlu kode tambahan
    • Server juga bisa diberi tahu tentang "event terakhir yang diterima"

Menghindari kompleksitas berlebihan

  • Komunitas Datastar di Discord membantu memahami visi Datastar untuk pembuatan aplikasi web
    • Pembaruan UI berbasis push
    • Pengurangan kompleksitas
    • Penanganan situasi kompleks secara lokal dengan alat seperti web components
  • Komunitas itu juga membantu pengguna baru menyadari saat mereka mendekati masalah dengan cara yang terlalu rumit

Tips utama

  • Jangan takut mengirim ulang seluruh komponen setelah dirender ulang
    • Ini lebih mudah dan tidak banyak memengaruhi performa
    • Kompresinya bisa lebih baik, dan browser sangat cepat dalam mem-parsing string HTML
  • Server adalah sumber kebenaran state dan lebih kuat daripada browser
    • Biarkan server menangani sebagian besar state; Anda mungkin tidak memerlukan signal reaktif sebanyak yang dibayangkan
  • Web Components sangat bagus untuk mengenkapsulasi logika dalam elemen kustom dengan locality of behavior yang tinggi
    • Animasi bidang bintang di header situs Datastar adalah contoh yang bagus
    • Elemen <ds-starfield> mengenkapsulasi seluruh kode animasi bidang bintang dan mengekspos tiga atribut untuk mengubah state internalnya
    • Datastar menggerakkan atribut tersebut saat input rentang berubah atau mouse bergerak di atas elemen

Potensi yang melampaui batasan

  • Potensi yang dimungkinkan Datastar adalah hal yang paling menarik
  • Komunitasnya secara rutin membuat proyek yang jauh melampaui batasan yang biasa dialami pengembang dengan alat lain

Contoh yang patut diperhatikan

  • Demo pemantauan database di halaman contoh
    • Dengan memanfaatkan hypermedia, demo ini sangat meningkatkan kecepatan dan penggunaan memori dibanding demo yang dipresentasikan di konferensi JavaScript
  • 1 miliar checkbox karya Anders Murphy
    • Ketika eksperimen 1 juta checkbox melebihi kapasitas server, ia memakai Datastar untuk mewujudkan 1 miliar checkbox di server murah
  • Aplikasi web yang menampilkan data semua stasiun radar di Amerika Serikat
    • Saat sinyal radar berubah, titik yang соответствует di UI berubah dalam waktu kurang dari 100 milidetik
    • Lebih dari 800 ribu titik diperbarui per detik, dan pengguna dapat melakukan scrub hingga 1 jam ke belakang dengan latensi kurang dari 700 milidetik
    • Fakta bahwa ini bisa dilakukan sebagai aplikasi hypermedia menunjukkan apa yang dimungkinkan oleh Datastar

Pengalaman penggunaan saat ini

  • Penulis masih berada pada tahap eksplorasi Datastar, dan telah dengan cepat serta mudah mengimplementasikan penanganan AJAX pembaruan UI yang merupakan fungsi standar HTMX
  • Berbagai pola untuk mencapai lebih banyak hal dengan Datastar sedang dipelajari dan diuji
  • Selama puluhan tahun, penulis tertarik pada cara memberikan pengalaman pengguna yang lebih baik lewat pembaruan real-time, dan menyukai bahwa Datastar memungkinkan pembaruan berbasis push bahkan dalam kode sinkron
  • Saat pertama mulai memakai HTMX, penulis merasakan kegembiraan besar, tetapi setelah beralih ke Datastar, rasanya tidak ada yang hilang, malah mendapat jauh lebih banyak
  • Jika Anda merasakan kegembiraan saat mulai memakai HTMX, Anda akan merasakan lompatan serupa lagi di Datastar, seolah menemukan kembali apa yang memang seharusnya dilakukan web sejak awal

Bacaan terkait

2 komentar

 
GN⁺ 2025-10-11
Opini Hacker News
  • Saya menghargai Chris karena berani keluar dari zona nyamannya, mencoba hal baru, lalu membagikan pengalamannya kepada kita. Saya mungkin agak bias karena sudah 4 tahun membuat web app dengan htmx, tetapi menurut saya ini menyoroti perbedaan arsitektur utama antara Datastar dan htmx: htmx berorientasi pada HTML, sedangkan Datastar berorientasi pada server. Memang benar API sisi kliennya lebih sederhana, tetapi itu karena logika sisi server menjadi lebih kompleks. Misalnya, jika elemen HTML tidak memiliki informasi tentang di mana fragment yang dikembalikan server harus disisipkan, maka informasi itu harus dicatat di sisi server, jadi kompleksitas pasti ada di salah satu sisi. Pilihan arsitektur ini tampaknya soal preferensi. Logika “less attributes” pada contoh juga sulit dibilang 100% adil, karena di htmx ia memasukkan atribut yang sifatnya opsional; misalnya jika hx-trigger="click" dihapus, atributnya langsung berkurang 20%. Dan menurut saya contoh itu akan lebih meyakinkan jika HTML-nya dibuat lebih aksesibel, misalnya memakai <button> alih-alih <span>. Pada akhirnya, kekuatan Datastar tampaknya adalah ia hadir dengan kemampuan seperti Alpine atau Stimulus yang sudah tertanam, dan itu benar-benar mengesankan
    • Dengan Datastar, bukankah kompleksitasnya jauh berkurang karena untuk memperbarui bagian lain dari halaman secara real-time kita tidak perlu mengimplementasikan eventing secara terpisah, melainkan bisa menurunkan semuanya sekaligus dan memperbaruinya? Tentu saja, tergantung situasinya, pendekatan berbasis event atau memuat belakangan mungkin tetap lebih baik
    • Saya melihat komentar bahwa ini seperti “fitur Alpine atau Stimulus yang dibangun langsung ke dalam HTMX”, jadi saya jadi mempertimbangkan membuat proyek pribadi dengan HTMX. Saya penasaran apakah ada materi yang menjelaskan bahwa library tambahan seperti AlpineJS atau Stimulus memang perlu
    • Ada pembahasan bahwa jika elemen HTML tidak punya informasi tentang di mana fragment harus disisipkan, maka server harus mengetahuinya, tetapi saya juga sempat berpikir bukankah frontend jadi lebih ringan dan cepat dalam kasus seperti ini? Apalagi jika elemennya sangat banyak?
    • Struktur ini agak mirip dengan framework Seaside di Pharo. Saat perusahaan kami membuat aplikasi B2B dengan Pharo, status UI dikelola di backend sehingga banyak sekali lalu lintas bolak-balik antara frontend dan backend. Untuk B2B yang real-time dan latensi tidak terlalu penting, ini tidak masalah, tetapi untuk aplikasi B2C yang menuntut skalabilitas tinggi, ini kurang cocok
  • Dari sudut pandang seseorang yang sudah memakai Datastar dan HTMX langsung, saya masih belum benar-benar paham apa perbedaan besar saat membangun aplikasi dengan Datastar. Saya memakai FastAPI, HTMX, Alpine.js, dan SSE bersama-sama untuk menampilkan log secara real-time, memperbarui status deployment, dan hal serupa. Saat melihat contoh Datastar, saya tidak terlalu melihat bagian yang lebih sederhana dibanding struktur ini. (Referensi kode: devpush SSE partial). Saya juga pernah mencoba Web Components saat mengembangkan Basecoat, tetapi karena masalah styling, manajemen state, dan berbagai alasan lain, akhirnya kembali ke HTML/CSS/JS tradisional. devpu.sh, basecoatui.com
    • Bahkan di HTMX juga, saat mempertimbangkan ekstensibilitas fungsional seperti Datastar, sering kali justru lebih sederhana untuk memperbarui seluruh daftar sekaligus. Daripada mencoba memperbarui status deployment satu per satu, memperbarui seluruh daftar membuat kita tidak perlu memikirkan edge case seperti pagination, sehingga jauh lebih sederhana dan kodenya juga lebih ringan
  • Kalau ada yang merasa Datastar tidak memadai untuk real-time/kolaborasi/multiplayer, saya ingin memperkenalkan 3 demo yang berjalan tanpa fitur PRO dan bahkan bisa naik ke halaman utama HN hanya dengan VPS 5 dolar. Ini menunjukkan seberapa matang teknologi Datastar: Checkboxes, Cells, Game of Life Example. Contoh checkbox dan cells memiliki rendering view yang fleksibel, jadi bisa di-zoom out cukup jauh, dan juga punya virtual scrolling dengan fitur backpressure
    • Jika saya memahami struktur kodenya dengan benar, sepertinya mereka sebenarnya tidak memakai pendekatan patch yang direkomendasikan datastar (diff/patch), melainkan merender ulang seluruh halaman setiap kali. Justru mental model seperti ini terasa jauh lebih sederhana daripada contoh yang melacak state klien secara detail dari server, jadi malah menarik buat saya. Saya penasaran apakah aplikasi kompleks pada umumnya juga bisa dibangun dengan cara ini. Kalau ada bacaan yang bisa dijadikan referensi tentang bagaimana melacak berbagai state widget dan merender ulang secara instan ketika pengguna berpindah ke halaman yang berbeda, saya ingin tahu
    • Pada contoh checkbox/cells disebutkan bisa “zoom out”, tetapi saya penasaran bagaimana tepatnya caranya. Dan akan lebih bagus jika ada opsi seperti data-replace-url yang otomatis memperbarui URL view saat ini ke koordinat tersebut (x=123&y=456, dll.)
    • Dari penyebutan fitur PRO saya jadi tahu bahwa ini memakai model open-core (sebagian open source, sisanya berbayar, lisensi 299 dolar). Saya pribadi ingin melewatkannya
  • Saya baru-baru ini membaca tulisan seperti ini (htmx, datastar, greedy developer), dan saya dengar fitur inti Datastar yang bagus dipindahkan ke versi berbayar (Pro). Saya ingin mendukung framework secara finansial, baik open source maupun berbayar, tetapi preseden seperti ini agak mengkhawatirkan
    • Saya juga mengikuti Datastar selama beberapa bulan sambil menunggu rilis 1.0.0, tetapi sekarang antusiasme saya benar-benar hilang. Saya terlalu sering dikecewakan oleh kasus yang “katanya open source, tapi sebenarnya tidak”, jadi makin sulit untuk percaya
    • Sebenarnya saya pernah menulis bahwa saya kurang suka Datastar, tetapi kali ini saya ingin sedikit membelanya. Pembuat framework ini sudah merilis kodenya secara gratis dengan lisensi MIT, jadi fitur yang dulu pernah dibuka gratis tetap bisa dipakai dengan MIT. Dari sudut pandang pengguna yang selama ini memakai tanpa berkontribusi, bergantung pada versi lama itu adalah pilihan masing-masing. Mulai sekarang beralih ke model berbayar adalah hak pemilik produk, dan kalau perlu ya tinggal di-fork saja
    • Saya sudah membeli lisensi PRO seharga 299 dolar sekali bayar, tetapi sampai sekarang belum pernah benar-benar memakai fitur PRO. Saya sempat ingin membuat klon Google Sheets, tetapi ternyata itu pun cukup bisa diimplementasikan tanpa PRO. (lihat demo cells)
    • Saya pernah merasa pihak Datastar bukan cuma terus mempromosikan betapa bagusnya Datastar di Discord HTMX, tetapi juga sedikit terkesan agresif. Saya juga pernah melihat komentar bernuansa “kalau semua fitur yang Anda butuhkan sudah ada, pakai saja beta forever; open source tidak berutang apa pun kepada siapa pun” di reddit
    • Saat memakai Datastar, saya langsung teringat kasus lama Meteor.js. (diskusi HN tentang Meteor.js)
  • Saya tidak terlalu memahami contoh kode dalam post ini. Misalnya contoh htmx berikut <span hx-target="#rebuild-bundle-status-button" hx-select="#rebuild-bundle-status-button" hx-swap="outerHTML" hx-trigger="click" hx-get="/rebuild/status-button"></span> tampaknya diubah menjadi kode datastar seperti ini: <span data-on-click="@get('/rebuild/status-button')"></span> Bahkan contoh-contoh lainnya lebih membingungkan. Pada akhirnya saya tetap tidak paham mengapa orang berpindah dari htmx ke Datastar
    • Pada dasarnya, di HTMX itu berarti “ketika span ini diklik, ambil HTML dari /rebuild/status-button, lalu ekstrak elemen #rebuild-bundle-status-button dari HTML yang dikembalikan, kemudian ganti elemen yang ada sekarang”. Sementara di Datastar artinya menjadi “saat span diklik, ikuti saja perintah dari /rebuild/status-button”. Jika server mengembalikan elemen dengan beberapa ID, Datastar akan otomatis mengenali semuanya dan menggantinya. Jadi tanpa target, select, dan swap pun, asal diberi ID, perilakunya tetap sesuai maksud
    • Struktur Datastar pada dasarnya memusatkan logika di backend. Mirip HTML tradisional zaman dulu: kirim request, terima HTML, lalu browser merendernya. Tetapi di Datastar, setelah halaman sekali dimuat seperti PWA, setiap kali ada interaksi ia mengirim request ke backend lalu menerima hanya perubahan yang perlu diterapkan. Ini seperti kebalikan dari SPA (single-page app) yang mengelola semua state di frontend tanpa logika di frontend. Pada intinya, ini lagi-lagi pengulangan soal bagaimana logika dibagi antara backend dan frontend, dan Datastar memungkinkan antarmuka tetap dinamis sambil memusatkan logika di server (backend)
    • Tapi saya tetap bertanya-tanya mengapa mereka memakai tag span untuk aksi klik. Bukankah tag button atau link lebih tepat?
  • Ironisnya, post ini membahas hypermedia, tetapi justru tidak menyertakan tautan ke situs resmi Datastar. Ini situs resminya: https://data-star.dev/
  • Salah satu keunggulan besar HTMX adalah klien tidak perlu tahu struktur data yang dikembalikan server, tetapi jika klien harus mengetahui ID atau makna dari elemen tertentu, rasanya janji itu jadi rusak. Tentu saja di banyak proyek nyata OOB (Out of Band) memang sering dipakai, jadi pemisahan struktur yang benar-benar sempurna juga agak jauh dari kenyataan. Akan bagus jika ada pendekatan yang bisa mengambil kelebihan dari kedua dunia
    • Pada praktiknya klien sebenarnya tidak perlu tahu apa pun. Klien tinggal menjalankan aksinya, lalu server bisa mengirimkan seluruh view halaman. Klien kemudian langsung merender semuanya. Ini mirip model immediate mode pada video game
  • Struktur Datastar yang menambal HTML dari server seperti ini terasa kurang baik dari sudut separation of concerns, dan semakin besar aplikasinya, semakin merepotkan rasanya jika server terus-menerus menyuntikkan potongan HTML
    • Tapi kalau sebaliknya JS di berbagai tempat menyuntikkan HTML dalam bentuk fragment, itu juga belum tentu lebih baik
    • Desain endpoint yang menyajikan potongan HTML dari server entah kenapa terasa kurang nyaman
  • Datastar terasa lebih matang dibanding htmx. Saya sudah berhasil membuat beberapa proyek dengan htmx, tetapi saya selalu merasa kurang puas karena untuk menangani event saya tetap perlu menambahkan JS glue code (terutama AlpineJS dan semacamnya). Kalau Datastar bisa mengurangi kebutuhan itu juga, saya benar-benar menantikannya
    • Saya sarankan membaca esai grugs around the fire di situs Datastar
  • Saya relatif terlambat ikut tren hypermedia; saya sempat memakai Datastar lebih dulu, tetapi belakangan pindah ke HTMX. API Datastar memang terasa sedikit lebih baik, tetapi sejak htmx 2.0 mendukung pembaruan OOB (Out-Of-Band), setelah itu saya lebih sering memihak htmx
    • Ungkapan “terlambat ke hypermedia” menarik. Istilah itu pertama kali diciptakan Ted Nelson pada 1965, dan menarik jika diingat bahwa saat itu ia berkata, “hyperfilm— a browsable or vari-sequenced movie— is only one of the possible hypermedia that require our attention”. Lihat makalah terkait
    • Hal yang mengecewakan saat menangani elemen OOB di HTMX: 1. Kalau OOB, htmx-swap-oob="true" wajib ada, kalau tidak perilakunya berbeda dari yang diharapkan 2. Sebaliknya, kalau bukan OOB lalu htmx-swap-oob="true" ada, atribut itu akan diabaikan atau malah menyebabkan perilaku salah. Akibatnya, ketika komponen yang sama ingin dipakai ulang sebagai OOB/non-OOB, server harus selalu mengirim flag isOob, dan itu sangat merepotkan
    • Saya lebih suka API alpine-ajax. Dengan hanya menentukan beberapa target, ia bisa mengganti masing-masing elemen secara konsisten tanpa JS. Konsep signal/state di Datastar justru terasa menambah kompleksitas, jadi saya kurang suka