Transkript: HTMX

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

Diesmal wollen wir etwas über HTMX sprechen.

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

Ja, halli, hallo, willkommen, Dominik.

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

Hi Thomas.

Hallo, groß.

Jo, hallo, hallo.

Ja, 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.

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

Eigentlich müssten wir das am Anfang stellen.

Sagen Leute Hallo und man weiß gar nicht, wer das ist.

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

Ich mache Softwareentwicklung.

Das ist schon eine ganze Menge Jahre.

Hab 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 HTMX.

Und ja, ja, 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.

Sehr schön.

Ja, sehr cool.

Ja, dann gehen wir uns die 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.

Weihnachtsgeschenk, eure Version ist deprecated, ja.

Ja, das heißt also 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 mal schon wieder so lange her.

Ich glaube ja, bei 3.6 habe ich glaube ich angefangen, also schon gar nicht so lange her.

3.7 kam dann relativ fix und jetzt ging schnell.

Also meine News nicht, ich habe nur gelesen, dass Python Programmiersprache des Jahres 21 geworden ist.

Yay!

Wir werden Famous und Schuhrug.

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 auch eigentlich relativ wurscht.

Ja, ich habe letztens eine irgendwo kurz, wo habe ich das gehört?

Ein Programmierbarer-Podcast war es, glaube ich.

Dass da jemand meinte, so, ja, das ist irgendwie eine niederländische Firma und das, was sie machen, ist, sie machen irgendwie, nehmen 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.

Yay.

Und das ist natürlich irgendwie, ja, gut, ob das jetzt so bei einem wahnsinnig viel sagt, ist halt.

Programmierbar.

Das habe ich von Ihnen noch nicht gehört.

Ja, ich höre immer so, was an anderen Podcasts auch so gibt es.

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 sowas, das finde ich aber ein bisschen komisch.

Also 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, äh, nee, nicht Webwork.

Das ist ein Mieter hier in Düsseldorf.

Working Draft heißt einer.

Auch einer der vielleicht der älteste Webentwicklungspodcasts und sicherlich einer der bekanntesten.

Auch mit Leuten hier aus Düsseldorf.

Und ja, das ist aber auch sehr frontendlastig.

Und genau, programmierbar ist relativ neu, ist halt auch sehr frontendlastig.

Folge 116?

Die machen häufig Dinge, ja, aber achso, dann vielleicht auch nicht so neu.

Ja, aber gut, im Moment werde ich ja gerade sehen.

3.

November, 2.

November, 10.

November, 12.

November, 17.

November, 24.

November.

Also, ja, also die Pace ist relativ häufig.

Ja, Working Draft hat es irgendwie über 500, 531 sind es jetzt irgendwie oder so.

Tja, hoch.

Und wir machen einmal die Woche.

Darfst du schon?

Ja, da brauchen wir noch ein bisschen.

Wie sagt jemand, mit dem Gameboy kann man jetzt in 50.000 Jahren einen Bitcoin meinen?

Ah ja, okay.

Irgendwie so,

die Teil ist jetzt auch rein aus der Luft gibt es.

Ja, und dann gibt es, also was ich auch manchmal noch höre, ist sowas, also jetzt wenn es deutschsprachigen Geschichten sind, Englischsprache gibt es natürlich endlos jede Menge, aber da gibt es noch sowas wie Softwarearchitektur im Stream.

Höre ich manchmal.

Und InnoQue hat ein paar Podcasts, das ist eine Firma und die hat auch was mit dem, also der Mensch, der Softwarearchitektur im Stream macht, der arbeitet da auch bei Anton.

EBA hat wollte.

Und da arbeitet auch jemand, also der Stefan Tilkoff arbeitet da auch und der, der ist auch viel in anderen Podcasts unterwegs, da habe ich auch einen Working Graph zum Beispiel.

Mal ein sehr schönes, auch zum passend zum Thema, was wir gleich, worüber wir gleich reden wollen.

Da gibt es eine Episode zum Thema Singlepage-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 auch schon mal eine Episode gemacht.

Ja, aber also so in dem, also ganz kurz müssen wir es ja gleich wieder erwähnen, weil das ja so ein bisschen heute auch

darum geht.

Ja, 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 ist toll.

Aber ja, es ist halt auch ein sehr vornelastiger 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 hier mit den Rosen

vorne sieht es gut aus.

KI in der Industrie, glaube ich, ist eine.

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

Ja.

Ansonsten mehr fällt mir jetzt ehrlich gesagt nicht ein, was es da auf Deutsch gibt.

Fällt dir noch was ein, Thomas dazu?

Du hörst gar nichts in die Podcast-Staten.

Meine Überlegung gerade war, bloß ob es im DevOp-Bereich, über Kubernetes oder irgend sowas, also im deutschsprachigen Raum noch was gibt.

Naja, keine Ahnung.

Ist mir auch nicht, 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, da glaube ich, würde ich das auch gar nicht mitbekommen.

Ja, der Nico hatte, glaube ich, so ein, zwei Sachen da.

Hat den Nico natürlich.

Aber der hat auch, glaube ich, schon ein halbes Jahr nicht mehr neue Folgen released.

Also weiß ich nicht, ob

es den noch gibt.

Von dem habe ich letztens gehört, der macht er irgendwie so ein Live-Webinar-Ding Stream, auch eher so Richtung Stream geht das irgendwie gerade.

Okay, okay.

Aber ja, stimmt.

Nee, 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.

Cool, ja.

Ja, ja.

Ja, ansonsten weiß ich nicht, gab es in der Python-Welt irgendwelche Neuigkeiten, irgendwelche interessanten Dinge?

Sonst.

Jahrespause, ne?

Ja, Jahreswechsel ist immer ein bisschen, oh ja.

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

Dann können wir das nicht so ein bisschen.

Da sind wir dieses Mal mit dem erstaunlich früh durch.

Jo, und wie wir ja schon angekündigt hatten, angedroht, gibt es nun auch ein bisschen Werbung.

Der Sponsor für diese Episode ist NordvPN.

Das ist ein VPN-Anbieter und da könnt ihr etwa auf nordvpn.com slash Python Podcast gehen und bekommt da 73% Rabatt auf ein Zweijahrespaket.

Und noch einen Gratismonat 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 ihr euch immer angucken.

Ist vielleicht ganz nett, manchmal braucht man das ja schon.

Also ich war zum Beispiel letztens irgendeinen Urlaub und wollte da die Dinge weitergucken, die ich normalerweise so gucke und musste dann festellen.

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 VPN aktivieren klicken und dann geht das halt einfach weiter.

Und hatte ich nicht überlegen, ob ich das nicht vielleicht mal haben möchte, ne, für den Fall.

Und 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 Interneterlebnis verhelfen, indem ihr ein VPN benutzt.

Ja, genau.

Und wenn ihr das mal ausprobieren möchtet, einfach auf nordvpn.com slash Python Podcast gehen und ja, 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 es erfunden hat, um einfach HTML so zu erweitern, wie es der Standard bis jetzt nicht zugelassen hat.

Also, dass man kein JavaScript mehr braucht, um coole, responsive Sachen im Web zu bauen.

Na doch, JavaScript brauchst du schon.

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

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, also vielleicht nochmal 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 denn 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.

Wie früher hättest du es denn ja?

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 also gut, fangen wir gerade mit dem harten theoretischen Kram an.

Es ist die Frage, ob das 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.

Vorher, was man vorher gemacht hat, ist halt so Klein-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 jetzt haben 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?

Das hatten wir, wie gesagt, in der Restepisode diese Dissertation von Roy Fielding, der halt auch an den Stadnarz da maßgeblich mitgearbeitet hat mit Tim Vanasley 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.

Und ja, aber es ist halt die Frage, ob das so interessant ist.

Ja, ich glaube, das hatten wir ja schon in der Reste-Evision, aber ich glaube, da müssen wir es gar nicht so ein.

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

Also wenn man bei Client Server war das Problem früher immer, man da irgendwie was geändert hat, dann muss man immer dafür sorgen, dass der ja, dass ja 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 Browser noch funktioniert und muss sich darum 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 Singlepage-App-Teil und ich glaube, das müssten wir 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 nochmal erzählen.

Also gerade was kleinserver so ist, aber der, glaube ich, der entscheidende Unterschied, was HTMX 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-Side.

Aber vielleicht will der Thomas das gerade genau da jetzt nochmal einsteigen.

Ja, also bei HTMX, es 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 ein DOM-Objekte machen.

Das ist eben so recht revolutionär eigentlich.

Revolutionär so hingegen, weil es halt wie das Wort Revolution ist im Endeffekt 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, ich finde es super spannend.

Ich habe, ich hört ja irgendwie schon seit einiger Zeit davon und genau, also wenn man sich anguckt, was sind die meist gesehenen Talks eben auf sowas wie, das ist auch der, glaube ich, der ist der Grund, warum wir auf die Thomas gekommen sind.

Irgendwie bei DjangoCon EU oder DjangoCon US, das ist halt HTMX, das ist halt ganz heiß.

Und ja, ich kann es auch sehr gut verstehen.

Also ich habe irgendwann mal angefangen, mich auch mit diesen sozusagen Frontend-Framework so ein bisschen zu beschäftigen.

Und für mich war damals der Grund, warum ich das gemacht habe, dass ich gerne so, also so ein UI-Anmutung gerne hätte wie bei einer nativen Applikation sozusagen.

Und das hat man ja halt so früher eigentlich bei Webseiten nicht so wirklich gehabt.

Weil, naja, da hat man immer ein 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, eine 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 Latez mehr hat und dass das halt alles super schnell ist und dass sich das so anfühlt wie was Natives.

Und das hatte mich interessiert und 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-Sturz da mitmachen.

Okay, und 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 halt so ein oder Webseiten so ein Problem ist, lag an diesem Request-Response, weil es dauert halt irgendwie, je nachdem, wo ein Server stört, steht halt mal alleine 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 habe 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ßenrum, 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.

Ja, und tatsächlich, das habe ich jetzt auch, ich habe jetzt auch mit HTMX so ein bisschen rumgespielt oder so und da 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.

Weil das vielleicht ja dann hast du zu viele Daten dann sonst am Client 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 halt 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 halt funktioniert.

Ja, aber das Ganze rendern so lange dauert.

Also 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 unentwictuiv 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 ungewöhnlich, weil 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 für mich auch so einen Sinn, wenn man halt irgendwie diese serialisierten Objekte durch die Gegend schicken kann.

Und deswegen, also was meintest du denn damit, wenn du sagst, dass wir zurückdrehen?

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

Also Zurückdrehen, das war halt eher so zeitlich gemeint, also dass man eben es so ähnlich macht, wie man es vor zehn 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 dir irgendwie und das ist nicht schön.

