HN Memperkenalkan: HTMX Playground yang 100% Diimplementasikan di Browser

• Ini adalah code sandbox yang memungkinkan Anda langsung mulai bereksperimen dengan HTMX di dalam browser tanpa instalasi atau konfigurasi lokal
• server.js menangani endpoint dan rendering template, sementara permintaan HTMX dicegat oleh server tiruan di dalam browser
• Cara penanganan permintaan dan template-nya familiar bagi pengguna Django, dan juga bisa digunakan untuk eksperimen dengan library selain HTMX
• Berbagi dilakukan dengan mengekspor lewat “Copy as JSON”, lalu memasukkan raw URL Gist ke “Load Playground”
• Perlu diperhatikan tidak adanya navigasi halaman, dukungan mobile yang terbatas, serta hilangnya pembaruan status on.get("/") akibat pemuatan iframe awal

---

Sandbox HTMX yang berjalan di dalam browser

• HTMX Playground adalah code sandbox sederhana untuk bereksperimen dengan HTMX tanpa instalasi
• Menyediakan contoh-contoh yang diadaptasi dari htmx.org examples
• Anda dapat menulis kode di dalam browser dengan alur yang mirip backend
  • Mendefinisikan endpoint di dalam server.js
  • Dapat merender template secara langsung
  • Berjalan server tiruan yang mencegat permintaan keluar dari HTMX
• Penanganan permintaan dan template engine-nya berbentuk familiar bagi pengguna Django
• Proyek ini sendiri tidak terbatas hanya pada HTMX, sehingga library lain juga bisa dicoba
• Kodenya tersedia di GitHub

Cara menyimpan/berbagi dan batasan yang diketahui

• Menyimpan dan berbagi

  • Tekan “Copy as JSON” di kanan atas untuk menyalin konten
  • Unggah konten yang disalin ke Gist
  • Masukkan raw URL ke “Load Playground”
  • Setelah URL halaman diperbarui, halaman dapat dibagikan

• Batasan

  • Tidak ada navigasi halaman
  • Dukungan mobile terbatas
  • server.js dapat memiliki status, seperti pada contoh Click to Edit
  • Jika status diperbarui di view on.get("/"), pembaruan tersebut dapat hilang
    • Karena pemuatan halaman awal lebih dulu diambil di iframe terpisah sebelum memperbarui iframe di layar

• Library yang digunakan

  • Svelte
  • Ace
  • PollyJS
  • Nunjucks

[GN⁺]

Opini Hacker News

• Saya pembuat htmx; saya sangat berterima kasih karena ini dibuat, dan menurut saya ini keren sekali

  • Saya penasaran apakah ada cara memakai HTMX dengan perubahan seminimal mungkin di sisi server
    Di halaman yang sudah ada, ketika formulir diisi dan dikirim, responsnya datang sebagai satu halaman penuh. Kalau bisa memberi tahu htmx, “halaman penuh memang kembali, tetapi perbarui hanya #my-form,” sepertinya tidak perlu menambahkan percabangan seperti “kalau ini request htmx” di server
    Ini bagus untuk orang yang ingin situs tetap berfungsi tanpa JavaScript, dan beberapa fitur seperti komentar, langganan email, dan tombol suka juga bisa ditangani oleh satu endpoint backend
  • Saya penasaran apakah pernah mendengar Phoenix LiveView, dan apakah konsepnya mirip dengan htmx

