Hotwire: HTML-over-the-wire-Technologie

 (hotwired.dev)
2 Punkte von GN⁺ 2024-06-03 | 1 Kommentare | Auf WhatsApp teilen
  • Hotwire ist ein Ansatz zum Erstellen moderner Web-Apps, der HTML statt JSON überträgt und damit auf schnelle erste Ladevorgänge und Reaktionsfähigkeit mit wenig JavaScript abzielt
  • Da das Rendering in Server-Templates verbleibt, kann der Entwicklungsablauf unabhängig von der verwendeten Sprache einfach gehalten werden
  • Die von 37signals für HEY entwickelten Frameworks lassen sich gemeinsam kombinieren und bilden so das Hotwire-Ökosystem von Web bis zu verschiedenen Plattformen
  • Die zentrale Komponente Turbo übernimmt Seitenwechsel, Formularübermittlungen, die Aufteilung in Komponenten und WebSocket-basierte partielle Updates, ohne dass JavaScript geschrieben werden muss
  • Für angepasste Interaktionen, bei denen Turbo nicht ausreicht, ergänzt Stimulus den Ansatz, und Hotwire Native ermöglicht es, auf Basis bestehender Web-Apps native mobile Apps zu erstellen

Der Ansatz, HTML auf dem Server zu rendern und auszuliefern

  • Hotwire ist ein alternativer Ansatz zum Erstellen moderner Webanwendungen im HTML-over-the-wire-Stil
  • Statt JSON wird HTML über das Netzwerk übertragen, sodass Anwendungen mit wenig JavaScript erstellt werden können
  • Ziel sind schnelle erste Seitenladezeiten, das Beibehalten von serverseitigem Template-Rendering sowie eine einfachere und produktivere Entwicklungserfahrung
  • Dabei soll nicht auf die Geschwindigkeit und Reaktionsfähigkeit verzichtet werden, die man von traditionellen Single-Page-Applications erwartet
  • HTML-over-the-wire kann als Referenzansatz zum Entwickeln eigener Werkzeuge dienen, oder man kann die von 37signals für HEY entwickelten Hotwire-Frameworks direkt verwenden