Und als das Angular dann aufkam, dann dachte man, ah, das ist sauber, weil das ist, weil JSON geht da über die Leitung und deshalb muss das ist das einfach besser, weil es schön ist und sauber ist.

Und aber diese Gleichung, die hat bei mir ein bisschen gebraucht, um die aus dem Kopf rauszustreichen, dass es eigentlich Käse ist.

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

Also es ist viel pragmatischer, eigentlich der 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, kann bloß sagen, dass es auch eine ganze Menge andere Leute eben sozusagen auch sehen, die ihr gerade halt Leute, die aus den eher Backend-Sprachen kommen, die eben Python oder Ruby oder irgendwas anderes programmieren, die haben halt 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 HTMX 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.

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 sie aber halt auch bloß nur dieser kleine Bereich austauschen.

Und das macht halt die Seite irgendwie ja und 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 dem Podcast so die Episoden oder bei dem Blog, die Artikel.

Und jetzt paginatet man da so durch.

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

Und das habe ich jetzt mit HTMX gemacht.

Und auch selbst wenn man den kompletten quasi Content der Seite austauscht, ist es immer noch sauschnell und man spürt da keinen Unterschied oder man hat nicht das Gefühl, dass das jetzt irgendwie, äh, irgendwie, dass man den kompletten Content ausgetauscht hat.

Sondern erst wenn halt man tatsächlich die komplette Seite austauscht, dann wird es langsamer.

Also Latenze habt so 100 Millisekunden merkst du halt dann vorher ein bisschen drunter, also unter 50 oder ist halt.

Ja, da merkt man das eigentlich nicht und das kann man durchaus schaffen, da drunter zu bleiben.

Und das ist natürlich dann, oder da dachte ich so, als ich das gemerkt habe, okay, dieser Use Case geht auch damit, dachte ich so, wow, okay, dann entfällt für mich eigentlich der Grund für diese JavaScript-Ding-Dinger ab.

Also was mich halt auch interessieren würde, was ich jetzt noch nicht genau gesehen habe, aber es liegt wahrscheinlich daran, dass ich das noch nicht 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 Ganze 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 heute die ganz normalen HTML-Tags.

Also wenn du eine Seite hast und da sind eben 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 machst, also für eins dieser Forms, dann werden die Daten dieses einen Forms zum Server geschickt und kriegst die Antwort wieder zurück.

Also dann die Komponenten sind sozusagen HTML-Tags.

Ja, also ich glaube, also wenn du, wenn du meinst, dass du sowas hast, also eben View 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, ist halt ein moderneres oder älteres, also eigentlich würde ich sagen, ist es halt das, ist 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 muss 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 jetzt 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, also ich, also der Grund, warum, also 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, das ist 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 HTML, das ist halt ein Dokumentformat.

Es ist halt nicht so, dass das einfach nur Daten sind.

Also das Gute ist natürlich auch, als Backend-Entwickler kann man natürlich sagen, mit den Pixel-Chips beschäftigen sich jetzt die Frontendler mit, man gibt ihnen einfach die Daten und dann ist es gut, da hat man damit nichts mehr zu tun.

Das heißt, es gibt ja auch diese Zweigattung von Entwicklern.

Aber das halt auch führt halt dazu, dass es nicht so, dass es halt 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 hast du halt 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 ist eigentlich, das sind immer die gleichen Daten.

Das ist halt.

Und ja, 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 da hinstellen auf einmal.

Das hast du 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 die Datentypen sind recht eingeschränkt.

Also ordentliches Time-Delta oder irgendwas.

Ja, das nicht.

Und da

persönlich bin ich persönlich halt großer Freund von Postgres.

Das ist enorm, was ist da alles Skript 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 für mich 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.

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, das ist 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 gelegen hat, jetzt glaube ich dem wieder auf und jetzt, was macht die Applikation denn jetzt mit den Daten?

Das wird nicht funktionieren.

Das haut nicht hin und das hat man ja auch eigentlich in allen von diesen frontendlastigen Anwendungen, dass dann ab und zu irgendwo 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 mehr 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 es prinzipiell ja auch gegen Baum gehen, weil es dann nicht mehr hinhaut auf Serverseiten.

Wenn sich tatsächlich an der Datenschema oder so irgendwas geändert hat.

Und ja, okay, ja.

Aber tatsächlich, ja, ja gut.

Okay, insofern.

Ja, also 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.

Okay, aber einmal kurz.

Aber du kriegst das Problem auch deutlich schneller.

Also, und 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 Web-Geschichten, dass man sagt, das musst du nicht mehr machen.

Also, um nochmal zurückzuhören, 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 bitte 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.

Nee, das ist sozusagen 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.

Der State der Applikation, die logisch.

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

Also auch 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 auf dem Server liegen.

Also der große Unterschied zu Web ist jetzt sozusagen, okay, jetzt rede ich über Dinge, weil ich keine Ahnung habe, aber der große Unterschied ist halt, dass das liegt halt in dem HTML selber.

Also das ist halt der große Unterschied zu allem, was früher war.

Das ist halt sozusagen dieser revolutionäre Schritt.

Das hatte man vorher, soweit ich weiß, noch nie gemacht.

Und das ist neu in HTML.

Und mit Rest, sozusagen.

Na gut, ich kenne halt auch die Frage, was man will.

Also das, ob man jetzt so eine Seite will, eine Seite, die sich eben super schnell lädt, weil der Nutzer bei Google was nachgesucht hat und dann folgt er dem Link, der ihm angezeigt wird und dann zack, will er die Seite da haben und will, will die Seite geöffnet haben und sehen.

Und da ist halt ganz wichtig, dass jetzt Google mit den Webweitels 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 da 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 Eigent auf den Kisten.

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.

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.

Okay, das ist okay, da kann man bewarten.

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 ist halt, das liegt halt im Use Case.

Kommt halt drauf, 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, und

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, wenn hinter jedem Link erstmal irgendwie ein paar megabyte großes JavaScript-Bundle liegt, was du laden musst und dann erstmal ein Ladebalken eingezeigt wird und dann einen, ich initialisiere die Applikation, ja, 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 es halt diese, 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 Server-Side Rendering und den ganzen Spaß.

Moment, was ist Hydration?

Was ist Dehydration?

Was ist Server-Side Rendering in dem Fall?

Gemeint?

Ja, also du benutzt im Grunde Node.js auf dem Server, um halt deinen, also du hast ja meistens dann auch so eine Template-Sprache, so ähnlich wie Django Templates, bloß halt in JavaScript, also JSX oder weiß ich nicht, wie das bei View heißt, keine Ahnung.

Und du kannst das ja jetzt, du kannst es im Browser rendern, ja.

Da läuft JavaScript, was de Templates nimmt und dann halt quasi mit den Daten, die es über JSON oder sonst irgendwie bekommt, halt dann HTML rausrendert.

Du kannst es 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.

So dass das Rendering halt nicht bei dir im Browser passiert, sondern auf dem Server.

Deswegen Server-Side-Rendering.

Und das ist halt dann für kürzere Antwortzeiten.

Ja, ja, also dann fühlt es sich für dein Browser, ist es dann so wie eine klassische, wie so eine Django-Website oder so.

Und dann aber schiebt der Server dir ja doch dann doch irgendwie so einen 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 alles?

Ich nehme mal an, dass das irgendwie sozusagen dieser reine, das hat mir alles gekriegt, das ist quasi in Anführungszeichen irgendwie trocken und weil es halt so schadisch ist.

Und ich nehme mal an, dass sie mit Hydration meinen, du schickst halt ein Bundle dahin und wenn das Bundle da ist, dann sagst du, okay, jetzt gibt mir mal die Daten per JSON und dann rendert es das halt auf den Client selber.

Das ist das,

was halt zum Beispiel bei VTS und so Komponenten passiert, wenn da bestimmte Teile im DOM getauscht werden, so HTML-Stipsel von Antworten vom Server dann auch.

Nee, nee, das

muss man bloß, das ist bloß on-top sozusagen.

Das ist bloß, wenn du es optimieren willst.

Also das ist bloß für den Fall, wenn du feststellst, einmal 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 mit du jetzt zum Beispiel NUX nimmst bei Vue und machst da Server-Side-Rendering, dann dein Browser kriegt einfach nur HTML und zeigt das an, wie bei jeder anderen Seite auch.

Für den, der führt keinen JavaScript erstmal aus.

Nur dann später.

Also die Frage ist, wo es so 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 den Client gerendert und dann werden nur die Daten per JSON geholt und dann, und das ist, denke ich, das, was mit Hydration gemeint ist.

Und die Sache ist, es ist schön, dass man das alles machen kann.

Und die Frage ist aber, ob man es 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 den 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.

Und 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 das 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 stolpert man selbstständig drüber.

Vor mehr als einem Jahr war das eben noch recht unbekannt.

Gut, und da war es halt dann eine coole Sache und gerade wenn man halt, eh sagt, man selber ist in einer Backend-Sprache 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 View 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 Vue.js.

Und ja, das ist dann manchmal so, dann ist der Frontend-Entwickler sozusagen oder da ist da einer mal krank oder im Urlaub oder irgendwas und dann klemmt es Frontendseitig, obwohl Backend-Kapazität dabei und dann ist es vielleicht mal andersrum oder irgendwas.

Ist doch eigentlich schöner, wenn man da sagt, okay, ich mache wirklich eben Full Stack 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.

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 die JavaScript free bad finden.

Und das ist halt auch schon mal also ja.

Also ja, alle

Leute, die JavaScript-Liebe haben, die bitte einmal aufzeigen.

Ja, naja, gut, also 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, naja, 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 sagen wir mal so, diesen Druck, den gibt es schon sehr stark.

Und aber nochmal, vielleicht ganz kurz, ich würde ganz kurz nochmal da ansetzen, wo wir eben waren, weil auch, 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, ja, auch wenn das dir jetzt so nicht mehr so aufhält, aber da werden halt dauernd die gleichen minifizierten JavaScript-Dinger durch die Gegend geschoben.

Wenn du von einer Seite auf die andere gibst, immer das gleiche Zeug, megabyteweise.

Das heißt, das ist halt

vom Verrückt.

Weil ich nicht einzelne Teile vom Dom nur tausche?

Ja, weil du musst halt die komplette Applikation schickst du halt in der Gegend drucken.

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 VTRS zum Beispiel so löst, dass man dann eben nur den einzelnen kleinen Bestandteil dann innerhalb dieser Komponente neu rendert.

Ne, 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, du kannst halt teilweise mit, es gibt so Exema-Skript jetzt Module irgendwie auch.

Und manchmal kannst du halt, musst du für manche Seiten Module nachladen und so.

Aber bisher der klassische Weg war halt, du baust deine komplette Applikation in ein JavaScript-File und das lieferst du aus.

