Transcript: HTMX

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode 38.

Dieses Mal wollen wir etwas über HTMX sprechen.

Hier ist der Dominik, bei mir ist wieder der Jochen.

Ja, hallihallo, willkommen Dominik.

Und wir haben heute einen neuen Gast, und zwar den Thomas. Hi Thomas.

Hallo, grüß dich.

Jo, hallihallo.

Schön, dass du da bist.

Ja, fangen wir wie immer an mit ein bisschen News aus der Szene.

Ja, oder vielleicht kann sich Thomas kurz vorstellen, so ganz...

Das wollte ich dann bei HTMX machen, aber weißt du was, du hast recht.

Eigentlich müssten wir das am Anfang stellen und sagen, Leute, hallo, und man weiß gar nicht, wer das ist.

Deswegen sag doch mal, Thomas, was machst du denn?

Ja, ich mache Softwareentwicklung. Das schon eine ganze Menge Jahre. Habe vor 20 Jahren mal Informatik studiert und vorher schon auch als Kind daran Spaß gehabt. Und ja, mache hauptsächlich eben Webentwicklung mit Python und Django, PostgreSQL und eben seit neuestem auch mit HTMLX. Und ja, hier, Jochen hat mich mal angesprochen, wollen wir nicht einen Podcast machen? Dachte ich, ja, schön, bin ich dabei. Und ja, jetzt bin ich hier.

Ja, sehr schön. Ja, sehr cool.

Ja, okay. Dann gehen wir noch

zu den News über. Erstmal ein bisschen News, ja.

Ich glaube, ich habe auch fast gar nichts

aufgeschrieben. Oh doch, Python 3.6

ist draußen, end of life.

Ich glaube, es war am 23.

Dezember oder so.

Also Weihnachten.

Weihnachtsgeschenk, eure Version ist duplicated.

Ja, das heißt

quasi die erste

Version Python 3, wo

viele Leute irgendwie das Gefühl

hatten, das ist jetzt besser als Python 2.

Ist jetzt auch End of Life.

Das heißt, ja, also

krass. Als ich das gesehen habe, dachte ich so, wow,

das ist schon wieder so lange her.

Bei 3.6 habe ich, glaube ich, angefangen.

Das ist schon gar nicht so lange her.

3.7 kam dann relativ fix und jetzt, ja, ging es schnell.

Also meine News,

ich habe noch gelesen, dass Python Programmiersprache

des Jahres 21 geworden ist.

Wir werden famous und beruhigt.

Ganz wichtige News.

Ja, es gab jetzt auch wieder eine neue Version

von diesem TOB

Index, wo Python

auf Platz 1 ist.

Allerdings muss man dazu sagen,

vielleicht, dass das irgendwie, also

so wahnsinnig viel kann man da nicht draus lesen.

Ja, ist doch eigentlich relativ wurscht.

Ja, ich habe letztens, wo habe ich das gehört?

Ein programmierbarer Podcast war es, glaube ich.

Dass da jemand meinte so, ja, das ist irgendeine

niederländische Firma und das, was die machen, ist,

sie machen irgendwie

neben den Namen der Programmiersprache,

machen Programming dahinter und

googeln dann danach und dann zählen sie die

Anzahl der Suchergebnisse. Das ist mehr oder weniger, was

sie tun. Und das ist

natürlich irgendwie, ja, gut, ob das jetzt so

einem wahnsinnig viel sagt, ist halt

unklar.

Das habe ich von dir noch nicht gehört.

Ja, ich höre

immer so, was es an anderen Podcasts auch so gibt.

Ja, deswegen, vielleicht ist das auch mal interessant, dass man

mal kurz darüber erzählt. Ja, also

da geht es meistens so um Frontend-Themen.

Also es gibt erstaunlich, das ist auch so was,

das finde ich immer ein bisschen komisch,

dass es, es gibt einige

Podcasts, die sich mit dem Thema Programmierung

und so beschäftigen, aber

fast alle eher so Frontend.

Also es gibt zum Beispiel Webwork,

nee, nicht Webwork, das ist ein Meetup hier in Düsseldorf.

Working Draft

heißt einer, auch einer

der vielleicht der älteste

Webentwicklungspodcast und

sicherlich einer der bekanntesten,

auch mit Leuten hier aus Düsseldorf

und ja,

das ist aber auch sehr Frontend-lastig

und

genau, programmierbar,

ist relativ neu, ist halt auch

sehr frontendlastig. Folge 116,

die machen häufig Dinge,

ja, aber, achso, vielleicht auch nicht so neu.

Ja, aber gut, Moment, wenn ich hier gerade sehe,

3. November, 2. November, 10. November, 12. November,

17. November, 24. November,

also ja, die Page ist relativ häufig.

Ja, Working Draft

hat irgendwie über 500, 531

sind es jetzt irgendwie oder so, weil

wir machen einmal die Woche.

Das ist schon, ja. Ja, da brauchen

wir noch ein bisschen.

ja. Wie sagt jemand mit dem

Gameboy, kann man jetzt in 50.000 Jahren

einen Bitcoin meinen?

Ah ja, okay. Irgendwie so,

die Zahl ist jetzt auch noch rein aus der Luft.

Ja, und dann gibt's, also

was ich auch manchmal noch höre, ist sowas, also

wenn es deutschsprachige Geschichten sind, Englischsprache

gibt's natürlich endlos jede Menge, aber

gibt's noch sowas wie Software-Architektur

im Stream.

Höre ich manchmal.

Und

InnoQ hat ein paar Podcasts,

ist eine Firma und die hat auch was mit dem, also

der Mensch, der

Software-Architektur im Stream macht, der

arbeitet da auch.

Und da

arbeitet auch jemand, also der

Stefan Tilkoff arbeitet da auch und

der ist auch viel

in anderen Podcasts unterwegs, da habe ich auch

einen Working Graph zum Beispiel.

Mal ein sehr schöner,

auch passend zum Thema, was wir gleich,

worüber wir gleich reden wollen,

da gibt es eine Episode zum Thema

Single-Page-Apps und

irgendwie, was ist eigentlich REST und so und die ist

sehr empfehlenswert. Oh ja, was eigentlich

REST ist, darüber wollen wir auch gleich sprechen. Ja,

genau, darüber haben wir auch schon mal

eine Episode gemacht.

Ja, aber also so in dem,

also so ganz kurz muss man es ja gleich wieder erwähnen, weil

das ja so ein bisschen heute auch darum geht. Ja,

stimmt. Dann gibt es noch

Wo wir sind ist vorne.

Das ist eigentlich ein sehr super, super

produziertes Ding. Der Titel ist toll.

Ja, der Titel ist toll und die Grafiken

sind toll und das sieht alles toll aus und die Webseite

das toll. Aber ja, es ist halt auch ein sehr frontendlastiger

Ding. Die machen halt auch

Streams und ja.

Genau. Und ich

meine, das sind so fast, dann gibt es noch so ein paar

KI-Geschichten,

die ich höre, da habe ich die Namen jetzt nicht und die

höre ich auch sehr unregelmäßig, weil meistens gefällt mir das

gar nicht so gut. Oh, aber das mit den BVC sind vorne

sieht so gut aus. KI in der Industrie, glaube ich, ist eine.

Das gefällt mir eigentlich ganz gut, da bin ich gespannt.

Ja. Ansonsten mehr fällt mir jetzt ehrlich

gesagt nicht ein, was es da auf Deutsch gibt.

Ja. Fällt dir noch was ein,

Thomas, dazu?

Nö, meine Überlegung gerade war bloß,

ob es im DevOps-Bereich

über Kubernetes oder irgend sowas, also

im deutschsprachigen Raum noch was gibt.

Naja,

keine Ahnung. Vielleicht gibt es das,

aber das ist auch etwas, wo ich gar nicht nachgucken würde

oder weil es mich gar nicht

so sehr interessiert.

Glaube ich, würde ich das auch gar nicht mitbekommen.

Niko hatte, glaube ich, so ein, zwei Sachen da

in den Techniken gemacht, aber der hat auch

glaube ich schon ein halbes Jahr nicht mehr neue

Folgen released. Also weiß ich nicht, ob es die noch gibt.

von dem habe ich letztens gehört,

da macht er irgendwie so ein Live-Webinar-Ding,

Stream, auch eher so Richtung Stream geht das.

Okay, okay.

Aber ja, stimmt, der macht natürlich,

also Tech-Tiefen, vorher hieß das irgendwie anders.

Ja, der macht auch nicht nur Frontend-Themen,

sondern alles Mögliche.

Auch so ein bisschen mit Schwerpunkt auf Data Science, aber...

Mhm, cool, ja.

Ja, ja.

Ja, ansonsten weiß ich nicht.

Gab es in der Python-Welt irgendwelche Neuigkeiten,

irgendwelche interessanten Dinge?

Hm, sonst...

War ja so eine Jahrespause, ne?

Ja, der Jahreswechsel ist immer ein bisschen ruhiger.

Ja, nö, ansonsten weiß ich da auch nichts mehr.

Dann sind wir dieses Mal mit dem Erstaunlichen früh durch.

Jo, und wie wir ja schon angekündigt hatten, angedroht,

gibt es nur noch ein bisschen Werbung.

Der Sponsor für diese Episode ist NordVPN.

Das ist ein VPN-Anbieter.

und da könnt ihr etwa auf notbpn.com

slash pythonpodcast gehen

und bekommt da 73% Rabatt

auf ein Zwei-Jahres-Paket

und noch einen Gratis-Monat extra.

Und genau, wenn euch

das nicht zusagen sollte, könnt ihr das auch

innerhalb von 30 Tagen kündigen,

ohne dass euch da Zusatzkosten entstehen.

Und ja, könnt euch immer angucken.

Ist vielleicht ganz nett. Manchmal braucht man das ja schon.

Also ich war zum Beispiel letztens

im Urlaub und

wollte da die Dinge weitergucken, die ich normalerweise so gucke

und musste dann feststellen,

Nee, das geht nicht, weil Streaming-Dienstleister

hat festgestellt, man ist woanders, als man normalerweise ist

und dann geht das halt nicht mehr.

Und da möchte man dann vielleicht doch

eher nur so auf irgendwo

V4N aktivieren, klicken und dann geht das halt

einfach weiter und

hatte ich nicht, muss ich mir überlegen,

ob ich das nicht vielleicht mal haben möchte

