- htmx wurde in die erste GitHub Open Source Accelerator-Kohorte aufgenommen und erhält damit die Möglichkeit, mit etablierten Open-Source-Projekten zusammenzuarbeiten und von ihnen zu lernen
- Diese Teilnahme bietet die Gelegenheit, Hypermedia und den Ansatz von htmx in der breiteren Entwickler-Community bekannter zu machen
- htmx plant, die Accelerator-Phase zu nutzen, um mit der Arbeit an htmx 2.0 zu beginnen
- Eine wichtige verbleibende Aufgabe ist es auch, zu lernen, wie sich die Arbeit an htmx zu einem Vollzeitjob machen lässt, um die Pflege und Weiterentwicklung des Projekts fortzusetzen
- Die gemeinsam ausgewählten Projekte decken verschiedene Open-Source-Bereiche wie Sicherheit, Dokumentation, Authentifizierung, Benachrichtigungen und CMS ab und zeigen damit die Bandbreite des GitHub Accelerators
Welche Chancen sich für htmx ergeben
- htmx wurde in die erste Klasse des GitHub Open Source Accelerator aufgenommen
- Durch diese Auswahl kann htmx von erfolgreichen Open-Source-Entwicklern und -Projekten lernen und mit ihnen zusammenarbeiten
- htmx sieht darin eine Chance, Hypermedia und htmx einem größeren Publikum bekannt zu machen
- Während der Teilnahme am Accelerator gibt es zwei Hauptziele
- Start der Arbeit an htmx 2.0
- Lernen, wie sich die Arbeit an htmx zu einem Vollzeitjob machen lässt
Gemeinsam ausgewählte Open-Source-Projekte
- BoxyHQ: Eine API-Produktpalette für Sicherheit und Datenschutz, die Engineering-Teams dabei hilft, regelkonforme Cloud-Anwendungen schneller zu entwickeln und bereitzustellen
- Cal.com: Ein Planungstool, das dabei hilft, Meetings zu terminieren, ohne endlose E-Mail-Schleifen
- Crowd.dev: Zentralisiert Community-, Produkt- und Kundendaten, um sichtbar zu machen, welche Unternehmen sich an Open-Source-Projekten beteiligen
- Documenso: Eine Open-Source-Alternative zu DocuSign, die Vertrauen durch Self-Hosting und überprüfbare interne Abläufe schaffen will
- Erxes: Eine Open-Source-Alternative zu HubSpot, mit der sich über ein einzelnes XOS Erlebnisse für verschiedene Geschäftsmodelle schaffen lassen
- Formbricks: Ermöglicht das Versenden von Umfragen an fein segmentierte Nutzergruppen an jedem Punkt der User Journey und kann mit gezielten Mikro-Umfragen bis zu sechsmal mehr Erkenntnisse liefern
- Forward Email: Ein kostenloser E-Mail-Weiterleitungsdienst für benutzerdefinierte Domains, der seit mehr als 6 Jahren von Kreativen, Entwicklern und Unternehmen genutzt wird
- GitWonk: Ein Open-Source-Tool für technische Dokumentation, das mit Fokus auf Developer Experience entworfen und entwickelt wurde
- Hanko: Ein Open-Source-Tool für Authentifizierung und Benutzerverwaltung im Passkey-Zeitalter, das sich in wenigen Minuten in Web- und Mobile-Apps integrieren lässt
- Infisical: Eine Open-Source-Plattform mit Ende-zu-Ende-Verschlüsselung zur sicheren Verwaltung von Secrets und Konfigurationen über Teams, Geräte und Infrastruktur hinweg
- Novu: Eine Open-Source-Benachrichtigungsinfrastruktur für Entwickler, die Komponenten und APIs zur Verwaltung aller Kommunikationskanäle an einem Ort bietet
- OpenBB: Demokratisiert Investment Research durch ein Open-Source-Finanzökosystem; mit OpenBB Terminal lässt sich Investment Research von überall aus durchführen
- Sniffnet: Ein Netzwerk-Monitoring-Tool, das dabei hilft, Internetverkehr einfach nachzuverfolgen
- Typebot: Bietet Bausteine für einzigartige Chat-Erlebnisse, die sich überall in Apps einbetten lassen, um Ergebnisse zu sammeln
- Webiny: Ein Open-Source-CMS auf Enterprise-Niveau für Serverless, das Dateneigentum, Skalierung und Anpassbarkeit betont
- Webstudio: Wurde als Open-Source-Alternative zu Webflow ausgewählt
1 Kommentare
Hacker-News-Meinungen
Hallo, wie viele wissen, bin ich der Entwickler von htmx und kann Fragen dazu beantworten.
htmx ist durch das Video von fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) und eine Videoserie des populären Twitch-Streamers ThePrimeagen deutlich populärer geworden.
Für HN-Leser dürfte auch meine Sammlung von Essays zu htmx und Hypermedia allgemein interessant sein: https://htmx.org/essays. Ebenfalls lesenswert ist das Buch über Hypermedia, htmx und mobiles Hypermedia mit Hyperview, das ich kürzlich zusammen mit einigen anderen Autoren veröffentlicht habe: https://hypermedia.systems
Natürlich bin ich ein Fan von htmx, aber der tiefere Kern ist aus meiner Sicht Hypermedia. Das ist ein Konzept, das es wert ist, erkundet zu werden, selbst wenn man nicht vorhat, htmx in der täglichen Entwicklung einzusetzen.
Es gibt auch viele hervorragende hypermedia-orientierte Libraries, etwa Hotwire von 37signals oder https://unpoly.com, das mir nach htmx am besten gefällt.
Für viele Django-Entwickler ist das eine große Hilfe.
Als ich vor ein paar Monaten eine Like-Funktion für Beiträge gebaut habe, musste ich vor htmx mit jQuery einen JSON-API-Server aufrufen und die Anzahl der Likes aktualisieren. Mit HTMX fühlte es sich dagegen so an, als würde man zusammen mit der Django-Logik einfach ganz normales HTML verwenden.
Es gehört zum Besten, was ich bisher entdeckt habe, und auch Formularverarbeitung ist sehr einfach. HTMX verbessert sowohl die User Experience als auch die Developer Experience erheblich.
Wenn man bedenkt, dass selbst bei sehr beliebten Projekten normalerweise bestehende Contributors den Großteil des Codes übernehmen, ist das ein starkes Wachstumssignal.
https://devboard.gitsense.com/bigskysoftware/htmx
Zur Einordnung: Das ist ein Tool, das ich gebaut habe.
Nachdem ich mir Website und Beispiele kurz angesehen habe, scheint der Schwerpunkt darauf zu liegen, dass Server-HTTP-Antworten vollständiges Markup enthalten und darauf basierend der Client-Zustand aktualisiert wird – also eher auf dem Neuschreiben des DOM.
Ich frage mich, ob htmx auch Zugeständnisse für rein clientseitige Trigger oder clientseitig erzeugte Inhalte macht.
Der Vorteil heutiger JavaScript-zentrierter Client-Frameworks besteht darin, möglichst viel Arbeit in den Browser zu verlagern und so Daten- und CPU-Nutzung auf dem Server zu reduzieren. Bei Web-Apps in großem Maßstab macht das einen großen Unterschied.
Ich frage mich, ob HTMX auch solche Engineering-Ziele erfüllen kann oder ob es ein Projekt mit einem völlig anderen Zweck ist. Mir ist klar, dass ein Client wie Facebook nicht hypermedia-orientiert ist, aber der Vergleich wird sich trotzdem kaum vermeiden lassen.
Es fühlt sich natürlich an, selbstdokumentierend und gut designt. Es fühlt sich wirklich wie eine natürliche Erweiterung von HTML an.
Das einzige fehlende Puzzlestück bei htmx ist für mich ein Komponentenmodell; für alle, die so etwas suchen, dürfte Astro[1] sehr gut dazu passen. Astro ermöglicht es, HTML-Komponenten zu definieren und zu verwenden, ohne den Runtime-Overhead von Vue oder React.
[1] http://astro.build
Htmx erinnert mich an Tailwind, weil es Attributnamen und -werte definiert, die zur Laufzeit von einer Library gelesen werden.
Dass kein Frontend-Build nötig ist, ist ein sehr großer Vorteil für die meisten Entwickler, die npm und webpack nicht anfassen wollen und es auch nicht müssen.
Die Grenze bei der Seitengröße scheint etwa bei einer kleinen Single-Page-App zu liegen; wenn es zu groß wird, kann man es vermutlich einfach in eine weitere Single-Page-App aufteilen.
Was React-/Vue-Entwickler besonders vermissen dürften, ist die Sichtweise, dass es ein einzelnes Objekt für den globalen Zustand gibt und eine in der Komponenten-Codebasis hierarchisch definierte Funktion dieses als UI rendert.
Allerdings ist auch diese Sichtweise selbst mit erheblichem Aufwand verbunden, führt zu vielen Meinungsverschiedenheiten und emotionalem Verschleiß und bringt den Frontend-Build samt seinen verwirrenden Varianten mit sich.
Ich nutze es noch nicht, bin aber schon ein großer Fan.
Gute Nachrichten
Ich habe im vergangenen Jahr htmx eingesetzt und dabei gute Ergebnisse und sehr lohnende Erfahrungen gemacht; besonders hervorragend war es beim serverseitigen Rendering mit hiccup in Clojure
Wenn man htmx einmal verstanden hat, ist es fast verblüffend, wie einfach und flexibel es ist. Es ist kaum zu glauben, warum sich HTML als Hypermedia nicht genau in diese Richtung weiterentwickelt hat
Es wird sehr klar, dass sich Webentwicklung eigentlich so hätte entwickeln sollen. Ich hoffe, dass das, was htmx heute mit JavaScript macht, eines Tages direkt in HTML und den Browser-Client eingebaut wird
Wenn man htmx fälschlich nur als eine Art Angular-Abkömmling sieht oder die Bedeutung seiner Weiterentwicklung der Hypermedia-Architektur nicht versteht, empfehle ich dringend, die hervorragenden Texte auf der Website zu lesen. Dann versteht man, was REST ist und warum echtes HATEOAS wichtig ist: https://htmx.org/essays/
Es gibt auch ein kostenloses Buch: https://hypermedia.systems/
Vor 10–15 Jahren sind wir auf einen kostspieligen Irrweg geraten: Statt Hypermedia, eine neue und mächtige Idee des frühen Webs, auszubauen und reichhaltiger zu machen, versuchten wir, mit JSON-API-Architekturen wieder dicke Clients auf dem Web nachzubauen
Ich freue mich, dass es htmx gibt und dass es für viele gut passt, aber in meiner Arbeit war es oft nicht die beste Wahl. Und das ist in Ordnung
Es ist großartig, dass das Web auf viele unterschiedliche Arten wachsen konnte, und man muss nicht davon ausgehen, dass es sich zwingend in eine bestimmte Richtung hätte entwickeln sollen
Der größte Fehler der Webentwicklung in den letzten etwa zehn Jahren war die Vorstellung, es müsse die eine richtige Antwort geben
Ob man das nächste Gmail oder einen statischen Blog baut: Der Cargo-Kult der Branche sagt, alles müsse auf dieselbe Weise gemacht werden, aber der gesunde Menschenverstand sagt etwas anderes
Für über 98 % des Webs dürfte das ausreichen. Für die restlichen 1,9 % kann man eine kleine JavaScript-Bibliothek verwenden
Nur die verbleibenden 0,1 % sind reine JavaScript-Webapps
Es wirkt wie dieselbe Idee: ein paar Attribute über HTML streuen, um einfache Fälle dynamisch zu machen
Angular 1, Vue und viele andere Frameworks haben so angefangen und sind, nachdem sie eine gewisse Popularität erreicht hatten, wegen realer Nachfrage nach schwierigeren Anwendungsfällen zu vollständigen Single-Page-App-Frameworks herangewachsen
Wenn ich ein „Angular-1-ähnliches“ Framework wählen müsste, würde ich eines nehmen, das seine Grenzen klar dokumentiert und einen klaren Pfad bietet, wann man beim Überschreiten dieser Grenzen ein ausgereiftes Single-Page-App-Framework einsetzen sollte. Falls jemand so ein Framework kennt, bitte teilen
Ich war schon Fan von HTMX, „bevor es cool wurde“
Ich freue mich sehr über das jüngste Interesse und den Erfolg und amüsiere mich auch ziemlich über den scherzhaften Spott und den Widerstand aus der Frontend-Ecke, die glaubt, das Web sei 2013 erfunden worden und sie hätten diese Stadt gebaut
Seit den Zeiten von Backbone.js hatte ich da eine Voreingenommenheit; schon damals verstand ich einen Teil des Schmerzes, war aber bis zu einem gewissen Grad skeptisch
Als danach React aufkam und junge, energiegeladene Leute anfingen, eine sehr simple Website mit 5 Seiten als Rube-Goldberg-Maschine aus Frontend-Frameworks zu bauen, habe ich meine Tech-Chips eingelöst und solche Dinge nicht mehr angefasst
Die Implementierungsdetails sind ziemlich anders, aber die Idee einer hypermediabasierten Anwendung stand im Zentrum von allem, was wir taten
Leider hat sie langfristig die Herzen der Leute nicht gewonnen, und bloggetriebene Entwicklung, also Cargo Cult, ersetzte unsere Bemühungen
Dass HTMX nun an Popularität zu gewinnen scheint, fühlt sich in gewisser Weise wie eine Wiedergutmachung an. Es ist schön zu sehen, dass wir nicht die Einzigen waren, die in solchen Konzepten gedacht haben
Natürlich könnte es auch heißen, dass meine Umsetzung mangelhaft war, wenn das Konzept stark war; vielleicht sollte ich mich also nicht zu sehr darüber freuen
Ich habe auch gehört, die Band habe ihre Gitarren verkauft und sich Turntables gekauft
Ich habe auch gehört, man habe HTTP-Endpunkte so umgeschrieben, dass sie JSON zurückgeben, und das sei REST gewesen
Ich habe auch gehört, die Band habe ihre Turntables verkauft und sich Gitarren gekauft
Ich habe auch gehört, man habe HTTP-Endpunkte so umgeschrieben, dass sie HTML-Template-Fragmente zurückgeben, und das sei HATEOAS gewesen
Ich verliere den Anschluss, finde ihn wieder, verliere ihn und finde ihn wieder
Allerdings war Backbone etwas locker gestrickt und bis Angular aufkam nicht besonders enterprise-tauglich
Jedenfalls wurde dieser Webanwendungs-Trend in meinem Umfeld populär, weil man Backend und Frontend trennen konnte und ein einziges Backend, meist REST/JSON, mobile und Web-Clients separat versorgen konnte
Das war der Grund, warum wir Single-Page-Apps gebaut haben, aber heute scheint das wieder vergessen zu sein
In meiner Welt ergab das für Apps hinter einem Login Sinn. Aber „sie“ wollten auch öffentlich zugängliche Sites wie Webshops als Single-Page-Apps bauen
Auch das kann ich nachvollziehen. Ich habe ein paar Websites mit Gatsby gebaut, und die Navigation ist wahnsinnig schnell, während sie trotzdem von Suchmaschinen indexiert werden
Nur wurde es in manchen Fällen immer komplexer, bis hin zu Dingen wie serverseitigem React. Zum Glück musste ich das nie anfassen
Einerseits hoffe ich, dass htmx, und allgemeiner Hypermedia, als Werkzeug akzeptiert wird. Es ist nützlich, aber am Ende eben nur ein Werkzeug
Ich hoffe, dass auch Frontend-Leute, die eine Weile nicht tief über Hypermedia nachgedacht haben, es so aufnehmen
Ich sehe die beiden Ansätze nicht als gegenseitig exklusiv und stimme Rich Harris’ Konzept der Transitional Web Applications zu, also der Mischung beider Ansätze
Ich ziehe nur die Grenze, ab der man Hypermedia aufgibt und zu einem ausgefeilteren clientseitigen Ansatz übergeht, an einer anderen Stelle als er
Ich denke das jedenfalls definitiv
Ich habe 1996 mit Perl angefangen und praktisch jede Strömung mitgemacht: PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL bis hin zu NextJS
Htmx fühlt sich wie ein Abzweig an, der aus diesem Strom herausführt, und ist es wert, darüber nachzudenken
Htmx stellt eine gute Frage: „Liegt die Komplexität deiner Arbeit im Kern auf dem Server oder auf dem Client?“
Bei den meisten Websites liegt die Komplexität im Kern auf dem Server. Die meisten von uns bauen weder Figma noch Google Sheets. Viele Websites sind, selbst wenn sie stark interaktiv sind, letztlich nur CRUD-Apps mit einer ansehnlichen Oberfläche
Frameworks wie NextJS versuchen, das Problem übermäßig komplexer Clients zu korrigieren, indem sie React auf den Server verlagern, erhöhen die Komplexität aber oft eher, als sie zu reduzieren
Wäre es dann nicht richtig, React aus dem Stack zu entfernen? Wenn es ein komplexer Client ist, kann man DOM und JavaScript überspringen und canvas sowie kompiliertes WebAssembly verwenden. Wenn es ein komplexer Server ist, kann man servergesteuerte, feingranulare DOM-Aktualisierungen nutzen
Das Problem, das ich bei diesem Ansatz sehe: Auch wenn die Komplexität der meisten Websites auf dem Server liegt, gibt es fast immer einige hochkomplexe Aufgaben, die auf dem Client liegen müssen. Bildbearbeitung, Sortieren, Filtern und Berechnen in Echtzeit sowie Drag- und Touch-Gesten gehören dazu
Es braucht einen hybriden Ansatz. Bloße Kompatibilität reicht nicht. Man kann htmx und React auf derselben Webseite verwenden, muss sie aber voneinander isolieren. Was ich möchte, ist keine Isolation, sondern grundlegende Integration
Das ideale Framework sollte reaktive, feingranulare Updates für das DOM unterstützen und zugleich eng mit kompiliertem WebAssembly integriert sein, das komplexe Client-Aufgaben übernimmt
Ich möchte den gesamten Code in einer mächtigen Sprache schreiben, nicht in JavaScript. Der Debugger sollte sowohl Server als auch Client abdecken, und der Unterschied zwischen beiden sollte verschwinden. Es sollte echte Full-Stack-Entwicklung sein, also eine Single-Stack-Anwendung
Clojure + ClojureScript wirkt zwar nahe an einer Single-Stack-Anwendung, aber nur oberflächlich
Wenn es für Common Lisp ein Killer-Framework gäbe, würde eine Single-Stack-Anwendung dafür perfekt passen
Der hybride Ansatz ist der von Astro propagierte Islands-Ansatz: https://docs.astro.build/en/concepts/islands/
Dieser Ansatz passt gut zu htmx und seinen Freunden, und wir verwenden in htmx-Projekten für die Teile, die Interaktivität brauchen, schlichtes Vanilla JavaScript dazu
Für kleine bis mittelgroße Projekte und kleine Teams kann das völlig ausreichen. Es ist wirklich erfrischend, die Entwicklertools zu öffnen, auf einen Teil der Seite zu zeigen und diesen Teil allein durch HTML und ein kleines JS-Snippet vollständig verstehen zu können
Ob Server oder Client: Man programmiert auf dieselbe Weise in C#. Beim ersten Laden der Seite wird alles serverseitig gerendert, danach übernimmt WebAssembly schrittweise und beginnt, C#-Code auf den Client zu laden, um UI-Interaktionen, die keine Serverdaten benötigen, schnell zu machen
Es funktioniert gut, aber die aktuelle Herausforderung ist, die Größe der WebAssembly-Dateien zu reduzieren. Derzeit liegen sie bei mehreren MB
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Glückwunsch. Es hat Spaß gemacht, mit Htmx ein kleines Projekt zu bauen, aber am Ende habe ich viel openlayers verwendet und mich deshalb für etwas anderes entschieden
Kartenbibliotheken sind bekannt dafür, clientseitig viel JavaScript zu benötigen, und für diese Aufgabe war Svelte das bessere Werkzeug
Ich plane, es künftig in Golang-Projekten wieder einzusetzen, und werde die Entwicklung weiter verfolgen
Wenn eine App ein einfaches oder mittelkomplexes Frontend braucht, und besonders wenn man bereits Template-Fragmente[0] verwendet, empfehle ich sehr, HTMX auszuprobieren. Selbst aus Sicht von jemandem, der aus der JavaScript-Welt kommt, macht die Arbeit damit ziemlich viel Spaß
Und die Person hinter dem Twitter-Account[1] ist wirklich witzig
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
Es fällt schwer, htmx als ernsthaftes Werkzeug zum Bau moderner Web-Apps oder Websites zu betrachten. Es fühlt sich so an, als mache es Funktionen unmöglich, die Nutzer inzwischen erwarten.
Zum Beispiel Facettensuche, bei der nach Datum vor/zwischen/nach gefiltert wird, die Filter aber nur angezeigt werden, wenn der Nutzer sie sehen möchte; oder die Möglichkeit, die Ergebnisansicht auf eine andere Spalte oder auf eine in
canvasgezeichnete Ansicht wie Karte oder Diagramm umzuschalten.Einiges davon lässt sich mit htmx sicher machen, aber irgendwann wird man am Ende doch JSON brauchen.
Angular kann solche Dinge ebenfalls, und mit etwas wie SolidJS lässt sich das tatsächlich ziemlich angenehm bauen.
Eine JSON API kann auch in anderen Apps wiederverwendet werden, htmx fühlt sich dagegen an, als hätte jemand Thymeleaf neu erfunden.
Ich dachte genauso, aber im Video wird konkret behandelt, wie Facettensuche mit htmx umgesetzt wurde.
Den zweiten Teil wird man vermutlich mit eigenem JavaScript oder mit hyperscript lösen.
Ob das ein guter Ansatz ist, weiß man erst, wenn man es wirklich baut und intensiv nutzt, aber mir fallen durchaus Szenarien ein, in denen es gut passt.
Der Punkt zur JSON API ist berechtigt. Wenn eine öffentliche API benötigt wird, sollte das in die Entscheidung einfließen. Aber nicht jedes Projekt hat diese Einschränkung.
Auch Smartphones haben mit der Suche in einer Tabelle mit tausend Zeilen keinerlei Probleme.
In so einem Fall würde ich mit htmx dem Nutzer einen breiten Datenbereich liefern und anschließend die feinere Echtzeitfilterung per JS erlauben.
Wenn auch Daten durchsuchbar sein sollen, die anfangs nicht angezeigt werden, kann man sie mit einer versteckenden CSS-Klasse mit ausliefern und diese Klasse entfernen, wenn sie gefunden werden.
Wie jede andere Technik passt auch htmx sehr gut zu bestimmten Problemklassen. Es ist in Ordnung, solange man es nicht zu Kunststücken zwingt, für die es nicht gut geeignet ist.
Solche Dinge sind komplex genug, dass sie ein gewisses Maß an vollständigem Scripting benötigen, und dagegen habe ich an sich nichts.
https://htmx.org/essays/hypermedia-friendly-scripting/
Durch die Umwege meiner Karriere habe ich die Frontend-JavaScript-Framework-Kriege fast komplett übersprungen, deshalb freut es mich zu sehen, dass ganz normales altes HTML gestärkt zurückkehrt.
Aus Sicht von Graceful Degradation ist das ein Rückschritt.
Ich finde, es braucht beeindruckende Beispiele, die mit htmx gebaut wurden. Es wäre gut, „made with htmx“-Beispiele zu haben, die eine neue Art von Web Experience erschließen.
Viele haben htmx auf einfache Anwendungsfälle festgelegt, für die man nicht die „schweren Geschütze“ auffahren muss.
Das ist bis zu einem gewissen Grad berechtigt, aber eingeschränkt. Der mit htmx verbundene Ansatz, zurück zum Server zu gehen, ist eine eigene Kategorie, die aus verschiedenen Gründen nicht früher erforscht wurde.
HTMX belebt auf backendunabhängige Weise alte App-Kategorien wieder.
Es tut nichts Neues oder etwas, das eine „neue App-Kategorie“ rechtfertigen würde.
Es ist eine Art, Hypermedia beziehungsweise contentorientierte Sites wie Shopping-Kataloge, Foren, Admin-Frontends oder Blogs zu bauen.
Ähnlich wie jquery/liveview/turbolinks, aber backendunabhängig und ohne viel, oder ganz ohne, Frontend-JS-Logik pflegen zu müssen.
Sobald schwere Interaktionen wie bei Google Docs oder Figma nötig werden, schrumpfen die Vorteile von htmx deutlich.
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Ein E-Commerce-Frontend, geschrieben mit HTMX und Hyperscript.
https://www.makaron.cz/
Man kann ein TodoMVC-HTMX-Frontend bauen, aber was nimmt man als Backend? Go, C#, Rust und einige andere Optionen wirken naheliegend, aber es hängt immer vom Kontext ab.
Ich erwähne C#, weil ASP.Net MVC + Razor sehr sauber zum HTMX-Paradigma zu passen scheint.
Ich habe mit ihnen nichts zu tun, aber es wurde mit htmx und etwas JS für komplexere Funktionen gebaut.
Wenn man bedenkt, dass htmx ausdrücklich das Ziel hat, einen guten alten Ansatz zu erweitern, bin ich mir nicht sicher, ob es eine „neue Art von Web Experience“ liefern kann.
Anfangs wirkt htmx gut, aber wenn man etwas bauen möchte, wofür man normalerweise JavaScript verwenden würde – ob Vanilla oder mit Framework –, etwa einen Dropdown-Button, landet man am Ende doch dabei, sich hyperscript anzusehen
Wenn man sich dann die Beispiele anschaut, gefällt einem nicht, dass im Code etwas steht, das wie Sätze aussieht, und man zieht weiter zu etwas anderem
Vielleicht sollte man htmx ohne hyperscript ausprobieren, oder hyperscript mehr Zeit geben
Aber wenn ich damit rechne, etwas über mehrere Jahre zu warten, ist es mir zu ungewohnt, und ich möchte nicht daran gebunden sein, falls ich es später nie wieder verwenden sollte
htmx selbst ist völlig egal, welches Tool für clientseitige Interaktionen man verwendet; das ist also eine separate Frage davon, ob htmx nützlich ist
Persönlich würde ich, wenn ich JS-Build-Tools usw. vermeiden wollte, htmx + Alpine.js wählen
Wie soll man damit umgehen, wenn er größer und komplexer wird?
Ich habe einmal bei einer Anwendung geholfen, die htmx verwendet hat, und es gab zwei Probleme. Mich würde interessieren, ob andere ähnliche Erfahrungen gemacht haben, ob das Probleme durch falschen Einsatz der Technik waren oder ob daran gearbeitet wird, sie zu lösen
Erstens war im Controller viel Custom Middleware nötig, um zu entscheiden, ob ein Endpoint das HTML der ganzen Seite zurückgeben sollte oder nur das Fragment, das htmx benötigt
Auf der htmx-Seite wirkt das simpel, aber vermutlich ist das ein Teil, den jedes Projekt mit htmx erneut bauen muss
Zweitens war rund um
hx-triggereiniges an Buchhaltung nötig. Wenn die UI komplexer wird, müssen viele Elemente auf externe Änderungen reagierenStatt einfach einen Zustand zu lesen und zu erwarten, dass ein Framework Updates einplant, mussten wir die Liste der Events, auf die reagiert werden soll, selbst verwalten
Hat jemand Ähnliches empfunden?