Und solange du das nicht hast, geht gar nichts.

Und ja, also wenn deine Applikation halt, also ich meine gut, sie muss nicht über Megabyte groß sein, aber es ist schon groß und ja, oft ist das halt das View drin oder React oder so.

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.

Eigentlich wollten wir ja über HTMX reden und nicht über Render, nicht was anderes irgendwie.

Ja, ja, ja.

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.

Also 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 Click-to-Edit.

Das ist glaube ich mit das erste.

Hat man erstmal so eine ganz normale HTML-Seite und dann unten ist so ein kleiner Block und da steht irgendwie Click-to-Edit und in diesem Block sieht man irgendwie Name, sag ich mal, Peter oder irgendwas oder irgendein Namevorname ist aber ein ganz einfaches Nutzerdaten.

Da 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 ä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 natürlich so, dass kein 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 Scroll-Position oder irgend sowas alles gleich bleiben.

Und da ist die Frage, wie das funktioniert.

Also mit dem Click to edit wird the server contacted.

And the server schickt then ein kleines HTML-Schnipselchen on the client.

And entsprechend the angabe in the HTML and the HTMX erweitert im Endeffekt das HTML plus um ganz einfach neue Attribute.

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

Gibt es verschiedene Swap-Methoden, da kann man sagen, inner HTML soll ausgetauscht werden, also das in dem Tag oder outer HTML, sprich das Tag selber soll auch mitersetzt werden.

Na gut, und dann kriegt man eben dieses HTML-Schnipselchen vom Server und das wird dann durch HTMX dann dort eingebaut.

Und dann hat man das Formular, kann es befüllen und am Endeffekt passiert der gleiche Spaß wieder.

Also 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, tausch mir bitte dieses One 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 Infinite Scroll machen kann, dass er dann in diesem HX-Web-Attribut einfach After End sagt und dann wird das einfach angehängt, dann das, was man auf das bekommt.

Also da kriegt man eigentlich den besten Eindruck, wenn man einfach mal diese Beispiele.

Das ist schon super.

Ja, also ich meine, im Grunde, also ich eigentlich ist die Idee, also mich wundert, dass das nicht schon viel früher passiert ist, ehrlich gesagt.

Mir geht es genauso.

Ich dachte, es ist ja genau, von dem ich eigentlich geträumt habe, gerade vor Jahren, als ich mit Jake Ferry da, so 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.

Das ist 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 andz dann darum, dass das dann auch umgesetzt wird und so.

Und das macht es im Endeffekt dann einfacher.

Ja, und im Grunde behandelt es eigentlich, macht es genau das gleiche, was man in einem Browser auf einer Webseite tut, nur halt nicht jetzt, dass man zum Beispiel, wenn man einen Browser halt auf einer Webseite ist, kann man ja immer nur das komplette HTML-Element ersetzen.

Und jetzt hat man sozusagen per JavaScript in HTMX 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 ein Browser, lösen halt nur zwei Events, lösen halt irgendwie 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 Delete-Put-Patch.

Und das habe ich mich auch früher gefragt, also gab es auch so bei Djungo Rest-Framework ja irgendwie immer diese Browsable-API und dann wollte ich halt mal so, da drin kann man ja auch Dinge hinzufügen und so.

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 Serverschicken sein.

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-saukule Idee.

Also bei mir hat es auch relativ schnell Klick gemacht, nachdem ich die ersten Beispiele da mir angeschaut habe.

Und es ist enorm, wie da auch das Interesse daran wächst.

Also zum Beispiel im Django, was ich jetzt ja eben einsetze für die Serverseite, kann man ja auch auf einer HTML-Seite mehrere Formulare dann reintun und mit Präfixen das dann für auswerten und so weiter.

Und es war auch, wenn ich mich da zurück erinnere, 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 es auch serverseitig deutlich einfacher, das zu handeln.

Ja.

Naja, und es ist ja jetzt tatsächlich auch nicht nur, also HTMX 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.

Und das war halt dann quasi auch halt, äh, HTMX ist jetzt sogar der Nachfolger davon, der dann halt ohne JQuery rauskommt und diesen ganzen Kran nicht mehr macht.

Und wo ich auch denke, das ist halt ein sehr breiter Trend, das macht es auch so interessant, weil es ist halt nicht nur diese eine Geschichte, es ist nicht nur HTMX, sondern diesen Ansatz verfolgen ganz viele Projekte in ganz vielen unterschiedlichen Sprachen.

Und ich weiß nicht, in welchem Talk das war, ob das der von der Junge US war oder nee, es war auch, glaube ich, mit Talk Python 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, der Alexia.

Und ich habe den auch nochmal aber anders 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.

Ja, krass.

Und das sagen, und also das ist halt dieses Thema.

Also ganz viele Backend-Leute, die eigentlich nie JavaScript schreiben wollten, schreiben, 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 bitte auch viel mit Ruby on Rails zusammenverwendet, gibt es halt nur Hotwire.

Also Akronym für HTML Over the Wire und Turbo Links, wo halt dann quasi schon die Seite hinter dem Link gefatscht wird, sodass wenn man auf den Link draufklickt, das halt dann direkt da ist.

Dann gibt es eben bei Elixier-Welt Phoenix gibt es LiveView, wo auch HTML-Snippets halt über den Websocket geschickt werden.

Dann gibt es das in PHP, da heißt das irgendwie Livewire in Laravelle.

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, ja.

Ja, richtig.

Das 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 und Rails.

Das ist Hotwire.

Und darum 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 Carsten 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, überhaupt erstmal reinzukommen, aber wenn man es, 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 ein 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 Request halt ein Attribut dran bappt.

Ich weiß nicht, ob 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, rendert man eben die komplette Seite, das ist auch sowas.

Wenn ein Browser kein JavaScript kann, ist es gar kein Problem.

Das funktioniert einfach so weiter, weil auf der Serverseite rendert man halt, wenn man sieht, okay, es war kein HTMX-Request, dann rendert man einfach die komplette Seite raus.

Ist gar kein Problem.

Und wenn es ein HTMX-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 Windowware dann, um halt da quasi sich nicht selber überlegen zu müssen, wie man jetzt erkennt, ob das jetzt ein HTMX-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 er zum Beispiel ein 400 zurückkommt auf einen HTMX-Request, dann sieht man nichts, weil HTMX schmeißt einfach die Antwort dann weg.

Und vielleicht will man die Standard-Django-Fehlermeldung aber haben mit einem Stackface oder so.

Und dafür ist

halt auch noch so ein bisschen, das ist, glaube ich, eine HTMX-Extension in JavaScript, die in Django HTMX drin ist, die dann halt dafür sorgt, dass man eben die normale Django-Fehler-Seite sieht, wenn man auch wenn ein HTML-X-Request halt serverseitig schiefgegangen ist.

Genau, also ich habe es mir auch angeschaut, die Bibliothek, habe eher 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 dann ab dann werden eigentlich meistens Schnipsel ausgetauscht und die URLs, wo ich eben einen Schnipsel bekommen will, die liefern immer einen Schnipsel zurück und die werden immer über HTMX aufgerufen.

So dass ich diese Fallunterscheidung serverseitig gar nicht habe, von wegen, ist das jetzt ein HTMX-Request oder nicht.

Es gibt, glaube ich, auch von Django Forms, irgendwie Django Forms Dynamic oder sowas, dass man da quasi Django Forms nutzen kann, direkt als HTMX-Forms.

Ah, okay.

Das kann ich noch gar nicht sagen.

Das ist irgendwie auch ganz

cool dazu.

Cool, ja.

Das heißt man, also Django Forms kennt ihr ja vielleicht, da kann man das direkt so einbauen.

Das ist immer ganz hilfreich.

Ja, ich habe letztens auch das immer gesehen, aber ich habe es mir noch nicht angeguckt.

Interessant.

Ja.

Ja, jetzt haben wir, also wir haben so ein bisschen jetzt, glaube ich, über die Syntax gesprochen, über das Beispiel und das, was es alles schon 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 sagen quasi, was getauscht werden soll, wohin das getauscht werden soll und wann es getauscht werden soll.

Genau, richtig.

Das mit einem Trigger geht es 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 von 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 567 neue Einträge unten machen.

Und wenn der Nutzer nach unten scrollt, kommt er wieder nach unten, kommt wieder das Revealed-Event, Schupp und er holt sich die nächsten Einträge.

Und dann kann man, ohne eine Zeile JavaScript zu schreiben, so ein Endless Scrolling implementieren.

Und das ist ja eine feine Sache.

Hier haben

wir Swap-Messer inner HTML tauschen, outer HTML, Target.

Und Out of Band gibt es auch noch, also wenn man zum Beispiel, ich hatte bei mir so eine Art Warnkorb und wenn ich jetzt bei dem Warnkorb sage, ich möchte, oder ich kaufe irgendwas ein und sage, ich möchte jetzt davon jetzt mehr haben, mache ich sogar sozusagen ein Plus.

Dann habe ich erstmal diesen Bereich aktualisiert, wo der Nutzer geklickt hat, weil ich dort will, ich statt eine 1, eine 2 anzeigen.

Aber jetzt gibt es vielleicht rechts oben noch irgendwie ein Symbol mit Summe aller Waren im Warenkorb oder so.

Und mache ich mit dem ersten, also mit dem eigentlichen Event durch diese eine Zeile austauschen.

Und out of Band kommt dann noch dazu, bitte tausche außerdem hier das Element mit dem der ID aus und dann kommt dann dort die neue Zahl für diese 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.

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 Einkaufswagen-Symbol und da will ich die Summe aller Waren anzeigen.

Dann 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 einem HTMX.

Ja, was gibt es 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 Auto-HTML, dann könnte man sich auch fragen, wozu braucht man eigentlich Outer und Inner?

Weil wenn man das komplette Element ersetzt, dann wird halt auch werden halt auch die HTMX-Attribute mitersetzt.

Und man kann zum Beispiel dann von der Serverseite her steuern, wie lange irgendwas dann, also man könnte zum Beispiel, man hat irgendwie News-Ticker oder sowas und sagt halt alle zwei Sekunden werden da neue Daten geladen.

Und dann kann man von der Serverseite aber sagen, wenn man das komplette Element austauscht, okay, man nimmt diesen Trigger raus, irgendwann nach zehn Minuten oder so und dann werden halt keine neuen, wird halt nicht mehr gepollt quasi.

Und da fünf man oder dann komplett das komplette Element ersetzen.

Dann braucht man halt Autar-TML.

Ja, also genau, solche Sachen kann man auch sehr einfach machen.

Hm.

Was gibt es noch?

Ja, genau, überhaupt diese Geschichten, wenn vom Server Sachen kommen.

Da weiß ich auch noch nicht so genau, wie das dann.