für den Fall.

Ja, auch wenn ihr

einen lokalen Internet-Service-Provider

habt, der vielleicht nicht so auf der Höhe

ist, was seine Peerings angeht, dann könnt ihr

da euch zu einem besseren Internet-Erlebnis

verhelfen, indem ihr einen VPN benutzt.

Ja, genau.

Und wenn ihr das mal ausprobieren möchtet, einfach auf

nordvpn.com slash pythonpodcast gehen

und ausprobieren.

Vielen Dank an NordVPN

für die Unterstützung.

Und dann geht es direkt in das Thema rein.

HTMX.

Was ist denn das?

Oh, das weiß ich auch nicht so genau.

Das sind die High-Power-Tools für

HTML, so hat es denn der Mensch

genannt, der das erfunden hat,

um einfach HTML so zu erweitern,

wie es der Standard bis jetzt nicht zugelassen hat.

Also, dass man keinen JavaScript mehr braucht,

um coole, responsivee Sachen im Web zu bauen.

Doch, JavaScript brauchst du schon.

Ja, aber du musst es nicht mehr schreiben, so wirklich.

Ja.

Ja, es wird dann so deklarativ.

Das ist eigentlich schon nicht schlecht.

Es entwickelt sich ja alles,

so ein bisschen in die Richtung spricht.

Ja, vielleicht noch mal ganz kurz, was das so ist.

also, worum es da geht, also

wie machen wir denn normalerweise jetzt Frontend

und Backend? Trennen wir das? Wie war das denn

früher? Und

ja, warum dann

HTMX? Also was ist das so die Idee dahinter? Also ich glaube,

früher war es einfach nur so, du hast

den Server gefragt und der hat dir dann die Webseite fertig

geschickt.

Nein, weil ganz früher,

ganz, ganz früher. Also das ist die Frage,

wie früh hättest du es denn gehabt?

Anfang der 90er oder so. Also ich würde

ja sagen, also das Web ist ja im Grunde

ein sehr neues Modell.

Also insofern, das ist das Gute.

Fangen wir gerade mit dem harten theoretischen Kram

an. Ich frage, ob das so ein guter Einstieg ist, aber

Ich weiß nicht.

Naja, also Web ist ja

eigentlich revolutionär in vielen

Eigenschaften, die es so hat

und halt ganz anders als irgendwie

die Dinge, die man vorher gemacht hat. Was man vorher gemacht hat,

ist halt so Client-Server zum Beispiel.

Oder Remote-Procedure-Calls

oder sowas. Solche Dinge.

Das ist halt alles deutlich älter als das Web.

Und Web ist halt eigentlich was anderes.

Aber ich glaube, die Geschichte erzählen wir gleich.

Und dann, was ist denn Web?

Dann erzähl doch erstmal, was denn Web ist.

Ja, naja, also Web ist halt sozusagen da, ja, wie definiert man das?

Es gibt halt diese, das hatten wir, wie gesagt, in der Restepisode,

diese Dissertation von Roy Fielding, der halt auch an dem Startenarzt

da maßgeblich mitgearbeitet hat mit Tim Berners-Lee.

Und der hat da seine Dissertation irgendwann drüber geschrieben.

Und da definiert er, was er quasi meint, was das ist,

so als REST, also Representational State Transfer oder so.

Aber es ist halt die Frage, ob das so interessant ist.

Ja, ich glaube, das hatten wir ja schon in der REST-Episode.

Ich glaube, da müssen wir es gar nicht sagen.

Ja, im Grunde so ganz, ganz, ganz grob ist es halt irgendwie,

es geht darum, dass der Client im Grunde nicht mehr viel wissen muss.

Dass man halt alles, was an Informationen man braucht,

um halt irgendwie einen Client betreiben zu können,

ja, sozusagen, dass das halt alles mitkommt.

Also sozusagen, dass man halt auch mit einem alten Browser halt zum Beispiel Dinge machen kann, dass man jetzt nicht immer den neuesten Browser haben muss. Bei Client-Server war das Problem früher immer, wenn man da irgendwie was geändert hat, dann muss man immer dafür sorgen, dass auch die aktuellste Version vom Client irgendwie geschippt wird, weil ansonsten funktioniert das halt nicht mehr.

Genau, genau.

Und das ist mit Web, also mit REST und Web ist es eigentlich dann insofern besser, als es halt auch mit alten Browsern noch funktioniert.

Man muss sich nicht darum kümmern, dass die Leute halt immer den aktuellsten Browser haben.

Und es sollte eigentlich mit jedem Browser funktionieren und so.

Und der Browser muss nicht wissen, was da kommt.

Also wenn ich jetzt zum Beispiel, das ist halt genau eine von diesen Geschichten, die halt jetzt bei diesen ganz modernen Geschichten in Anführungsstrichen,

also dieses Single-Page-App-mäßigen Teilen, halt wieder so ist wie ganz, ganz früher.

Jetzt hast du wieder was gesagt, das Single-Page-App-Teil.

Und ich glaube, das müsste so ein bisschen strukturierter sein.

Ich glaube, wir sind ja gerade schon wieder sehr in der Historie drin.

Ja, du hast danach gefragt.

Ja, ja, ich habe ja gesagt, wir müssen das auf jeden Fall später auch noch mal erzählen.

Gerade was Kleinserver und so ist.

Aber der, glaube ich, der entscheidende Unterschied, was hat MX, das halt macht,

diesen modernen Trend, dass man halt eine Single-Page-Application braucht,

um Frontend schön darzustellen, ersetzen kann.

Und zwar mit Auslieferung vom Backend, also so Server-Seiten.

Aber vielleicht will ja Thomas das gerade genau da jetzt noch mal einsteigen.

Also bei HTMLX, das ist sicherlich auf JavaScript basiert, anders kommt man ja in den Browser nicht wirklich rein, um dort irgendwas zu programmieren im Browser, aber Ziel der Übung ist eigentlich, dass der Endanwender, also der Entwickler dann kein JavaScript mehr schreibt oder wenig JavaScript und da wird HTML erweitert um neue Attribute,

Sodass man es HTML klassisch verwenden kann, also wie es eben vor 20 Jahren gemacht wurde, sprich vom Server zum Client kommt HTML, gegebenenfalls auch HTML-Schnipsel oder so ähnliches und man braucht das jetzt nicht in ein JSON-Format erstmal konvertieren und dann am Client wieder aus dem JSON dann irgendwie HTML machen oder DOM-Objekte machen.

Das ist eben so recht revolutionär eigentlich. Revolutionär so hingegen, weil es halt wie das Wort revolutionär ist, am Ende rückwälzend, wird zurückgewälzt auf den Status, wo wir eben vom Server zum Client HTML geschickt haben und geht dann da sozusagen einen anderen Weg.

Und mir persönlich hat es sehr gut gefallen, dass man dann sagt, man hat eben eine übliche HTML-Seite und kann dann kleine Schnipselchen eben interaktiver und ähnliches gestalten und muss sich das nicht so komplizierte Frameworks ranziehen wie React oder Vue. Das kann man mit einfachen Mitteln eine ganze Menge erreichen und das fand ich ganz cool, hab's mal ausprobiert in einem kleinen Projekt. Ja, und da bin ich jetzt hier, um ein bisschen davon zu erzählen.

Ja, ich finde es auch super spannend. Ich habe ja schon seit einiger Zeit davon und genau, also wenn man sich anguckt, was sind die meistgesehenen Talks eben auf sowas wie, das ist auch der Grund, warum wir auf dich Thomas gekommen sind, irgendwie bei DjangoCon EU oder DjangoCon US, das ist halt HTMX, das ist halt ganz heiß irgendwie und ja, ich kann es auch sehr gut verstehen.

Also ich habe irgendwann mal angefangen, mich auch mit diesen Frontend-Frameworks so ein bisschen zu beschäftigen und für mich war damals der Grund, warum ich das gemacht habe, dass ich gerne so ein UI-Anmutung gerne hätte wie bei einer nativen Applikation sozusagen.

Also das hat man ja halt so früher eigentlich bei Webseiten nicht so wirklich gehabt, weil, naja, da hat man immer Request-Response-Cycle irgendwie und das dauert dann halt einfach und man sieht das auf jeden Fall, dass da was passiert und es ist halt nicht so schnell, als wenn man jetzt halt irgendwie eine, irgendwie in Anführungsstrichen klassische App hat, die halt irgendwie lokal auf dem Rechner läuft.

Und für mich war das halt so, das Versprechen dieser quasi Frameworks, dass man das halt auch im Browser so hinkriegen kann, dass man da keine Latenz mehr hat und dass das halt alles super schnell ist und dass sich das anfühlt wie was Natives.

Und das hatte mich interessiert und da dachte ich, okay, naja gut, wenn man das halt so machen muss, dann geht das halt nicht anders und dann muss ich halt dieses komische JavaScript-Zeugs da mitmachen. Okay, aber wenn ich dafür diese UI-Geschichte kriege, dann ist es das ja vielleicht wert.

Weil das ist ja tatsächlich so ein bisschen so eine nervige Geschichte. Und ja, ich dachte eigentlich immer, der Grund, warum das bei normalen Web-Anwendungen oder Webseiten so ein Problem ist, lag an diesem Request-Response.

weil es dauert halt irgendwie, je nachdem, wo ein Server

steht, hat man allein Latenz

bei einem Request von, weiß ich nicht,

mindestens mal so 50 Millisekunden oder sowas

und ich dachte, das liegt dann halt, das

führt dann schon dazu, dass man das irgendwie dann,

dass sich das dann langsam anfühlt und

hab dann sogar solche Sachen eingebaut

in meine ersten Versuche mit so

diesen, also ich glaube, das erste

hab ich tatsächlich React irgendwie am Anfang

verwendet und

hab dann immer irgendwie

die Daten für,

ich hatte so eine Liste

von Dingen, wo ich Pagination hatte

und dann habe ich die Daten für die nächsten,

immer für die paar Seiten außen rum,

immer schon gleich mitgefetcht, damit ich die nicht holen

muss, weil ich dachte, wenn ich da auf einen

sozusagen Link

in Anführungsstrichen klicke und dann müssen Daten

geholt werden, dann dauert das ja wieder lange und das will ich ja

gar nicht, sondern ich will, dass das sofort da ist.

Genau. Ja, und

tatsächlich

das habe ich jetzt auch, ich habe jetzt auch mit

