Vergiss JavaScript! So verändert HTMX die Webentwicklung

In diesem Video erfährst du alles über HTMX, ein leistungsstarkes FrontEnd-Framework für die Web Programmierung. Ich zeige dir die Grundlagen und warum HTMX so genial ist. Als BackEnd nutzen wir einen kleinen Express Server.
Lerne, wie du HTMX in deinem Code einsetzen kannst, um deine Webanwendung zu vereinfachen.
Ressourcen:
HTMX: htmx.org/
Vollständiger Code: github.com/lor...
Abonniere meinen Kanal für mehr Videos über Programmieren, HTML und JavaScript! #HTMX #Express #FrontEnd #Tailwind #WebProgrammierung #Code #Website #Framework

[@nmbr73]

Sehr sehr geiles Video - Respekt! Hat richtig Spaß gemacht es zu gucken!

[@sebastianbechtold7157]

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.

[@charonissimo7683]

Danke! Ich bin zwar ein Anfänger, aber freue mich auf mehr

[@lorisgaller]

Freut mich, wenn es dir gefallen hat und bleib dran! :)

[@PaAndy89]

Geil, 10 Jahre nach Angular 1 machen wir das gleiche einfach nochmal 😂

[@shevchyc]

Mein Lieblingsyoutuber ist wieder da 😍

[@robinsmit9603]

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.

[@clumsyjester459]

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.

[@mx_darwin043]

⁠@@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.

[@clumsyjester459]

@@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.

[@mx_darwin043]

@@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.

[@dorklol2969]

geiles video, danke dafür und meinen sub haste :) nen deutscher bigbox oder fireship fehlt noch

[@lorisgaller]

Dankeschön!! Das find ich auch! :D

[@sucellio5973]

Bisher das beste Video auf youtube im Jahr 2024

[@BastetFurry]

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. ;)

[@clumsyjester459]

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.

[@henrx02]

Sehr gutes Video 👍

[@josh4play.youtube]

wirklich gutes video thx ✌

[@borsenbringer3125]

What ??? Wieso habe ich diesen krassen Channel erst so spät entdeckt ??

[@lorisgaller]

🤣

[@smatplacid]

Wegen des hyper geilen Algorithmus von YT 🤷‍♂

[@MetalheadAndNerd]

Bauen wir hier gerade eine Webseite, die 500 Requests macht, bis sie fertig geladen ist?

[@timgraf7933]

An sich ganz gut. Schauen wir mal, ob es sich durchsetzt.

[@lukass7450]

Gut erklärt! htmx finde ich geeignet für einfache oder simple Webseiten

[@clumsyjester459]

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"?

[@pinkeHelga]

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.

[@amigalemming]

Klingt ganz nützlich, aber die Durchschnittswebseite wird wahrscheinlich trotzdem weiterhin mit Tonnen von extern eingebundenem JavaScript-Werbemüll voll sein.

[@shevchyc]

Ich warte auf ein Video über SASS/SCSS! 😮

[@clumsyjester459]

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?

[@mx_darwin043]

Tailwind regelt 😁

[@PySnek]

Nicht schon wieder ein neuer Webdev Furz. Alle paar Monate wieder... Da dreht man doch durch!

[@Foreversun33]

😢

[@benjaminkieper568]

Die erst Version ist von 2013. Das Konzept ist nicht neu... Ansonsten finde ich das Video gut.

[@lorisgaller]

Richtig. Vielen Dank für das Feedback! :)

[@dustsucker4704]

HTMX ist geil bis du eine zweite applications hast die die API nutzen soll.

[@clumsyjester459]

Ich bau lieber eine Backend-Anwendung, die sowohl HTML, als auch JSON renderen kann, als mich in einem Frontend Framework mit asynchronem JS rumzuschlagen.

[@sen-sha]

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: kzbin.info/www/bejne/in2Yhaemj5hmrrc

[@user-cj4iw8oz8f]

Kannst du auch selber denken oder hast überhaupt Ahnung von Softwarearchitektur? Das ganze kannst du doch durch eine Schichtenarchitektur lösen.

[@sen-sha]

@@user-cj4iw8oz8f Es hindert Dich niemand daran genau das zu tun. Und auf dieser Basis komplexe Anwendungen zu realisieren.

[@andreassandkuhler4672]

@@user-cj4iw8oz8f Sehe ich auch so

[@andreassandkuhler4672]

Man macht sich einfach einen Zwischenserver, der Inhalte aufbereitet.