Gibt es Support für Websockets oder solche Sachen irgendwie?

Ja, ja, Websocket Support gibt es.

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, es hält die Bibliothek klein.

Die meisten Leute brauchen das halt nicht,

denke ich mal.

Genau, und dann kann man es auch auslagern.

Ja, ich glaube, Server-Set-Events-Support dafür ist auch irgendwie drin.

Da dachte ich auch so, habe ich jetzt, 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 lange, aber ich wusste nie so richtig, was das ist.

Aber ja, es ist halt auch eigentlich nichts Besonderes.

Und vor allen Dingen es blickt halt auf den 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, zum mehr so einer allgemeinen 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-Maschine-Kommunikation.

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 es so ein kleines bisschen irgendwie anders ist und ein kleines bisschen verbessert wird, kontinuierlich.

Will ich aber eine Maschine zur Maschinekommunikation haben, ist sowas wie AB-Testing vollkommener Schwachsinn natürlich.

Ich werde ja nicht eine Maschine sagen, ha, du kriegst die API und der andere Klein 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 eine maschinelle Zugriff auf diese 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 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.

Wir haben noch nicht genau RPC erklärt und jetzt kommst du vielleicht mit GRPC an.

Das muss man kurz 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.

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 Webentwicklern 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 großen, keinen wirklichen Grund, warum man jetzt irgendwie, außer dass man halt das JSON-Ig naheliegt, wenn man jetzt JavaScript macht.

Aber ansonsten gibt es da ja gar keinen Grund dafür, dass man könnte halt auch irgendwie andere Datenformate halt benutzen.

Ich meine, weil 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 auch wirklich üblich, da zu sagen, okay, ich rendere mein Kram nicht nach JSON, sondern nach XML.

Oder wie heißt dieses?

Es gibt auch einen Binär-JSON B-JSON?

JSON-B gibt das.

Ja, nee, das ist.

Ach, ich hätte das.

Ich habe es wieder vergessen.

Ja, es gibt irgendwie auch eine binäre Variante davon, die man auch mit Jungrexframe ganz gut verwenden konnte.

Da wurde es halt ein bisschen kleiner.

Aber ja, tatsächlich benutzen aber auch irgendwie alle JSON letztlich.

Ja, aktuell.

Ich bin ja ehrlich gesagt ganz tiefen entspannt.

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 es 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 tief entspannt, 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 auf JSON geeinigt hätten, das sehe ich auch nicht so.

Das ist halt, also, ich meine, ehrlich gesagt, ich finde es persönlich angenehmer, als XML war doch mal ein Stück schrecklicher.

Das ist so ein Grund, wo ich sagen würde, den Computer will ich nicht anfassen.

Das ist komisch, ganz komisch.

Wirklich.

Ja, klar, da

gab es die größten verschiedenkomischen Sachen wie XML.

Viel schlimmer als Assembly oder sowas.

Ja.

Tja, ja.

Aber wir haben doch einige Sachen nicht erklärt.

Und zwar, ähm, wie hieß er nochmal, Carsten Gross?

Carsten Gross, glaube ich, spüren wir sie, weil er möchte wahrscheinlich vermeiden, dass man ihn dauert Gross.

Sorry, gut ist es.

Jedenfalls hat er so einen Talk gehalten, da hat er auch viel über Hateers gesprochen.

Also Hateers, ich eigentlich.

Entschuldigung, denn

das Akronym ist auch ein bisschen unglücklich.

Sehr gut.

Was ist denn das und worum geht es denn da?

Da hatten wir eigentlich doch schon drüber gesprochen.

Ja, weil da gibt es ja schon Beispiele auch auf der Seite von HTMX und mach.

Ich persönlich kann dazu halt nur sagen, dass ich es nicht weiß und mich interessiert es auch nicht.

Das ist ein Steckenpferd und er zeigt viel und redet viel.

Aber mir ist das zu abstrakt.

Also ich halte mich aus den Diskussionen da auch raus, was ist REST, was ist HDOS oder irgendwas.

Ich will, für mich ist HTTP greifbar, HTML ist für mich greifbar und so weiter.

Aber das ist mir dann zu abstrakt und kann ich nicht viel zu sagen.

Ich glaube, also ja, wahrscheinlich haben wir tatsächlich darüber geredet, wenn das halt, also die Übersetzung von Hateers 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ß halt nicht mehr, was er wird.

Immer Hypermedia meinst im Webkontext HTML.

Ja, okay.

Obwohl für Quelle für die Wahrheit ist für mich einfach Postgres.

Das sind die Daten, da kann man 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.

Ja, aber genau das 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 auch noch solche Sachen wie dein Cache oder du hast halt vielleicht irgendwelche Ques 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 dann in dem HTML halt irgendwie drin.

Das ist halt so Dinge, diese Hetty S-Geschichte.

Aber ja, ich finde das auch ziemlich kompliziert und theoretisch und das ist sehr schwer, das zu erklären.

Das ist ä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 so vielleicht so ein bisschen versteht.

Aber den Talk müssen wir natürlich auch verlinken, der ist ja natürlich sehr beim Recht.

Ja, okay.

Ja, aber da am besten hört man sich genau den Talk dann an und nicht uns, wie wir da vorreiten.

Ja, das ist dann wahrscheinlich.

Ich kann da nicht mitreden.

Keine Ahnung.

Ja.

Ja, da habe ich noch eine Frage irgendwo.

Ich sehe da, wo sind die Grenzen oder irgendwas, wann sollte man tatsächlich auf React oder wie umsteigen.

Kam nochmal vorher mal so eine Frage.

Und da sehe ich aktuell eigentlich keinerlei Grenzen.

Also es erinnert mich so, wie ich vor 20 Jahren mit Python angefangen habe und da war eben so eine Sache.

In der Firma meinte ich, na, wollen wir das nicht lieber mit Python machen, anstatt aus einer Mischung aus C, C<unk> und Shell-Skripten.

Und dann hieß es, naja, da konnte ich dann 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 oder hat dann C,

C<unk> und so.

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

Und im Endeffekt hat nie jemand dann nochmal nachgefragt, wir sollten es ja in C oder C<unk> machen, weil einfach die Kunden zufrieden waren.

Es hat schnell funktioniert, war alles prima und da kamen rein, weil neue Wünsche von den Kunden, sodass dann das eben nie wirklich richtig gemacht werden musste, wo ich auch sehr froh drüber bin und so und ähnliches ist es jetzt auch hier.

Jetzt könnte man sagen, ja, dann, wenn man es richtig macht, dann müssten wir es doch in Vue oder React machen, aber keine Ahnung, nee, ich sehe da jetzt keinerlei Grenzen.

Ja.

Ne, würde ich auch sagen, also es ist halt echt, man kann damit wahrscheinlich für die allermeisten Sachen ausreichend viel machen.

Ja, das einzige Problem ist wahrscheinlich, dass man wieder wie immer von vorne anfangen muss und dass einmal alles wieder in schön mit der anderen Technologie bauen muss.

Oder so, dass das Change immer das Pain ist.

Das war wahrscheinlich auch der Grund, warum die Leute und die Menschen bei dir dachten, mit CNC Plus Plus schreibt man bessere Webanwendungen oder so.

Wenn es eine Webanwendung war, ist

das natürlich nicht.

Ja, das war damals auch im Web-basiert, ja, aber auch viel, viel Backend, aber das war halt einfach so üblich.

Es war unüblich.

Und das Unübliche wird natürlich erstmal in Frage gestellt und da ist klar, es ist erstmal kein Vertrauen da.

Es ist ja immer so, wenn irgendwas Neues ist, mal kein Vertrauen da.

Und je schneller etwas hypt, umso schneller ist auch die Wahrscheinlichkeit, dass es dann eben in zwei Jahren doch wieder weg ist.

Naja, aber so haben wir jetzt immer schon gemacht, dass er Teil des Problems als der

Lösung ist.

Ja, aber ich würde auch sagen, das ist halt sehr, sehr mächtig.

Also ich würde auch sagen, das ist halt vielleicht einer der Gründe, warum halt so viel, warum halt so viele Frameworks, ja, also Frameworks sind ja auch so sind ja auch schon so Dinge, wo man, wo ich jetzt als Entwickler ehrlich gesagt sage, sagen würde, das will ich gar nicht haben.

Also ich will, also Frameworks sind nicht meine Freunde, das ist irgendwie, und das ist mir durchaus klar, ja.

Also ich will eigentlich möglichst wenig mit Frameworks zu tun haben.

Also eins, das du kannst dann, oder?

Bitte?

Eins, das du kannst.

Nee, ich will eigentlich keine Frameworks verwenden.

Weil das Problem bei Frameworks ist natürlich, dass ich da halt eine richtig fiese, harte Kopplung, äh, enge Kopplungen dran habe und dass ich davon nicht mehr wegkomme.

Und deswegen finde ich als Entwickler das natürlich gar nicht so angenehm.

Auf der anderen Seite gibt es halt einen großen Druck, die zu verwenden.

Aber der kommt ja meistens nicht von den Entwicklern, sondern der kommt ja meistens dann halt, und ich würde denken, dass bei den JavaScript-Frameworks ist das halt so, da das ist halt, das sind halt irgendwie Firmen, die halt, die halt vorher eine Applikation haben, das habe ich jetzt auch aus der Nähe in letzter Zeit irgendwie oft bestaunen dürfen, jetzt gerade was irgendwie in dieser Pandemiezeit halt, irgendwie, die haben halt Applikationen so irgendwie halt tatsächlich in C<unk> geschrieben oder Java oder sowas, die auf Clients laufen, ja, also die

auf irgendwie auf dem Desktop laufen und die dann halt irgendwie mit einem Server reden oder halt irgendwas, was auch immer die dann tun.

Und das funktioniert aber nicht so gut.

Weil irgendwie, wenn die Leute jetzt zu Hause sitzen, dann denen kannst du dann zum Beispiel einfach nicht mehr so gut, also das deren Rechner hast du nicht so richtig unter Kontrolle, dann irgendwie Netzwerk ist oft schlecht, irgendwie, das ist alles, das funktioniert alles nicht so super.

Dann hilft bloß halt so ein Citrix oder irgendwas oder halt Desktop-Sache oder irgendwas.

Genau, das ist dann eine Lösung, aber das ist halt auch schrecklich.

Und im Zuge dieses Erkenntnisprozesses, dass dann viele sagen, oh, das ist ja alles ganz furchtbar, das funktioniert ja gar nicht, stellen jetzt ganz viele um auf webbasierte Geschichten.

Weil mit webbasierten Geschichten geht das halt.

Klar, wirklich.