HTMLX so ein bisschen rumgespielt oder so und dann habe ich gemerkt,

oh, das ist gar nicht der Punkt, das ist halt schnell genug.

Also wenn das 50 Millisekunden dauert,

dann reicht das vollkommen aus,

dass sich das halt schnell anfühlt.

Und...

Also vielleicht hast du zu viele Daten

dann sonst am Kleinen drin,

die der dann handeln muss, oder?

Nö, nö.

Das ist einfach...

Also meine Vorstellung,

dass das halt daran liegt,

dass die Langsamkeit von dem Netzwerk festkommt,

war so nicht ganz korrekt.

Okay.

Sondern das liegt eigentlich...

An der Interaktivität, oder?

Das liegt daran,

dass das komplette Browserfenster

immer ausgetauscht wird.

Das ist halt der Punkt.

Und dass der Browser teilweise

auch bei komplizierteren Seiten

halt einfach lange braucht,

um das wieder komplett neu zu rendern, was er ja tut.

Ja, aber das Ganze rendern so lange dauert.

Was ich ganz interessant fand von dem, was der Thomas gerade gesagt hat,

war, dass er sagte, man muss das

erst in JSON umwandeln von dem

alten Zustand, damit man es wieder zurückdrehen

kann. Das heißt, so der Urzustand

ist halt ein anderer dann gewesen

als JSON. Was ich jetzt, muss ich sagen, weil ich bin

auch nicht so lange dabei wie ihr,

gar nicht so unnatürlich finde, weil ich zum Beispiel

jetzt aus Django Models immer direkt in JSON reinrendere

oder so und halt diesen Umweg über die

Templates gar nicht so häufig gehen musste.

Deswegen

ist das für mich so ein bisschen Umgewöhnung. Also ich finde

das Django-Template-System sehr angenehm,

weil es halt die ganzen Features von Django

zurückholt, die man sonst verliert, wenn man

halt Js macht. Aber ansonsten

hat es für mich auch so einen Sinn, wenn man halt

diese serialisierten Objekte durch die Gegend schicken kann.

Und deswegen,

also was meintest du denn, wenn du sagst, dass wir

zurückdrehen? Also was wäre für dich denn so die...

Also zurückdrehen, das war eher so

zeitlich gemeint. Also dass man eben

es so ähnlich

macht, wie man es vor 10 Jahren

oder so gemacht hat.

Und das ist witzig, wenn man sich mit Leuten unterhält,

die eben jetzt vor

rund sieben, acht Jahren

oder irgendwas Web-Anwendungen geschrieben haben,

hatten die meistens alle

eine kleine Hilfsbibliothek, die auf

jQuery aufbaut.

Und mit der hatten sie damals so HTML-Schnipsel

irgendwie in bestimmten

ja,

ab und zu hin und her geschickt.

Und alle dachten, oh, das ist

dirty irgendwie und das ist nicht schön.

Als das Angiola dann aufkam, dann dachte man, ah, das ist sauber, weil Jason geht da über die Leitung und deshalb ist das einfach besser, weil es schön ist und sauber ist.

Aber diese Gleichung hat bei mir ein bisschen gebraucht, um dir aus dem Kopf rauszustreichen, dass das eigentlich Käse ist.

Also warum soll das Jason jetzt besser sein oder schöner sein oder irgendwas?

Also es ist viel pragmatischer, HTML-Schnipsel über die Leitung zu schicken.

Ja, und das habe ich bei so einem kleinen oder zwei kleinen Projekten ausprobiert und funktioniert prima.

Und ja, ich kann bloß sagen, dass es auch eine ganze Menge anderer Leute eben sozusagen auch sehen,

die ihr gerade halt Leute, die aus dem eher Backend-Sprachen kommen,

die eben Python oder Ruby oder irgendwas anderes programmieren,

die haben in dem Bereich eben Spaß dran,

weil sie dann in ihrer gewohnten Programmierumgebung bleiben können

und brauchen jetzt nicht da sich diesen großen JavaScript-Stack anzutun.

Sicherlich, das HTMLX selber ist auch in JavaScript geschrieben,

aber das heißt jetzt ja nicht bloß, dass man dann mit JavaScript schreiben muss.

Man kann es einfach, weil es rein deklarativ ist und das finde ich halt sehr schön.

Da gibt es ein paar Attribute, mit denen man das HTML erweitern kann und dann kann man eben auch einzelne Bereiche auf so einer Seite austauschen. Man hat also eine große Seite und dann kann man eben drei, vier Bereiche haben und dann kann man in diesen Bereichen Interaktivität schaffen, indem man dort einen Button hat und dann tut sich aber halt auch bloß nur dieser kleine Bereich austauschen. Und das macht halt die Seite irgendwie, ja, sehr interaktiv.

Ja, ja, das, was ich jetzt, ich habe gestern, vorgestern mal so ein bisschen damit rumgespielt und was ich, ich habe mein altes, meinen alten Use Case mir nochmal quasi versucht damit umzusetzen und das ist halt gar nicht so einen kleinen Teil austauschen, sondern quasi so den Hauptcontent auf einer Seite, also man hat quasi eine Liste von Dingen und zum Beispiel wie bei einem Podcast so die Episoden oder bei einem Blog die Artikel und jetzt paginated man da so durch.

Und das hat, für mich war der Grund früher mal, warum ich gedacht habe, okay, ich muss mir das mal angucken mit den JavaScript-Frameworks, dass das halt dann schneller geht, wenn man das halt irgendwie schon, wenn man da nicht jedes Mal die Seite neu laden muss.

Und das habe ich jetzt mit HTMLX gemacht und auch selbst, wenn man den kompletten Content der Seite austauscht, ist es immer noch sauschnell und man spürt da keinen Unterschied oder man hat nicht das Gefühl, dass man den kompletten Content ausgetauscht hat, sondern erst, wenn man tatsächlich die komplette Seite austauscht, dann wird es langsam.

Ja, also Latenz ab so 100 Millisekunden merkst du halt dann

und vorher ein bisschen drunter, also unter 50 oder

ist auch super. Da merkt man das eigentlich nicht und das

kann man durchaus schaffen, da drunter zu bleiben und das ist

natürlich dann, und da dachte ich so, als ich das gemerkt

habe, so okay, dass dieser Use-Kit geht auch damit,

dachte ich so, wow, okay, dann

entfällt für mich eigentlich der

Grund für diese JavaScript-Dinger

und dann. Also was mich halt noch interessieren würde,

was ich jetzt noch nicht genau gesehen habe, aber es liegt wahrscheinlich

daran, dass ich das nicht so eingebaut habe, kann ich das

trotzdem so in Komponenten strukturieren, wie

ich mir das vorstelle aus dem Vue.js raus

und wie läuft das mit den ganzen

netten Animation-Plugins

und sowas ganzes irgendwie, muss ich

das dann kleinteilig einbauen vom Server, hängt das dann

drüber und wie werden die Sachen da wieder

reingerendert, das habe ich immer noch nicht so ganz begriffen, weil

also Vue.js rendert das ja auch irgendwie

im Hintergrund einmal durch

und tauscht dann die Teile aus

im DOM

und auf welcher Ebene muss ich das denn machen?

Ja, man hat ja

die ganz normalen HTML-Tags,

also wenn du eine Seite hast

und da sind irgendein

drei interaktive Bereiche

drin, dann wäre es

eigentlich sinnvoll, du machst eine große Seite

und dann da dreimal

ein Form-Tag zum Beispiel

und wenn du ein Submit

für dieses Form macht, also für eins dieser

Forms, dann werden

die Daten dieses einzelnen,

dieses einen Forms zum Server geschickt

und kriegst die Antwort wieder zurück.

Also dann, die Komponenten

sind sozusagen HTML-Tags.

Ja, also

Also wenn du meinst, dass du sowas hast, also eben Vue und React, die machen das, da ist ja genau das, das ist ja ein ganz anderes Modell und wahlweise je nachdem aus welcher Geschichte man kommt, selber kommt es ein moderneres oder älteres, also eigentlich würde ich sagen, ist es halt ein ganz altes Modell, das ist halt eigentlich Client-Server und das ist eigentlich eher so Remote-Procedure-Call und der Client, der State bei den sozusagen in Anführungsstrichen modernen, aber eigentlich architekturmäßig alten,

Anwendungen, die halt so ein bisschen

wie die Client Server, der State der Applikation

liegt halt in JavaScript, deswegen

musst du auch, musst View das rendern, deswegen gibt es

die Tablet-Sprache in, also JSX

in React und so. Aber genau

an der Stelle müssen wir jetzt vielleicht nochmal in die Historie

gehen, weil ich glaube, jetzt haben wir so ein bisschen die kleine Einleitung gemacht,

aber das wäre jetzt genau nochmal interessant zu wissen,

was ist denn jetzt genau der Unterschied

zwischen RPC

und Client Server und

Naja, also auch der Unterschied

sozusagen zwischen JSON und HTML,

ich muss auch sagen, ich finde

JSON, ehrlich gesagt, so als

Entwickler viel angenehmer,

um damit zu arbeiten, als jetzt sowas wie

XML oder HTML oder sowas.

Oder überhaupt Markup Languages.

Einfach deswegen, weil JSON

halt viel einfacher ist.

Zum Beispiel, also einer der wesentlichen Unterschiede,

ein bisschen subtil, aber tatsächlich ist es halt das,

was einem dann so extrem

auf die Füße fallen kann oder

was halt sehr viel Aufwand erzeugt, ist halt

XML oder

oder HTML, das ist halt ein Dokumentformat.

Das ist halt nicht so, dass das einfach

nur Daten sind.

Das Gute ist natürlich auch, als Backend-Entwickler kann man natürlich sagen,

wenn man sich mit dem Pixel-Schubser beschäftigt, sichert sich Frontend

damit, man gibt denen einfach die Daten und dann ist gut,

dann hat man damit nichts mehr zu tun. Das heißt, es gibt ja auch

diese zwei Karton von Entwicklern.

Das führt halt auch dazu, dass es nicht so

mächtig ist,

in gewisser Weise. Also der Hauptunterschied zwischen

Dokument und Daten ist halt

zum Beispiel die Reihenfolge.

Du hast halt in einem Dokument eine Reihenfolge

von Dingen. Da spielt es eine Rolle,

ob Sachen vorne stehen oder hinten.