• Saya sempat mempertimbangkan untuk memakai HTMX secara serius, tetapi khawatir pool developer-nya terlalu kecil sehingga perekrutan akan sulit
  Saya terbiasa dengan framework proprietary yang mirip Thymeleaf, seperti isml dari Intershop, dan belakangan berniat pindah ke stack frontend Angular karena lebih mudah merekrut developer frontend khusus
  Pendekatan seperti htmx bisa menjadi kompleks, developer tidak ingin bertarung dengan monster spaghetti, dan jika frontend hanya membuat HTML sementara backend harus menyambung semuanya, developer backend bisa menjadi bottleneck
  Saya penasaran apakah HTMX mempertimbangkan jebakan seperti ini, dan bagaimana menanganinya

  • htmx sangat intuitif untuk dipelajari, jadi kalau bukan lulusan coding bootcamp yang hanya belajar React, developer yang memahami topik ilmu komputer sungguhan sepertinya bisa produktif dalam paling lama seminggu
  • Cara menanganinya sederhana: HTMX butuh waktu belajar kurang dari setengah hari, dan kemungkinan bahkan lebih cepat
    Namun HTMX tidak menyelesaikan semua situasi; ada kalanya tetap perlu single-page app yang memakai framework JavaScript
  • Menarik menyebut Angular lalu mengatakan htmx bisa menjadi kompleks; sepertinya sudut pandangnya terhadap kompleksitas berbeda
    Framework seperti Angular memberi struktur, tetapi kompleksitasnya tetap ada, dan mungkin jauh lebih besar
    Pada akhirnya yang dibutuhkan adalah developer frontend yang memahami web stack seperti JavaScript, CSS, HTML, dan API browser dengan baik; orang seperti itu bisa memilih tool dan framework yang sesuai dengan pekerjaan, dan akan cepat mempelajari HTMX
  • Tidak ada yang lebih meyakinkan daripada keberhasilan, dan htmx menempati peringkat ke-2 kategori framework dalam JS Rising Stars 2023
    https://risingstars.js.org/2023/en#section-framework
    Tepat di belakang React dan di depan Vue, Svelte, serta Angular, jadi dari sisi itu masa depannya terlihat bagus. Namun saya memperkirakan peringkatnya akan turun setelah euforia awal mereda
    htmx cukup sederhana sehingga sebagian besar developer web bisa mempelajarinya dalam sekitar satu hari, tetapi cara pengembangannya mendorong organisasi ke arah paradigma full-stack di mana developer memiliki seluruh fitur, sehingga bukan hanya developer, PM dan arsitek juga perlu mengubah cara berpikir
    Ada juga buku online gratis: https://hypermedia.systems
    Selain dokumentasi (https://htmx.org/docs, sekitar satu jam untuk dibaca), ada tulisan-tulisan yang membahas isu filosofis dan praktis seputar htmx dan hypermedia secara umum: https://htmx.org/essays
    htmx memiliki sangat sedikit ide dasar, dan berusaha dibuat “dapat diperluas”, karena perilaku berguna seperti lazy loading pun bisa diimplementasikan dengan dua atribut: https://htmx.org/examples/lazy-load
    Pada saat yang sama, ada hook seperti event atau event filter serta fitur yang lebih mendalam, sehingga jika menggali lebih jauh, perilaku yang diinginkan bisa diimplementasikan
    Kode spaghetti selalu menjadi risiko dalam semua pengembangan perangkat lunak, dan secara pribadi saya tidak yakin library single-page app mencegah spaghetti
    Dalam htmx, lebih baik memusatkan upaya pada backend dan memecah aplikasi dengan baik menggunakan alat yang disediakan lingkungan sisi server
    Karena htmx memungkinkan memilih teknologi server apa pun, ia memberi lebih banyak pilihan dan paradigma untuk mengorganisasi logika aplikasi dibandingkan single-page app, yang karena sudah memiliki aplikasi JavaScript/TypeScript besar di frontend, cenderung ikut mendorong backend ke arah yang sama
    Di sini juga ada upaya merangkum aplikasi seperti apa yang cocok untuk htmx: https://htmx.org/essays/when-to-use-hypermedia/
    htmx adalah tool yang bagus dalam banyak kasus, tetapi tetap hanya tool, bukan solusi serba bisa untuk pengembangan web
  • Untuk perekrutan, ini lebih dekat ke melihat kemampuan backend daripada riwayat HTMX
    Anggap saja merekrut developer backend yang bisa sedikit frontend; tidak perlu ada HTMX di CV, cukup dasar-dasar seperti JavaScript
    Sebagian besar developer web memenuhi syarat itu

• Saya sudah memakai MapLibre bersama Django dan htmx, dan sepertinya perlu mengunggah contoh supaya bisa dibagikan kepada orang lain

  • Saya juga membuat sesuatu yang mirip, https://ratethispad.com, dan proses pembuatannya cukup menyenangkan
    Tidak ada yang memakainya, tetapi saya juga ingin melihat proyek itu
  • Tidak ada yang bisa saya bagikan secara publik, tetapi saya sudah bekerja dengan Django, htmx, SQLAlchemy, Plotly, dan rasanya cukup solid
  • Kalau ingin memindahkan lebih banyak contoh resmi, buat issue berisi tautannya dan bisa ditambahkan ke repositori

• Setahu saya Monaco secara desain tidak berjalan di mobile, jadi Ace dipakai di mobile
  Setidaknya begitu saat terakhir kali saya memeriksa issue GitHub
  [0] https://github.com/Microsoft/monaco-editor/issues/246

  • Monaco berjalan dengan baik di mobile, dan saya baru saja mencobanya di https://tsdiagram.com

• Apakah ini juga mendukung ActiveX?

  • Sedih rasanya menyadari bahwa saya sudah cukup tua untuk memahami lelucon ini
  • Saya jadi teringat HP Quality Center
    Versi awalnya seluruh UI berbasis ActiveX, dan saya masih ingat melihat banyak progress bar untuk memasang DLL

• Dengan Service Worker, hal seperti ini juga bisa dibuat, dan beberapa halaman bisa dibuka di tab lain untuk dijelajahi
  Sepertinya tidak terlalu sulit, dan untuk pembuatan halaman bisa memakai JavaScript murni atau apa pun yang diinginkan pengguna

• Katanya dibuat dengan Svelte; jadi di mana para puris MPA dan garpu rumputnya?

  • Saya puris MPA, tetapi saya juga sepenuhnya mengakui bahwa ada kategori aplikasi tertentu di mana single-page app adalah pilihan terbaik

• Saya suka konsep htmx dan mulai membaca bukunya hari ini, tetapi setiap kali terpikir bahwa suatu saat harus mendukung aplikasi mobile native juga, saya jadi ragu untuk menggunakannya
  Dalam kasus itu, rasanya bukan hanya frontend, tetapi sebagian besar backend juga harus ditulis ulang
  Saya tahu hyperview.org, tetapi untuk use case yang saya minati, aplikasi React Native saja tidak cukup

  • https://htmx.org/essays/splitting-your-apis/
    Cukup letakkan logika domain di luar controller

• Saya penasaran apakah ada orang yang membuat aplikasi offline dengan server virtual yang didefinisikan di dalam Service Worker dan pola request-response HTML/HTMX

  • Pertanyaan bagus
    Saya suka htmx, tetapi tidak bisa memakainya dalam situasi yang harus tetap berjalan offline
    Kalau kode server bisa dijalankan apa adanya di worker, itu akan menjadi hack yang keren
  • Saya sedang membuat server/backend untuk htmx yang berjalan sebagai layanan lokal di samping browser
    Secara teori, stack server apa pun yang bisa di-self-host seharusnya memungkinkan
    Tujuannya membuat single binary tanpa dependensi layanan eksternal, dan saya memakai Go
    Komponen seperti layanan lokal yang bisa memperbarui diri sendiri dan database replikasi sudah cukup banyak tersedia, dan cross-compile untuk berbagai sistem operasi serta arsitektur juga mudah
    Sebagai alternatif dari memasukkan semuanya ke browser, pendekatan ini tampak cukup masuk akal jika diasumsikan kita bisa menjalankan proses terpisah
    Hanya saja, saya berharap Go juga punya manajemen permission seperti Deno
  • Ada contoh nyata: https://github.com/jon49/htmx-todomvc
    Untuk aplikasi pribadi, saya memakai pola ini semuanya, hanya saja menggunakan library kecil mirip htmx buatan sendiri
    Sepertinya beralih ke HTMX juga tidak akan terlalu sulit

• Saya penasaran apakah memindahkan HATEOAS ke ranah aplikasi desktop atau mobile adalah ide bagus, dan itu bisa jadi eksperimen yang menarik

  • Kalau yang dimaksud mobile native, sekitar 2013 saya pernah memakai HATEOAS di kode native
    Berfungsi dengan baik, tetapi tidak sefleksibel web, dan tiap layar yang bisa ditautkan harus dikembangkan dengan pendekatan black box yang ketat
    Percobaannya sendiri menarik, tetapi saya tidak yakin seberapa bernilai untuk dipakai di production
  • Saya hanya melihat HATEOAS sebagai konsep abstrak, dan belum pernah merasa dalam UI nyata bahwa “interaksi pengguna benar-benar jadi lebih baik”
    REST menyenangkan karena menyederhanakan monster-monster SOAP, tetapi juga membawa cukup banyak dogmatisme
    Saya paham tujuan dasarnya, karena REST menyesuaikan arsitektur konsep, data, dan layanan agar terasa alami bagi pengguna
    Namun HATEOAS terasa seperti hasil dari keinginan akan lebih banyak dogmatisme dan pamer gaya di rapat arsitektur, alih-alih berfokus pada apakah pengalaman pengguna menjadi lebih baik berkat modelnya
    Saya penasaran apakah ada contoh UI yang menunjukkan mengapa HATEOAS harus dijadikan prinsip dasar
    Pada dasarnya, setiap halaman punya tautan ke “hal yang harus dilakukan berikutnya”, dan HATEOAS terasa seperti cara yang mengilap untuk membawa model state semacam itu ke pemanggilan layanan REST
  • Saya malah penasaran dulu apakah HATEOAS memang ide yang bagus
  • Ada di sini: https://hyperview.org/