Und naja, wenn ich jetzt sozusagen irgendwie eine große grafische GUI-Anwendung umstelle, halt auf irgendwas Webbasiertes, naja, dann ist halt sehr naheliegend zu sagen, okay, ich habe hier mein Team mit irgendwie 500 Leuten, keine Ahnung, irgendwie, in ein paar Teams aufgeteilt und die haben halt ihren Bildprozess und, keine Ahnung, ihre Tools und die Architekturpatterns, die sie halt irgendwie verwenden.

Gibt es da nicht vielleicht irgendein Enterprise-Web-Framework, das ich verwenden kann, wo ich das dann quasi genauso machen kann?

Und dann greift man halt vielleicht zu Angular, äh, Angular irgendwie oder so, weil das halt so ähnlich ist.

Und halt auch dieses ganze Framework irgendwie Sprech und Enterprise-Sprech halt da mit drin ist.

Und das Problem dabei ist aber natürlich, dass man das nicht eben nicht machen kann.

Du kannst nicht einfach irgendwie eine große Applikation nehmen, du hast halt irgendwie dann das in quasi genauso, wie du es vorher gemacht hast, halt mit JavaScript machen und dann ist es halt eine Webanwendung.

Das funktioniert halt nicht, sondern du musst eigentlich dir überlegen, okay, die muss dann halt anders funktionieren.

Weil Web-Anwendungen halt nun mal einfach anders funktionieren als diese klassischen Desktop-UI-Indeptungen.

Ja, dann müsste jemand auf jeden Fall erstmal den Unterschied verstehen, was vielleicht schon eine Herausforderung ist.

Und dann muss ja jemand, der den Unterschied verstanden hat, den Leuten, die das entscheiden, auch erklären, dass das auch die richtige Idee

ist, das zu tun.

Aber das Problem ist jetzt, stell dir vor, du bist derjenige, der zuständig ist für diese Entwickler und du weißt, die kennen jetzt aber ihr sonst was Framework halt und wie kriegst du die beschäftigt mit einem mit der Umstellung auf irgendwas Webbasiertes?

Ohne, dass du die ein Jahr lang schulen musst oder keine Ahnung, wie der Produkt für mich zu beeindruckt?

Das geht nicht so einfach.

Ja, aber wenn du halt dann ganz verzweifelt genug bist, denkst dir, vielleicht geht's mit Angular.

Und dann ist das nicht.

Ich würde sagen, ohne diese Schulung geht das nicht so einfach.

Also es ist einfach eine schwierige Situation auch.

Also du musst, also wenn du die Sprache wechseln musst, ist es natürlich schon mal schwierig.

Das heißt, vielleicht ist es gut tatsächlich, wenn man irgendwie vor Desktop-GUI-Anwendung in Python geschrieben hat, dann kann man vielleicht auch Web-Anwendung in Python schreiben, obwohl ich auch schon finde, dass das Django schon sehr anders ist als GUI-Sachen in Python schreiben, was man ja bestimmt unbedingt machen will.

Naja.

Also ich glaube, diesen Plattformwechsel, den kriegst du nicht so einfach hin.

Also ich wusste jetzt auch nicht so genau, wie ich jetzt eine Android-Anwendung entwickeln will.

Ja klar, das ist nicht einfach, aber das ist eine Aufgabe.

Aber langsam oder sicher geht alles Richtung Web.

Also für mich ist der Chromium mein neuer Desktop, also ich schalte zwischen Tabs hin und her, die im Chromium drin sind.

Und das Native GUI habe ich nur noch den PyCharm.

Und ansonsten eigentlich nichts.

Du bist auch einer ein bisschen PyCharm nutzen, okay, verstehe.

Ach, finde ich, kann man schon machen.

Du hast ja auch in letzter Zeit wie Pycharm benutzt, ja, ich hab's

auch schon gemerkt.

Ja, wobei, also ich meine, ich weiß nicht, wie dir das geht, also tatsächlich mich benervt bei PyCharm, dass es halt relativ langsam reagiert.

Ja, das letzte, habe ich letztens irgendwo gelesen, hat jemand, David Beasley hat das, glaube ich, irgendwie in einem seiner README's zu irgendeinem anderen Software-Projekt, hat er da sehr bösartige Dinge über Java gesagt.

Und zwar meinte er so, ja, Java, ach es gibt, er spricht nicht von Java, sondern er sagte, es gibt da so diese Programmiersprache, ihr wisst schon, sie reimt sich auf Lava.

Und da ist das immer so, die erkennt man immer daran, dass also an diesem Moment peinlicher Stille, bevor die Lüfter dann losheulen.

Das ist halt.

Obwohl PyCharm ist flüssig zu bedienen, also da kann man keine Frage.

Echt findest du?

Nein, da braucht man halt einen aktuellen SLD.

So, und also doch läuft eigentlich schon.

Naja.

Nee, also ich meine vor allen Dingen bei PyCharm solche Sachen wie, man drückt auf irgendeinen Button.

Oder man macht halt eine Tassenkombination.

Also man macht zum Beispiel sowas wie, irgendwie, bei mir ist es Command 0 oder Command 1 für irgendwie den Verzeichnisbaum aufmachen oder halt Git Dings aufmachen, zumachen.

Und ich habe immer das Gefühl, wenn ich das drauf drücke, das ist halt, da sind so 100 Millisekunden Verzögerung oder so, bevor da irgendwas passiert.

Und das nervt fürchterlich, weil das halt, ja.

Aber.

Ich habe übrigens angefangen, Jochen, dieses Jahr, und das habe ich mir fest vorgenommen, mein VI einzurichten und mal zu gucken, ob ich den vernünftigsten Laufen kriege.

Ja, muss man machen.

Ja, es nervt

ein bisschen.

Ansonsten, Python finde ich eigentlich tatsächlich, nachdem ich das jetzt eine ganze Zeit lang benutzt habe, ziemlich cool.

Also von den Features uns her, finde ich das total super.

Da ist das echt gut.

Das ist ziemlich komplet und ja, ist alles durchdacht, aber irgendwie das ist halt so ein bisschen sich so ein bisschen hässlich.

Langsam anfühlt.

Ja, gut, es ist halt eine andere.

Ja, persönliches Empfinden.

Aber vielleicht kann ich das so stylen, wie ich meinen anderen Sachen style, dann macht das doch gar keinen Unterschied mehr.

Aber tatsächlich, das mit Chromium ist halt neue Desktop.

Ich meine, da auch da irgendwie VS Code.

Ich weiß nicht, ob du schon mal VS Code ausprobiert hast.

Ich habe es mal ausprobiert,

aber ja, mehr kann ich nicht dazu sagen.

Ja, ich habe

mein Tage auf

der Produkte.

Eigentlich gar keine Ahnung, ich muss das auch mal.

Es wird auch auf der Liste, aber kommt nach VI drin.

Ja, weil da ist das ja auch irgendwie krumm drunter und das funktioniert eigentlich tatsächlich auch ziemlich gut.

Ich würde sagen, tatsächlich, ich habe jetzt auch eine ganze Zeit, wie es gut.

Es ist nicht so komplett wie PyCharm, es ist auch nicht so durchdacht und so, aber es ist tatsächlich, wenn man da irgendwie Command B oder das ist schneller als bei PyCharm.

Aber naja.

Okay, ja, ja.

Kann schon sein, aber auf beim Laptop und auch selbst auf meinem Vorgänger ging es eigentlich gut.

Er hatte mal irgendwie Probleme, als er irgendein Verzeichnis indiziert hat, wo er eigentlich nicht reinindizieren sollte.

Da hat er ganz schön zu tun gehabt.

Aber das kann man dann auch exkluden, dass er da nicht reingucken soll, weil da eben zigtausend Dateien drin sind und dann hört er auch auf damit.

Kann ich erstmal nicht.

Vielleicht habe ich auch irgendwas falsch konfiguriert, das muss man ganz natürlich auch sein.

Oder was ich auch mal hatte, da hat sie mir immer den Akku leer gesaugt, da hatte ich die, habe ich die JVM für Intel auf meinem Arm Mac verwendet und das lief dann in der Emulation und das war irgendwie auch ganz schrecklich.

Das hatte, da dachte ich mal so, hä, warum zieht denn das so viel Akku?

Das ist ja irgendwie, und dann musste ich eine andere JVM nehmen und dann war es gut und dann funktioniert das auch.

Aber ja.

Ach, ein, was fiel mir noch ein zu JavaScript und den ganzen Spaßsachen.

Was ich ja schön finde, dass das HTML sich immer noch weiterentwickelt und vorangetrieben wird, sodass man im Endeffekt dann weniger schreiben muss.

Also ich zum Beispiel ein Date-Picker irgendwas.

Wenn man danach sucht, da gibt es tausend Implementierungen von Date-Pickern.

Aber ich als Webanwender will einfach dann nur fertig werden und da ist es einfach schön, wenn ich sagen kann, Input-Type ist gleich Date zum Beispiel.

Oder eben Input Date Time Local, um eben Date und Zeite zu picken.

Und das finde ich spannend, dass sich da halt das immer noch alles entwickelt.

Und die Spezifikationen gibt es und sicherlich ist es leider noch so, dass eben unter iOS kein richtiger Chrome verfügbar ist.

Das ist ein bisschen schade, dieses Apple Browser Band.

Aber kann durchaus sein, dass da die EU dem bald ein Riegel vorschiebt mit dem Digital Markt Act.

Es wäre sehr schön, wenn da, weil das ist, da kannst du als einzelner Webentwickler auf- und niederspringen und vielleicht kommt auch doch mal von der Legislative da irgendwas, weil es ist einfach ein Markt, der Apple Play Store und es ist ein globaler Markt und das dann dort zu diskriminieren gegenüber anderen Browsern ist einfach nicht in Ordnung.

Also hoffen wir mal, dass dort das vorwärts geht, weil dann ist nochmal mehr Druck da, dass die Safari-Engine mal vorwärts macht und dass die da nicht absichtlich blockieren können.

Es wird ja absichtlich blockiert, damit sie weiterhin schön Geld verdienen innerhalb ihres App-Stores.

Und darum hat Apple überhaupt keinen Bock drauf auf Progressive Web Apps.

Das ist halt vielen Leuten nicht bekannt.

Wenn man mit Leuten drüber spricht, die jetzt nicht aus dem Software-Bereich kommen, die verstehen das erstmal gar nicht, von was man da spricht.

Und naja, hoffen wir mal, dass da irgendwie das in der Richtung auch weitergeht.

Weil dann geht es eben Richtung ProGress Web App.

Gut, okay, das ist natürlich wieder eine Sache.

Aufhänger HTMX, also HTMX, es ist sozusagen auf keinen Fall offline first oder irgend sowas.

Man braucht die Verbindung zum Server.

Das ist sozusagen eine ganz zentrale Sache an dieser Stelle.

Wenn man