Wenn ich in JSON irgendwie ein Objekt habe,

dann ist das egal, ob das vorne

steht oder hinten. Das sind immer die gleichen Daten.

Und

das macht es sehr schwer zu handeln,

weil ich dann beim Parsen halt aufpassen muss

und so. Aber auf der anderen Seite

macht es halt auch sehr mächtig. Ich kann halt auch

ja, also

die Dinge quasi, die ich

da anzeigen möchte, direkt drin beschreiben. Das kann ich

so in JSON ja nicht machen. Aber in HTML

kann ich das.

Also in HTML kann ich halt ein Formular hinschreiben,

das halt irgendwie

einen Kontakt zum Beispiel anzeigt oder halt

mir anzeigt, wie ich den ändern kann,

ohne dass ich dazu sonst irgendwas

wissen muss. Ja, genau, also du kannst ja tatsächlich auch den ganzen

Datentyp verändern. Du musst ja jetzt nicht nur irgendwie

ein JSON-Objekt durch ein anderes austauschen,

sondern du kannst ja was ganz anderes dahin stellen auf einmal.

Das heißt so magisch irgendwie.

Ja, genau. Und bei JSON

geht das halt nicht. Bei JSON musst du halt wissen,

was das ist. Ansonsten funktioniert es nicht.

Was mir bei JSON

jetzt nicht so gefällt, dass halt

Datentypen sind recht eingeschränkt. Also ordentliches Timedelta oder irgendwas.

Ja.

Da bin ich persönlich halt großer Freund von Postgres. Das ist enorm,

was es da alles gibt in der relationalen Datenbank. Und da sind meine Daten eben

gespeichert. Da kommen die her. Und dann will ich aus der SQL-Datenbank,

irgendwie das beim Client anzeigen

und da ist es

relativ klar, wenn ich sage, ich mache

aus dem SQL, mache ich

HTML und das schicke ich zum Browser.

Das ist relativ einfach.

Also wenn ich da erstmal aus dem

SQL JSON mache

und dann mache ich aus dem JSON HTML,

ist es einfach ein Schritt mehr.

Und da frage ich mich, warum?

Ja und

es ist halt auch so, dass man dann

die ganzen Probleme aus der alten Welt

wiederbekommt, nämlich zum Beispiel, was ist

wie, also deine

Applikation muss jetzt natürlich das

JSON verstehen und hat

jetzt auch Versionen zum Beispiel. Also was ist denn,

wenn jetzt kommt das JSON

von heute sozusagen,

aus irgendeinem Backend, aus irgendeiner Datenbank

und die Applikation ist

aber ein Jahr alt, weil ich halt jetzt, weiß ich nicht, keine Ahnung,

ein Browserfenster irgendwie,

ich habe einen Rechner irgendwie in die Ecke gelegt,

der dann ein Jahr lang gelingen hat, jetzt klippe ich den wieder auf

und jetzt, was macht die Applikation denn jetzt

mit den Daten?

Das wird wahrscheinlich nicht funktionieren.

Das haut nicht hin und das hat man

ja auch eigentlich in allen

von diesen frontendlastigen

Anwendungen, dass dann ab und zu

so ein Pop-up kommt, bitte Seite neu

laden, weil

neue Software-Update oder irgendwas

anders, so ein Browser-Reload dann sozusagen

wie so ein Software-Update.

Genau, das hat man in dem

HTMX-Fall eigentlich

Ja, das hat man in dem Rest-Web

irgendwie sozusagen Fall.

In dieser Architektur hat man das nicht, weil da gibt es das einfach nicht.

Man kann prinzipiell

auch auseinanderlaufen. Also wenn ich jetzt ein Formular

einmal erstmal mir lade,

ein HTML-Formular,

und dann vergeht wirklich eine Menge,

vergeht eben Zeit und es gibt ein Software-Update

und dann mache ich bei mir einen Post

von meinen Formulardaten, kann das prinzipiell

ja auch gegen den Baum gehen, weil es dann nicht mehr hinhaut

auf Server-Seite.

Wenn sich tatsächlich an der Datenschema

oder so irgendwas geändert hat.

Okay, ja.

Aber tatsächlich, ja, ja gut, okay, insofern.

Ja, wir gehen einfach mal davon aus,

dass man, wenn man Dinge irgendwie jahrelang da liegen lässt,

man nicht davon ausgehen sollte,

dass die einwandfrei so funktionieren wie am ersten Tag.

Ja, ja, okay, aber du kriegst das Problem auch deutlich schneller.

Also du hast halt dieses Problem plötzlich wieder.

Du hast das Problem wieder,

dass du deine Clients aktuell halten musst.

Das war eigentlich sozusagen eine der großen Versprechungen

von Webgeschichten, dass man sagt, das musst du nicht mehr machen.

Also um nochmal zu drücken,

also die alte Client-Server-Architektur bedeutet,

Ich habe eine Hauptanwendung, einen Server, auf dem die ganzen Daten, die ganze Datenbank liegt und die Clients, die selbstgeschriebene Anwendungen sind, die auf anderen Rechnern laufen, die dann halt mit dem Server kommunizieren, die halt eine bestimmte Version haben.

Und wenn ich jetzt irgendwas Neues veröffentliche, dann muss ich dafür sorgen, dass der jeweilige Client sich ein Update herunterlädt, seine Applikation aktualisiert, um wieder mit dem Server reden zu dürfen.

Der Kern der Applikation ist eben nicht auf dem Server, sondern der Kern der Applikation ist halt auf dem Client. Und vom Server kommen nur Daten.

Okay, also der Kern der Applikation bedeutet tatsächlich, ja, okay.

Der State der Applikation, die Logik.

Jetzt hast du schon wieder State gesagt.

Ich glaube, das haben wir auch noch nicht so richtig beschrieben.

Was ist denn ein State überhaupt?

Also die Wahrheit vielleicht über das, was gerade ist.

Ja, also sozusagen die Information, wenn du jetzt eine Liste von Kontakten hast,

zum Beispiel irgendwie in einer Applikation, wo liegt diese Liste?

wie hast du die sortiert, welche hast du wieder rausgeschmissen

und wer kennt das? Kennt das

der Client selber oder kennt

das auch oder nur der Server?

Und das ist der Unterschied. Ja, quasi bei

Client-Server liegt es halt beim Client.

Ja, oder es könnte auch vom Server liegen. Also der große

Unterschied zu Web ist jetzt sozusagen,

okay, jetzt rede ich über Dinge, von denen ich keine Ahnung habe,

aber der große Unterschied ist halt, das liegt

halt in dem

HTML selber.

Das ist halt der große Unterschied

zu allem, was früher war. Das ist halt sozusagen dieser

revolutionäre Schritt. Das

hat man vorher, soweit ich weiß,

noch nie gemacht.

Und das ist neu in HTML.

Und mit REST, sozusagen.

Na gut, ich kenne

auch die Frage, was

man will. Also, ob man jetzt so

eine Seite will,

eine Seite, die sich eben super

schnell lädt, weil der Nutzer

bei Google was danach gesucht hat und

dann folgt er dem Link, der ihm angezeigt

wird und dann, zack, will er die Seite da haben

und will die Seite geöffnet haben und sehen.

Und da ist halt ganz wichtig,

dass, ja,

was jetzt Google mit den Web-Visals oder

irgendwas so abprüft, dass zack,

diese First-Time-User-Experience gut ist,

zack, die Seite soll sich schnell laden.

Und witzigerweise gibt es

ein Produkt von dem gleichen

Großkonzern, Google,

zum Beispiel Gmail.

Und wenn ich Gmail starte, sehe ich erstmal

einen Wartebalken.

Das geht mir natürlich als Nutzer eigentlich

Eier auf den Keks.

Sehe ich erstmal, wie sich die ganze

Anwendung lädt und das will ich

nicht. Also ich will im Endeffekt, will ich auch

gar nicht so eine Native GUI

im Web haben eigentlich.

Ich will zack, dass die Seite da ist.

Und

drum ist die Frage eigentlich,

was man will. Sicherlich gibt es Anwendungen,

gibt es Anwendungen, die tut man

als Anwender eben morgens starten

und die tut man abends dann wieder schließen

oder so.

Dann ist es okay.

Was ich will, ist ein Nutzererlebnis.

Also ja, das ist natürlich schon, dass es schnell da ist.

Es muss schnell irgendwas passieren.

Aber ich brauche nicht direkt sofort den ganzen Content,

sondern ich will da so reingeführt werden,

dass ich willkommen bin, dass ich eingestimmt werde,

auf was da funktioniert.

Na gut, aber das liegt halt im Use Case.

Da denke ich drauf an, was das für eine Applikation ist,

die man da, oder was der Use Case ist.

Und für die allermeisten Web-Use Cases ist es halt wichtiger,

dass man quasi von, dass man

das auch, dass man zum Beispiel auf Links klicken kann

und dann halt auf eine andere Seite kommt und da irgendwas macht.

Ja, genau, dass man halt einfach was

Und das geht ja auch mit

diesem Modell, dass dein

Client halt irgendwie

eine richtige Applikation ist, funktioniert das

halt nicht mehr. Das bricht halt

die Links im Web im Grunde, weil

wenn du jetzt hinter jedem

Link erstmal irgendwie ein paar Megabyte

großes JavaScript-Wandel liegt, was du laden

musst und dann erstmal ein Ladebalken eingezeigt wird

und dann ich initialisiere die Applikation,

dann macht es keinen Spaß mehr, auf Links zu klicken.

Also das mit den Links und dass man von einer Seite auf die andere kommt,

das funktioniert nur, wenn da nicht jedes Mal megabyteweise Zeugs rüberkommt

und initialisiert werden muss und nicht irgendwie ein komplexes User-Interface hochgefahren wird,

sondern wenn es halt was Einfaches ist.

Auf der anderen Seite ist natürlich diese Vernetzung auch total interessant und cool.

Ja, ich meine, die großen

Web-Frameworks, die

wie React und Vue, die haben das ja auch erkannt

und jetzt versuchen die

serverseitig zu rendern.

Dann gibt es dieses mit Hydration und

Dehydration oder

Serverseit-Rendering und den ganzen Späßen.

Moment, was ist Hydration, was ist Dehydration,

was ist Serverseit-Rendering in dem Fall?

Gemeint?

Naja, also du benutzt im Grunde

Node.js auf dem Server, um halt

dein, also du hast ja

