In purer Form (d.h. ohne auch ein "klassisches" Front-End-Framework wie Vue/React etc.) zu haben, erscheint mir das für "ernsthafte" Anwendungen zu beschränkt. Allerdings: Ich habe als Teil meiner eigenen Vue-Komponentenbibliothek tatsächlich etwas grob ähnliches gebaut. Damit kann man u.a. ebenfalls HTTP-Requests und deren Integration in das Datenmodell der Seite rein deklarativ im HTML (bzw. der Vue-Templatesprache eben) definieren. Das ist wirklich sehr einfach und praktisch. Mit anderen Worten, die Idee ist grundsätzlich gut, aber die Erfahrungen von 15 Jahren moderner Web-Frontend-Frameworks sollte man dafür nicht komplett über Bord werfen. Als Ergänzung super, als Ersatz kaum.
Sieht interessant aus. Muss ich mir mal reinziehen. Bin zwar nicht mehr beruflich Entwickler, sondern in Rente. Aber eben deshalb habe ich jetzt wieder Zeit für solche interessanten Dinge.
Klingt prinzipiell geil. Ich Stelle mir das nur unglaublich nervig vor, wenn komplexes HTML zusammengestellt werden soll. Um z. B. gut aussehende Input-Felder und Formulare zu ermöglichen. Wenn ich mir überlege wie so ein Multiselect Input aussehen kann und was da JS seitig zusammen gerendert wird, möchte ich das nicht zum Problem des Backends machen. Da finde ich das Konzept (Web-Server) Backend liefert nur Daten (als JSON) und FE Interpretation der Daten sowie Rendering des FE viel besser. Es ist klarer in seinen Aufgaben getrennt. Trotzdem finde ich die Idee ganz cool für einfache kleine Themen.
Bisher fand ich es eigentlich immer einfacher, die Formulare im Backend zu rendern. Mit einer vernünftigen lib ist das eine Zeile pro Feld, z.B. "f.input :age, collection: 18..60" mit "simple_form" in Ruby on Rails. Wenn du mehr interaktive Elemente brauchst, darfst du natürlich weiterhin JS schreiben. Gibt genügend libraries, die nur Komponenten "hydrieren" und denen egal ist, wie die Komponenten ins DOM gekommen sind, z.B. Stimulus, Alpine.js, die "compiler" von Unpoly. Ich bin in keinem Frontend Framework Experte, aber gefühlt ist "React + Backend API" ungefähr 5x mehr Aufwand als "htmx/Hotwire/Unpoly/Livewire/Inertia + server-side rendered". Und wenn du die API sowieso brauchst, dann baue ich dir zu meiner Server-side rendered Anwendung noch ne API dazu und bin trotzdem schneller, wenn ich mich nicht die ganze Zeit in irgendeinem JS framework mit asynchroner Logik rumschlagen muss.
@@clumsyjester459das hat halt viele andere Hintergründe weshalb Frontend Frameworks wie Vue, React, Angular usw benutzt werden. Komponenten/Design Systems Asynchrones Rendering von komplexen Komponenten, State Management, Frontend Routing -> Micro Frontends usw. Ich glaube es kommt immer auf die Größe und Komplexität des Projektes an. Ich denke kein frontendler hat Lust darauf 500 html Seiten anzufassen für kleine UI Änderungen, die bestimmt Element beinhalten.
@@mx_darwin043 Komponenten/Design Systems -> geht auch im Backend. Asynchrones Rendering -> hat Vorteile, macht aber auch alles 10x komplizierter. Frontend Routing -> wieso sollte das ein Vorteil sein? Was spricht gegen normale Links und backend routing, solange das keinen full page-reload verursacht? State Management -> Ja, htmx Seiten funktionieren selten in einem "offline Modus". Sie speichern einfach so viel State wie möglich immer sofort im Backend. Aber nur weil man das mit einem echten JS framework theoretisch bauen könnte, ist das ja auch nicht geschenkt. Das muss eine Seite schon "wirklich" brauchen, damit sich dieses Feature lohnt.
@@clumsyjester459 ich glaube backend Komponente, die oft einfache partials abbilden kann man schlecht damit vergleichen. JS Frameworks nutzen hier einen Virtual DOM, Lifecycle hooks, slots fürs dynamische templating usw. Das dem ganzen Dynamik und Performance boost bietet. Das Design System bezog sich auf ein z.B Storybook bei denen Base Komponenten definiert und erstellt werden anstatt einfache CSS Klassen. Asynchrones Rendering wird mittlerweile über einfache helper functions, die von dem Framework mitgeliefert werden, abgefrühstückt. Frontend routing nutzt (wenn man es einstellt) die normale Browser History Api womit man die normalen Browser Funktionen weiter nutzen kann. Ein reines Skelleton zu laden ohne overhead erwies sich gerade hinsichtlich SPAs als sehr performant. Ein State Handlung nutzt mit idR für durchaus mehr als nur den offline Modus. Sich auf eine Seite zu befinden und User Informationen im Store geladen zu haben und sie dynamisch überall verwenden zu können ohne erst ein backend zu callen hat oft seine Vorteile. Man sollte es da nur nicht übertreiben und 30 calls beim initialen laden machen, da gebe ich dir recht. Ich habe die letzten 5-8 jahre an Produkte gearbeitet, die aufgrund der Architektur es voraussetzen. Meistens 10-20+ micro services usw.
Der große Bruder von htmx ist Unpoly. Kann hier keine Links posten, aber google mal Audi Mediacenter und drück F12. Ist das deiner Meinung nach noch eine "einfache oder simple Webseite"?
Ist es so ein Riesen-Vorteil, wenn man auf Javascript verzichten kann? 🤔Wird nicht einfach eine komplizierte Technik weggelassen und dafür eine andere vorher einfache Technik verkompliziert?
Seitdem CSS nativ Variablen und nesting kann, ist das doch nahezu überflüssig. Ja, Mixins fehlen noch ein bisschen. Aber dafür einen eigenen preprocessor?
HTMX wird immer so mystifiziert, daß es wie ein ganz neuer Standard wirkt. Es ist eine JavaScript-Bibliothek, die Custom-Elements als zentrales Konzept verfolgt. Das ist mittlerweile ein alter Hut, wurde auch von Knockout implementiert und auch HTMX ist schon über 10 Jahre alt. Das Konzept hatte sich nicht durchgesetzt und wird in jüngster Zeit wiederentdeckt.
Dasselbe habe ich vor über 12 Jahren selbst implementiert. Nichts daran ist neu. Es hat sich nicht durchgesetzte, weil es strukturell falsch ist. Und deswegen wird sich diese nicht heute Idee auch wieder nicht durchsetzen.
Wer keinen Wert auf Standards legt (wie Model-View-Control, Responsive Webdesign etc.), damit keine komplexe Webseite bauen will und/oder auch Spaß an der Fehleranalyse bei z.B. einfachen Tippfehlern hat, dem sei es gegönnt. ODER: wer wenig Programmiererfahrung hat und mit wenig Aufwand kleine und einfache dynamische Anwendungen erstellen möchte - dafür ist es gut! Have fun! :) Ich - als erfahrener Entwickler - rate davon ab.
Klingt ganz nützlich, aber die Durchschnittswebseite wird wahrscheinlich trotzdem weiterhin mit Tonnen von extern eingebundenem JavaScript-Werbemüll voll sein.
Ich bau lieber eine Backend-Anwendung, die sowohl HTML, als auch JSON renderen kann, als mich in einem Frontend Framework mit asynchronem JS rumzuschlagen.
Naja... am Ende wird das JS auch nur vorm Entwickler versteckt und fügt damit Komplexität hinzu die die CPUs der Anwender ausbaden dürfen. Und ja, das sind pro User nur ein paar Cycles mehr, aber wenn Hunderttausende im Schnitt je ein Watt pro Seitenaufruf mehr verbrauchen müssen, nicht vergessen das die Übertragung einer Bibliothek auch wieder Netzwerkverkehr verursacht und damit Strom verbraucht, läppert sich das schnell irgendwann zu nem Megawatt. Nur weil unnötigerweise eine Bibliothek verwendet wurde statt zu überlegen wie mans ohne und am besten gleich ohne JS hinbekommt. Das bedeutet dann auch das man vielleicht doch das ein oder andere Projekt wieder mit statischen Seiten durchführt, den spätestens ein Blog Beispielsweise muss nicht erst bei jedem Seitenaufruf nen Backend mit ner Datenbank bemühen, da kann man sich auch nen Seitengenerator bauen der einfach alles als HTML mit nem CSS Kleid ausspuckt das man dann hostet. Wenn man das von überall editieren können will kann man ja immer noch ein Backend bauen was dann per Klick die Änderungen in den Statischen Teil überführt. Oder einfach per SSH auf den Server, die Basisdateien, könnte ja Markdown sein, editieren und den Generator auf der Shell aufrufen. Nur fraglich ob der durchschnittliche User damit klar kommt weil Hilfe Hilfe ne Shell. ;)
Schau dir mal Unpoly an. Im Gegensatz zu htmx, welches erwartet, dass man ihm immer genau die passenden HTML fragmente liefert, geht Unpoly davon aus, dass der Server immer volle Seiten rendert und schneidet sich dann mit CSS Selektoren das raus, was es braucht. Funktioniert super mit statischen Seiten als Backend. Ja, ganz ohne JS wäre es noch schöner, aber dann muss dein Browser bei jedem page refresh das ganze HTML und CSS neu parsen. Ist also auch nicht gratis. Da denkt nur immer keiner dran.
Nach diesem Video wirst Du sehen, warum HTMX ziemlicher Unsinn und ein Konzept ist, welches es vor über 10 Jahren bereits mal gab und seit dem aus gutem Grund nicht überlebt hat. Und deswegen auch nicht wirklich zu empfehlen ist: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-TL5TtpZ33xU.html