dann Richtung ProGrephis Web-App schaut, dass man sagt, okay, man hat eine offline-fähige Web-Anwendung, klar, dann ist es mit JavaScript natürlich besser.

Aber 99% der Fälle braucht man das eigentlich auch gar nicht.

Ja, nee, Offline-First war auch mal eine ganze Zeit lang, das kam irgendwie so aus dieser ganzen Couch-DB-Ecke und eigentlich finde ich den Ansatz ja auch ganz interessant irgendwie.

Halt quasi auch eine Datenbank einfach auf der kleinen Seite zu haben.

Und da gibt es ja auch diverse Geschichten in den Browsern.

Also gibt es ja auch irgendwie, weiß ich nicht mehr, quasi so ein SQL-Lite, haben die meisten irgendwie drin, was man verwenden kann.

Und dann synchronisiert man das halt wieder zurück irgendwie und so.

Das ist eigentlich auch alles ganz nett.

Aber ja, tatsächlich war das dann aber doch nie so nötig, weil inzwischen ist ja doch fast überall Netz und es funktioniert eigentlich auch ganz gut.

Genau, das ist

verzehnfacht einfach die Komplexität und den Aufwand, dass und drum geht eigentlich alles Richtung ständige Verbindung zum Internet.

Also es gibt ja ganz wenige Sachen, wo es eigentlich wirklich braucht, wenn ich will.

Ich will, wenn ich in der Bahn bin und habe keine Netz, keine Netzanbindung, will ich eine WhatsApp-Nachricht schreiben können oder ich will eine E-Mail schreiben und lesen können.

Aber für alle möglichen anderen Sachen brauchst du einfach auch den Server, weil der hat ja die aktuellen Informationen und du kannst ja nicht aus den Fingern saugen.

Und brauchst du eben die Netzwerkverbindung.

Und darum klappt es erstmal so eigentlich ganz gut, auch kann man ganz gut viel abdecken.

Eine Frage habe ich mir noch aufgeschrieben, ganz zentral ist eigentlich gut, also wir erstellen jetzt HTML serverseitig.

Und irgendwie bin ich persönlich da jetzt auch noch gar nicht glücklich, mit der Methode HTML serverseitig zu erstellen.

Also das, also ich habe da jetzt aktuell, verwende ich von Django zum Beispiel das Format unterstrich-html.

Das finde ich ganz praktisch, weil da eben da dieses Save-String ausgewertet wird.

Also da wird alles, was gequotet werden soll, wird automatisch gequotet, außer es ist eben ein Safestring, wo explizit klar ist, dass der soll nicht gequotet werden.

Und das ist für mich erstmal ganz schön.

Aber was ich auch schön finde, sind diese F-Strings in Python.

Und da fehlt mir aktuell noch so eine Mischung.

Ich hätte gerne so eine Mischung, dass ich sage, also im Python will ich HTML erstellen.

Also ich will das jetzt nicht auslagern.

Ich will dann nicht immer zwischen zwei Dateien hin und her wechseln.

Einmal mein Template-File und dann mein Python-File.

Also ich würde gerne das HTML im Python erstellen.

Und das würde ich am liebsten mit F-Strings machen.

Haut aber halt nicht hin, weil das F-Strings hat ja keine Ahnung, was es quoten soll oder nicht.

Und da habe ich bis jetzt auch noch nicht so richtig die optimale Lösung gefunden.

Ja, ne, habe ich auch noch nichts.

Ich weiß nicht genau, ob das mit F-Strings.

Also tatsächlich in JavaScript geht das wahrscheinlich.

Da gibt es ja diese Template, Literal Strings, ne?

Damit könnte man das wahrscheinlich machen.

Ja, wäre schön, wenn es sowas macht.

Aber so im Entscheidung gibt es das echt.

Ja.

Ja, ja, ja, ja, ja.

Ne, weiß ich auch nicht.

Aber ja, das stimmt.

Ich meine, ja, das ist die Frage, ob das.

Alle machen das jetzt halt über diese Template-Geschichten, ne?

Aber ob das jetzt der beste Weg ist, weiß ich auch nicht.

Ja, aber also im Kontext von HTMX ist es bei mir so, ich erstelle kleine Methoden, die kleine Schnipsel zurückgeben.

Ja, warum brauchen die?

Warum sind

das eben sechs, sieben Zeilen und für diese sechs, sieben Zeilen dann dann nochmal eine extra Datei öffnen, das tut dann den Fluss beim Softwareentwicklungen, bei der Softwareentwicklung irgendwie behindern.

Aber kannst du nicht auch einfach ein Django-Template quasi in den Spring reinschreiben und den dann rendern?

Weil du musst es ja nicht in den Pfeil reintun.

Könnte ich auch, ja, klar.

Könnte ich machen.

Aber dann muss ich dem halt auch wieder einen Kontext geben und dann muss ich immer wieder schreiben, Name ist gleich Name und Login ist gleich Login und ähnlichen Spaß muss ich dem Kontext reingeben.

Kann man machen, funktioniert auch.

Aber irgendwie muss er halt seine Variablen bekommen.

Man könnte da vielleicht einfach Globals übergeben.

Ja, aber dann weiß die Idee nicht mehr, dass diese Variable eigentlich verwendet wurde.

Und tut die hellgrau anzeigen, so nach dem Motto, hey, die kannst du doch eigentlich wegwerfen, die Variable hier.

Ja.

Ja, auch nicht ideal.

Naja, stimmt.

Gibt es noch Entwicklungsmöglichkeiten an der Stelle.

Ja, ich bin, ähm, aber genau, das hat, da habe ich gerade diese Offline-App-Geschichte drauf gebracht.

Ich weiß gar nicht, ob das Leute machen, aber ehrlich gesagt würde ich das auch gerne mal ausprobieren.

Im Grunde kann man ja auch, äh, man kann ja auch, ja, das ist wieder dann das Problem mit der Pakettierung.

Man kann in Python nicht einfach ein Binary bauen, aber wenn ich mir jetzt überlege, SQL Lite ist ja, also klar, kann man nicht so Konkurrent drauf schreiben, aber ist auch sehr mächtig und kann wahrscheinlich irgendwie, das meiste, was man so braucht, wenn man jetzt irgendwie eine Datenbank für eine Webgeschichte hat, kann man nicht einfach die komplette Webapplikation schippen mit einer SQL Lite und den Daten drin.

Und dann sagen, so, hier startet das Ding und dann geht das halt auf Localhost, hat man halt eigentlich sozusagen die eigene Seite und dann, wenn irgendwas geschrieben wird, kann man sie einmal in SQL Lite schreiben, aber halt auch nochmal irgendwie über das Netz oder so.

Oder man synchronisiert die Datenbanken irgendwie.

So könnte man.

Natürlich viel möglich, prinzipiell kannst du das, also da wird sich ja noch viel entwickeln, nach WebAssembly alles kompilieren und kannst prinzipiell auch wahrscheinlich Python nach WebAssembly kompilieren.

Ja, das haben ja auch schon Leute gemacht.

Sub-Wups alles pakettieren und dann haust du schon einen Postgres hinterher und dann lädt der Kunde erstmal hier 50 Megabyte runter.

Ja.

Und ich meine, obwohl 50 MB sind auch schnell runtergeladen.

Und dann hast du dort alles drinnen im WebAssembly aus.

Ich bin gespannt, was sich da entwickelt.

Ja.

Ja.

Tja, tja.

Kann man sich auf jeden Fall sich auch noch eine Menge interessante Dinge überlegen, was man damit alles machen kann.

Ja, ich glaube, im harten Weg sind wir so ein bisschen fast zurück.

Ja.

Ich hatte aber beim Thomas noch auf seinem Repo noch so ein paar Sachen entdeckt, wie sein Working Out Loud Repo, wo er so ein bisschen dann Sachen verlinkt und dann auch die Parsentipps entdeckt und so, wo ich einige Sachen an Jochenphilosophie endet.

Und was ich entdeckt habe, war du, den PDM, den kannte ich tatsächlich noch nicht.

Was ist denn das?

Nochmals habe ich den schlecht verstanden.

Den PDM, das sind Python Distro Manager oder sowas.

Oder was macht der eigentlich?

Ich muss nochmal gucken.

PDM.

PDM.

Ja, also ein Paketmanager.

Den entdeckt das als Alternative zu Poetry, hast du den beworben.

Das kannst du auch.

Beworben habe ich den, glaube ich, nicht, aber wir müssen mal aufbauen.

Also ja, ja, ja, genau.

Genau.

Nee, ich war einfach da unsicher.

Genau, bei mir ist öfters so, oder geht ja wahrscheinlich vielen so, man steht da, nehme ich jetzt Tool A, nehme ich Tool B, nehme ich 0C.

Und da ist, ähm, seit einer Weile mache ich das so, dann gehe ich zu GitHub, zu meinem Account, erstelle da ein Repository, was im Endeffekt aus einer REATME besteht.

Und dann schreibe ich da auf, was für Möglichkeiten überhaupt existieren.

Das hilft mir, um meine Gedanken zu strukturieren.

Im Endeffekt ist es erstmal einfach ein Zettel für mich, dass ich dann da habe und wenn ich die Bebrecherche zwei Tage oder drei Tage später weitermache, habe ich da erstmal einen Leitfaden, wo ich stehen geblieben bin.

Aber es ist immer ganz nett, das ein bisschen stehen zu lassen, weil ein Jahr später braucht man es vielleicht dann wieder oder so.

Und dann weiß ich es.

Würde ich es bei mir auf dem Zettel schreiben, würde ich es im Schreibtisch oder so und ich bin dann da.

Bei GitHub finde ich es nicht.

Also Version Control ist für sowas schon genau das Richtige.

Aber jedenfalls bin ich da, weil wir schon ein paar Mal auch über so Paketierungssachen gesprochen haben.

Über das PDM, also das heißt Python Development.

Habe ich auch noch nicht gehört, keine Ahnung.

Jetzt ist das M wieder weg, das ist nicht ein.

Das hast du bei den Python-Tipps gefunden hast.

Ja, PDM.

Moment, ich muss jetzt wieder zurückschauen.

Python Development Master heißt es.

Als Alternative für Poetry, ich habe noch nicht genau verstanden, wo das ist, deswegen war ich neugierig, weil wir ja mit Poetry in letzter Zeit so ein paar Probleme hatten.

Genau, richtig.

Und ob das vernünftig funktioniert.

Aber wenn es dir nicht sofort einfällt, dann hast du es wahrscheinlich auch gar nicht gehabt.

Nee, ich habe damals recherchiert an einem Abend, das mal so aufgeschrieben, aber ich kann da jetzt keine Details dazu sagen.

Und genau, mir geht es genauso.

Ich tue nämlich den Artikel jetzt hier mal kurz aktualisieren mit dem Poetry.

