HN-Vorstellung: HTMX Playground, zu 100 % im Browser umgesetzt

 (lassebomh.github.io)
6 Punkte von GN⁺ 2024-01-09 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Code-Sandbox, mit der man HTMX-Experimente direkt im Browser starten kann, ohne Installation oder lokale Einrichtung
  • server.js behandelt Endpunkte und Template-Rendering; HTMX-Requests werden von einem Mock-Server im Browser abgefangen
  • Request-Handling und Template-Ansatz sind Django-Nutzern vertraut und lassen sich auch für Experimente mit anderen Libraries als HTMX verwenden
  • Teilen funktioniert, indem man per „Copy as JSON“ exportiert und die Gist-Raw-URL in „Load Playground“ einfügt
  • Zu beachten sind fehlende Seitennavigation, eingeschränkter Mobile-Support und der mögliche Verlust von Status-Updates in on.get("/") durch das initiale Laden des iframe

Eine HTMX-Sandbox, die im Browser läuft

  • HTMX Playground ist eine einfache Code-Sandbox, mit der man HTMX ohne Installation ausprobieren kann
  • Sie bietet Beispiele, die aus den ursprünglichen htmx.org-Beispielen adaptiert wurden
  • Im Browser kann man Code in einem Backend-ähnlichen Ablauf schreiben
    • In server.js definiert man Endpunkte
    • Templates können direkt gerendert werden
    • Ein Mock-Server fängt ausgehende Requests von HTMX ab
  • Request-Handling und Template-Engine sind in einer Form gehalten, die Django-Nutzern vertraut ist
  • Das Projekt selbst ist nicht auf HTMX beschränkt, sodass man auch andere Libraries ausprobieren kann
  • Der Code ist auf GitHub veröffentlicht

