7 poin oleh GN⁺ 2024-10-10 | 12 komentar | Bagikan ke WhatsApp
  • 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

 
felizgeek 2024-10-10

Perhatian lebih baik daripada ketidakpedulian~ Saya suka HTMX. Termasuk filosofinya.
Mirip sekali dengan SQLite dari segi nuansanya wkwk

 
savvykang 2024-10-13

Apa kesamaan antara SQLite dan HTMX?

 
aer0700 2024-10-12

Mirip seperti Sqlite?

 
halfenif 2024-10-11

Komentarnya mendalam. Filsafat ya..

 
[Komentar ini disembunyikan.]
 
savvykang 2024-10-10

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.

 
heycalmdown 2024-10-10

Tulisan ini sepertinya bukan ditulis di Korea.

 
ndrgrd 2024-10-10

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.

 
roxie 2024-10-11

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.

 
rlrsbtm80879 2024-10-10

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.

 
ndrgrd 2024-10-10

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.

 
GN⁺ 2024-10-10
Opini Hacker News
  • Pendapat tentang pewarisan atribut terbagi. Dapat dinonaktifkan dengan opsi htmx.config.disableInheritance

    • State di sisi klien dan penggantian oleh htmx tidak selalu cocok. Terutama untuk kasus sederhana
    • Event memang kuat, tetapi kompleks dan sulit di-debug. Ini adalah sifat pemrograman berbasis event
    • Tidak setuju dengan mode antrean default. Alih-alih membatalkan dan mengganti permintaan yang ada, mode ini mempertahankan permintaan saat ini dan hanya mengantrekan satu permintaan tambahan
    • Promosi mug untuk orang-orang yang tidak menyukai htmx
  • Alasan tidak terjun ke frontend adalah karena pilihannya terlalu banyak, kritiknya juga banyak, dan tren teknologinya sering berubah

    • Pemrograman backend dan sistem juga punya banyak perbedaan pendapat, tetapi tidak sekacau frontend
  • Sedang membangun storefront berperforma baik menggunakan HTMX, dan hasilnya memuaskan

    • Peritel pakaian besar di Brasil menggunakan HTMX dan strategi partial rendering
  • Ide "HTMX in React" pada dasarnya seperti menciptakan ulang React Server Components

    • Server mengirim JSON lalu React mengubahnya menjadi komponen virtual DOM
    • Ini dapat menyelesaikan masalah state komponen, dan memungkinkan penggunaan komponen React tanpa bridge khusus
    • Bisa menggunakan library web fetching yang terhubung dengan React, serta menghindari pilihan antrean milik HTMX
    • Bisa mengatasi masalah morphdom dan masalah elemen input DOM di browser
    • RSC masih eksperimental, dan implementasi dasarnya mengasumsikan JS dijalankan di server
  • Tidak setuju dengan pendapat bahwa mode antrean default itu tidak rasional

    • Jika pengguna mengirim input, lalu mengubahnya di tengah jalan dan mengirim lagi, maka permintaan sebelumnya memang harus dibatalkan
    • Jika respons mengganti konten dengan ID yang berbeda, respons kedua tidak bisa melakukan penggantian yang sama
  • Kesan setelah pertama kali menggunakan HTMX: mudah diterapkan untuk pekerjaan sederhana dan terasa menyenangkan

    • Masih belum yakin apakah akan menggunakannya untuk proyek yang kompleks
  • Setelah membaca keluhan tentang state, terasa bahwa penulisnya mungkin belum pernah membuat situs web sebelum era React

    • Contohnya tidak terasa masuk akal, dan tampaknya dia kecewa karena mencoba memakai htmx seperti React tetapi hasilnya tidak sesuai harapan
  • Bertanya-tanya apakah HTMX memiliki fitur seperti Turbo Mount

    • Menganggap itu salah satu cara terbaik menggunakan Hotwire/Turbo
  • Ingin tahu lebih jauh tentang masalah morphdom yang terkadang menimpa sebagian elemen secara tak terduga

    • Menjaga state elemen input dan elemen detail adalah salah satu fungsi utama library seperti morphdom