Alasan Gumroad Tidak Memilih htmx

 (htmx.org)
6 poin oleh GN⁺ 2024-10-04 | 1 komentar | Bagikan ke WhatsApp
  • Gumroad meninjau htmx untuk proyek baru Helper dengan harapan frontend yang ringan, tetapi beralih ke React/Next.js ketika kebutuhan UX yang kompleks makin besar
  • htmx tampak menjanjikan untuk interaksi sederhana, tetapi pada formulir dengan validasi dinamis dan field kondisional, logika sisi server menjadi bertele-tele sehingga alur pengembangan terasa tidak alami
  • Drag-and-drop pada workflow builder, kolaborasi real-time, pengelolaan state yang kompleks, dan pembuatan formulir dinamis lebih langsung diimplementasikan dalam ekosistem React dan model komponennya
  • Dukungan materi pemecahan masalah dan alat AI lebih melimpah di sisi Next.js dan React, sementara htmx dirugikan dalam kecepatan pengembangan karena minimnya data pembelajaran open source
  • htmx bisa cocok untuk aplikasi server-rendered yang sudah ada atau model interaksi sederhana, tetapi untuk antarmuka yang kaya state seperti Helper, React dan Next.js lebih sesuai

Latar belakang meninjau htmx di Helper

  • Gumroad mulai mempertimbangkan htmx sebagai kandidat frontend saat memulai proyek baru Helper
  • Harapan awal muncul dari pengalaman sebelumnya bahwa React terasa lebih berat dari yang dibutuhkan, dan mereka melihat htmx sebagai cara untuk menambahkan interaksi sederhana secara ringan
  • Di dalam tim, ada juga penilaian bahwa htmx mirip meme yang menyindir ekosistem JavaScript yang makin rumit
    • Seperti Tailwind yang terlihat seperti sintaks lain untuk CSS inline, htmx juga dipandang lebih mirip sintaks lain untuk JavaScript inline
  • Tailwind mendapatkan tempat dalam sistem tooling Gumroad, tetapi htmx tidak berkembang sesuai tujuan Helper dan tidak menghasilkan pengalaman pengguna terbaik bagi pelanggan

Titik di mana React/Next.js terasa lebih alami

  • Pengalaman pengembangan dan penanganan formulir

    • Implementasi yang benar tetap mungkin dilakukan dengan htmx, tetapi Gumroad merasa proses membuat fitur bekerja di Next.js lebih intuitif
    • Pada formulir kompleks dengan validasi dinamis dan field kondisional, pekerjaan sisi klien di React lebih sederhana, sedangkan di htmx logika sisi server menjadi panjang

  • Batasan UX dan interaksi

    • htmx cenderung mendorong aplikasi ke pola Rails/CRUD, sehingga pengalaman dasarnya mudah menjadi biasa atau generik
    • Antarmuka drag-and-drop pada workflow builder membutuhkan implementasi akal-akalan di htmx, dan terasa lebih kasar dibanding pengalaman mulus yang didapat dari library React

  • Alat AI dan kecepatan pemecahan masalah

    • Alat AI lebih akrab dengan Next.js, tetapi kurang akrab dengan htmx; salah satu alasannya adalah minimnya data pembelajaran open source
    • Materi di sisi React/Next.js lebih kaya, sehingga saat masalah muncul, solusi bisa ditemukan lebih cepat

  • Kompleksitas dan skalabilitas

    • Semakin kompleks proyeknya, kesederhanaan htmx makin terasa sebagai batasan ketimbang keunggulan
    • Saat kolaborasi real-time dan visualisasi data yang kompleks ditambahkan, pendekatan berpusat pada server di htmx membuat pengelolaan state di antara berbagai komponen makin sulit

Perbedaan yang terlihat pada tiap fitur Helper

  • Drag-and-drop: react-beautiful-dnd dalam ekosistem React menyediakan drag-and-drop yang mulus dan aksesibel dengan sedikit konfigurasi
  • Pengelolaan state yang kompleks: Untuk mencerminkan konfigurasi dan logika kondisi tiap langkah workflow ke UI secara real-time, pendekatan state management React seperti useState atau Redux terasa lebih langsung
  • Pembuatan formulir dinamis: Membuat formulir pengaturan berbeda untuk tiap jenis langkah dan mengubahnya berdasarkan input pengguna lebih intuitif ditangani dalam model komponen React
  • Kolaborasi real-time: Fitur beberapa pengguna mengedit workflow secara bersamaan relatif lebih langsung diimplementasikan dengan WebSockets dan React, sedangkan di htmx dibutuhkan logika sisi server yang lebih rumit serta JavaScript kustom
  • Optimisasi performa: Saat workflow makin besar dan kompleks, rendering bisa dioptimalkan lebih rinci di React dengan virtual DOM dan hook seperti useMemo serta useCallback