Ich bin aktuell einfach bei Pip und das klappt auch soweit eigentlich ganz gut.

Also das Poetry konnte ich nicht so richtig da.

Also ich verwende es nach wie vor, ich würde nur, man muss ja die blöden Bugs fixen, die uns allen auf die Nerven gehen.

Ja.

Also ich bin, wie gesagt, mit den Pip-Tools werde ich auch nicht warm, dass das irgendwie

weiß ich nicht.

Also ich finde vom User Interface her ist Poetry schon deutlich schöner.

Das Problem ist nur halt, es funktioniert nicht.

Ja, genau.

Man muss ja nicht immer alles noch verdrekt wegschmeißen, wenn sie kaputt ist.

Manchmal kann man sich auch gradieren.

Aber hast du mal, hast du, ich meine, ich habe letzte Woche wieder war ich auf dem Repository bei Poetry, weil ich irgendwie bestätigen wollte nach irgendwie, ich weiß nicht, wie vielen Leuten, dass das auch bei mir nicht funktioniert.

Und da habe ich dann, also wenn man da, ich weiß nicht, wie viele offene Issues da sind gerade irgendwie 1000 oder sowas.

Und einen Corporate-Monat einlegt und alle gemeinsam an Poetry's Verbesserungen arbeiten und dann ist das Problem endlich alle mal aus der Welt geschafft.

Tja, tja, ja, genau.

Offene Issues über 1000, also das ist halt schon, ja.

Und es ist halt nur ein einzelner Typ, der in seiner Freizeit macht.

Ja klar, kann man ihm ja auch keinen Vorwurf machen, aber ich

meine nicht.

Alles prima, ne?

Ja, ja, also ich meine, aber es ist halt halt so beliebt, dass halt so Sachen finden.

Und dann braucht er eigentlich halt Hilfe, ne?

Ja.

Ich habe hier Pip und dann für Sachen kann man auch Pip-Tools obendrauf nehmen.

Reicht erstmal voll aus.

Ja, Pip-Tools habe ich jetzt auch letztens, fand ich eigentlich, also das hat auch ganz gut funktioniert, das ist halt ein bisschen hakliger zu benutzen.

Das ist so ein bisschen, aber weil man dann halt lange Kommandozeilen, mit denen man da irgendwie den Kram dann.

Aber ja, aber es funktioniert tatsächlich ziemlich gut, muss ich auch sagen.

Und es hat halt die ganzen Paketfunktionen, die Poetry hat halt nicht.

Aber ehrlich gesagt, die brauche ich auch nicht.

Ja, also was ich halt eigentlich nur brauche, sind eigentlich zwei Sachen.

Poetry Add, Poetry Remove, Poetry, Poetry Update und Poetry Install.

Ja gut, aber dann sollst du ja auch nicht halt bei dem, was Pip-Tools können, nur dass Pip-Tools das halt sehr unkomfortabel machen.

Ja, und ja, genau.

Naja, gut.

Aber irgendwie ist das noch nicht aller Tageabend, was das angeht tatsächlich.

Ja, ich weiß nicht, habt ihr noch was?

Auf eurer Listisch stehen.

Nö, ich bin durch.

Nö, also wir könnten ja noch Picks machen.

Dann kommen die Picks der Woche, des Monats, der Folge jedenfalls dann.

Was habt ihr denn da ausgesucht?

Also ich fange vielleicht einfach an.

Ich weiß nicht, ob ich schon mal gesagt habe, das vergesse ich, wie gesagt, immer, ich muss jetzt mal aufschreiben.

Die Python Dev-Tools, kennt ihr die?

Das ist so Python Dev-Tools, da kann man sich einloggen.

Man kann einfach Sachen wie statt Print ein Debug-Statement in Python, was dann Pretty Print macht und so.

Einfach so ein paar Kleinigkeiten.

Nö, natürlich, nö nicht, nötig.

Nö, kann ich ja nicht.

Wo findet man das oder was ist das?

Einfach Python-Heintop.

Ach ja, ich glaube, ich hab's.

Was macht das?

Ich glaube, das ist ein anderes.

Guck mal kurz, dass das mal kurz auf die Doc Help-Manual.io irgendwie.

Python-DevTools einbort.

Achso, äh.

Nee, ist das eine andere.

Wahrscheinlich mehrere.DevTools.Help-Manual.io.

Nee, okay, kriege ich nicht hin.

Ja, egal, auf jeden Fall, das sind nicht viele Funktionen, aber irgendwie fand ich es ganz nett und das sah ganz niedlich aus.

Und ich mag ja so moderne Terminal-Sachen sehr gerne.

Ah, den Lochenpick der Woche, ich habe meine Dot-Files mal ein bisschen aktualisiert.

Die sind ja vor allen Dingen auch für viele Windows-Nutzer ganz gut geeignet, weil ich muss das ja auch auf der Arbeit nutzen und so.

Und da kann man sich jetzt, wenn man das vernünftig installiert, unter einer PowerShell die ganzen Modern Unix-Commands ziehen und die alle reinpacken.

Ist das nicht so Python-spezifisch?

Aber auch Virtual Wrapper habe ich eingebaut, jetzt nur die Funktion, die ich nutze, dass es nicht viele sind.

Damit es ein bisschen kompabler ist, weil Virtual Wrapper PowerShell irgendwie nicht so richtig

funktioniert hat.

Okay, da habe ich das doch eine sehr gute Überleitung.

Was benutzt du denn zum Managen deiner Dot-Files?

Tatsächlich Git.

Ja, aber

was meinst du mit Managen meiner Dot-Files?

Naja, wenn du jetzt auf einer.

Nehme mal, du hast einen neuen Account irgendwie auf einer anderen Maschine, logst dich die ein, setzt gerne deine Dot-Files da so wie überall sonst auch.

Genau, ich habe in meinem Dotfiles-Repo für die jeweiligen Systeme, also im Moment ist es halt PUSIX und Windows und für Nix ist auch was, aber das funktioniert nicht richtig, das ist halt nicht public.

Install-Skripte, das heißt, ich mache halt eine Admin-Shell auf und starte das Install-Skript.

Dann clont er mir die eigentlich an die richtige Stelle, die meistens einfach Home Dot-Files ist.

Dann im Install-Skript führt er dann das SIM-Link-Skript aus.

Das heißt, der Link quasi von meinen Config-Files komplett auf die Configs vor dem Programm, die ich natürlich installieren musste, auch in dem Install-Skript.

Das heißt, er installiert alle Programme als SIM-Link-T und fertig.

Okay, aber und welches Skript ist das?

Hast du es

selber geschrieben?

Ja.

Ah, okay.

Ja, weil da gibt es ja dann schon einige Sachen.

Also ich habe bisher immer Dotbot verwendet dafür.

Okay.

Aber das ist mir letztens irgendwie, als ich, ich weiß gar nicht, weil was da anlass war, wo es mir dann kaputt gegangen ist.

Und ich mir dachte so, also das habe ich mir jetzt auch schon so lange nicht mehr angeguckt.

Irgendwie muss ich da mal schauen, ob es da was Besseres hat.

Vielleicht möchte ich auch sowas benutzen, weiß ich.

Vielleicht bin ich noch so.

Ich habe alles noch ganz einfach selber geschrieben, weil so viel ist das ja nicht jetzt.

Ja, ja, gut.

20 Simlings oder was der ersetzt und dann einmal Software mit dem bei jeweiligen Systempaketmanager installieren, den du ja auch auf Windows installieren kannst.

Da musst du halt nur zuerst den Paketmanager installieren.

Und dann ist ja alles eh Open Source, das macht er ja alles drauf.

Und dann hast du immer auf jeden Fall die gleiche Shell, was ich immer sehr super finde.

Was sogar einigermaßen mittlerweile für die PowerShell geht.

Und das ist, oh, das ist auch was ganz Tolles, das ist auch in den Dot-File schon drin.

Es gibt seit November für die PowerShell einen Autocompletion, das so ein bisschen funktioniert wie das von Fisch.

Und das ist, ja, das brauche ich natürlich immer.

Weil ich normalerweise mit der Fish-Shell da sehr dran gewohnt bin und sehr viel Zeit sparen kann.

Ja, genau, weil, und dann, also das Ergebnis war dann, wäre dann mein Pick, was ich jetzt versuche zu verwenden.

Also ich bin gerade dabei, das auszuprobieren und zu gucken, was ich da, wie ich das so hinbieten kann, dass es das tut, was ich gerne davon hätte.

Und zwar das Tool heißt Chesmois.

Chemois.

Ja.

Chemois, genau.

Ja.

Und das ist so ein Go geschrieben.

Das ist also wie so ein auch eines von den, werden ja momentan ganz viele System-Tools.

Das macht tatsächlich keine SIM-Link-Geschichte.

Oder macht halt auch unter Umständen SIM-Links, ne, ich glaube aber eigentlich nicht.

Das guckt sich an, wie der Zustand deine aktuellen Pfalz ist, wie es sein sollte, sozusagen auch aus dem Git-Repo und passt es dann halt an.

Und das kann halt jetzt noch so ein paar Sachen mehr.

Also einmal das Schöne ist halt, dass es halt, da es quo ist, kriegt man halt so ein statisches Binary, was keine Abhängigkeiten hat, relativ leicht auf jeder Maschine.

Und das hat halt auch noch so eine Templating-Language mit drin, womit man dann halt sozusagen je nachdem, was auf der Maschine irgendwie gesetzt ist, halt Dinge anders machen kann.

Also wenn halt so Umfeldzeit anders ist, dann müssen manche Dinge ja anders sein oder wenn der User anders heißt.

Das sieht sehr schön aus.

Das ist ziemlich cool und es hat halt auch Anbindungen an alle möglichen anderen Geschichten, wie zum Beispiel an irgendwie Passwortmanager und so, sodass du halt auch deine SSH-Keys irgendwie rüberziehen kannst und solche Sachen.

Das ist ja geil.

Oh, ich habe ein neues.

Ja, und das ist halt ziemlich cool.

Es gibt How-Tooster für alle möglichen Anwendungsfälle, wo man sich das, äh man sich da angucken kann.

Also ich verwende es jetzt oder ich probiere damit so ein paar, seit ein paar Tagen irgendwie Dinge mitzumachen.

Und ich bin eigentlich sehr angetan.

Also ich glaube, das wird wahrscheinlich demnächst meine neue Lösung zum Managen meiner Dot-Files.

Das klingt sehr, sehr gut.

Ich hätte da noch eine andere Frage an der Stelle.

Ich weiß nicht, ob das jetzt hier hinpasst, aber worauf ich gerade versuche umzustellen, ist, die ganzen Keys, weil du gerade von geredet hast, mit Key-Rebus und so, mit Yubi-Keys zu schützen.

