- htmx terpilih untuk GitHub Open Source Accelerator angkatan pertama, sehingga memperoleh kesempatan untuk berkolaborasi dan belajar dari proyek-proyek open source yang telah matang
- Partisipasi ini menjadi momentum untuk memperkenalkan hypermedia dan pendekatan htmx ke komunitas pengembang yang lebih luas
- htmx berencana memanfaatkan periode Accelerator untuk mulai mengerjakan htmx 2.0
- Agar pemeliharaan dan pengembangan proyek dapat terus berlanjut, mempelajari cara menjadikan pekerjaan pada htmx sebagai pekerjaan penuh waktu juga tetap menjadi tugas penting
- Proyek-proyek yang terpilih bersama mencakup beragam area open source seperti keamanan, dokumentasi, autentikasi, notifikasi, dan CMS, yang menunjukkan cakupan GitHub Accelerator
Peluang yang didapat htmx
- htmx terpilih untuk kelas pertama GitHub Open Source Accelerator
- Dengan terpilih kali ini, htmx dapat belajar dan berkolaborasi dengan pengembang dan proyek open source yang sukses
- htmx memandang proses ini sebagai kesempatan untuk memperkenalkan hypermedia dan htmx secara lebih luas
- Ada dua tujuan utama selama masa partisipasi di Accelerator
- Memulai pengerjaan htmx 2.0
- Mempelajari cara menjadikan pekerjaan pada htmx sebagai pekerjaan penuh waktu
Proyek open source lain yang terpilih bersama
- BoxyHQ: rangkaian produk API untuk keamanan dan privasi yang membantu tim engineering membangun dan menerapkan aplikasi cloud yang patuh regulasi dengan lebih cepat
- Cal.com: alat penjadwalan yang membantu mengatur pertemuan tanpa perlu bolak-balik mengirim email
- Crowd.dev: membantu memusatkan data komunitas, produk, dan pelanggan agar dapat mengetahui perusahaan mana yang berpartisipasi dalam proyek open source
- Documenso: alternatif DocuSign open source yang bertujuan membangun kepercayaan melalui self-hosting dan peninjauan cara kerja internal
- Erxes: alternatif HubSpot open source yang memungkinkan pembuatan pengalaman untuk berbagai jenis bisnis melalui satu XOS
- Formbricks: memungkinkan pengiriman survei ke kelompok pengguna yang tersegmentasi di titik mana pun dalam perjalanan pengguna, serta mengumpulkan hingga 6x lebih banyak insight lewat micro-survey bertarget
- Forward Email: layanan email forwarding gratis untuk domain kustom yang telah digunakan kreator, pengembang, dan perusahaan selama lebih dari 6 tahun
- GitWonk: alat dokumentasi teknis open source yang dirancang dan dibangun dengan fokus pada pengalaman pengembang
- Hanko: alat autentikasi dan manajemen pengguna open source untuk era passkey, yang dapat diintegrasikan ke aplikasi web dan mobile hanya dalam beberapa menit
- Infisical: platform open source dengan enkripsi end-to-end untuk mengelola secret dan konfigurasi secara aman di seluruh tim, perangkat, dan infrastruktur
- Novu: infrastruktur notifikasi open source untuk pengembang yang menyediakan komponen dan API untuk mengelola semua saluran komunikasi di satu tempat
- OpenBB: mendemokratisasi riset investasi melalui ekosistem keuangan open source, dan memungkinkan riset investasi dilakukan dari mana saja dengan OpenBB Terminal
- Sniffnet: alat pemantauan jaringan yang membantu melacak traffic internet dengan mudah
- Typebot: menyediakan blok untuk menciptakan pengalaman chat yang unik, dan dapat di-embed di mana saja dalam aplikasi untuk mengumpulkan hasil
- Webiny: CMS serverless open source tingkat enterprise yang menekankan kepemilikan data, skalabilitas, dan kustomisasi
- Webstudio: terpilih sebagai alternatif open source untuk Webflow
1 komentar
Pendapat Hacker News
Halo, seperti yang banyak dari Anda tahu, saya adalah pembuat htmx dan bisa menjawab pertanyaan terkait
Popularitas htmx naik pesat berkat video dari fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) dan seri video dari streamer Twitch populer ThePrimeagen
Bagi pembaca HN, kumpulan tulisan saya tentang htmx dan hypermedia secara umum di https://htmx.org/essays mungkin menarik, dan buku terbaru yang saya terbitkan bersama beberapa penulis tentang hypermedia, htmx, serta Hyperview untuk hypermedia mobile di https://hypermedia.systems juga layak dibaca
Tentu saja saya penggemar htmx, tetapi menurut saya inti yang lebih dalam adalah hypermedia. Ini konsep yang layak dieksplorasi meskipun Anda tidak berencana memakai htmx dalam pengembangan sehari-hari
Ada juga banyak library bagus yang berorientasi hypermedia, seperti Hotwire dari 37signals atau https://unpoly.com, favorit saya setelah htmx
Ini sangat membantu banyak developer Django
Saat membuat fitur like untuk artikel beberapa bulan lalu, sebelum htmx saya harus memanggil server JSON API dengan jQuery dan memperbarui jumlah like, tetapi dengan HTMX rasanya seperti memakai HTML biasa saja bersama logika Django
Ini termasuk yang terbaik yang pernah saya temukan sejauh ini, dan penanganan form juga sangat mudah. HTMX sangat meningkatkan baik pengalaman pengguna maupun pengalaman developer
Mengingat bahkan pada proyek yang sangat populer biasanya kontributor lama yang menangani sebagian besar kode, ini sinyal pertumbuhan yang kuat
https://devboard.gitsense.com/bigskysoftware/htmx
Sebagai catatan, ini adalah tool yang saya buat
Setelah melihat sekilas situs web dan contohnya, tampaknya respons HTTP dari server berisi markup lengkap dan berdasarkan itu status client diperbarui; dengan kata lain, penekanannya pada penulisan ulang DOM
Saya penasaran apakah htmx juga menyediakan kompromi untuk trigger khusus client atau konten yang dibuat di client
Keunggulan framework client yang berpusat pada JavaScript saat ini adalah dapat memindahkan sebanyak mungkin pekerjaan ke browser sehingga mengurangi penggunaan data dan CPU di server. Pada aplikasi berskala web, ini perbedaan besar
Saya penasaran apakah HTMX juga bisa memenuhi tujuan rekayasa seperti ini, atau apakah ini proyek dengan tujuan yang sepenuhnya berbeda. Saya paham client seperti Facebook tidak berorientasi hypermedia, tetapi bagaimanapun perbandingan akan sulit dihindari
Terasa alami, seperti mendokumentasikan dirinya sendiri, dan dirancang dengan baik. Benar-benar terasa seperti ekstensi alami dari HTML
Bagi saya, satu-satunya bagian yang hilang dari htmx adalah model komponen, tetapi bagi yang mencari hal semacam itu, tampaknya akan sangat cocok dengan Astro[1]. Astro memungkinkan Anda mendefinisikan dan memakai komponen HTML tanpa beban runtime seperti Vue atau React
[1] http://astro.build
Htmx mengingatkan saya pada Tailwind. Sebab ia pada dasarnya membuat nama atribut dan nilai yang dibaca oleh satu library saat runtime
Tidak memerlukan build frontend adalah keunggulan yang sangat besar bagi sebagian besar developer yang tidak ingin, dan tidak perlu, berurusan dengan npm dan webpack
Batas ukuran halaman tampaknya kira-kira setara aplikasi single-page kecil, dan jika terlalu besar, sepertinya bisa dipecah lagi menjadi aplikasi single-page lain
Bagian yang mungkin paling dirindukan developer React/Vue adalah sudut pandang bahwa ada satu objek untuk state global, lalu satu fungsi yang didefinisikan secara hierarkis dalam codebase komponen merendernya menjadi UI
Namun sudut pandang itu sendiri juga berat, memunculkan banyak perbedaan pendapat dan menguras emosi, serta membawa serta build frontend dan berbagai variasinya yang membingungkan
Saya belum memakainya, tetapi saya sudah menjadi penggemar berat
Kabar baik
Selama setahun terakhir saya memakai htmx dan mendapatkan hasil yang baik serta pengalaman yang memuaskan; khususnya sangat bagus saat melakukan server-side rendering dengan hiccup di Clojure
Setelah htmx dipahami, Anda hampir akan terkejut melihat betapa sederhana dan fleksibelnya ia. Sampai sulit dipercaya mengapa HTML tidak berevolusi seperti ini sebagai hypermedia
Menjadi sangat jelas bahwa pengembangan web memang seharusnya berevolusi seperti ini. Saya berharap suatu hari nanti apa yang htmx lakukan dengan JavaScript akan tertanam langsung ke dalam HTML dan klien browser
Jika Anda keliru melihat htmx sekadar sebagai turunan Angular, atau tidak memahami makna dari pengembangan arsitektur hypermedia, saya sangat menyarankan membaca tulisan-tulisan bagus di situsnya. Dengan begitu Anda akan memahami apa itu REST dan mengapa HATEOAS yang sebenarnya penting: https://htmx.org/essays/
Ada juga buku gratis: https://hypermedia.systems/
10–15 tahun lalu, alih-alih memperluas dan memperkaya hypermedia yang merupakan ide baru dan kuat dari web awal, kita mengambil jalan keliru yang mahal dengan mencoba membangun kembali klien tebal di atas web menggunakan arsitektur JSON API
Saya senang htmx ada dan cocok bagi banyak orang, tetapi dalam pekerjaan saya, itu sering kali bukan pilihan terbaik. Dan itu tidak apa-apa
Bagus bahwa web bisa tumbuh dengan beragam cara, dan kita tidak perlu melihat web sebagai sesuatu yang seharusnya berevolusi hanya ke satu arah tertentu
Kesalahan terbesar dalam pengembangan web selama kira-kira 10 tahun terakhir adalah gagasan bahwa harus ada satu jawaban yang benar
Baik Anda membuat Gmail berikutnya maupun blog statis, cargo cult di industri mengatakan semuanya harus dilakukan dengan cara yang sama, tetapi secara akal sehat tentu tidak begitu
Itu akan cukup untuk lebih dari 98% web. Untuk 1,9% sisanya, bisa memakai library JavaScript kecil
Hanya 0,1% yang tersisa yang merupakan webapp JavaScript murni
Tampaknya idenya sama: menaburkan sedikit atribut pada HTML untuk membuat kasus-kasus mudah menjadi dinamis
Banyak framework seperti Angular 1, Vue, dan lainnya bermula seperti ini, lalu setelah mendapatkan popularitas tertentu, tumbuh menjadi framework single-page app penuh karena adanya kebutuhan nyata untuk kasus-kasus yang lebih sulit
Jika harus memilih framework yang “seperti Angular 1”, saya akan memilih yang mendokumentasikan batasannya dengan jelas dan menyediakan jalur yang jelas untuk memakai framework single-page app yang matang ketika harus melewati batas tersebut. Jika ada yang tahu framework seperti itu, silakan bagikan
Saya sudah menjadi penggemar HTMX “sejak sebelum jadi keren”
Saya sangat senang melihat perhatian dan keberhasilannya belakangan ini, dan saya juga cukup menikmati ejekan bercanda serta penolakan dari kubu frontend yang percaya bahwa web diciptakan pada 2013 dan merekalah yang membangun kota itu
Sejak era Backbone.js saya sudah punya bias, dan saat itu pun saya memahami sebagian rasa sakitnya, tetapi tetap cukup skeptis
Lalu React muncul, dan ketika orang-orang muda yang penuh energi mulai membuat situs web yang sangat sederhana berisi 5 halaman menjadi mesin Rube Goldberg berbasis framework frontend, saya mencairkan chip teknologi saya dan tidak menyentuh hal-hal seperti itu
Detail implementasinya cukup berbeda, tetapi gagasan tentang aplikasi berbasis hypermedia adalah inti dari semua yang kami lakukan
Sayangnya, dalam jangka panjang kami tidak berhasil merebut hati orang-orang, dan pengembangan yang digerakkan blog—dengan kata lain cargo cult—menggantikan upaya kami
Kini popularitas HTMX tampaknya meningkat, jadi rasanya ada semacam ganjaran. Senang melihat bahwa bukan hanya kami yang berpikir dengan konsep seperti ini
Tentu saja, kalau konsepnya memang kuat, itu bisa berarti eksekusi saya yang kurang, jadi mungkin saya tidak boleh terlalu senang
Saya juga pernah mendengar band menjual gitar mereka dan membeli turntable
Saya juga pernah mendengar endpoint HTTP ditulis ulang agar mengembalikan JSON, dan itu disebut REST
Saya juga pernah mendengar band menjual turntable mereka dan membeli gitar
Saya juga pernah mendengar endpoint HTTP ditulis ulang agar mengembalikan potongan HTML template, dan itu disebut HATEOAS
Saya sedang kehilangan rasa, mendapatkannya kembali, kehilangannya, lalu mendapatkannya kembali
Namun Backbone agak longgar, dan sampai Angular muncul, rasanya belum terlalu enterprise
Bagaimanapun, alasan arus aplikasi web seperti ini populer di sekitar saya adalah karena frontend dan backend bisa dipisahkan, dan satu backend—biasanya REST/JSON—dapat melayani klien mobile dan web secara terpisah
Itulah alasan kami membuat single-page app, tetapi sekarang tampaknya hal itu terlupakan lagi
Di dunia saya, itu masuk akal untuk aplikasi di balik login. Namun “mereka” juga ingin membuat situs publik di internet seperti web shop menjadi single-page app
Itu pun bisa saya pahami. Saya pernah membuat beberapa situs web dengan Gatsby, dan navigasinya sangat cepat sekaligus tetap terindeks mesin pencari
Namun dalam beberapa kasus, kompleksitasnya makin bertambah, sampai muncul hal-hal seperti React sisi server. Untungnya saya tidak perlu menyentuhnya
Di sisi lain, saya berharap htmx, dan secara lebih umum hypermedia, diterima sebagai alat. Ia berguna, tetapi pada akhirnya hanya alat
Saya juga berharap orang-orang frontend yang sudah lama tidak memikirkan hypermedia secara mendalam menerimanya seperti itu
Saya tidak melihat kedua pendekatan itu saling eksklusif, dan saya setuju dengan konsep aplikasi web Transitional dari Rich Harris, yaitu cara mencampurkan kedua pendekatan tersebut
Hanya saja, saya menarik garis untuk meninggalkan hypermedia dan beralih ke pendekatan sisi klien yang lebih canggih di posisi yang berbeda darinya
Saya jelas berpikir begitu
Saya mulai dengan Perl pada tahun 1996, lalu mengalami hampir semua gelombang mulai dari PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL, hingga NextJS
Htmx terasa seperti cabang yang keluar dari arus itu, dan layak dipikirkan
Htmx mengajukan pertanyaan yang bagus. “Apakah kompleksitas pekerjaan Anda pada dasarnya ada di server, atau di klien?”
Pada sebagian besar situs web, kompleksitas pada dasarnya ada di server. Kebanyakan dari kita tidak sedang membuat Figma atau Google Sheets. Banyak situs web, meski sangat interaktif, hanyalah aplikasi CRUD dengan antarmuka yang enak dilihat
Framework seperti NextJS mencoba memperbaiki masalah klien yang terlalu kompleks dengan memindahkan React ke server, tetapi sering kali justru menambah kompleksitas alih-alih menguranginya
Kalau begitu, bukankah sebaiknya React dikeluarkan dari stack? Jika kliennya kompleks, Anda bisa melewati DOM dan JavaScript lalu memakai canvas dan WebAssembly yang dikompilasi. Jika servernya kompleks, Anda bisa memakai pembaruan DOM granular yang digerakkan oleh server
Masalah yang terlihat dari pendekatan ini adalah bahwa meskipun kompleksitas sebagian besar situs web ada di server, hampir selalu ada beberapa pekerjaan berkompleksitas tinggi yang harus berada di klien. Misalnya pengeditan gambar, pengurutan・pemfilteran・perhitungan real-time, serta gestur drag・touch
Dibutuhkan pendekatan hibrida. Sekadar kompatibel saja tidak cukup. htmx dan React memang bisa dipakai di halaman web yang sama, tetapi harus diisolasi satu sama lain. Yang saya inginkan bukan isolasi, melainkan integrasi yang mendasar
Framework ideal harus mendukung pembaruan granular yang reaktif terhadap DOM, sekaligus terintegrasi erat dengan WebAssembly terkompilasi yang menangani pekerjaan klien yang kompleks
Saya ingin menulis semua kode dalam bahasa yang kuat, bukan JavaScript. Debugger harus menangani server dan klien sekaligus, dan perbedaan di antara keduanya harus hilang. Ini harus benar-benar pengembangan full-stack, yaitu aplikasi satu stack
Clojure + ClojureScript terlihat mendekati aplikasi satu stack, tetapi hanya di permukaan
Jika ada killer framework untuk Common Lisp, rasanya itu akan sangat cocok untuk aplikasi satu stack
Pendekatan hibrida adalah pendekatan islands yang diklaim Astro: https://docs.astro.build/en/concepts/islands/
Pendekatan ini cocok dengan htmx dan kawan-kawannya, dan di proyek htmx kami menggunakannya bersama vanilla JavaScript sederhana pada bagian-bagian yang membutuhkan interaksi
Untuk proyek kecil・menengah dan tim kecil, ini bisa jadi sudah cukup. Rasanya benar-benar menyegarkan ketika bisa membuka developer tools, menunjuk sebagian halaman, lalu memahami seluruh bagian itu hanya dengan melihat HTML dan potongan JS kecil
Baik di server maupun klien, Anda menulis kode dengan cara yang sama menggunakan C#. Saat pemuatan halaman pertama, semuanya dirender di sisi server, lalu setelah itu WebAssembly secara bertahap mengambil alih dan mulai memuat kode C# di klien untuk mempercepat interaksi UI yang tidak memerlukan data server
Ini bekerja dengan baik, tetapi tantangan saat ini adalah mengurangi ukuran file WebAssembly. Sekarang ukurannya masih beberapa MB
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Selamat. Membuat proyek kecil dengan Htmx memang menyenangkan, tetapi pada akhirnya saya banyak memakai openlayers, jadi saya memilih yang lain
Library peta terkenal berat di JavaScript sisi klien, dan untuk pekerjaan itu Svelte adalah alat yang lebih baik
Saya berencana memakainya lagi di proyek Golang ke depan dan ingin mengikuti perkembangannya
Jika aplikasi Anda membutuhkan frontend yang sederhana atau dengan kompleksitas sedang, terutama jika sudah memakai fragmen template[0], saya sangat menyarankan untuk mencoba HTMX. Bahkan dari sudut pandang orang yang datang dari dunia JavaScript, bekerja dengannya cukup menyenangkan
Dan pengelola akun Twitter[1]-nya benar-benar lucu
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
Sulit menganggap htmx secara serius sebagai alat untuk membangun aplikasi web atau situs modern. Rasanya htmx membuat fitur-fitur yang sudah diharapkan pengguna menjadi mustahil dibuat
Misalnya faceted search yang memfilter tanggal sebelum·di antara·sesudah, tetapi hanya menampilkan filter saat pengguna menginginkannya, atau fitur untuk mengubah tampilan hasil ke kolom lain, peta, atau view yang digambar di canvas seperti chart
Sebagian mungkin bisa dilakukan dengan htmx, tetapi pada titik tertentu akhirnya Anda akan membutuhkan JSON
Angular juga bisa melakukan hal-hal seperti ini, dan jika memakai sesuatu seperti SolidJS, pembuatannya sebenarnya cukup menyenangkan
JSON API bisa digunakan ulang oleh aplikasi lain, tetapi htmx terasa seperti seseorang menciptakan ulang Thymeleaf
Saya juga berpikir begitu, tetapi video itu membahas secara konkret bagaimana faceted search diimplementasikan dengan htmx
Bagian kedua mungkin akan ditangani dengan menulis JavaScript langsung atau memakai hyperscript
Kita baru tahu apakah itu pendekatan yang baik setelah benar-benar membangunnya dan memakainya secara intensif, tetapi jelas ada skenario yang terasa cocok
Poin tentang JSON API itu valid. Jika Anda membutuhkan API publik, itu harus masuk dalam pengambilan keputusan. Namun tidak semua proyek memiliki batasan seperti itu
Smartphone pun tidak punya masalah mencari di tabel seribu baris
Dalam kasus seperti ini, saya akan memberi pengguna cakupan data yang luas lewat htmx, lalu mengizinkan filtering real-time yang lebih detail berikutnya dengan JS
Jika ingin data yang awalnya tidak ditampilkan juga bisa dicari, kirimkan sekaligus dengan class CSS tersembunyi, lalu hapus class itu saat ditemukan dalam pencarian
Seperti teknologi lain, htmx sangat cocok untuk kumpulan masalah tertentu. Tidak apa-apa selama kita tidak memaksanya melakukan trik yang memang tidak dikuasainya
Hal seperti ini cukup kompleks sampai memerlukan scripting penuh dalam kadar tertentu, dan saya sendiri tidak menentangnya
https://htmx.org/essays/hypermedia-friendly-scripting/
Berkat lika-liku karier saya, saya hampir melewatkan perang framework JavaScript frontend, jadi menyenangkan melihat HTML lama biasa kembali dengan kemampuan yang lebih kuat
Ini adalah kemunduran dari sisi degradasi progresif
Menurut saya perlu ada contoh mengesankan yang dibuat dengan htmx. Akan bagus jika ada contoh “made with htmx” yang merintis jenis pengalaman web baru
Orang-orang menstereotipkan htmx untuk use case sederhana yang tidak sampai perlu mengeluarkan “senjata serius”
Ada benarnya sampai taraf tertentu, tetapi itu membatasi. Pendekatan kembali ke server yang terkait dengan htmx adalah kategori tersendiri yang belum sempat dieksplorasi lebih awal karena berbagai alasan
HTMX adalah tentang menghidupkan kembali kategori aplikasi lama dengan cara yang tidak bergantung pada backend
Ia tidak melakukan sesuatu yang baru atau yang cukup untuk membenarkan “kategori aplikasi baru”
Ini adalah cara membuat hypermedia, yaitu situs yang berpusat pada konten seperti katalog belanja, forum, frontend admin, dan blog
Mirip dengan jquery/liveview/turbolinks, tetapi tidak bergantung pada backend dan tidak perlu memelihara banyak, atau bahkan sama sekali, logika JS frontend
Jika Anda membutuhkan interaksi berat seperti Google Docs atau Figma, manfaat yang diberikan htmx jauh berkurang
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Ini adalah frontend e-commerce yang ditulis dengan HTMX dan Hyperscript
https://www.makaron.cz/
Frontend TodoMVC HTMX bisa saja dibuat, tetapi backend-nya memakai apa? Go, C#, Rust, dan beberapa pilihan lain terasa alami, tetapi selalu tergantung konteks
Saya menyebut C# karena ASP.Net MVC + Razor tampak sangat rapi cocok dengan paradigma HTMX
Saya tidak ada hubungan apa pun dengan mereka, tetapi situs ini dibuat dengan htmx dan sebagian JS untuk fungsi yang lebih kompleks
Mengingat htmx secara eksplisit bertujuan memperluas pendekatan lama yang baik, saya tidak yakin apakah ia bisa memberikan “jenis pengalaman web baru”
Awalnya htmx terlihat bagus, tetapi ketika Anda mencoba membuat sesuatu yang biasanya layak memakai JavaScript—baik vanilla maupun framework—seperti tombol dropdown, pada akhirnya Anda akan mempertimbangkan hyperscript
Lalu ketika melihat contohnya, tampilan seperti ada kalimat di dalam kode terasa tidak menyenangkan, sehingga Anda beralih ke yang lain
Mungkin kita perlu mencoba memakai htmx tanpa hyperscript, atau mungkin perlu memberi hyperscript lebih banyak waktu
Namun jika membayangkan sesuatu yang harus dipelihara selama beberapa tahun, rasanya terlalu asing, dan saya tidak ingin terikat padanya jika nanti tidak akan pernah memakainya lagi
Dari sisi htmx, ia sama sekali tidak peduli alat interaksi sisi klien apa yang digunakan, jadi itu masalah terpisah dari apakah htmx berguna atau tidak
Secara pribadi, jika ingin menyingkirkan alat build JS dan semacamnya, saya akan memilih htmx + Alpine.js
Bagaimana cara menanganinya ketika skalanya membesar dan menjadi kompleks?
Saya pernah membantu aplikasi yang memakai htmx, dan ada dua masalah. Saya penasaran apakah ada yang punya pengalaman serupa, apakah ini masalah karena teknologinya dipakai dengan keliru, atau apakah sedang ada upaya untuk mengatasinya
Pertama, diperlukan banyak middleware kustom di controller untuk menentukan apakah endpoint harus mengembalikan HTML halaman penuh atau hanya fragmen yang dibutuhkan htmx
Dari sisi htmx tampaknya sederhana, tetapi mungkin ini bagian yang harus dibuat ulang oleh setiap proyek yang memakai htmx
Kedua, diperlukan pencatatan/koordinasi di sekitar
hx-trigger. Ketika UI menjadi kompleks, banyak elemen harus bereaksi terhadap perubahan eksternalAlih-alih membaca suatu state dan berharap framework menjadwalkan update, kami harus mengelola sendiri daftar event yang perlu direspons
Apakah ada yang merasakan hal serupa?