Ekosistem dan keputusan akhir

  • Ekosistem React/Next.js besar dan matang, sehingga menyediakan solusi untuk hampir semua masalah yang dihadapi Gumroad
  • Di htmx, sering kali mereka harus berkompromi pada fitur atau membangunnya ulang sendiri, dan dalam integrasi layanan serta library pihak ketiga pun ada kasus di mana React punya binding tetapi htmx tidak punya padanannya
  • Setelah berpindah ke React/Next.js, Gumroad menilai itu pilihan yang lebih cocok untuk membangun UX yang kompleks
    • Mereka bisa bergerak lebih cepat, membuat pengalaman pengguna yang lebih imersif, dan memanfaatkan tool serta library yang sudah ada
    • Pengalaman pengguna aplikasi untuk pelanggan inti Helper juga dapat ditingkatkan secara signifikan
  • Batasan htmx bukan berarti mustahil diatasi, tetapi proses mengatasinya membuat mereka menjauh dari kekuatan utama htmx dan bergerak ke solusi yang lebih alami di lingkungan yang berpusat pada JavaScript
  • htmx bisa menjadi pilihan yang baik untuk model interaksi sederhana atau proyek yang dibangun di atas aplikasi server-rendered yang sudah ada
  • Untuk antarmuka yang kompleks dan kaya state seperti Helper, React dan Next.js lebih tepat, dan Gumroad menilai mereka bisa terus mengevaluasi ulang tech stack seiring perubahan kebutuhan dan teknologi baru

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-04
Komentar Hacker News

  • Ini sesuatu yang pernah saya tulis di thread lain: CEO Gumroad mengatakan di Twitter bahwa ia sempat mencoba htmx untuk sebuah proyek, tetapi akhirnya memilih NextJS.
    Saya sedang mencari kisah pengalaman negatif yang cukup thoughtful untuk dimuat di situs web htmx, jadi saya bertanya apakah ia bersedia menuliskan pengalamannya, dan saya berterima kasih karena ia dengan senang hati setuju.

    • Sikap yang secara langsung menunjukkan titik-titik di mana htmx mungkin tidak selalu menjadi pilihan terbaik membuat saya makin menghormati proyek ini.
      Ini terasa menyegarkan dibanding proyek-proyek lain yang mengklaim diri sebagai solusi terbaik untuk segala hal.
      Saya terutama penasaran dengan catatan soal drag-and-drop: apakah itu memang dianggap sangat sulit di htmx, dan kalau begitu apakah ada rencana untuk mengatasinya.
    • CEO Gumroad juga mengatakan bahwa Rails itu sendiri adalah technical debt, dan ketika ditanya alasannya, ia hanya menjawab bahwa React jauh lebih baik.
      Padahal bukan berarti Rails dan React tidak bisa dipakai bersama.
      Menurut saya tulisan itu sendiri bukan terlalu tentang pengalaman negatif dengan htmx, melainkan bahwa begitu drag-and-drop dan kolaborasi real-time muncul, mungkin pilihan untuk bereksperimen dengan htmx sejak awal memang keliru.
      Saya juga tidak begitu paham apa yang ingin ditunjukkan screenshot-nya, tetapi tetap saja menurut saya ini tulisan yang bagus untuk dimuat di situs web htmx.
    • Menunjukkan titik-titik di mana htmx bisa kurang cocok dibanding alat lain patut dihargai.
      Bagi saya, htmx lebih dekat sebagai pengganti jQuery daripada pengganti React.
      htmx dan jQuery menambahkan interaksi ke dokumen, sedangkan React berusaha menjadi keseluruhan dokumen.
      Alat yang dipakai harus berbeda sesuai pekerjaannya.
    • Setelah melihat tulisan yang ditautkan dan https://htmx.org/essays/htmx-sucks/, saya jadi memutuskan tidak akan memakai htmx atau merekomendasikannya kepada orang lain.
    • Thread lainnya adalah https://news.ycombinator.com/item?id=41727315.

  • Bagian “AI dan dukungan tooling: worth noting juga bahwa tool AI sangat familier dengan Next.js, tetapi tidak terlalu familier dengan htmx” ditulis dengan datar seolah itu kekurangan biasa, tetapi ini pertanda yang cukup menyeramkan bagi masa depan tool pengembangan, library, framework, dan bahasa.
    Prediksi saya, model bahasa besar akan makin memperkuat efek winner-takes-all dan keuntungan sebagai penggerak awal yang sudah ada, dan berkat data pelatihan yang lebih banyak serta lebih baik, penggunaan tool open source juga akan makin terdorong.

    • Masalah AI dan dukungan tooling sebenarnya adalah perpanjangan dari masalah komunitas dan ekosistem.
      Bahkan sebelum model bahasa besar, React sudah punya keunggulan karena sebagian besar pertanyaan sudah ada di StackOverflow, dan ada library matang untuk hampir setiap keperluan.
      Sekarang hanya ada orang yang menanyakan ke model bahasa besar pertanyaan yang dulu akan mereka tanyakan di StackOverflow, dan hasilnya sama.
      Kalau memakai sesuatu yang banyak dipakai orang lain, ada keuntungannya.
    • Bahwa model bahasa besar memperkuat efek winner-takes-all dan keuntungan sebagai penggerak awal pada tool pengembangan mungkin benar bagi orang yang bergantung pada model bahasa besar untuk coding.
      Namun saya sangat yakin itu bukan taruhan yang bagus sebagai strategi jangka panjang untuk karier software engineer.
    • Tool AI terkunci pada titik waktu tertentu, dan meskipun dilatih dengan materi baru, jumlah informasi yang bisa dipelajari tetap terbatas.
      Saya sempat berpikir bahwa ini justru bisa menjadi hal yang baik.
      Industri software menghabiskan terlalu banyak waktu mengejar tool, fitur bahasa, dan framework terbaru.
      Sedikit stagnasi, lalu menyelesaikan pekerjaan dengan alat yang sudah dimiliki alih-alih membuat palu baru setiap 6 bulan, mungkin bisa menjadi hal positif.
    • Kalau seorang developer tidak bisa bekerja tanpa sesuatu yang menuliskan kodenya untuknya, saya tidak tahu mengapa ia direkrut sejak awal.
    • Saya tidak terlalu mengkhawatirkan hal ini, dan kekhawatiran Gumroad mungkin saja dilebih-lebihkan.
      Dari komentarnya saja tidak jelas apakah ini benar-benar pengalaman AI yang tidak bisa menangani HTMX dengan baik, atau bergeser menjadi cerita tentang kurangnya materi lain.
      Model bahasa besar sering kali bekerja sangat baik seperti penerjemah umum.
      Jika ia memahami pola dan konsep umum dari framework populer, serta cukup tahu sintaks framework yang lebih kecil, berdasarkan pengalaman ia juga bisa menghasilkan kode framework niche yang cukup bagus.
      Mirip seperti bajak laut bisa membicarakan topik yang tidak pernah mereka sebutkan dalam data pelatihan, tetapi dengan gaya bicara bajak laut.

  • Bagian “Saat membuat form kompleks dengan validasi dinamis dan field kondisional, kami akhirnya menulis logika sisi server yang rumit untuk menangani sesuatu yang di React akan menjadi pekerjaan sisi klien yang sederhana” membuat saya teringat meme Anakin Padme.
    “Tapi kalian tetap mengimplementasikan validasi sisi server juga, kan… kan?”

    • Kalau form web lebih kompleks daripada formulir kertas, mungkin form web itu sendiri perlu dipikirkan ulang.
      Saya sulit membayangkan form yang mudah di React tetapi sulit di htmx, kecuali jika yang diinginkan adalah memasukkan state aplikasi global ala React lalu menyelesaikan 90% dengan library.
    • Validasi juga dilakukan di server.
      Hanya saja dilakukan sekali saat submit, bukan per halaman.

  • Berbeda dengan pernyataan “kami pikir htmx bisa menjadi solusi bagus untuk menjaga frontend tetap sangat ringan”, tampaknya begitu mereka meninggalkan frontend ringan, htmx jadi tidak lagi cocok.
    Mereka mulai memakai library pihak ketiga untuk merender UI/UX dan manajemen state yang kompleks.
    Selain itu, mengatakan “melakukan X lebih mudah di React” bukan perbandingan yang adil jika itu dilakukan dengan library pihak ketiga.
    Anda tidak perlu melakukannya sendiri hanya karena ada orang lain yang melakukannya untuk Anda.
    Saya banyak sepakat dengan tulisan itu, tetapi jika sejak awal sudah tahu membutuhkan state dan rendering yang kompleks, menurut saya htmx memang bukan solusi yang baik sejak awal.

    • Saya rasa tepat sekali begitu.
      Saya suka htmx, tetapi tulisan ini menunjukkan bahwa penulisnya punya pemahaman teknis yang cukup kurang.
      Ini bukan soal kelebihan dan kekurangan yang akan terlihat hanya dengan sedikit mengenal platform web dan dokumentasi htmx.org, melainkan lebih terlihat seperti ingin mencoba HTMX karena suasananya sedang ramai.
    • Ini menjadi simetri yang bagus dengan tulisan orang-orang yang sejak awal seharusnya tidak memakai React, lalu menulis “setelah mengganti aplikasi React dengan htmx, semuanya jadi jauh lebih baik”.
    • Dikotomi htmx versus JavaScript mengingatkan saya pada tes behavior-driven development di behave versus tes pytest.
      Bahasa Gherkin tampak bagus untuk kasus sederhana dan pada prinsipnya bisa diperluas untuk kasus kompleks, tetapi semakin banyak lapisan tingkat abstraksi yang harus dikelola, pytest yang berupa Python murni menjadi lebih nyaman.
    • Saya juga berpikir persis sama.
      Cakupan proyeknya sama sekali tidak “sederhana”, dan kalau saya, saya akan langsung memilih React.
    • Dari deskripsi fitur yang diinginkan saja sudah terlihat bahwa JavaScript berat memang akan diperlukan.

  • Terkait bagian yang mengatakan bahwa “implementasi antarmuka drag-and-drop untuk workflow builder merupakan tantangan besar di htmx, dan membutuhkan workaround yang canggung dibandingkan pengalaman mulus yang bisa diperoleh dengan library React”, HTMX lebih cocok saat hanya melakukan sebanyak yang diperlukan untuk frontend bundle, dan tidak lebih dari itu
    Cukup kaitkan ke event htmx.onLoad, lalu di dalam konten yang dimuat cari dan pasang markup yang diberi atribut, misalnya columns, cards, tasks, dan sebagainya
    Misalnya, Anda bisa mengikat sortable.js ke markup yang sudah dirender, lalu menghubungkan event sortable ke pembaruan state melalui HTMX
    Cukup sederhana, dan dokumentasinya juga punya contoh yang persis seperti ini: https://htmx.org/docs/#3rd-party

    • Saya menggunakan HTMX bersama komponen UIKit
      Situs web modern, stateful, dan dinamis sama sekali tidak bertentangan dengan HTMX

  • Kalau membaca artikelnya, tim ini tampak lebih terbiasa dengan pengembangan frontend daripada pengembangan backend
    Dari sudut pandang developer gaya lama, kadang terlihat sedikit ketakutan dan salah paham dalam cara berpikir developer frontend
    Sejujurnya, menurut saya hanya perlu sedikit menyesuaikan pola pikir untuk memahami bagaimana pendekatan ini bekerja, tetapi saya juga paham bahwa banyak orang sepanjang kariernya belum pernah melihat pendekatan klien/server yang umum
    Meski begitu, nilai komponen React siap pakai serta kemudahan menemukan dokumentasi dan bantuan memang tidak bisa diabaikan

    • Saya rasa bukan hanya developer, tetapi UX designer yang berpikir ala React juga menjadi hambatan terbesar dalam adopsi htmx
      Satu generasi designer telah merancang mobile dan web dengan cara yang sangat mirip, lalu melemparkan kompleksitas implementasinya kepada developer
      Namun web seharusnya, dan boleh saja, berbeda dari mobile jika memungkinkan
      Di artikel itu dikatakan desainnya terlalu “generic” seperti aplikasi CRUD, tetapi apakah itu benar-benar buruk?
      Kita punya pencapaian besar berupa model dokumen yang diadopsi secara luas sehingga pengalaman pengguna bisa dibuat dapat diprediksi di semua situs, tetapi kita hanya melihatnya sebagai “membosankan”
      Seolah-olah kebosanan itu sendiri punya masalah intrinsik
      Saya memahami tekanan pasar yang menuntut pengalaman unik dan bermerek yang terasa seperti aplikasi mobile, tetapi saya jadi membayangkan bagaimana jadinya jika para designer juga bisa berpikir ala WWW seperti mereka berpikir ala React

  • Saya suka bahwa HTMX memuat artikel ini dan artikel-artikel serupa di situsnya sendiri
    Tampaknya ada cukup banyak alasan masuk akal mengapa HTMX saja tidak cocok untuk mereka
    Saya bukan spesialis frontend, tetapi ada beberapa pemikiran
    Pertama, bukankah validasi form tetap harus dilakukan di backend juga?
    Saya penasaran mengapa begitu sulit bagi sistem backend untuk menyampaikan hasilnya ke frontend
    Dalam banyak kasus ada alasan bagus untuk melakukan validasi form di frontend dan backend, jadi dalam situasi seperti itu HTMX saja mungkin tidak cukup, tetapi cara masalah ini disampaikan agak membingungkan
    Kedua, jika hanya memakai HTMX, aplikasi memang bisa terdorong ke arah seperti ini sampai batas tertentu, dan dalam beberapa kasus itu hal yang baik, tetapi mereka tampaknya menilai bahwa untuk pelanggan mereka diperlukan cara lain
    Ketiga, saya ingin tahu lebih banyak bagaimana tim ini menggunakan alat AI sampai ketergantungan pada alat AI menjadi masalah utama
    Jika alat pengembangan AI menjadi penting ke depannya, pertanyaan menariknya adalah apakah standar untuk mendapatkan tooling dan integrasi yang cukup agar framework atau bahasa pemrograman baru bisa diadopsi akan menjadi terlalu tinggi
    Keempat, seperti keluhan umum terhadap HTMX, sebagian proyek memang membutuhkan lebih dari yang disediakan HTMX
    Kelima, salah satu alasan saya menyukai Django dan Python juga karena komunitas, integrasi, dan ekosistem add-on yang mendalam
    Sesuatu seperti https://unpoly.com/, yang konsepnya mirip tetapi fiturnya lebih banyak daripada HTMX, mungkin lebih cocok untuk mereka

  • Terkait pernyataan “proses pengembangan Next.js terasa alami”, saya tidak tahu bagian mana dari sintaks ReactJS ini yang terasa alami
    Bisa saja terasa familier, tetapi tidak alami
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • Sejauh yang saya tahu, HTMX tidak punya solusi elegan untuk timer dan interval
      Pada akhirnya kemungkinan harus disambungkan secara canggung dengan JavaScript
    • Contoh kode ini sebenarnya cukup lunak
      Jika menginginkan custom hook dengan timeout yang bisa berubah-ubah, itu bisa menjadi jauh lebih rumit
      Dan juga harus menulis artikel panjang tentang topik ini: https://overreacted.io/making-setinterval-declarative-with-r...
    • Saya penasaran kode seperti apa yang tampak alami untuk use case ini
      Bisakah Anda menuliskan kodenya?

  • Patut dipuji bahwa htmx.org menjadi host untuk artikel ini

    • Saya rasa sangat bernilai ketika suatu layanan atau alat menjelaskan bukan hanya mengapa harus digunakan, tetapi juga mengapa tidak harus digunakan
    • Memuat artikel seperti ini adalah sikap yang benar-benar rendah hati dan jujur
      Pada akhirnya, kalau seseorang mencoba htmx lalu marah karena kebutuhannya tidak terpenuhi, sekarang ada materi yang bisa dirujuk
    • Ditautkan di bawah “On The Other Hand…” pada https://htmx.org/essays/
    • Awalnya saya memperkirakan semacam rant atau tulisan sarkastik, tetapi ternyata ini artikel bagus dengan poin-poin yang bagus, jadi saya senang
      Saya memakai htmx di beberapa proyek saya dan hasilnya cukup baik
      Artikel seperti ini justru membuat saya lebih yakin menggunakan htmx, karena jarang ada tulisan yang menunjukkan di mana htmx unggul dan di mana kekurangannya

  • Poin ketiga terasa menakutkan
    Saya jadi membayangkan dunia di mana perusahaan membayar agar framework mereka terwakili secara berlebihan dalam set pelatihan model, lalu menjual kontrak berdasarkan itu
    Mirip seperti optimisasi mesin pencari yang baked in ke dalam alat pengembangan