Hotwire: Teknologi HTML Over the Wire

 (hotwired.dev)
2 poin oleh GN⁺ 2024-06-03 | 1 komentar | Bagikan ke WhatsApp
  • Hotwire adalah pendekatan untuk membuat aplikasi web modern dengan mengirim HTML alih-alih JSON, menargetkan pemuatan awal yang cepat dan responsivitas tanpa banyak JavaScript
  • Karena rendering tetap berada di template server, alur pengembangan dapat tetap sederhana terlepas dari bahasa yang digunakan
  • Framework yang dibuat 37signals untuk HEY dikombinasikan bersama untuk membentuk ekosistem Hotwire yang mencakup web hingga berbagai platform
  • Komponen utamanya, Turbo, menangani transisi halaman, pengiriman formulir, pemisahan komponen, dan pembaruan parsial berbasis WebSocket tanpa menulis JavaScript
  • Interaksi kustom yang belum cukup ditangani Turbo dilengkapi oleh Stimulus, sementara Hotwire Native memungkinkan pembuatan aplikasi mobile native berdasarkan aplikasi web yang sudah ada

Pendekatan merender HTML di server lalu mengirimkannya

  • Hotwire adalah pendekatan alternatif untuk membangun aplikasi web modern dengan metode HTML-over-the-wire
  • Alih-alih JSON, ia mengirim HTML melalui jaringan, sehingga memungkinkan pembuatan aplikasi tanpa banyak JavaScript
  • Tujuannya adalah pemuatan halaman pertama yang cepat, mempertahankan rendering template di sisi server, serta pengalaman pengembangan yang lebih sederhana dan produktif
  • Arahnya tidak mengorbankan kecepatan dan responsivitas yang diharapkan dari aplikasi satu halaman tradisional
  • HTML-over-the-wire juga bisa digunakan sebagai referensi untuk membuat alat sendiri, atau langsung memakai framework Hotwire yang dibuat 37signals untuk HEY