meistens dann auch so eine Template-Sprache, so ähnlich wie

Django-Templates bloß halt in JavaScript, also

JSX oder weiß nicht, wie das bei Vue heißt,

keine Ahnung. Und du kannst

das ja jetzt, du kannst es im Browser rendern,

ja, da läuft JavaScript, was seine

Templates nimmt und dann halt

quasi mit den Daten, die es über JSON oder sonst irgendwie bekommt,

halt dann HTML rausrendert.

Du kannst das aber auch auf dem Server rendern. Du kannst

ja da ja Node.js laufen lassen, dann kannst du auch Templates nehmen

und dann halt auch HTML rausrendern.

Und das HTML, was du da rausrenderst, kannst du

auch einfach so an den Kleinen schicken.

Sodass das Rendering halt nicht bei dir im Browser

passiert, sondern auf dem Server. Deswegen Server

Side Rendering. Das ist halt dann für kürzere

Antwortzeiten. Ja, ja, also

dann fühlt es sich für deinen Browser, ist es dann so wie

eine klassische, wie so

eine Django-Webseite oder so und

dann aber schiebt der Server

dir ja doch dann doch irgendwie so ein JavaScript-Bundle

dahin und dann wird das ersetzt und

ich weiß nicht, ehrlich gesagt, ich weiß jetzt auch nicht genau, wie das

funktioniert mit dem Hydration oder so. Genau, aber

was ist jetzt das Hydration? Ich nehme mal an,

dass das ist irgendwie so

sozusagen, dass

dieser reine, das hat ja mal etwas gekriegt,

das ist quasi in Anführungszeichen irgendwie trocken

und weil es halt so statisch ist

und ich nehme mal an, dass sie mit Hydration meinen,

du schickst halt den Bundle dahin

und wenn das Bundle da ist, dann sagst du, okay, jetzt gib mir die Daten

per JSON und dann rendert es das halt auf den

Client selber. Das ist das, was zum Beispiel

bei Vue.js in so Komponenten passiert, wenn da

bestimmte Teile im DOM

getauscht werden, so HTML-Schnipsel von

Antworten vom Server dann auch.

Nee, nee, das muss man bloß, das ist bloß

on top sozusagen, also

das ist bloß, wenn du es optimieren willst, also

das ist bloß für den

Fall, wenn du feststellst, eine Vue-Anwendung,

die ist eben jetzt nicht so schnell

für den First-Time-User,

dann kannst du dieses Hydration-Dehydration

einsetzen, um

diesen ersten Seitenaufruf zu

beschleunigen. Ja, und sozusagen als Browser,

wenn du auf so eine Seite,

wenn du jetzt zum Beispiel Nuxt nimmst bei Vue

und machst da Server-Site-Rendering,

dann dein Browser kriegt einfach nur

HTML und zeigt das an, wie bei jeder anderen Seite

auch.

Für den, der führt kein

JavaScript erstmal aus.

Nur dann später.

Also die Frage ist, wo es gerendert wird.

Bei Server-Side-Rendering wird es auf dem Server gerendert

und bei irgendwann später,

wenn das Bundle da ist, was halt aber

megabyteweise Zeug sein kann, ja das dauert halt,

bis das da ist, dann wird wieder

auf dem Client gerendert und dann werden nur die Daten

per JSON geholt und das ist,

denke ich, das, was mit Hydration gemeint ist.

Und die Sache ist,

es ist ja schön, dass man das alles machen kann.

Und die Frage ist aber, ob man

will. Und da

bin ich eben vielleicht auch

zu alt oder zu steif.

Ich verwende seit Jahren

Python und bin mit der Sprache sehr zufrieden.

Und dass ich jetzt

JavaScript, die Sprache, die mir

eh nicht so 100% sympathisch ist,

jetzt auch noch auf dem Server einsetze

oder irgendwas, habe ich eben

persönlich keinen Bock drauf.

Und darum habe ich

das Schöne ist ja, ich habe da angefangen

im privaten Kontext auch

für jemanden eine Seite machen

wollen und

so ein Bestellsystem

und das Schöne, da hatte ich einfach Zeit

und es war auch kein Druck

irgendwie da und auch keiner, der gesagt

hat, Thomas, nimm die oder jene Tools.

Wenn man da Zeit hat, kann man wirklich mal nochmal recherchieren

und auch sagen, nee, so möchte

ich es jetzt nicht machen, ich will es jetzt so

machen und dann habe ich erstmal ewig

gesucht, bis ich überhaupt was gefunden habe

und durch Zufall bin ich eben auf das

HTMX dann gestoßen. Inzwischen ist es

auch populärer, inzwischen wird man

steuert man selbstständig

drüber. Vor mehr als einem Jahr war das

eben noch recht unbekannt.

Gut, und da war es halt eine coole

Sache und gerade wenn man

halt

sagt, man selber ist in

Backendsprache

damit vertraut,

dann macht das eigentlich großen Sinn,

weil dann kann man das auch sehr

leicht verwalten, diesen Stack.

Ansonsten, ja,

sicherlich kann man das machen. Ich glaube auch, dass das

prima funktioniert mit dem Vue und React

und so alles. Aber wenn

man das selber alles in der Kontrolle haben

will, also ich kenne es selber jetzt beruflich

zum Beispiel, nutzen wir auch

VGS und

das ist dann manchmal so,

dann ist der Frontend-Entwickler

sozusagen oder dass da einer mal krank

oder im Urlaub oder irgendwas und dann klemmt es

Frontend-seitig, obwohl Backend-Kapazität

dabei und dann ist es vielleicht mal andersrum oder

irgendwas. Das ist doch eigentlich

schöner, wenn man da sagt, okay, ich mache wirklich

eben Fullstack vom HTML

bis zur Datenbank, habe ich

alles unter Kontrolle und da finde ich

diese Trennung zwischen Frontend-Entwickler

und Backend-Entwickler, das ist so wie

so eine komische Diskriminierung,

wie, ja,

muss eigentlich nicht sein, also ja.

Ja.

Ja, ja, ich würde auch

sagen, also normalerweise ist diese Unterscheidung

von der Backend eigentlich halt hauptsächlich irgendwie, es gibt halt

Leute, die

JavaScript mögen und es gibt andere Leute, die

JavaScript fullback finden und

das ist halt so schon mal, also

ja.

Alle Leute, die liebe JavaScript-Liebe haben,

die bitte einmal aufzeigen.

Ja, na ja, gut.

Das ist übrigens auch so ein Ding.

Also ich meine, im Grunde die Entwicklung

wird da getrieben von, also weil in der

JavaScript-Welt, und ich höre da ja auch

ab und zu Dinge, da

geht man jetzt sozusagen schon in die Richtung zu

sagen, ah ja, also wir sind jetzt eigentlich

weit genug, warum machen wir nicht JavaScript

also komplett, also auch im Server vor allen Dingen.

Es gibt ja eigentlich keinen Grund mehr, das nicht zu verwenden.

Ich würde sagen, schon, doch gibt es Gründe, das nicht

zu verwenden. Aber

diesen Druck, den gibt es

schon sehr stark.

Aber nochmal vielleicht ganz kurz, ich würde

ganz kurz nochmal

da ansetzen, wo wir eben waren,

weil man kann

jetzt mit diesen Frameworks natürlich auch Server-Side-Rendering machen,

nur das löst die Probleme nicht.

Also wenn

alle Webseiten

irgendwie fette

Dinger wären mit Server-Side-Rendering,

würde das Web so nicht mehr funktionieren.

Das würde kaputt gehen.

Und das ist halt irgendwie, weil du musst

diese Megabyte-Daten ja immer noch durch die Gegend

schieben. Auch wenn das dir jetzt nicht mehr so

auffällt, aber

werden halt dauernd die gleichen

minifizierten JavaScript-Dinger

durch die Gegend geschoben. Wenn du von einer Seite auf die

andere gehst, immer das gleiche Zeug, Megabyte-weise.

Das ist einfach total verrückt.

Weil ich nicht die einzelnen Teile

vom Dom nur tausche?

Ja, weil du musst halt die komplette Applikation

schickst du halt in der Gegend rum.

Ja?

Und die Applikation ist ja in weiten Teilen

immer die gleiche.

Aber so viel ist es ja nicht. Ich meine, es wird ja dann

gecached und ich kann mir vorstellen,

dass die ersten drei Bilder

jeder Webseite dann größer sind

als das ganze JavaScript-Spaß.

Also ich hätte jetzt auch tatsächlich irgendwie

intuitiv gedacht, dass man das halt auch mit VJS zum Beispiel

so löst, dass man dann eben nur

den einzelnen kleinen Bestandteil

dann innerhalb dieser Komponente

neu rendert.

Nee, du musst immer, also ich weiß nicht genau,

es gibt noch so Geschichten,

da bin ich jetzt aber auch nicht vertraut mit, dass du

so dieses Hot-Module, du kannst halt

teilweise mit, es gibt so

Exima-Skript jetzt Module irgendwie auch

und manchmal kannst du halt, musst du

für manche Seiten, kannst du Module nachladen und so,

aber bisher der klassische Weg

war halt, du baust deine komplette

Applikation in einen JavaScript-File und das

lieferst du aus.

Und solange du das nicht hast, geht gar nichts.

Und ja, also wenn deine

Applikation, also ich meine gut,

sie muss nicht über Megabyte groß sein, aber

ja, wenn, also

ist schon groß und

oft ist View

drin oder React und dann halt die

Bibliotheken, die alle verwenden. Und das Zeug wird halt

bei jedem, wenn du auf eine andere Seite gehst,

wird das halt immer mit übermittelt. Und das ist ja

eigentlich vollkommen verrückt ineffizient.

Also das ist ja eigentlich,

tut einem ja weh, wenn man sich das so überlegt.

Das ist das, was das bedeutet.

Eigentlich wollten wir ja über HDMIX reden und nicht über

nicht über Renderfix. Genau, richtig.

Nicht was anderes irgendwie.

Ja, okay.

Genau.

Ja, wie funktioniert das denn bei HTMX?

Ja, wollen wir mal so ein Beispiel besprechen?

Ja, also wir können mal ein Beispiel besprechen.

Am besten, man gibt dann selber mal HTMX einfach in seine bevorzugte Suchmaschine ein

und dann kommt man auf die Seite und da gibt es auch ein paar Beispiele.