Also eine Zwei-Faktor-Authentifizierung da reinzubauen.

Geht das auch einfach so?

Weil ganz cool, weil ich hab, bei mir funktioniert es auch so Mittel gut.

Also ich habe erst meine wichtigsten Applikationen da mit drin, aber das könnte.

Das wäre natürlich noch richtig klasse, wenn ich dann einfach irgendwie an der richtigen Stelle den richtigen

Stick habe oder so.

Das müsste eigentlich funktionieren.

Also YubiKey ist halt die Frage, wie man das, wie man.

Ich meine, ich würde es sowieso, ich meine, ich verwende ja One-Passwort, auch wenn ich das natürlich irgendwie auch ein bisschen unangenehm ist, dass er so teuer ist und dass es so ein Subscription-Modell hat, aber das ist halt das einzige Ding, was ich gefunden habe, was halt zuverlässig auf allen Geräten funktioniert und halt auch irgendwie eine durchdachte UI hat.

Und das funktioniert auch mit Chesmoir.

Ah, Chemois.

Meine Güte, Französisch.

Franz tatsächlich, ja.

Ich weiß jetzt nicht genau.

Ja, ich muss mir das einfach mal durchlesen.

Das sieht auf jeden Fall sehr, sehr toll aus, weil genau das ist halt diese ganzen Skripte, dass ich mich alles nicht mehr machen muss, weil es alles von automatisch weißt.

Muss ich mich an der Struktur halten von meinen Dot-Files dann?

Irgendwie standardisiert oder so?

Ja.

Wahrscheinlich, ne?

Ja, mal gucken, vielleicht mag ich das.

Das sieht auf jeden Fall sehr toll aus, dass man einfach sagt, Schemoir und dann gleiche Line mit Install, dein Username und dann einfach nur Trainer Update, das ist schon cool.

Ja, ja.

Ja.

Und du?

Äh, ich?

Ja.

Ich nutze da

kein Tool.

Also ich hatte da früher mal das wenigstens noch irgendwie weggesichert oder irgendwie so.

Also speziell nochmal extra zu einem normalen Backup.

Aber ansonsten habe ich da jetzt eigentlich nichts Spezielles, weil ich da auch nicht viel anpasse eigentlich.

Also, ja.

Ich nutze ja nicht den VI oder so, wo es so viele.

Ja, ja, den muss man halt irgendwie ausgiebig konfigurieren.

Vom E-Macs mal weggewechwechselt.

Da war das auch noch beim E-Mac, musste man da eine ganze Menge machen.

Aber jetzt habe ich eigentlich nur eigentlich nichts, was ich da groß verwalten sollte.

Ja, aber dann musst du jetzt mit deinem Pick der Folge noch.

Hast du einen?

Nö, hab ich nicht.

Okay, also kein PIS-Modul gestolpert, dass du sagst, das musst du die ganze Welt kennen.

Äh, ganz kurz, zum Beispiel, also eine Sache, die man gerade auch, äh, die ich gerade gesehen habe, wo du sagtest, Sachen installieren.

Wenn man das macht, also ich hab bei, das ist eine der Geschichten, die ich gestern, glaube ich, gemacht habe, bei Schimmer, ist wenn dann, wenn das, man kann Dinge, Skripte definieren, die ausgeführt werden sollen, wenn sich was geändert hat.

Und wenn, ich habe dann zum Beispiel bei Mac gibt es ja Homebrew, nicht Chocolati, es ist bei Windows, bei Mac ist Homebrew.

Da kann man ein Brew-File haben, wo die ganzen Pakete, die man so installieren möchte, drinstehen und wenn man das ändert, dann sagt man auf einer anderen Maschine irgendwie, genau.

Dann wird dieses Skript ausgeführt, zieht sich das File rein und wenn sich das geändert hat, dann installiert es es halt direkt.

Das ist ja cool, ja.

Und das ist halt schon sehr nett.

Ja, sowas muss ich halt alles noch manuell machen.

Ich habe halt meine Listen, die dann unterschiedliche pakettierte Paket-Packages quasi installieren, wenn ich das dann will.

Aber ja, ich finde das ganz interessant, weil ich finde, man wird vielleicht auf verschiedenen Maschinen auch nicht immer alle Pakete gleichzeitig.

Egal, dass das so ein bisschen.

Müssen wir uns auf jeden Fall mal angucken, wie so der Use Case davon hast du hast.

Mir ist mir noch was eingefallen.

Ich habe das Tool Copy Q verwendet.

Also wie Copy und dann ein Q.

Und das ist ein Clipboard Manager und das finde ich ganz praktisch, weil der eben eine History hat von den Sachen, die ich eben in der letzten Zeit mit Copy und Paste und hergenommen habe.

Und dann kann ich mit STRG Alt V eben gucken, was ist in der Liste drin und da hat er ja sogar auch Bilder drin und mit Formatierung und so weiter.

Das ist, finde ich, super praktisch.

Und dann kann man halt natürlich auch in der Liste super schnell suchen, indem ich mit Autocomplete halt eben hier die ersten Zeichen von der gesuchten Zeichenkette eingeben kann.

Und das finde ich sehr praktisch, dass man das so eine Art Rucksack mit dabei hat, da kann man alles reingewesen.

Also so ein Copy, also Buffer mit mehreren Buffern halt, ne?

Das ist das schon sehr schön.

Genau.

Das gibt es im Emacs, gibt es im PyCharm, aber im Endeffekt ist es ja cooler, wenn man es auf dem Desktop hat, überall Anwendungen hinbekommen.

Ja, genau, gibt es halt auch in VS Code.

Sogar auf Windows.

Ich habe auch das mal gesucht für so eine Alternative für Windows und das funktioniert alles einigermaßen cool, ja.

Ah, schön.

Ja, genau.

Das ist ganz praktisch.

Ja, sehr gut.

Ah, ich hätte noch, oh, ich habe auch noch einen zweiten.

Da gab es jetzt letztens ein neues Buch von Adam Johnson, ein sehr schönes Schon geschrieben, nennt sich Speedup Your Django Tests.

Da haben wir bestimmt auch schon mal drüber geredet, das ist irgendwie ganz toll.

Kurz, ja.

Wir haben über Tests von HTMX noch gar nicht gesprochen, ist mir eingefallen.

Ach, wieso?

Oder was muss man da?

Das ist nicht so schlimm.

Also ich glaube, es gibt noch nicht so richtig gute Möglichkeiten, das zu testen.

Aber natürlich.

Ja, du testest das wie jeden anderen View auch.

Ach so.

Da musst du gar nichts machen.

Das ist ja halt das Toll.

Okay, dann habt ihr nichts gesagt.

Ja, das ist tatsächlich sehr nett.

Also dieses Prozent auch los.

Dann wollte ich dich nicht weiter bei deinem Buchpick und.

Ja, ja, Moment, aber ich würde gerne abschweifen und nochmal über JavaScript herziehen, weil das noch nicht genug passiert ist.

Also ich habe ja jetzt in letzter Zeit auch so ein bisschen View, so View ist halt das Framework, was ich noch vielleicht am interessantesten finde.

Und Websockets und so gemacht und so und da halt auch dann Tests geschrieben.

Und ja, also dann habe ich mit Jest ganz viele Tests gemacht und das ist echt, also das ist, das war, das hat wirklich keinen Spaß gemacht.

Ist das Symbol von Jest nicht diese Clowns-Gauklamütze auf dem Kopf?

Ich weiß es nicht genau.

Ich weiß nicht, guck mal kurz bitte nach.

Das würde sehr gut sein.

Kann sein.

Ja, ich musste auch Testmütze schreiben müssen.

Ja, auf jeden Fall, das war halt echt, oh, also.

Das ist der Gauklarschuh.

Also das ist jetzt auch quasi gar nicht mehr so neu und so.

Und dann, ich bin mehrfach in Sachen reingelaufen, wo ich dachte, so das geht nicht oder, oh, das kann ich jetzt so nicht machen, okay, wie macht man das dann richtig?

Und dann landet man halt auch irgendwie so in so Wüsten-Gitub-Issues, wo

seit Jahren schon Leute sagen,

das ist aber nicht so schön hier, was ist denn da los?

Geht das nicht?

Und dann geht es halt tatsächlich nicht, und zwar immer noch nicht.

Und es ist halt auch, und dann die Integration mit Viet habe ich dann halt schwierig.

Und also diese Developer-Experience war eher so mittelmäßig.

Und genau, allen Leuten, die glauben, dass JavaScript-Entwicklung voll gut ist und dass das noch nicht zugüngt ist und dass man das unbedingt auf dem Server machen möchte, dann würde ich fragen.

Also ihr kennt schon so ordentliche Web-Frameworks auf dem Server.

Habt ihr schon mal verwendet?

Habt ihr euch das mal angeguckt, wie das da so geht?

Aber wenn nein, guckt es euch mal an.

Aber auch das wird ja besser.

Du hast ja letztens auch noch eine Sache gelingt, Pinya als Ersatz für VX, das

ist ja schon.

Für den Verbesserung.

Mit DevTool-Support und sowas ist da auch, ja.

Aber das braucht man halt nicht, wenn man das so beim Server macht, weil das halt.

Ja, naja, jedenfalls, genau.

Da wollte ich nur kurz.

Genau.

Boost your, genau, Anim Johnson, der hat ein neues Buch geschrieben, Boost Your Developer Experience.

Und genau, ich habe es noch nicht gelesen, weil es so frisch ist, es kam jetzt am Montag raus, dass ich es noch nicht dazu gekommen bin.

Aber kann man sich ja mal angucken.

Da ist auf jeden Fall wahrscheinlich eine Menge tolle Sachen drin.

Also es geht halt um viele, auch jetzt eben solche Dinge wie halt Pre-Comet-Tox oder halt Pi-Upgrade und ja, auch viel Nicht-Django-Zeugs ist da halt auch drin.

Aber ich kann es auch empfehlen, hab schon gelesen.

Achso, ach ist ja gut.

Ja, ich habe es zufälligerweise zugeschickt bekommen vom Auto her.

Zum Probelesen.

Und ja, es ist okay, genau.

Also ich finde es auch schön, also auch das vorhergehende Buch von ihm, Speedup Python-Tests.

Ich finde es schön, wie er schreibt, ganz pragmatisch, also ohne großes Blabla.

Schön lohnt sich.

Ja, ja, ja, ja, ja.

Na gut, dann noch mit diesen Worten als Schlusssatz.

Werdet es doch gewogen und haltet wieder rein.

Das nächste Mal.

Ja, klar.

Und ja, hört uns gerne immer, wenn ihr mögt.

Ich wünsche euch noch einen schönen Tag, Abend, Nacht, wo auch immer ihr seid.

Und bis dann.

Tschüss.

Ciao, ciao.

Danke, Thomas.