Peran Turbo, Stimulus, dan Hotwire Native

  • Turbo adalah komponen inti Hotwire
    • Menyediakan teknik pelengkap untuk memproses transisi halaman dan pengiriman formulir dengan cepat
    • Memecah halaman kompleks menjadi komponen dan melakukan streaming pembaruan halaman parsial melalui WebSocket
    • Menyediakan fungsi-fungsi ini tanpa perlu menulis JavaScript
  • Stimulus digunakan ketika dibutuhkan kode kustom yang tidak cukup ditangani oleh Turbo saja
    • Turbo biasanya menangani setidaknya 80% interaksi yang secara tradisional membutuhkan JavaScript
    • Stimulus memungkinkan status dan koneksi ditangani dengan cara yang berpusat pada HTML
  • Hotwire Native adalah framework web-first untuk membuat aplikasi mobile native
    • Menyediakan alat yang diperlukan untuk membangun aplikasi mobile dengan memanfaatkan aplikasi web yang sudah ada

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-03
Pendapat Hacker News

  • Ada versi yang pemasaranannya lebih minim untuk fitur ini, yaitu htmx: https://htmx.org/
    Satu file JavaScript memungkinkan fungsi seperti ini, dan saya paling sering melihatnya dipakai bersama backend Go, tetapi tampaknya cukup fleksibel. Saya sudah terpikir untuk mencobanya sejak sekitar setahun lalu

    • Setidaknya menurut standar Hacker News, htmx jauh lebih sering terekspos
      Dalam setahun terakhir saja ada ratusan kiriman di HN 0, dan bahkan ada posting yang menembus 1000 poin. Sementara itu, Hotwire dalam setahun terakhir bahkan tidak sampai 30 kiriman 1, dan yang paling populer di antaranya adalah tulisan ini
    • Saya tidak paham maksudnya htmx dipasarkan lebih minim. Saya baru pertama kali mendengar Hotwire, tetapi htmx muncul terlalu sering di mana-mana di sini
      Cukup lihat sebentar YouTube, para influencer programmer terus menampilkan htmx dengan thumbnail wajah mereka
    • https://unpoly.com yang juga mencakup fitur lain layak disebut
    • HTMX mungkin termasuk yang paling bagus pemasarannya dibanding framework mana pun
      Twitter-nya juga sangat aktif, sering muncul di kanal YouTube The Primeagen, dan cukup populer
    • Dipasarkan lebih minim? Rasanya htmx membanjiri semua platform sosial

  • Jika mencari sesuatu yang mirip di PHP/Laravel, saya sangat merekomendasikan Livewire: https://laravel-livewire.com/
    Untuk proyek yang lebih kompleks saya tetap memakai React, tetapi tetap terasa menyegarkan bisa menulis semuanya dengan Blade/PHP sambil mempertahankan elemen UI yang reaktif. Saya juga ingat pernah melihat paket yang memungkinkan komponen React/Vue dirender di dalam Livewire saat diperlukan: https://minglejs.unitedbycode.com/. Itu tampak seperti jalan keluar yang menarik ketika perlu menarik paket yang sudah ada

  • Dulu saya cukup negatif terhadap Hotwire/Livewire, tetapi sekarang saya melihatnya sebagai alat yang tepat sesuai situasi
    Mengirim partial template lewat wire adalah pendekatan hypermedia, hanya saja belakangan ini kita tidak terlalu membangun aplikasi hypermedia dengan baik. Saya sampai pada pandangan ini setelah membaca ulang htmx dan paper REST dari RTF, dan walau saya tidak menganggap hypermedia sebagai arsitektur yang secara intrinsik lebih unggul, ini tetap rekan yang sah di antara banyak pilihan, dan bagus melihatnya terus berevolusi meski pelan

  • Ini mendekati cara termudah untuk membuat PWA tanpa terjatuh ke lubang kelinci React/Vue/Svelte
    Saya juga pernah memakainya dan menurut saya semuanya bagus, tetapi dibanding htmx, itu terasa lebih berpusat pada pengalaman pengembang daripada berpusat pada teknologi. Persaingan di antara keduanya pada akhirnya akan ditentukan oleh framework backend mana yang terintegrasi lebih baik

    • Kalau aplikasi mobile hanya berupa WebView, mungkin iya. Kalau tidak, Anda harus memelihara keduanya: REST API untuk aplikasi mobile dan handler permintaan Hotwire/Livewire yang mengirim fragmen HTML
      Secara pribadi, saya melihat PWA sebagai masalah klien, dan seharusnya ditangani di sisi klien tanpa menambah ketergantungan pada server
    • Saya penasaran mengapa pendekatan ini dianggap kurang seperti lubang kelinci dibanding alternatif yang disebutkan

  • Percakapan HN dari tahun 2020 yang lebih dekat dengan saat ini pertama kali muncul ada di sini: https://news.ycombinator.com/item?id=25507942

  • Rasanya seperti sudah hampir kembali ke titik semula. Saya ingat sekitar 2005 atau 2006 pernah memakai pendekatan mencegat klik, menambahkan parameter, lalu hanya menerima potongan bagian HTML yang sudah dirender dan mengganti isi utama dengan .innerHTML

    • Sebelum AJAX muncul di awal 2000-an, Adam Rifkin pernah memperlihatkan demo startup-nya, KnowNow, dan saat itu sangat mengejutkan melihat halaman web memperbarui dirinya sendiri tanpa refresh
      Triknya adalah membiarkan permintaan HTTP tetap terbuka dan server sesekali mengirim pembaruan, dan pembaruan itu juga berupa HTML. Waktu itu mungkin bahkan belum bisa memanipulasi DOM, jadi bisa jadi benar-benar berupa halaman dengan tag yang tidak pernah ditutup
    • Daripada mengatakan sudah berputar satu siklus penuh, mungkin lebih tepat melihat berbagai paradigma UI web sedang memperluas cakupannya
      Framework server-rendered sedang mempermudah interaksi di klien, dan React melalui RSC sedang mempermudah server rendering. Untuk web app yang sangat interaktif, SPA tetap lebih unggul
    • Setiap kali Hotwire atau library serupa naik daun, pembahasan seperti ini selalu muncul, tetapi secara realistis CRUD sederhana berbasis AJAX tidak pernah benar-benar hilang
      Memang ada sangat banyak proyek SPA, tetapi itu tidak menjelaskan semua website di dunia
    • https://animasci.com/ memakai pendekatan serupa
      Pagination diimplementasikan dengan cara menggulir ke bawah, menekan “Show more”, lalu meminta halaman berikutnya dari server sebagai fragmen HTML, memuatnya ke iframe tak terlihat, dan setelah selesai dimuat menempelkannya ke halaman saat ini
    • Di akhir 2000-an saya cukup menyukai Wicket dan tidak suka JavaScript, tetapi mengelola state UI dan template di server mudah menjadi jebakan dari sisi performa dan skalabilitas dalam lingkungan tim
      Mengingat betapa banyak peningkatan pada web, JavaScript, dan TypeScript sejak saat itu, sulit untuk kembali antusias pada pendekatan ini

  • Saya tidak banyak menangani web app yang membutuhkan frontend sangat interaktif, tetapi di toko e-commerce dan aplikasi Rails internal, Turbo dan Stimulus sangat menurunkan jumlah hal yang harus dipelajari developer baru

    • Jika stack dijaga tetap sederhana, sebenarnya dari awal tidak sesulit itu
      Misalnya, di satu proyek Django saya pernah dengan cepat membangun seluruh tool kantor memakai KnockoutJS yang sudah terbukti, dan ini juga cukup sejalan dengan semangat HTMX. Arrow.JS yang masih awal juga mirip. Kompleksitas, terutama kompleksitas UI, pada dasarnya sering kali kita ciptakan sendiri, dan cara lama sama sekali belum usang, malah sedang kembali. Ada satu generasi developer muda yang masuk ke industri pada masa paling bodoh ketika industri meyakinkan orang bahwa semua aplikasi web harus diubah menjadi gumpalan yang terlalu rumit dan sulit ditanggung
    • Berdasarkan pengalaman memakai Stimulus, Stimulus itu buruk sekali dan saya tidak akan memakainya lagi. Hotwire lumayan

  • Saya sudah membayar dan memakai Hey sejak peluncuran, dan jika pengalaman web app Hey adalah contoh terbaik Hotwire, saya akan melewatkannya
    Pada koneksi lambat, pengalamannya buruk. Mungkin karena developernya tidak menambahkan state loading atau error, mungkin karena kompleksitasnya tinggi, atau mungkin karena bug di Hey. Saya tidak tahu, tetapi jelas tidak bagus
    Pada latensi menengah hingga tinggi, perilakunya terasa tak terduga atau seperti bug. Kotak kosong terbuka, tautan tidak bekerja seperti yang diharapkan, dan saat beberapa aksi dilakukan cepat berurutan, tidak dibatalkan dengan cara yang intuitif. Rasanya serba tidak pas
    Sejelek apa pun SPA, ini terasa seperti satu langkah menjauh dari UI yang terasa native dan alami

  • Alasan tulisan ini kembali ramai sekarang adalah karena minggu lalu seseorang memposting bahwa Hey lambat saat membuka modal: https://x.com/noahflk/status/1795758603577545035
    Hey dibuat oleh DHH, dan DHH juga membuat Hotwire dan Rails. Setelah itu, perdebatan memanas dengan campuran bantahan DHH bahwa video aslinya direkam di jaringan terbatas, tanggapan bahwa jika memuat modal saja butuh waktu maka Hotwire terlalu bergantung pada jaringan, pembelaan terhadap Rails/Hotwire, dan penolakan terhadap pendekatan tersebut. Itu menjadi topik besar di Twitter minggu lalu

    • Memang benar DHH mengatakan video aslinya direkam di jaringan terbatas
      Penulisnya juga menulis bahwa itu “diperlambat dengan sengaja untuk demonstrasi”: https://x.com/noahflk/status/1795855075526471915. Ia bilang tujuannya bukan menunjukkan pengalaman orang dengan “MacBook bagus di SF dan internet gigabit”, melainkan orang yang memakai internet seluler lambat dan laptop murah. Ada juga yang menunjukkan bahwa Google Calendar SPA jauh lebih lambat, dan pilihannya juga bukan cuma “internet gigabit di SF” atau “3G yang sangat dibatasi”. Postingan aslinya sangat menyesatkan, nyaris seperti kebohongan
    • Tautan balasan langsung dari DHH: https://x.com/dhh/status/1796163806650868149
    • Saat saya melihat Hey sekitar setahun lalu, dari seberang Pasifik pun performanya tampak cukup gesit
      Terutama struktur halamannya yang mengesankan. Misalnya, pada overlay menu konteks mereka menerapkan kombinasi details/summary/anchor dengan pendekatan progressive enhancement, sehingga bahkan jika JavaScript dimatikan atau aset gagal dimuat, konten menu tetap bisa dimunculkan dengan anggun dalam layout sederhana. Selain itu, ada banyak bagian yang memakai Web API dengan hati-hati, dan saya ingat kode kliennya juga hampir tidak diobfuscate serta dilengkapi source map. Saya bukan penggemar DHH dan juga tidak berniat mengikuti drama minggu itu, tetapi kali ini saya merasa 37signals melakukannya dengan benar
    • Sudah diperbaiki. Pembaruannya bisa dilihat di sini: https://x.com/dhh/status/1797370923391357143

  • Dua tahun lalu saya membuat Swap JS, implementasi lebih minimal dari ide yang sama: https://github.com/josephernest/Swap
    Saya sudah memakainya di beberapa proyek dan hasilnya bekerja dengan baik