Oben in der Kopfleiste ist es zu sehen, ein paar Examples.

Und ein Beispiel ist zum Beispiel Click2Edit. Das ist glaube ich mit das erste. Da hat man erstmal so eine ganz normale HTML-Seite und da unten ist so ein kleiner Block und da steht irgendwie Click2Edit und in diesem Block sieht man irgendwie Name, sage ich mal Peter oder irgendwas oder irgendein Name, Vorname, sogar ein ganz einfaches Nutzerdaten.

Irgendwann kann man hinklicken und wenn man hinklickt, dann tut sich dieser kleine Bereich aktualisieren und man hat ein HTML-Formular.

Dann kann man dieses HTML-Formular eben befüllen und sagen speichern.

Und mit dem Speichern, schwupp, ändert sich wieder dieser kleine Block und der ist sozusagen wieder Read-Only, wie er am Anfang war, bloß mit den aktualisierten Daten.

Und das Ganze funktioniert natürlich so, dass kein, der gesamte Browser immer auf dieser Seite bleibt, also nicht die gesamte Seite wird neu geladen.

Also sprich, würde man irgendwo hingescrollt haben oder irgendwas und es dann unten auf einer Seite machen, würde die Scrollposition oder irgend sowas alles gleich bleiben.

Und da ist die Frage, wie das funktioniert.

Mit dem Klick to edit wird dann der Server kontaktiert und der Server schickt dann ein kleines HTML-Schnipselchen an den Client und entsprechend der Angabe in dem HTML und das HTMLx erweitert im Endeffekt das HTML bloß um ganz einfache neue Attribute.

Anhand dieser Attribute stellt eben diese Library fest, aha, das soll hier eingefügt werden.

Es gibt verschiedene Swap-Methoden, da kann man sagen, innerHTML soll ausgetauscht werden, also das in dem Tag oder outerHTML, sprich das Tag selber soll auch mit ersetzt werden.

Na gut, und dann kriegt man eben dieses HTML-Schnipselchen vom Server und das wird dann durch HTMX dort eingebaut und dann hat man das Formular, kann es befüllen und am Endeffekt passiert der gleiche Spaß wieder.

Ich kann das als Nutzer dann ausfüllen.

Und wenn ich auf Speichern klicke, dann wird eben auch nur dieser kleine Bereich zum Server hingeschickt

und man erhält wieder einen HTML-Schnipselchen, der dort an dieser Stelle eingebaut wird.

Und das Schöne für den Anwender ist, dass es halt super simpel ist.

Man muss dann bloß mit ganz wenigen Attributen sagen, hier, tausche mir bitte dieses oder jenes aus

und dann hat man das Ganze schon, also man muss sich da

nicht mit JavaScript beschäftigen oder so

und ja, das ist

sozusagen diese

Grundidee der Bibliothek, dass man

HTML-Schnipsel

über die Leitung schickt

und das deklarativ im HTML

verfügbar macht.

Ja, sehr spannend, das macht auch solche

Sachen wie möglich, dass man dann,

also das ist auch ein weiteres Beispiel, zum Beispiel

auf der Seite, dass man Infidelscroll machen kann,

dass er dann in diesem HXWeb-Attribut

einfach After End sagt und dann wird das einfach

angehängt, dann das, was man

bekommt und so.

Also da kriegt man eigentlich

den besten Eindruck, wenn man einfach mal diese Beispiele

durchgeht. Genau, das ist

schon super.

Ja, also ich meine, im Grunde, also

eigentlich ist die Idee, also mich wundert, dass

das nicht schon viel früher passiert

ist, ehrlich gesagt. Mir ging es genauso, ich dachte

man, das ist ja genau, von dem ich eigentlich

geträumt habe, gerade vor Jahren, als ich

mit Jake Ferry da so, sag mal, dass du selber

irgendwie was gelöst, irgendwie

und das ist eigentlich die Idee

dieses Deklarativen auch, also das ist eben

das HTML ist da

sehr schön, diese Beschreibungssprache

sicherlich ist es keine Programmiersprache, eine Beschreibungssprache

aber im Endeffekt

geht ja vieles hin in das Deklarative

also man will ja einfach bloß sagen

das soll so und so sein und

dann kümmert sich irgendein anderer Prozess

dann darum, dass das dann

auch umgesetzt wird und so und das macht es im Endeffekt

dann einfacher

Ja und im Grunde behandelt das

eigentlich macht es genau das gleiche, was man

im Browser auf einer Webseite tut, nur

halt nicht jetzt, dass man zum Beispiel

wenn man im Browser halt auf einer Webseite ist, kann man ja

immer nur das komplette HTML

Element ersetzen. Und jetzt hat man sozusagen

per JavaScript in HTMLX

halt die Dinge, die man nur auf dem

einen großen Ding machen kann, kann man jetzt auf allen

kleinen Elementen halt auch machen. Man kann das halt

irgendwie durch was anderes ersetzen.

Man kann, also es ist

normalerweise im Browser lösen halt nur zwei

Events, lösen

halt irgendwie in Requests aus. Das eine ist halt

Anchor-Tag und das andere

ist halt irgendwie Submit, also

Form. Und

es gibt nur Get und Post,

aber es gibt ja noch viel mehr

HTTP-Werben. Es gibt ja noch die Lead-Put-Patch

und das habe ich

mich auch früher gefragt. Also es gab es auch

so bei Jungle-Rest-Framework ja irgendwie bei dieser

Browsable-API und dann wollte ich halt mal

so, da drinnen kann man ja auch

Dinge hinzufügen und so. Ich so, okay, und jetzt

muss ich noch Put testen und so, hm, komisch.

Put geht irgendwie nicht. Wieso geht denn Put nicht?

Und das war mir auch gar nicht klar, dass halt Browser

können halt keinen Put irgendwie

an Zauber schicken, sondern das muss man halt mit JavaScript machen,

weil es geht einfach nicht.

Und es gibt ja eigentlich gar keinen Grund, warum das jetzt

nicht weiter standardisiert wurde. Und HTMX

ersetzt sozusagen das, was da noch fehlt,

durch JavaScript.

Und das ist eigentlich eine sau, sau coole Idee.

Also, bei mir

hat es auch relativ schnell Klick gemacht, nachdem ich

die ersten Beispiele dann mir angeschaut habe.

Und es ist

enorm, wie da auch das

Interesse daran wächst. Also zum Beispiel

im Django, was ich jetzt hier eben

einsetze für die Serverseite,

kann man ja auch auf einer HTML-Seite

mehrere Formulare

dann reintun und mit Präfixen das

dann auswerten und so weiter.

Und das war auch, wenn ich mich da

zurückerinnere, rechter Krampf irgendwie immer.

Und hier ist es

einfach entkoppelt.

Ich kann ja auch auf einer Seite drei Formulare

haben und die submitten sich eben

einzeln individuell. Da brauche

ich da nicht ein großes

Formular machen mit drei

Unterbereichen oder so. Das macht's

auch serverseitig deutlich

einfacher, das zu handeln.

Ja.

Naja, und es ist ja jetzt

tatsächlich auch nicht nur, also

hat demnächst vielleicht zu der Geschichte, dass

der Autor hatte vorher

eine Bibliothek geschrieben als jQuery

Plugin. Das nennt sich

irgendwie intercooler.js.

Daher, das hat auch mit

jQuery relativ viel zu tun.

Ähm, äh, und das war halt dann

quasi auch halt, äh, HTMLX ist jetzt

sogar der Nachfolger davon, der dann halt ohne JQuery

auskommt und diesen ganzen Kram nicht mehr macht.

Ähm, und

äh, was ich auch, äh,

wo ich auch denke, das ist, äh, halt

ein sehr, äh, also

ein breiter Trend, das macht es auch so

interessant, weil es ist halt nicht nur diese eine Geschichte,

es ist nicht nur HTMLX, sondern, äh,

diesen Ansatz verfolgen ganz viele

Projekte in ganz vielen unterschiedlichen Sprachen, ne?

Und, ähm, ich weiß nicht, in

welchem Talk das war, ob das der

von der Jungle Queen US war

oder nee, es war auch, glaube ich, mit TalkPython

to me, Interview

mit dem Entwickler von

HTMX,

sagte er einen Satz, den ich von

unterschiedlichen Leuten aus unterschiedlichen Communities

schon ganz oft gehört habe.

Den habe ich auch schon gehört von Chris

McCord von Phoenix Live View

in der Elexia und ich habe den auch

nochmal woanders gehört und zwar der Satz ist

ja, also ehrlich gesagt, dafür

dass ich kein JavaScript schreiben wollte, habe ich jetzt

ganz schön viel JavaScript geschrieben.

Und das sagen, also das ist halt dieses Thema, so ganz viele Backend-Leute, die eigentlich nie JavaScript schreiben wollten, haben jetzt dann doch viel JavaScript geschrieben, um das loszuwerden.

Und wenn das viele Leute machen und quasi zu einem ähnlichen Ergebnis kommen und das tatsächlich funktioniert, dann wird das wahrscheinlich auch so bleiben und das sieht danach aus, als hätte man da was gefunden, was tatsächlich gut funktioniert und das macht es dann natürlich auch interessant.

Also wenn das jetzt nur eine Geschichte wäre, aber ich weiß nicht, ob mir jetzt die ganzen Namen einfallen, aber in der Ruby on Rails Welt, also wobei HTMX wird ja auch viel mit Ruby on Rails zusammenverwendet, gibt es halt noch Hotwire, also ist auch Akronym für HTML over the wire und Turbolinks, wo halt dann quasi schon die Seite hinter dem Link gefetcht wird, sodass wenn man auf den Link draufklickt, das halt dann direkt da ist.

Dann gibt es eben bei Elixier, in der Elixier-Welt Phoenix gibt es Liveview, wo auch HTML-Snippets halt über einen Websocket geschickt werden. Dann gibt es das in PHP, da heißt das irgendwie Livewire in Laravel.

Und ja, ich weiß es gar nicht, da gibt es, also auf jeden Fall in vielen unterschiedlichen Communities machen Leute jetzt gerade sowas und ja, das scheint irgendwie ein sehr, sehr breiter Trend zu sein.

Der Schöne an dem HTMX ist halt, dass es sich da vollkommen raushält. Also das kann man mit jedem Backend-Framework nutzen, wie man möchte. Und die anderen, die sind halt oft Backend-spezifisch.