Die Rolle von Turbo, Stimulus und Hotwire Native

  • Turbo ist die zentrale Komponente von Hotwire
    • Es bietet ergänzende Techniken für schnelle Seitenwechsel und Formularübermittlungen
    • Es teilt komplexe Seiten in Komponenten auf und streamt partielle Seitenaktualisierungen per WebSocket
    • Diese Funktionen werden ohne das Schreiben von JavaScript bereitgestellt
  • Stimulus kommt zum Einsatz, wenn angepasster Code benötigt wird, für den Turbo allein nicht ausreicht
    • Turbo deckt in der Regel mindestens 80 % der Interaktionen ab, für die traditionell JavaScript nötig gewesen wäre
    • Stimulus ermöglicht es, Zustand und Verbindungen auf HTML-zentrierte Weise zu handhaben
  • Hotwire Native ist ein Web-First-Framework zum Erstellen nativer mobiler Apps
    • Es stellt die nötigen Werkzeuge bereit, um auf Basis bestehender Web-Apps mobile Apps zu entwickeln

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-03
Meinungen auf Hacker News

  • Eine weniger vermarktete Version dieser Funktionalität ist htmx: https://htmx.org/
    Damit wird so etwas mit einer einzigen JavaScript-Datei möglich. Ich habe es vor allem in Kombination mit Go-Backends gesehen, aber es wirkt ziemlich flexibel. Seit etwa einem Jahr denke ich darüber nach, es einmal auszuprobieren

    • Zumindest nach Hacker-News-Maßstäben würde ich sagen, dass htmx deutlich mehr Aufmerksamkeit bekommen hat
      Allein im letzten Jahr gab es Hunderte HN-Einreichungen 0, darunter auch Beiträge mit über 1000 Punkten. Hotwire hingegen hatte im letzten Jahr weniger als 30 Einreichungen 1, und die beliebteste davon ist dieser Beitrag
    • Ich verstehe nicht, warum htmx weniger vermarktet sein soll. Von Hotwire höre ich zum ersten Mal, aber htmx sehe ich überall
      Schon ein kurzer Blick auf YouTube zeigt, dass Programmierer-Influencer htmx ständig mit ihren Gesichtern in den Thumbnails pushen
    • Erwähnenswert ist auch https://unpoly.com, das noch weitere Funktionen enthält
    • HTMX ist möglicherweise besser vermarktet als fast jedes andere Framework
      Auch auf Twitter ist es sehr aktiv, es taucht häufig auf dem YouTube-Kanal von The Primeagen auf und ist ziemlich beliebt
    • Weniger vermarktet? Gefühlt quillt htmx aus allen Social-Plattformen heraus

  • Wenn man in PHP/Laravel etwas Ähnliches sucht, kann ich Livewire sehr empfehlen: https://laravel-livewire.com/
    Für komplexere Projekte verwende ich weiterhin React, aber es fühlt sich immer wieder erfrischend an, alles in Blade/PHP schreiben zu können und dabei reaktive UI-Elemente zu behalten. Ich erinnere mich auch an ein Paket, mit dem sich bei Bedarf React-/Vue-Komponenten innerhalb von Livewire rendern lassen: https://minglejs.unitedbycode.com/. Das wirkt wie ein interessanter Ausweg, wenn man bestehende Pakete einbinden muss

  • Früher war ich Hotwire/Livewire gegenüber ziemlich negativ eingestellt, inzwischen sehe ich sie als Werkzeuge für den passenden Kontext
    Partielle Templates über die Leitung zu schicken ist ein Hypermedia-Ansatz; heutzutage bauen wir nur nicht mehr so viele gute Hypermedia-Apps. Über htmx und erneutes Lesen von RTFs REST-Dissertation bin ich hier gelandet. Ich sehe Hypermedia nicht als grundsätzlich überlegene Architektur, aber als legitime Option unter mehreren, und es ist gut, dass sie sich, wenn auch langsam, weiterentwickelt

  • Das kommt wahrscheinlich dem einfachsten Weg am nächsten, eine PWA zu bauen, ohne in das Kaninchenloch von React/Vue/Svelte zu fallen
    Ich habe diese ebenfalls verwendet und halte sie für großartig, aber im Vergleich zu htmx wirken sie eher auf Developer Experience als auf die Technik selbst fokussiert. Der Wettbewerb zwischen ihnen dürfte am Ende davon abhängen, welche sich besser in welches Backend-Framework integrieren lässt

    • Wenn die mobile App einfach nur eine WebView ist, kann das stimmen. Andernfalls muss man sowohl eine REST API für die mobile App als auch Hotwire-/Livewire-Request-Handler pflegen, die HTML-Fragmente ausliefern
      Persönlich sehe ich eine PWA als Client-Problem; man sollte keine Server-Abhängigkeit hinzufügen, sondern es auf der Client-Seite lösen
    • Mich würde interessieren, warum dieser Ansatz weniger ein Kaninchenloch sein soll als die genannten Alternativen

  • Hier ist die HN-Diskussion von 2020, also näher an dem Zeitpunkt, als es erstmals erschien: https://news.ycombinator.com/item?id=25507942

  • Es fühlt sich fast so an, als wären wir einmal im Kreis herum. Ich erinnere mich, dass wir um 2005 oder 2006 Klicks abgefangen, Parameter angehängt und nur gerenderte HTML-Teilfragmente zurückbekommen haben, um dann den Body per .innerHTML zu ersetzen.

    • Anfang der 2000er, bevor AJAX aufkam, zeigte Adam Rifkin eine Demo seines Startups KnowNow; damals war es verblüffend, dass sich eine Webseite ohne Refresh selbst aktualisierte.
      Der Trick bestand darin, eine HTTP-Anfrage offen zu halten und den Server gelegentlich Updates senden zu lassen; diese Updates waren ebenfalls HTML. Damals konnte man vielleicht noch nicht einmal das DOM manipulieren, also war es im wörtlichen Sinn womöglich eine Seite mit einem nie geschlossenen Tag.
    • Genauer als „einmal im Kreis herum“ wäre wohl, dass verschiedene Web-UI-Paradigmen ihren Geltungsbereich ausweiten.
      Server-Rendering-Frameworks machen Client-Interaktion einfacher, und React macht Server-Rendering über RSC einfacher. Für sehr interaktive Web-Apps ist eine SPA weiterhin im Vorteil.
    • Diese Diskussion hört man jedes Mal, wenn Hotwire oder ähnliche Bibliotheken auftauchen, aber realistisch betrachtet ist einfaches AJAX-basiertes CRUD nie verschwunden.
      Es gibt zwar sehr viele SPA-Projekte, aber das beschreibt nicht alle Websites der Welt.
    • Auf https://animasci.com/ wird ein ähnlicher Ansatz genutzt.
      Die Pagination ist so umgesetzt: Wenn man nach unten scrollt und auf „Show more“ klickt, wird die nächste Seite als HTML-Fragment vom Server angefordert, in ein unsichtbares iframe geladen und nach Abschluss des Ladens an die aktuelle Seite angehängt.
    • Ende der 2000er mochte ich Wicket ziemlich und JavaScript mochte ich nicht, aber UI-Zustand und Templates auf dem Server zu verwalten wurde in Teamumgebungen leicht zur Falle für Performance und Skalierbarkeit.
      Wenn man bedenkt, wie sehr sich Web, JavaScript und TypeScript inzwischen verbessert haben, fällt es schwer, sich für diesen Ansatz erneut zu begeistern.

  • Ich habe nicht viele Web-Apps gebaut, die ein hochgradig interaktives Frontend brauchen, aber in E-Commerce-Shops und internen Rails-Apps haben Turbo und Stimulus die Menge dessen, was neue Entwickler lernen müssen, stark reduziert.

    • Wenn man den Stack einfach hielt, war es ursprünglich gar nicht so schwierig.
      Zum Beispiel haben wir in einem Django-Projekt mit dem bewährten KnockoutJS schnell ein komplettes Tool fürs Büro gebaut, und das steht dem Geist von HTMX in gewisser Weise nahe. Das noch junge Arrow.JS ist ähnlich. Komplexität, insbesondere UI-Komplexität, war meist selbst gemacht; die alten Methoden sind keineswegs veraltet, sondern kommen eher zurück. Es gibt eine Generation junger Entwickler, die in der dümmsten Phase der Branche eingestiegen ist, als man ihnen einreden wollte, jede Webanwendung müsse zu einem überkomplexen, kaum erträglichen Gebilde werden.
    • Aus eigener Erfahrung mit Stimulus: Stimulus war miserabel, und ich werde es nie wieder verwenden. Hotwire war in Ordnung.

  • Ich nutze Hey seit dem Launch kostenpflichtig, aber wenn die Hey-Webapp-Erfahrung das Vorzeigebeispiel für Hotwire sein soll, verzichte ich lieber.
    Bei langsamen Verbindungen ist es schlecht. Vielleicht liegt es daran, dass die Entwickler keine Lade- oder Fehlerzustände eingebaut haben, vielleicht an der hohen Komplexität, vielleicht an Bugs in Hey. Ich weiß es nicht, aber gut ist es nicht.
    Bei mittlerer bis hoher Latenz wirkt das Verhalten unvorhersehbar oder wie verbuggt. Leere Boxen öffnen sich, Links verhalten sich nicht wie erwartet, und wenn man mehrere Aktionen schnell hintereinander ausführt, werden sie nicht auf intuitive Weise abgebrochen. Es fühlt sich einfach unstimmig an.
    So schlecht SPAs auch sein mögen: Das hier scheint ein Schritt weg von einer UI zu sein, die sich nativ und natürlich anfühlt.

  • Dass dieser Artikel jetzt wieder auftaucht, liegt daran, dass letzte Woche jemand gepostet hat, Hey sei beim Öffnen eines Modals langsam: https://x.com/noahflk/status/1795758603577545035
    Hey stammt von DHH, und DHH hat auch Hotwire und Rails entwickelt. Danach vermischten sich DHHs Einwand, das Originalvideo sei in einem gedrosselten Netzwerk aufgenommen worden, Reaktionen, wonach Hotwire zu stark vom Netzwerk abhänge, wenn das Laden eines Modals so lange dauere, Verteidigungen von Rails/Hotwire und Kritik am Ansatz zu einer hitzigen Debatte. Letzte Woche war das ein großes Thema auf Twitter.

    • Es stimmt, dass DHH sagte, das Originalvideo sei in einem gedrosselten Netzwerk aufgenommen worden.
      Der Autor schrieb selbst, es sei „für die Demo absichtlich verlangsamt“ worden: https://x.com/noahflk/status/1795855075526471915. Er sagte, er habe nicht die Erfahrung von Leuten mit „gutem MacBook und Gigabit-Internet in SF“ zeigen wollen, sondern die von Leuten mit langsamem mobilen Internet und billigem Laptop. Es wurde auch angemerkt, dass die Google-Calendar-SPA deutlich langsamer sei, und außerdem sind „SF-Gigabit-Internet“ und „stark gedrosseltes 3G“ nicht die einzigen Optionen. Der ursprüngliche Post war sehr irreführend und kam faktisch einer Lüge nahe.
    • Link zu DHHs direkter Antwort: https://x.com/dhh/status/1796163806650868149
    • Als ich Hey vor etwa einem Jahr gesehen habe, wirkte es selbst von der anderen Seite des Pazifiks ziemlich flott.
      Besonders die Seitenstruktur war beeindruckend. Zum Beispiel wurde für ein Kontextmenü-Overlay eine Kombination aus details/summary/anchor im Sinne von Progressive Enhancement eingesetzt; selbst bei deaktiviertem JavaScript oder nicht geladenen Assets wurde der Menüinhalt in einem einfachen Layout elegant geladen. Darüber hinaus gab es viele Stellen, an denen Web APIs sorgfältig genutzt wurden, und ich erinnere mich, dass der Client-Code kaum obfuskiert war und Source Maps beilagen. Ich bin kein DHH-Fan und habe auch nicht vor, das Drama dieser Woche zu verfolgen, aber diesmal hatte ich den Eindruck, dass 37signals es richtig gemacht hat.
    • Es wurde bereits behoben. Das Update ist hier zu sehen: https://x.com/dhh/status/1797370923391357143

  • Vor zwei Jahren habe ich Swap JS gebaut, eine minimalere Umsetzung derselben Idee: https://github.com/josephernest/Swap
    Ich habe es in einigen Projekten verwendet, und es funktioniert gut.