Speichern, Teilen und bekannte Einschränkungen

  • Speichern und Teilen

    • Oben rechts auf „Copy as JSON“ klicken, um den Inhalt zu kopieren
    • Den kopierten Inhalt in einen Gist hochladen
    • Die Raw-URL in „Load Playground“ eingeben
    • Sobald die Seiten-URL aktualisiert wurde, kann sie geteilt werden

  • Einschränkungen

    • Es gibt keine Seitennavigation
    • Mobile-Support ist eingeschränkt
    • server.js kann wie im Beispiel Click to Edit Status halten
    • Wenn im on.get("/")-View der Status aktualisiert wird, kann dieses Update verloren gehen
      • Grund ist, dass der initiale Seitenaufruf zuerst in einem separaten iframe erfolgt, bevor er das iframe auf dem Bildschirm aktualisiert

  • Verwendete Libraries

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-09
Hacker-News-Kommentare

  • Ich bin die Person, die htmx gemacht hat, und finde das wirklich großartig — vielen Dank, dass du das gebaut hast

    • Ich frage mich, ob es eine Möglichkeit gibt, HTMX mit minimalen Änderungen auf der Serverseite zu verwenden
      Wenn man in einer bestehenden Seite ein Formular ausfüllt und absendet, kommt die Antwort als vollständige Seite zurück. Es wäre praktisch, htmx sagen zu können: „Die ganze Seite kommt zurück, aber aktualisiere nur #my-form“, sodass man auf dem Server keine Verzweigung wie „wenn es eine htmx-Anfrage ist“ einbauen muss
      Das wäre gut für Leute, die möchten, dass ihre Website auch ohne JavaScript funktioniert, und man könnte mehrere Funktionen wie Kommentare, E-Mail-Abos und Like-Buttons über einen einzigen Backend-Endpunkt abwickeln
    • Ich frage mich, ob du Phoenix LiveView kennst und ob das ein ähnliches Konzept wie htmx ist

  • Ich habe überlegt, HTMX ernsthaft einzusetzen, aber ich habe Sorge, dass der Entwicklerpool zu klein ist und das Recruiting schwierig wird
    Ich war an proprietäre Frameworks ähnlich wie Thymeleaf gewöhnt, etwa isml von Intershop, und wollte in letzter Zeit auf einen Angular-Frontend-Stack umsteigen, weil es leichter ist, dedizierte Frontend-Entwickler einzustellen
    Ein Ansatz wie htmx kann kompliziert werden, Entwickler wollen nicht gegen ein Spaghetti-Monster kämpfen, und wenn das Frontend nur HTML erzeugt und das Backend alles zusammenkleben muss, könnten Backend-Entwickler zum Flaschenhals werden
    Ich frage mich, ob HTMX diese Fallen berücksichtigt hat und wie es damit umgeht

    • htmx ist beim Lernen sehr intuitiv; sofern jemand nicht nur aus einem Coding-Bootcamp kommt und ausschließlich React gelernt hat, dürfte ein Entwickler mit echtem Informatik-Hintergrund spätestens nach einer Woche produktiv damit arbeiten können
    • Die Antwort ist einfach: HTMX zu lernen dauert nicht einmal einen halben Tag, wahrscheinlich sogar noch weniger
      HTMX löst allerdings nicht jede Situation, und es gibt Fälle, in denen man eine Single-Page-App mit einem JavaScript-Framework braucht
    • Nach der Erwähnung von Angular zu sagen, htmx könne kompliziert werden, ist interessant; offenbar gibt es unterschiedliche Sichtweisen auf Komplexität
      Frameworks wie Angular geben Struktur, aber die Komplexität bleibt bestehen und ist womöglich sogar deutlich größer
      Was man letztlich braucht, sind Frontend-Entwickler, die den Web-Stack mit JavaScript, CSS, HTML und Browser-APIs gut verstehen; solche Leute können passende Tools und Frameworks für die Aufgabe auswählen und lernen auch HTMX sehr schnell
    • Nichts ist überzeugender als Erfolg, und htmx wurde 2023 bei den JS Rising Stars in der Kategorie Frameworks auf Platz 2 gewählt
      https://risingstars.js.org/2023/en#section-framework
      Direkt hinter React und vor Vue, Svelte und Angular, daher sieht die Zukunft in dieser Hinsicht gut aus. Ich gehe aber davon aus, dass das Ranking sinken wird, sobald die anfängliche Begeisterung abflaut
      htmx ist ziemlich einfach, sodass die meisten Webentwickler es in etwa einem Tag lernen können, aber der Entwicklungsansatz schiebt Organisationen in Richtung eines Full-Stack-Paradigmas, bei dem Entwickler eine Funktion vollständig verantworten. Das erfordert einen Denkwechsel nicht nur bei Entwicklern, sondern auch bei PMs und Architekten
      Es gibt auch ein kostenloses Online-Buch: https://hypermedia.systems
      Zusätzlich zur Dokumentation (https://htmx.org/docs, etwa eine Stunde Lesezeit) gibt es Texte zu philosophischen und praktischen Fragen rund um htmx und Hypermedia allgemein: https://htmx.org/essays
      htmx versucht „erweiterbar“ zu sein, weil es nur sehr wenige Grundideen hat und nützliche Verhaltensweisen wie Lazy Loading schon mit zwei Attributen umsetzen kann: https://htmx.org/examples/lazy-load
      Gleichzeitig gibt es Hooks wie Events oder Event-Filter und auch tiefere Funktionen, sodass man bei Bedarf tiefer einsteigen und das gewünschte Verhalten umsetzen kann
      Spaghetti-Code ist in jeder Art von Softwareentwicklung immer ein Risiko, und ich war persönlich nie überzeugt, dass Single-Page-App-Bibliotheken Spaghetti-Code verhindern
      Bei htmx ist es oft besser, die Anstrengung auf das Backend zu konzentrieren und die Werkzeuge der Serverumgebung zu nutzen, um die Anwendung sauber zu zerlegen
      Weil htmx die Wahl beliebiger Servertechnologien erlaubt, gibt es mehr Optionen und Paradigmen zur Organisation der Anwendungslogik als bei Single-Page-Apps, bei denen eine große JavaScript-/TypeScript-App im Frontend oft auch das Backend in dieselbe Richtung drängt
      Hier habe ich auch zusammengefasst, für welche Anwendungen htmx eine gute Wahl ist: https://htmx.org/essays/when-to-use-hypermedia/
      htmx ist in vielen Fällen ein gutes Werkzeug, aber eben nur ein Werkzeug und keine Universallösung für Webentwicklung
    • Beim Hiring geht es eher um Backend-Kompetenz als um HTMX im Lebenslauf
      Im Grunde stellt man Backend-Entwickler ein, die ein wenig Frontend können. HTMX muss also nicht im CV stehen; Grundlagen wie JavaScript reichen aus
      Auf die meisten Webentwickler trifft das zu

  • Ich habe MapLibre zusammen mit Django und htmx verwendet und sollte wohl mal ein Beispiel hochladen, damit andere es ebenfalls nutzen können

    • Ich habe auf ähnliche Weise https://ratethispad.com gebaut, und der Bauprozess hat ziemlich viel Spaß gemacht
      Zwar benutzt es niemand, aber ich würde mir dein Projekt trotzdem gern anschauen
    • Ich habe nichts, was ich öffentlich teilen könnte, aber ich habe mit Django, htmx, SQLAlchemy und Plotly gearbeitet und fand das ziemlich robust
    • Wenn du weitere offizielle Beispiele portieren möchtest, kannst du einfach ein Issue mit dem Link erstellen, dann kann es dem Repository hinzugefügt werden

  • Soweit ich weiß, funktioniert Monaco auf Mobilgeräten absichtlich nicht, deshalb verwendet man dort Ace
    Zumindest war das so, als ich zuletzt in die GitHub-Issues geschaut habe
    [0] https://github.com/Microsoft/monaco-editor/issues/246

    • Monaco hat auf Mobilgeräten bei mir gut funktioniert; ich habe es eben auf https://tsdiagram.com ausprobiert

  • Unterstützt das auch ActiveX?

    • Traurig zu merken, dass ich alt genug bin, um diesen Witz zu verstehen
    • Musste an HP Quality Center denken
      In den frühen Versionen bestand die gesamte UI aus ActiveX, und ich erinnere mich noch an jede Menge Fortschrittsbalken für die DLL-Installation

  • Damit ließe sich auch so etwas mit einem Service Worker bauen, und man könnte mehrere Seiten in anderen Tabs öffnen und darin navigieren
    Das scheint nicht allzu schwer zu sein, und für die Seitenerzeugung könnte man reines JavaScript oder was auch immer der Nutzer möchte verwenden

  • Also wurde es mit Svelte gebaut; wo sind die MPA-Puristen mit ihren Mistgabeln?

    • Ich bin ein MPA-Purist, erkenne aber durchaus an, dass es eine Klasse von Anwendungen gibt, für die Single-Page-Apps die beste Lösung sind

  • Das Konzept von htmx gefällt mir, und ich habe heute angefangen, das Buch zu lesen, aber jedes Mal, wenn ich daran denke, dass irgendwann auch native mobile Apps unterstützt werden müssen, zögere ich bei der Nutzung
    In dem Fall müsste man wohl nicht nur das Frontend, sondern auch einen beträchtlichen Teil des Backends neu schreiben
    hyperview.org kenne ich, aber für die Anwendungsfälle, die mich interessieren, reicht eine React-Native-App nicht aus

  • Ich frage mich, ob jemand mit einem im Service Worker definierten virtuellen Server und dem HTML/HTMX-Request-Response-Modell Offline-Apps baut

    • Gute Frage
      Ich mag htmx, konnte es aber in Situationen, in denen auch Offline-Betrieb nötig war, nicht verwenden
      Wenn sich Server-Code unverändert im Worker ausführen ließe, wäre das ein großartiger Hack
    • Ich baue einen Server bzw. ein Backend für htmx, das als lokaler Dienst neben dem Browser läuft
      Theoretisch sollte jede selbst hostbare Server-Architektur möglich sein
      Das Ziel ist eine einzelne Binärdatei ohne Abhängigkeiten von externen Diensten, und ich verwende Go
      Komponenten wie ein sich selbst aktualisierender lokaler Dienst oder eine replizierte Datenbank sind bereits weitgehend vorhanden, und Cross-Compilation für verschiedene Betriebssysteme und Architekturen ist ebenfalls einfach
      Als Alternative dazu, alles in den Browser zu packen, erscheint dieser Ansatz ziemlich sinnvoll, sofern man davon ausgehen kann, einen separaten Prozess ausführen zu dürfen
      Ich wünschte nur, Go hätte auch so eine Rechteverwaltung wie Deno
    • Es gibt ein reales Beispiel: https://github.com/jon49/htmx-todomvc
      Für meine privaten Apps verwende ich durchgehend dieses Muster, nur mit einer kleinen htmx-ähnlichen Bibliothek, die ich selbst gebaut habe
      Auf HTMX umzustellen, dürfte auch nicht besonders schwer sein

  • Ich frage mich, ob es eine gute Idee wäre, HATEOAS in Desktop- oder Mobile-Apps zu übertragen; als Experiment wäre das interessant

    • Wenn du native Mobile-Apps meinst: Ich habe um 2013 herum HATEOAS in nativem Code ausprobiert
      Es funktioniert, ist aber nicht so flexibel wie im Web, und jeder verlinkbare Screen muss strikt als Black Box entwickelt werden
      Der Versuch an sich war spannend, aber ich bin mir nicht sicher, wie viel Wert das in der Produktion hat
    • Ich habe HATEOAS immer nur als abstraktes Konzept gesehen und nie in einer echten UI gedacht: „Wow, dadurch ist die Benutzerinteraktion wirklich besser geworden“
      Ich war froh, dass REST die SOAP-Monster vereinfacht hat, aber es brachte auch eine beträchtliche Portion Dogmatismus mit sich
      Ich verstehe das grundlegende Ziel von REST, weil es Konzepte, Daten und Service-Architektur an das anpasst, was für Nutzer natürlich ist
      Aber HATEOAS wirkt eher wie das Ergebnis des Wunsches nach noch mehr Dogmatismus und Angeberei in Architektur-Meetings, statt sich darauf zu konzentrieren, ob das Modell die User Experience tatsächlich verbessert
      Ich frage mich, ob es ein UI-Beispiel gibt, das zeigt, warum HATEOAS ein grundlegendes Prinzip sein sollte
      Im Grunde hat jede Seite Links dazu, „was als Nächstes zu tun ist“, und HATEOAS wirkt wie eine schillernde Art, ein solches Zustandsmodell in REST-Service-Aufrufe zu übertragen
    • Ich frage mich schon, ob HATEOAS überhaupt eine gute Idee ist
    • Hier ist es: https://hyperview.org/