Also bei Ruby on Rails, das ist Hotwire und drum war das, ja, ich habe es mir angeschaut und hätte eigentlich da Interesse gehabt, aber das war dann irgendwie schon wieder irgendwie kompliziert und nicht so einfach. Das HTMX hat es, glaube ich, der Carson Cross hat es da sehr, sehr schön nochmal reduziert von der Komplexität und das ist ja auch im Endeffekt sein Ziel.

sein Ziel ist es, die Komplexität

zu reduzieren, dass es

schön einfach ist.

Und das hat er aus meiner Sicht sehr

gut geschafft. Das sind eine Handvoll

Attribute, die hat man schnell

verstanden oder auch noch nachgeschlagen

und dann kann man da ganz

gut eine Menge Dinge machen.

Man muss natürlich erstmal umdenken, um überhaupt

erstmal reinzukommen, aber

das macht Spaß.

Also das kann ich nur empfehlen.

Ja.

Es gibt auch

eine jetzt von Adam Johnson,

der hat irgendwie ein Ding geschrieben,

Django HTMX,

das ist eben

als Integration jetzt auch in Django als Framework,

aber das macht auch fast nichts, das macht ganz wenig,

das macht nur

sozusagen, es ist eine Middleware dabei,

die an den Requests halt ein Attribut

dran wappt,

ich weiß nicht, ist HTMX oder sowas, wo man dann einfach

nachgucken kann, weil man muss auf der Serverseite

halt unterscheiden können, war das jetzt ein

Request, der von HTMX gekommen ist oder nicht, und dann

je nachdem, erinnert man

die komplette, das ist auch sowas, wenn

ein Browser kein JavaScript kann, das ist gar kein

Problem, das funktioniert einfach so weiter,

weil auf der Serverseite

rendert man halt, wenn man sieht,

okay, es war kein HTMLX-Request, dann rendert man

einfach die komplette Seite raus, ist gar kein Problem.

Und wenn es ein HTMLX-Request war, gut, dann

rendert man halt nur das Fragment raus, das

halt ersetzt werden muss. Und

das heißt, es funktioniert in beiden Fällen und

irgendwie, man hat halt diese Windelware dann, um

halt da quasi sich nicht selber überlegen zu müssen,

wie man jetzt erkennt, ob das jetzt ein HTMLX-Request war

oder nicht und dann hat das ding auch noch so teile drin für damit diese fehler views halt

ordentlich funktionieren also wenn halt ein fragment nicht ordentlich gerendert wird dann

ist wenn man sonst nichts macht ignoriert also wenn dann wenn er zum beispiel 400 zurückkommt

dann sieht man nichts weil hat im extra ist einfach die antworten weg und vielleicht die standard junk

Fehlermeldung aber haben mit einem Stacktrace oder so.

Und genau, dafür ist halt

auch noch so ein bisschen, das ist glaube ich

eine HTMLX-Extension in JavaScript,

die in Django HTMLX drin ist,

die dann halt dafür sorgt, dass man

eben die normale Django-Fehler-

Seite sieht, wenn man, auch wenn

HTMLX-Requests halt außerhalb der Seite schiefgegangen ist.

Genau, also ich habe es mir auch

angeschaut, die Bibliothek,

habe das gleiche festgestellt wie du, es ist relativ

wenig eigentlich drin und

es ist auch wenig notwendig

und darum nutze ich es ja auch gar nicht,

weil ich habe mir für mich dann nochmal überlegt,

wie willst du deine Anwendung gestalten?

Also zum einen unterstütze ich nicht JavaScript-lose Browser.

Also JavaScript ist für meine Seite jetzt notwendig.

Also da ist es schon im 21. Jahrhundert.

Aber das ist dann so, dass ich die URLs trenne.

Also es gibt den ersten Seitenaufruf

und der erste Seitenaufruf bringt eben eine ganz normale HTML-Seite

mit einem HTML-Tag, Head-Tag, Body-Tag

und HTML wieder zu

und ab dann werden eigentlich

meistens Schnipsel

ausgetauscht und

die URLs, wo ich

eben ein Schnipsel bekommen will,

die liefern immer ein Schnipsel

zurück und die werden immer über HTMLX aufgerufen,

sodass ich diese Fallunterscheidung

serverseitig gar nicht habe, von wegen

ist das jetzt ein HTMLX-Request

oder nicht. Es gibt glaube ich auch

von Django Forms, Django Forms Dynamic

oder sowas, dass man da quasi Dango Forms

nutzen kann, direkt als HTML Mix Forms.

Ah, okay. Das kannte ich noch gar nicht.

Das haben wir auch ganz cool dazu.

Cool, ja.

Das heißt, also Dango Forms kennt ihr vielleicht,

da kann man das direkt so einbauen.

Das ist immer ganz hilfreich.

Ja, ich habe letztens auch das irgendwo gesehen, aber ich habe es

mir noch nicht angeguckt.

Interessant.

Ja.

Ja,

wir haben so ein bisschen jetzt, glaube ich, über

die Syntax gesprochen,

das Beispiel und das, was da alles Schönes gibt.

Also man macht meistens halt mit diesem

Swap-Target oder sowas, ja, also

Moment, es gibt Swap und Target, glaube ich, ja.

Also das heißt, wir haben, wir sagen quasi, was

getauscht werden soll, wohin

das getauscht werden soll und

wann es getauscht werden soll.

Genau, richtig, das mit dem Trigger geht sozusagen

los, also bei einem Form muss

man den Trigger jetzt gar nicht angeben, weil bei einem Form

ist es das Drücken auf den

Submit-Button.

Aber es gibt eben andere Trigger, wie du

vorhin Dominik angesprochen hast,

den Revealed-Trigger zum Beispiel.

Also ich kann so einen Infinite-Scroll

implementieren, indem ich ganz unten

eben einen HTML-Schnipsel

habe, mit dem

Trigger Revealed und der

feuert dann, sobald dieses

Schnipselchen in den sichtbaren Bereich

kommt im Browser.

Und das ist natürlich dann relativ cool.

Dann kriege ich das Event, dann hole ich mir

neue Daten, dann kann ich 5, 6, 7

neue Einträge unten

machen. Und wenn der Nutzer nach unten

scrollt, kommt er wieder nach

unten, kommt wieder das Revealed-Event

und er holt sich den nächsten Eintrag. Und dann kann man

ohne eine Zeile

JavaScript zu schreiben, so ein Endless

Scrolling implementieren.

Und das ist ja eine feine

Sache.

Wir haben Swap.

Swap-Message in der HTML tauschen,

Auto-HTML, Target

und Out-of-Band gibt es auch noch.

Also wenn man zum Beispiel,

ich hatte bei mir so eine Art Warenkorb

Und wenn ich jetzt bei dem Warenkorb sage, ich kaufe irgendwas ein und sage, ich möchte davon jetzt mehr haben, mache ich sozusagen einen Plus. Dann habe ich erstmal diesen Bereich aktualisiert, wo der Nutzer geklickt hat, weil ich dort will ich statt einer 1 eine 2 anzeigen. Aber jetzt gibt es vielleicht rechts oben noch irgendwie ein Symbol mit Summe aller Waren im Warenkorb oder so.

mache ich mit dem ersten, also mit dem

eigentlichen Event, tue ich diese eine Zeile austauschen

und out of band kommt dann noch

dazu, bitte tausche

außerdem hier das Element

mit der und der ID aus und dann

kommt dann dort die neue Zahl

für die gesamte Summe.

Das gibt es auch noch, das out of band

Aktualisierung von Daten

angekommen ist. Also man kann eben zusätzlich

out of band, also wenn der Server

weiß, hier ich möchte noch was aktualisieren,

Was aber jetzt nicht in dem aktuellen Schnipsel mit aktualisiert wird, kann der Server out of band noch ein zusätzliches Schnipsel mitschicken, was dann eben am Client aktualisiert wird.

Der Anwendungsfall war eben so eine Art Warenkorb. Man klickt unten bei dem einen Artikel plus, dann weiß ich, jetzt habe ich jetzt zweimal diesen einen Artikel.

Aber oben, rechts oben als Beispiel, ist so ein Einkaufswagensymbol und da will ich die Summe aller Waren anzeigen.

kann ich damit eben das auch aktualisieren.

Also an zwei Stellen. Einmal diese

unten bei der eigentlichen Ware

und oben im Warenkorb.

Das ist auch nur so ein ganz nettes Feature

von dem HTMX.

Ja, was gibt's

sonst noch zu sagen?

Ja, auch solche Sachen, dass man

da fand ich auch nett

sagen kann, okay,

lad mal dieses Element

alle zwei Sekunden nach. Das ist halt auch so ein

Anwendungsfall

für Outer-HTML, da könnte man sich auch fragen, wozu braucht man eigentlich

Outer und Inner? Weil

wenn man das komplette Element ersetzt,

dann werden halt auch die

HTMLX-Attribute mit ersetzt. Und man kann zum Beispiel

dann von der Server-Seite her

steuern, wie lange

irgendwas dann, also man könnte zum Beispiel

machen halt irgendwie einen Newsticker oder sowas

und sagt halt, alle zwei Sekunden

werden da neue Daten geladen.

Und dann kann man von der Server-Seite aber sagen, wenn man das

komplette Element austauscht, okay, man nimmt diesen

Trigger raus, irgendwann

nach zehn Minuten oder so, und dann

halt keine neuen, wird halt

nicht mehr gepollt quasi.

Und dafür muss man dann das komplette Element

ersetzen, dann braucht man halt Auto-HTML.

Ja, also genau, solche Sachen kann man auch

sehr einfach machen.

Was gibt's noch?

Ja, genau,

überhaupt diese Geschichten, wenn vom Server

Sachen kommen, da weiß ich auch noch

nicht so genau, wie das dann, gibt's

Support für Websockets oder solche Sachen?

Ja, ja, WebSocket-Support

gibt's, habe ich aber selber jetzt noch

nicht ausprobiert. Und es wird

aktuell eben die Bibliothek

aktualisiert, dass WebSockets zu einem

externen Paket wird.

Dass man also das gar nicht mehr per Default

drin hat, sondern

dann sich selber nachladen muss.

Ich persönlich finde es gut, das hält die

Bibliothek klein. Ja, die meisten Leute brauchen

das halt nicht, denke ich mal. Genau, und dann kann man es auch

auslagern.

Ja, ich glaube,

Server-Send-Events

