- Saya sangat menyukai ide dasar Htmx yang sederhana, tetapi setelah menggunakannya di seluruh tim, ternyata dalam praktiknya tidak sesederhana itu dan cukup kompleks
Pewarisan atribut di Htmx jelas merupakan sebuah kesalahan
- Dalam potongan kode, pewarisan atribut bersifat implisit dan mengejutkan
- Seperti di CSS, pewarisan adalah hack murah tetapi ada harganya
- Ini bertentangan dengan argumen penulis tentang localitas perilaku
- Nilai bawaan pewarisan berbeda untuk berbagai atribut (misalnya,
hx-delete tidak diwariskan tetapi hx-confirm dan hx-ext diwariskan)
- Kita harus mengingat pengecualian, dan akhirnya menuliskan semuanya secara eksplisit sehingga pewarisan menjadi tidak bermakna
Sebagian besar aplikasi web yang menarik tidak bisa begitu saja mengganti elemen DOM secara menyeluruh
- Elemen DOM hampir selalu memiliki state lokal browser (misalnya status buka/tutup pada elemen
<details>, nilai input pada elemen <input>, status buka/tutup elemen dropdown)
- Jika Htmx menggunakan pendekatan sederhana dengan langsung mengganti outerHTML, semua state itu akan hilang
- Ekstensi Morphdom juga menimpa beberapa elemen dengan cara yang berbeda dari perkiraan
Menyimpan state pada elemen DOM itu sendiri adalah ide yang buruk
- Morphdom dimaksudkan untuk mengatasi masalah pada bagian sebelumnya, tetapi ditemukan bahwa cara kerja Htmx didasarkan pada penggantian elemen secara menyeluruh
- Antrean request disimpan pada elemen DOM itu sendiri
- Saat request dimulai, elemen tersebut atau elemen lain yang merujuk kepadanya akan memiliki antrean request
- Jika elemen DOM diganti sepenuhnya, antrean di-reset sehingga beberapa mode kegagalan buruk bisa dihindari
- Namun, pada Morphdom elemen tetap dipertahankan, sehingga antreannya juga tetap ada
- Akibatnya kita berada di area perilaku tak terdefinisi yang semacam melanggar desain Htmx
Mode antrean bawaan berantakan
- Secara default, jika Htmx memicu request lain pada antrean yang sama (elemen yang sama), request yang sedang berjalan akan dibatalkan
- Itulah strategi bawaannya
- Fakta ini baru diketahui belakangan
- Ini sangat tidak intuitif dan berarti pekerjaan bisa hilang
Pemicu event tidak bersifat lokal
- Pemicu event sering membantu membuat sesuatu terjadi, tetapi efeknya tidak lokal dan memiliki masalah serupa dengan pewarisan atribut
- Jika bekerja dengan DSL di bahasa sisi server, ini bisa sedikit membantu, tetapi rasanya mirip pemrograman callback JavaScript kuno
- Saat event terjadi, kita "berlangganan" lalu melakukan sesuatu
Sulit menjaga state komponen dengan baik
- Masalah yang lebih luas, mirip dengan masalah state elemen DOM, adalah bahwa komponen buatan kita sendiri juga memiliki state-nya sendiri
- Misalnya, jika kita menginginkan halaman yang terdiri dari tiga bagian yang memiliki state sendiri yang dibutuhkan server (misalnya halaman dari kumpulan hasil), serta state yang dibutuhkan React atau WebComponents, maka muncul masalah sinkronisasi state antara komponen induk dan anak
- Htmx tidak menyediakan cara yang baik untuk ini
- Ada ide seperti memakai parameter query, input form tersembunyi, pemicu event, dan sebagainya, tetapi semuanya memiliki catatan penting yang besar
- React dan Halogen punya jawaban untuk ini
- Dalam kedua kasus, komponen anak memiliki state sendiri, dan induk dapat memberikan "props" seperti semacam "saran"
- Komponen juga memiliki state internalnya sendiri, dan bisa mengabaikan atau memprioritaskannya di atas props
- Props umumnya diberikan oleh server atau diturunkan dari server, sementara state umumnya adalah state sisi klien
- Komponen siap pakai yang disediakan oleh React, atau komponen yang harus digunakan, sering kali memang membutuhkan React
- React dan Htmx tidak berinteraksi dengan baik
- Pernah mencoba bekerja dengan WebComponents tanpa hasil yang memuaskan, dan komponen tersebut memiliki batasan aneh yang mengejutkan
- Juga pernah membuat bridge langsung ke komponen React yang digunakan di bahasa sisi server, tetapi secara umum Htmx dan React saling berebut soal alur state dan pengelolaan elemen DOM
- Sudah mencoba Alpine, dan itu bagus, tetapi tetap saja itu adalah library pemrograman sisi klien lain, sehingga menjadi duplikatif jika React sudah ada di codebase
Meski begitu, tetap ada kelebihannya
- Bisa memakai bahasa sisi server adalah keunggulan yang sangat jelas dan nyaris tak terbantahkan
- Tidak ada seorang pun di tim yang ingin menulis ulang semua business logic ini ke TypeScript
- Tidak perlu serialisasi dari tipe DB ke tipe frontend
- Tidak ada kebocoran data dan tidak perlu GraphQL
- Bisa memanfaatkan kemampuan abstraksi yang lebih kuat dari bahasa sisi server
- Alih-alih mengimplementasikan validasi yang sama di frontend dan backend, kita bisa memakai form builder dari bahasa sisi server
- Namun, kekurangan-kekurangan di atas juga nyata
Htmx-in-React?
- Arah masa depan yang menarik mungkin adalah mengimplementasikan ulang Htmx di dalam React
- Server mengirim blob JSON lalu React mengubahnya menjadi komponen virtual DOM
- Dengan begitu, masalah state komponen akan teratasi
- Tidak perlu bridge khusus untuk menggunakan komponen React
- Bisa memakai library web fetching yang terhubung dengan React, dan dengan hati-hati menghindari salah satu pilihan antrean di Htmx
- Masalah Morphdom dan masalah elemen input DOM di browser juga akan terselesaikan, karena ini pada dasarnya sudah hampir menjadi masalah yang terpecahkan di React
- Dengan cara ini, dependensi pada Htmx bisa dihilangkan sambil tetap mempertahankan manfaat idenya. Tentu saja, asalkan ada anggaran untuk memulai pekerjaan sebesar itu
Pendapat GN⁺
- Ide dasar Htmx memang menarik, tetapi dalam penggunaan nyata bisa menghadapi berbagai masalah kompleks
- Beberapa desain Htmx seperti pewarisan atribut, penggantian elemen DOM, dan mode antrean tidak intuitif dan dapat memicu perilaku yang tak terduga
- Integrasi dengan React atau WebComponents juga tampaknya tidak mudah
- Meski demikian, bisa menggunakan bahasa sisi server tetap merupakan kelebihan besar
- Ke depan, mengimplementasikan ulang Htmx berbasis React juga bisa menjadi arah yang menarik
12 komentar
Perhatian lebih baik daripada ketidakpedulian~ Saya suka HTMX. Termasuk filosofinya.
Mirip sekali dengan SQLite dari segi nuansanya wkwk
Apa kesamaan antara SQLite dan HTMX?
Mirip seperti Sqlite?
Komentarnya mendalam. Filsafat ya..
Kalau punya pengalaman mengembangkan web dengan server-side rendering & jQuery sebelum era SPA, Anda akan langsung paham bahwa ini adalah teknologi dari kubu itu. Sepertinya mereka yang mulai belajar pengembangan web lewat SPA sedang mengejar sesuatu yang baru lalu salah paham.
Tulisan ini sepertinya bukan ditulis di Korea.
Betul juga. Sepertinya ini alat yang dibuat untuk halaman sederhana, jadi saya tidak mengerti kenapa sampai muncul perdebatan dengan membawa contoh atau use case yang aneh lalu mengatakan bahwa alat ini tidak cocok untuk itu.
Seperti yang bisa dilihat dari halaman utama htmx, htmx cenderung mengambil posisi bahwa (jika hanya mereka yang ada) teknologi frontend modern termasuk React tidak diperlukan.
Itu terkait dengan alasan htmx mendapat perhatian. Tulisan ini juga merupakan terjemahan dari artikel kontribusi luar negeri, dan di luar negeri orang-orang sudah lelah dengan segala macam pengelolaan state di React. Karena itu, mereka melihat htmx—yang menawarkan fungsi serupa dengan React tetapi tidak memerlukan pengelolaan state seperti React—sebagai alternatif pengganti React. Itulah sebabnya htmx terus dibandingkan dengan React.
Yah. Kalau alasannya seperti itu, bukankah lebih tepat mengambil argumen yang mengklaim bisa menggantikan React lalu membandingkannya?
Bahkan hanya melihat fitur yang tercantum di halaman ini saja, HTMX jelas bukan sesuatu yang cocok dipakai pada halaman yang kompleks, dan sama sekali bukan sesuatu yang bisa menggantikan React.
Opini Hacker News
Pendapat tentang pewarisan atribut terbagi. Dapat dinonaktifkan dengan opsi
htmx.config.disableInheritanceAlasan tidak terjun ke frontend adalah karena pilihannya terlalu banyak, kritiknya juga banyak, dan tren teknologinya sering berubah
Sedang membangun storefront berperforma baik menggunakan HTMX, dan hasilnya memuaskan
Ide "HTMX in React" pada dasarnya seperti menciptakan ulang React Server Components
Tidak setuju dengan pendapat bahwa mode antrean default itu tidak rasional
Kesan setelah pertama kali menggunakan HTMX: mudah diterapkan untuk pekerjaan sederhana dan terasa menyenangkan
Setelah membaca keluhan tentang state, terasa bahwa penulisnya mungkin belum pernah membuat situs web sebelum era React
Bertanya-tanya apakah HTMX memiliki fitur seperti Turbo Mount
Ingin tahu lebih jauh tentang masalah morphdom yang terkadang menimpa sebagian elemen secara tak terduga