Support dafür ist auch irgendwie drin.

Da dachte ich auch so,

habe ich irgendwann letztens nochmal

geguckt, was das denn wirklich ist, weil das habe ich nie so,

das ist zwar schon uralt und gibt es total lang, aber

ich wusste nie so richtig, was das ist.

Aber ja, es ist halt auch eigentlich nichts Besonderes.

Und vor allen Dingen, es belegt halt auf dem Server auch,

man muss halt eine Verbindung offen halten, nur

dass man halt vom Client

aus nichts zurückschicken kann, sondern es ist halt eine

Verbindung, die immer offen bleibt, wo man

vom Server halt irgendwie Daten

an den Client schicken kann.

Aber ja, also mit Django geht das nicht gut.

Aber man muss halt dafür Django Channels halt verwenden.

Ja, genau.

Eine Sache fällt mir noch ein,

mehr so eine allgemeine Sache.

Viele sind ja Freunde dieser JSON-APIs,

weil sie sich dann denken,

ah, super, dann habe ich ja eine API

und damit kann ich zum einen ein Webfrontend machen

und zum anderen kann ich da eine API anbieten

für eine Maschine, Maschinenkommunikation.

Und das ist aus meiner Sicht Blödsinn.

Weil man da zwei ganz verschiedene Anwendungsfälle zusammenwürfelt.

Also bei einer GUI, da will ich super agil sein,

die will ich täglich aktualisieren können,

da will ich täglich deployen können

und da sollen sich auch täglich kleine Änderungen ergeben können.

Weil das den Nutzer in der Regel nicht stört,

wenn das so ein kleines bisschen irgendwie anders ist,

nur ein kleines bisschen verbessert wird

kontinuierlich.

Wenn ich aber eine Maschine zur Maschinenkommunikation

haben, ist sowas wie

A-B-Testing vollkommener Schwachsinn.

Natürlich, ich werde ja nicht

einer Maschine sagen,

du kriegst die API und

der andere Client kriegt

diese APIs und diese Daten.

Das ist ja vollkommen konträre, ganz

verschiedene Anwendungsfälle.

Und drum, das war bei mir

anfangs bei Angular, wo ich dachte, oh cool,

eine API und da kann ich dann

GUI entwickeln und außerdem

eben da einen maschinellen

Zugriff auf dieser Seite haben. Aber es sind eben

zwei ganz getrennte Dinge, die auch

ganz

getrennt behandelt werden sollten.

Und da

könnte man ja dann auch dann sagen, na gut, wenn ich

Maschine-Maschine-Kommunikation machen will,

könnte man ja sowas wie gRPC

einsetzen, was dann im Endeffekt

auch mehr Datentypen unterstützt

und insgesamt optimaler ist.

Jetzt sind wir wieder, wir haben noch nicht genau

RPC erklärt und jetzt kommst du gleich mit gRPC an.

Ich muss erklären, was das ist.

Das gRPC ist

eine Technologie von Google

und das ist ein binäres

RPC, also Remote Procedure Call

Methode

und das ist

sehr effizient und schnell.

Es ist auch

Arschima-basiert, also du musst

klar, der Server

sagt klar, was für Daten er austauscht

und das wird

im Kubernetes-Bereich

oder so ähnlich

dann auch stark verwendet.

Aber halt bei den Web-Entwicklern ist

gRPC noch nicht angekommen und

das wird wahrscheinlich auch noch ein bisschen dauern,

bis das da bekannt

und verstanden wird, um was es da eigentlich geht.

Ja.

Naja, da ist JSON

schon so das Ding, was man...

Also ich meine, es gibt ja im Grunde keinen

wirklichen Grund, warum man jetzt irgendwie...

Außer, dass man halt das JSON irgendwie nahe

liegt, wenn man jetzt

JavaScript macht, aber ansonsten

gibt es ja gar keinen Grund dafür,

dass man könnte halt auch irgendwie

andere

Datenformate halt benutzen.

Bei Jungle REST Framework war das ja auch mal so, da konnte man halt auch

ich glaube, ich weiß nicht, ob das heutzutage noch

jemand macht, aber früher war das halt durchaus

üblich da zu sagen, okay, ich rendere

meinen Kram nicht nach JSON, sondern nach XML.

Oder wie heißt dieses, es gibt auch

ein Binär-JSON.

B-JSON?

JSON-B gibt es.

Ja, nee, das ist, ach, ich hab's wieder vergessen, aber ja, es gibt irgendwie auch eine binäre Variante davon, die man auch mit Jungle Wrestling ganz gut verwenden konnte, da wurde es halt ein bisschen kleiner, aber ja, tatsächlich benutzen aber doch irgendwie alle JSON letztlich.

Ja, aktuell. Ich bin da ehrlich gesagt ganz tiefenentspannt. Also um 2001 habe ich meine Diplomarbeit geschrieben und klar, was war das Thema? XML. Also damals ging alles um XML und auch das HTML sollte XML werden und so weiter. Dann bin ich ja so froh, dass dann dort irgendwie die Vernunft gesiegt hat und das XHTML sich nicht durchgesetzt hat.

und eben, weil das ist

am Endeffekt dann auch nur Krampf, wenn man

das zu sehr in die Richtung treibt

und wie gesagt, damals war

alles mit XML, aktuell

ist alles mit JSON und

da bin ich auch ganz tiefenentspannt, dass da dann

irgendwie auch nochmal was Neues kommt.

So ist auf jeden Fall

die Entwicklung aus meiner Sicht.

Ja, naja, da ist

noch nicht

aller Tage Abend, was diese

jetzt alle auf JSON geeinigt hätten,

das sehe ich auch nicht so.

Ich meine, ehrlich gesagt, ich finde es

persönlich angenehmer als XML. XML war doch mal

ein Stück schrecklicher.

Das ist so ein Grund, wo ich sage, den Computer

will ich nicht anfassen.

Das ist komisch, ganz komisch.

Wirklich.

Ja, klar, da gab es die größten

komischen Sachen wie XSLT

und sowas, aber das ist lange her.

Viel schlimmer als Assembly oder sowas.

Tja, ja. Aber wir haben doch einige Sachen nicht erklärt.

Und zwar, wie hieß der nochmal?

Carsten Gross, glaube ich,

weil er möchte wahrscheinlich vermeiden,

dass man ihn tauern muss.

Sorry.

Jedenfalls hat er so einen Talk gehalten

und da hat er auch viel über Haters gesprochen.

Also Hater, ich habe einen noch.

Entschuldigung.

Das Akronym ist auch ein bisschen unglücklich.

Ja, sehr gut.

Was ist denn das und worum geht es denn da?

Da hatten wir eigentlich schon drüber gesprochen.

Ja, weil da gibt es ja schon Beispiele auch

auf der Seite von htmx.

Ich persönlich kann dazu halt nur sagen,

dass ich es nicht weiß und mich interessiert es auch nicht.

Das ist sein Steckenpferd

und er zählt viel und redet viel.

Aber mir ist es zu abstrakt.

Ich halte mich aus den Diskussionen

da auch raus, was das heißt, was das Hato ist

oder irgendwas.

Für mich ist HTTP greifbar,

HTML ist für mich greifbar und so weiter.

Aber das ist mir dann

zu abstrakt und

da kann ich nicht viel zu sagen.

Wahrscheinlich haben wir

tatsächlich darüber geredet, wenn das halt, also die Übersetzung

von Haters ist

Hypermedia at the Engine of Application State.

Also da geht es so ein bisschen darum, dass halt

tatsächlich die

Quelle der Wahrheit dann

an der richtigen Stelle steht, und zwar

im HTML, und ich weiß auch nicht mehr,

was er mit Hypermedia meint.

Hypermedia ist im

Webkontext HTML.

Obwohl, die Quelle

der Wahrheit ist für mich einfach Postgres.

Das sind die Daten, da kann man den Strom

ausschalten, dann kann man den Strom wieder

anschalten, dann weiß ich, wo meine

Daten sind, die sind im Postgres drin.

Und ja, das ist

dort, das ist eben

meine Perspektive.

Ja, aber genau, gut, das sind dann halt

deine Datenhaltung, aber

der Application State

ist ja jetzt nicht unbedingt in der,

da hast du ja auch noch andere Sachen, da hast du ja auch noch

solche Sachen wie

dein Cache oder du hast halt vielleicht

irgendwelche Queues und

du hast halt auch noch irgendwie eine Session

und ganz viel Zeugs.

Aber klar, natürlich,

also, ja, die Frage ist halt,

ja, also bei alles, was sozusagen im Browser

passiert, ist halt in dem HTML halt irgendwie drin.

Das ist halt so ein Ding, diese HATI

ist Geschichte, aber ja, ich finde das auch

ziemlich kompliziert und theoretisch

und das ist sehr schwer, das zu erklären.

Ich finde das ähnlich wie

Dependency Injection, da kann man sich

das hundertmal erklären lassen und dann

sage ich immer, für mich ist es wie Konfigurierung.

Aber keine Ahnung,

das ist mir zu abstrakt dann einfach.

Ja, weil man

den Talk schaut und erklärt das halt so ein bisschen,

das ist vielleicht ganz gut, wenn man das vielleicht so ein bisschen versteht.

Aber den Talk müssen wir natürlich auch verlinken,

der ist ja natürlich sehr bahnrecht.

Ja, okay.

Ja, aber da am besten hört man sich genau

den Talk dann an und nicht uns, wie wir

darüber reden.

Ja, das ist wahrscheinlich so.

Ich kann da nicht mitreden.

Dann habe ich noch eine Frage irgendwo.

Ich sehe da, wo sind die Grenzen?

Wann sollte man tatsächlich auf React oder Vue umsteigen?

Da kam vorher mal so eine Frage.

Da sehe ich aktuell eigentlich keinerlei Grenzen.

Es erinnert mich so, wie ich vor 20 Jahren mit Python angefangen habe.

Und da war eben so eine Sache in der Firma.

Wollen wir das nicht lieber mit Python machen, anstatt aus einer Mischung aus C, C++ und Shell-Skripten? Und dann hieß es, naja, da konnte ich ja bloß herausboxen, dass wir für den Prototypen Python nehmen. Aber danach muss es sozusagen dann mal richtig gemacht werden.

Richtig, richtig, C++ und so.

Ja, und das war ich sehr froh, dass ich diesen Kompromiss rausboxen konnte.