Transcript: HTMX

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

Dieses Mal wollen wir etwas über HTMLX sprechen.

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

Ja, hallihallo, willkommen Dominik.

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

Hallo, grüß dich.

Jo, hallihallo.

Schön, dass du da bist.

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

Ja, oder vielleicht kann sich Thomas kurz vorstellen.

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

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

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

Ja, ich mache Softwareentwicklung. Das schon eine ganze Menge Jahre. Habe vor 20 Jahren mal Informatik studiert und vorher schon auch als Kind daran Spaß gehabt. Und ja, mache hauptsächlich eben Webentwicklung mit Python und Django, PostgreSQL und eben seit neuestem auch mit HTMX.

Und 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, okay

Dann geben wir ein bisschen News über

Erstmal ein bisschen News, ja

Ich glaube, ich habe

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 duplicated

Ja, das heißt

quasi die erste

Version Python 3, wo

viele Leute irgendwie

das Gefühl hatten, das ist jetzt besser als Python 2.

Ist jetzt auch

End of Life. Das heißt, ja, also

krass. Als ich das gesehen habe,

dachte ich so, wow, das ist schon wieder so lange her.

Ich glaube, bei 3.6 habe ich angefangen.

Das ist schon gar nicht so lange her.

3.7 kam dann relativ fix und

ging schnell.

Also meine News, ich habe noch gelesen, dass Python

Programmiersprache des Jahres 21 geworden ist.

Yay! Wir werden

famous und berühmt.

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,

so wahnsinnig viel

kann man da nicht daraus lesen.

Ja, ist doch eigentlich relativ wurscht.

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

Ein programmierbarer Podcast war es, glaube ich.

Dass da jemand meinte, das ist eine

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

sie machen irgendwie

neben den Namen der Programmiersprache

Programming dahinter und

googeln dann danach und dann zählen sie

die Anzahl der Suchergebnisse.

Das ist mehr oder weniger, was sie tun.

Und das ist natürlich irgendwie, ja, gut,

ob das jetzt so einem wahnsinnig viel sagt, ist halt

unklar.

Das habe ich von dir noch nicht gehört.

Ja, ich

höre immer so, was es an anderen Podcasts

auch so gibt. Ja, deswegen, vielleicht ist das doch 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 immer ein bisschen komisch,

dass es, also es gibt einige

ja, Podcasts,

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.

Working Draft

heißt einer.

Auch einer der, vielleicht der älteste

Webentwicklungspodcast

und sicherlich einer der bekanntesten.

Auch mit Leuten hier aus

Düsseldorf und

ja, das ist aber auch sehr Frontend-lastig.

Und

genau, programmierbar

ist relativ neu.

ist halt auch sehr frontend lastig.

Folge 116.

Die machen häufig Dinge, ja, aber

achso, vielleicht auch nicht so neu.

Ja, aber gut, auf den Moment werde ich ja gerade sehen.

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

17. November, 24. November.

Also ja, die Pay ist relativ häufig.

Ja, Working Draft hat

irgendwie über 500, 531 sind sie jetzt

irgendwie oder so.

Und die machen einmal die Woche.

Da hast 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

Zahl ist jetzt auch rein aus der Luft.

Ja, und dann gibt es, also was ich auch

manchmal noch höre, ist sowas, also wenn es

deutschsprachige Geschichten sind, Englischsprache gibt es natürlich

endlos jede Menge, aber es gibt noch

sowas wie Softwarearchitektur im Stream.

Höre ich

manchmal.

Und

InnoQ hat ein paar Podcasts,

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

Mensch, der

Software-Aspektoren im Stream macht, der arbeitet da auch.

Jeder hat Wohl.

Und da arbeitet auch jemand, also der

Stefan Tilkoff arbeitet da auch und der

ist auch viel in anderen Podcasts unterwegs. Da habe ich auch

einen Working Graph zum Beispiel.

Mal ein sehr schöner, auch passend zum Thema,

worüber wir gleich reden wollen. Da gibt es eine Episode

zum Thema Single-Page-Apps und

was ist eigentlich REST und so und die ist sehr empfehlenswert.

Oh ja, was eigentlich REST ist, darüber wollen wir auch gleich sprechen

Ja, genau, darüber haben wir auch schon mal

eine Episode gemacht

Ja, aber also so in dem

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

weil es ja so ein bisschen heute auch darum geht

Ja, stimmt, dann gibt es

noch, wo wir sind, ist vorne

das ist eigentlich ein sehr super

produziertes Ding, der Titel ist toll

Ja, der Titel ist toll und die Grafiken

sind toll und das sieht alles toll aus

die Website ist toll, aber ja, es ist halt auch ein sehr vorne

entlastiger Ding, die machen halt

auf Streams und ja.

Genau. Und ich

meine, das sind so fast, dann gibt es noch

so ein paar KI-Geschichten.

Die höre ich, da habe ich die Namen jetzt nicht.

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

das gar nicht so gut. Oh, aber das mit dem

Season 4 sieht gut aus. KI in der Industrie, glaube ich,

ist einer. 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.

Ja. Fällt dir noch was ein,

Thomas, dazu?

Du hast gar nicht so viel Podcasts erzählt

Nö, meine Überlegung gerade war bloß, ob es

im DevOps-Bereich über Kubernetes

oder irgend sowas, also im deutschsprachigen

Raum noch was gibt

Naja, keine Ahnung

Vielleicht gibt es was, 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

Niko hatte glaube ich so ein, zwei Sachen

für den Niko natürlich

Aber der hat auch schon ein halbes Jahr nicht mehr

neue Folgen released, also weiß ich nicht

von dem habe ich letztens gehört,

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

Stream, auch eher so Richtung Stream geht das.

Okay, okay.

Aber ja, stimmt, der macht natürlich,

also Tech-Thiefen, 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

ja.

Cool, ja.

Ja, ansonsten weiß ich nicht, gab es in der Python-Welt

irgendwelche Neuigkeiten,

irgendwelche interessanten Dinge?

sonst.

War ja so

Jahrespause, ne?

Ja, Jahreswechsel ist immer ein bisschen ruhiger.

Ja, nö.

Ansonsten weiß ich da auch nichts mehr.

Dann können wir

fast mit dem Thema

nicht früh durch.

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

vpn.com slash pythonpodcast gehen

und bekommt da 73% Rabatt

auf ein 2-Jahres-Paket

und noch einen Gratis-Monat extra

und genau, wenn euch

das nicht zusagen sollte, könnt ihr das auch

innerhalb von 30 Tagen kündigen

ohne, dass euch da Zusatzkosten entstehen

und ja, könnt euch das mal angucken

ist vielleicht ganz nett, manchmal braucht man das ja schon

also ich war zum Beispiel letztens

im Urlaub und

und wollte da die Dinge weitergucken, die ich normalerweise so gucke und musste dann feststellen,

nee, das geht nicht, weil Streaming-Dienstleister hat festgestellt, man ist woanders, als man normalerweise ist

und dann geht das halt nicht mehr.

Und da möchte man dann vielleicht doch eher nur so auf irgendwo VPN aktivieren klicken

und dann geht das halt einfach weiter.

Und hatte ich nicht, muss ich überlegen, wie ich das nicht vielleicht mal haben möchte 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 Internet-Erlebnis

verhelfen, indem ihr einen VPN benutzt.

Ja, genau.

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

nordVPN.com slash pythonpodcast gehen

und 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-Codes für HTML.

So hat es denn der Mensch genannt,

der das erfunden hat.

Um einfach

HTML so zu erweitern,

wie es der Standard bis jetzt nicht zugelassen hat.

Also, dass man keinen

JavaScript mehr braucht, um coole,

responsivee Sachen im Web zu bauen.

Na doch, JavaScript brauchst du schon.

Ja, aber du musst das nicht mehr

schreiben, so wirklich.

Ja.

Ja, es wird dann so deklarativ.

Das ist eigentlich schon

nicht schlecht. Es entwickelt sich ja alles so ein bisschen

in die Richtung spricht.

Ja, vielleicht noch mal ganz kurz,

was das so ist.

Wie machen

wir denn normalerweise jetzt Frontend und Backend?

Trennen wir das? Wie war das denn früher?

Und

warum dann HTMX?

Also was ist das so?

Früher war es einfach nur so, du hast den Server gefragt

und der hat dir dann die Webseite fertig geschickt.

Ja...

Nein, weil ganz früher...

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

Anfang der 90er oder so.

Also ich würde ja sagen,

das Web ist ja im Grunde ein sehr neues

Modell. Also insofern,

fangen wir gerade mit dem

harten theoretischen Kram an.

Ich weiß nicht, 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 vorgemacht hat.

vorher, was man vorher gemacht hat, ist halt so

Client-Server zum Beispiel.

Oder Remote-Procedure-Calls

oder sowas. Solche Dinge.

Das ist halt alles deutlich älter als das Web.

Und Web ist halt eigentlich was anderes.

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

Und dann, was ist denn Web?

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

Ja, naja, also Web

ist halt sozusagen

da, ja,

wie definiert man das?

Es gibt halt diese, das hatten wir, wie gesagt,

in der Rest-Episode, diese Dissertation von

Roy Fielding, der halt auch an Startnards da maßgeblich mitgearbeitet hat mit Tim Berners-Lee und der hat da seine Dissertation irgendwann drüber geschrieben und da definiert er, was er quasi meint, was das ist, so als Representational State Transfer oder so. Aber es ist halt die Frage, ob das so interessant ist.

Ja, ich glaube, das hatten wir ja schon in der Restepisode. Ich glaube, da müssen wir es gar nicht sagen.

Ja, im Grunde so ganz, ganz, ganz grob ist es halt irgendwie, es geht darum, dass der Client im Grunde nicht mehr viel wissen muss, dass man halt alles, was an Informationen man braucht, um halt irgendwie einen Client betreiben zu können, ja sozusagen, dass das halt alles mitkommt.

also sozusagen, dass man halt auch mit einem alten Browser

halt zum Beispiel Dinge machen kann, dass man

jetzt nicht immer den neuesten Browser haben muss, also

bei kleinen Server war das Problem früher immer,

wenn man da irgendwie was geändert

hat, dann muss man immer dafür sorgen, dass

auch die aktuellste Version vom

Client irgendwie geschippt wird, weil

ansonsten funktioniert das halt nicht mehr.

Und das ist mit Web,

also mit REST und Web ist es eigentlich

dann insofern besser, als

es halt auch mit alten Browsern noch funktioniert, man muss sich nicht

darum kümmern, dass die Leute halt immer

den aktuellsten Browser haben und

und es sollte eigentlich mit jedem Browser funktionieren und so.

Und der Browser muss nicht wissen, was da kommt.

Also wenn ich jetzt zum Beispiel, das ist halt genau eine von diesen Geschichten,

die halt jetzt bei diesen ganz modernen Geschichten in Anführungsstrichen,

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

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

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

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

Ja, du hast danach gefragt.

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

gerade was kein Server ist, aber der

glaube ich der entscheidende Unterschied, was HTMLX

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 Servers halt dann.

Aber vielleicht will der Thomas das

gerade genau da jetzt nochmal einsteigen.

Ja, also

bei HTMLX, das ist

sicherlich auf JavaScript basiert, anders

kommt man ja in den Browser nicht wirklich

rein, um dort irgendwas

zu programmieren im Browser.

aber Ziel der Übung ist eigentlich, dass der Endanwender, also der Entwickler dann kein JavaScript mehr schreibt oder wenig JavaScript und da wird HTML erweitert um neue Attribute, sodass man das HTML klassisch verwenden kann, also wie es eben vor 20 Jahren gemacht wurde, sprich vom Server zum Client kommt HTML, gegebenenfalls auch HTML Schnipsel oder so ähnliches

und man braucht das jetzt nicht in ein JSON-Format erstmal konvertieren

und dann am Client wieder aus dem JSON dann irgendwie HTML machen oder DOM-Objekte machen.

Das ist eben so recht revolutionär eigentlich.

Revolutionär so hingegen, weil es halt wie das Wort Revolutionär ist,

am Ende 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, habe es mal ausprobiert in einem kleinen Projekt.

und da bin ich jetzt hier, um ein bisschen davon zu erzählen.

Ja, ich finde es super spannend.

Ich höre ja schon seit einiger Zeit davon.

Wenn man sich anguckt, was sind die meistgesehenen Talks auf sowas wie,

das ist auch der Grund, auf den Thomas gekommen ist,

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

Ja, ich kann es auch sehr gut verstehen.

also ich habe irgendwann mal angefangen mich auch mit

diesen sozusagen

Frontend Frameworks so ein bisschen zu beschäftigen

für mich war damals der Grund, warum ich das gemacht habe

dass ich gerne so

ja

so ein

UI

Anmutung gerne hätte, wie bei

einer nativen

Applikation sozusagen

das hat man ja halt so früher eigentlich bei Webseiten

nicht so wirklich gehabt, weil

naja, da

hat man immer

Request-Response-Cycle

irgendwie und das dauert dann halt einfach

und man sieht das auf jeden Fall, dass da was passiert und es ist halt

nicht so schnell, als wenn man jetzt halt irgendwie

eine

in Anführungsstrichen klassische App hat,

die halt irgendwie lokal auf dem Rechner läuft

und

für mich war das halt so,

das Versprechen dieser

quasi Frameworks, dass man das halt

auch im Browser so hinkriegen kann, dass man da

keine Latenz mehr hat und dass das halt alles

super schnell ist und dass sich das anfühlt

wie was natives.

und das hatte mich interessiert und da dachte ich,

okay, naja gut, wenn man das halt so

machen muss, dann geht das halt nicht anders und

dann muss ich halt dieses komische JavaScript

da mitmachen. Okay,

aber wenn ich dafür diese

UI-Geschichte

kriege, dann ist es das ja vielleicht

wert, weil das ist ja tatsächlich

so ein bisschen so eine nervige Geschichte.

Und ja,

ich dachte eigentlich immer, der Grund, warum

das bei normalen Web-Anwendungen

halt so ein, oder bei Webseiten

so ein Problem ist, lag an diesem Request-Response,

weil es dauert halt irgendwie, je nachdem wo ein Server

steht, hat man alleine eine Latenz

bei einem Request von, weiß ich nicht,

mindestens mal so 50 Millisekunden oder sowas

und ich dachte, das liegt dann halt, das

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

dass sich das dann langsam anfühlt und

hab dann sogar solche Sachen eingebaut

in meine ersten Versuche mit so

diesen, also ich glaube, das erste

hab ich tatsächlich React irgendwie am Anfang

verwendet und

hab dann immer irgendwie die

Daten für, so, 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 mitgeflatscht,

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.

Und tatsächlich

das habe ich jetzt auch

mit HTMLX 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.

Also vielleicht hast du

zu viele Daten dann sonst am Kleinen drin, die der

dann handeln muss?

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.

An der Interaktivität?

Das liegt daran, dass

das komplette Browserfenster immer ausgetauscht wird.

Das ist halt der Punkt. Und dass der

Browser teilweise auch bei komplizierteren

halt einfach lange braucht, um das

wieder komplett neu zu rendern.

Ja, aber das Ganze rendern, solange dauert.

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

sagte, man muss das erst in

JSON umwandeln von dem alten Zustand,

damit man es wieder zurückdrehen kann.

Das heißt, so der Urzustand

ist halt ein anderer dann gewesen als JSON.

Was ich jetzt, muss ich sagen, weil ich bin auch nicht so lange

dabei wie ihr, gar nicht

so unintuitiv finde, weil ich zum Beispiel jetzt aus

Django Models immer direkt in JSON reinrendere oder so

und halt diesen Umweg über die Templates

gar nicht so häufig gehen musste.

Deswegen ist das für mich so ein bisschen

Umgewöhnung, also ich finde das Django-Template-System sehr

angenehm, weil es halt die ganzen

Features von Django zurückholt,

die man sonst verliert, wenn man halt Js macht,

aber ansonsten hat es für mich

auch so einen Sinn, wenn man halt 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

eher so zeitlich gemeint, also dass

man eben so

ähnlich macht, wie man es vor

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

ficken.

Ja, und das

habe ich bei so einem kleinen

oder zwei kleinen Projekten ausprobiert und

funktioniert prima

und

kann bloß sagen, dass es auch eine ganze Menge

anderer Leute eben sozusagen auch sehen,

die gerade halt Leute, die aus dem

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 HTML

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.

Es gibt ein paar Attribute, mit denen

man das HTML erweitern kann und dann

kann man eben auch einzelne Bereiche

auf so einer Seite austauschen.

Man hat also eine große Seite und dann kann man eben

drei, vier Bereiche haben

und dann kann man in diesen Bereichen

Interaktivität schaffen, indem man dort

einen Button hat und dann tut sich aber halt auch bloß nur

dieser kleine Bereich austauschen.

Und das macht halt die Seite

irgendwie, ja,

intern interaktiv.

Ja, ja, das was ich jetzt, ich hab

gestern, vorgestern mal so ein bisschen

damit rumgespielt

und was ich, ich hab

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 kann quasi eine

Liste von Dingen und zum Beispiel wie

bei einem Podcast so die Episoden

oder bei einem Blog die Artikel und jetzt

paginated man da so durch

und das hat

für mich war der Grund früher mal, warum

ich gedacht habe, okay, ich muss mir das mal

angucken mit den JavaScript-Frameworks, dass das halt

dann schneller geht, wenn man das halt irgendwie

schon, wenn man da nicht jedes Mal

die Seite neu laden muss.

Und das habe ich jetzt mit HTMLX gemacht und auch selbst

wenn man den kompletten Content der

auszutauschen. Es ist immer noch sauschnell und man

spürt da keinen Unterschied.

Oder man hat nicht das Gefühl,

dass man den

kompletten Content ausgetauscht hat, sondern

erst wenn man tatsächlich die komplette

Seite austauscht, dann wird es langsam.

Also Lizenz hast du 100 Millisekunden, merkst du

halt, ein bisschen unter, so unter 50

oder ist schon super. Da merkt man das eigentlich nicht und

das kann man durchaus schaffen, da drunter zu bleiben.

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

gemerkt habe, okay, dieser Use-Kit geht auch

damit, dachte ich so, wow, okay.

Dann entfällt für mich

eigentlich der Grund für diese JavaScript-Dinge

Also was mich interessieren würde

was ich jetzt noch nicht genau gesehen habe

aber es liegt wahrscheinlich daran, dass ich das noch nicht so eingebaut habe

Kann ich das trotzdem so in Komponenten strukturieren

wie ich mir das vorstelle aus dem Vue.js raus

und wie läuft das mit den ganzen

netten

Animation-Plugins und sowas

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 VDS rendert das ja auch irgendwie im Hintergrund einmal durch

und tauscht dann die Teile aus im DOM.

Und auf welcher Ebene muss ich das denn machen?

Ja, man hat ja die ganz normalen HTML-Tags.

Also wenn du eine Seite hast und da sind eben drei interaktive Bereiche drin,

dann wäre es eigentlich sinnvoll, du machst eine große Seite

und dann hat die da dreimal ein Form-Tag zum Beispiel.

und wenn du ein Submit für dieses Form macht, also für eins dieser Forms,

dann werden die Daten dieses einzelnen,

des einen Forms zum Server geschickt und kriegst die Antwort wieder zurück.

Also dann, die Komponenten sind sozusagen

HTML-Tags.

Ja, also wenn du meinst, dass du sowas hast, also eben

Vue und React, die machen das, da ist ja genau das,

das ist ja ein ganz anderes Modell und wahlweise, je nachdem aus welcher Geschichte

und Jochen unterhalten sich über die Programmiersprache Python

und so. Aber genau an der Stelle

müssen wir jetzt vielleicht nochmal einiges hochgehen, weil ich glaube,

jetzt haben wir 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 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

ist halt ein Dokumentformat.

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

Und das Gute ist natürlich auch,

als Backend-Entwickler kann man natürlich sagen,

wenn man sich mit dem Pixel-Schubschrauber beschäftigt,

sichert sich Frontend damit. Man gibt denen einfach die Daten

und dann ist gut, dann hat man damit nichts mehr zu tun.

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

Das führt halt auch dazu,

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

eine Reihenfolge von Dingen.

Da spielt es eine Rolle, ob Sachen vorne stehen oder hinten.

Wenn ich in JSON

ein Objekt habe, dann ist das egal,

ob das vorne steht oder hinten.

Das sind immer die gleichen Daten.

und ja, das

macht es sehr schwer zu handeln, weil

ich dann beim Parseln 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

dazu sonst irgendwas wissen muss.

Du kannst ja tatsächlich auch den ganzen Datentyp verändern.

Du musst ja jetzt nicht nur irgendwie ein JSON-Objekt durch ein anderes

austauschen, sondern du kannst ja was ganz anderes

dahin stellen auf einmal.

Das ist ja so magisch irgendwie.

Ja genau, und bei JSON geht das halt nicht.

Bei JSON musst du halt wissen, was das ist.

Ansonsten funktioniert es nicht.

Was mir bei JSON jetzt nicht so gefällt,

ist halt, die Datentypen

sind recht eingeschränkt.

Ordentliches

Timedelta oder irgendwas.

Ja.

und Python und dann will ich aus dem SQL irgendwie das beim Client anzeigen und da ist es f 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.

Und da frage ich mich, warum?

Ja und

es ist halt auch so, dass man dann die ganzen

Probleme aus der alten Welt wiederbekommt

nämlich zum Beispiel, was ist wie

also deine Applikation

muss jetzt natürlich das JSON verstehen

und hat jetzt auch

Versionen zum Beispiel, also was ist denn

wenn jetzt kommt das JSON

von heute sozusagen

aus irgendeinem Backend, aus irgendeiner Datenbank

und die Applikation ist aber ein Jahr alt

weil ich halt jetzt, weiß ich nicht, keine Ahnung

ein Browserfenster irgendwie

Ich habe einen Rechner irgendwie in die Ecke gelegt, der dann ein Jahr lang gelegen hat, jetzt kreufe ich den wieder auf und was macht die Applikation denn jetzt mit den Daten?

Das wird wahrscheinlich nicht funktionieren.

Das haut nicht hin und das hat man ja auch eigentlich in allen von diesen frontendlastigen Anwendungen, dass dann ab und zu irgendwo so ein Popup kommt, bitte Seite neu laden, weil neue Software-Update oder irgendwas anderes, so ein Browser-Reload dann sozusagen wie so ein Software-Update.

Genau, das hat man in dem

HTMLX-Fall eigentlich

Ja, das hat man in dem

Rest-Web irgendwie sozusagen

Fall, in dieser Architektur hat man das nicht, weil da gibt es

das einfach nicht

Man kann prinzipiell auch auseinanderlaufen, also wenn ich jetzt

ein Formular einmal erstmal mir

lade, ein HTML-Formular

und dann vergeht wirklich

eine Menge, vergeht eben Zeit und es gibt

ein Software-Update und dann mache ich bei mir

einen Post von meinen Formulardaten

kann das prinzipiell ja auch gegen den Baum gehen, weil

es dann nicht mehr hinhaut auf Server-Seite

wenn sich tatsächlich an der

Datenschema oder so irgendwas geändert hat.

Und ja, okay.

Aber tatsächlich,

ja gut, okay.

Wir gehen einfach mal davon aus, dass man, wenn man

Dinge irgendwie jahrelang da liegen lässt, man nicht davon

ausgehen sollte, dass die einwandfrei so funktionieren wie am ersten Tag.

Ja, ja, okay.

Aber du kriegst das Problem auch

deutlich schneller. Und du hast halt dieses Problem

plötzlich wieder. Du hast das Problem wieder, dass

du deine Clients aktuell halten musst.

Das war eigentlich,

Das ist eine der großen Versprechungen von Webgeschichten, dass man sagt, das musst du nicht mehr machen.

Also um nochmal zurück zu kommen, die alte Client-Server-Architektur bedeutet,

ich habe eine Hauptanwendung, einen Server, auf dem die ganzen Daten, die ganze Datenbank liegt

und die Clients, die selbstgeschriebene Anwendungen sind, die auf anderen Rechnern laufen,

die dann halt mit dem Server kommunizieren, die halt eine bestimmte Version haben.

Und wenn ich jetzt irgendwas Neues veröffentliche, dann muss ich dafür sorgen,

dass der jeweilige Client sich ein Update herunterlädt, seine Applikation aktualisiert,

um wieder mit dem Server reden zu dürfen.

Der Kern der Applikation ist eben nicht auf dem Server,

sondern der Kern der Applikation ist halt auf dem Client.

Und vom Server kommen nur Daten.

Okay, also der Kern der Applikation bedeutet

tatsächlich

der State der Applikation.

Jetzt hast du schon wieder State gesagt,

ich glaube, das haben wir auch noch nicht so richtig

beschrieben. Was ist denn ein

State überhaupt? Also

die Wahrheit

vielleicht über das, was gerade

ist?

Ja, also sozusagen die Information,

und 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? Genau.

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, von denen ich keine Ahnung habe, aber der große Unterschied

ist halt, das liegt halt in dem

HTML selber.

Das ist halt der große

Unterschied zu allem, was früher war

Das ist halt sozusagen dieser revolutionäre Schritt

Das hat man vorher, soweit ich weiß

noch nie gemacht

Und das ist neu in HTML

und mit REST

Ich kenne halt auch die

Frage, was man will

Ob man jetzt so eine

Seite will, eine Seite, die sich

eben super schnell lädt, weil

der Nutzer bei Google was danach gesucht hat

und dann folgt er dem Link, der ihm

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

und will die Seite geöffnet haben

und sehen und da ist halt ganz wichtig,

dass

was jetzt Google mit den Webvices

oder irgendwas so abprüft, dass

zack, diese First-Time-User-Experience

gut ist, zack, die Seite soll sich schnell laden.

Und witzigerweise

gibt es ein Produkt von dem gleichen

Großkonzern, Google,

zum Beispiel Gmail

und wenn ich Gmail starte, sehe ich

erstmal einen Wartebalken.

Das geht mir natürlich als so zu Eichei auf den Keks.

Sehe ich erstmal,

wie sich die ganze Anwendung lädt.

Das will ich nicht.

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,

die tut man als Anwender eben

morgens starten und die tut man

abends dann wieder schließen oder so.

Da ist ja noch

Das ist okay.

Was ich will, ist ein Nutzererlebnis.

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

da ist. Es muss schnell irgendwas passieren.

Aber ich brauche nicht direkt sofort den ganzen Content,

sondern ich will da so reingeführt werden,

dass ich willkommen bin, dass ich

eingeschubt werde, auch was da funktioniert.

Na gut, aber das ist halt, das liegt halt

im Use Case. Da denke ich drauf an, was das für

eine Applikation ist,

die man da, oder was der Use Case ist.

Und für die allermeisten Web-Use

Cases ist es halt wichtiger, dass man

quasi von, dass man das auch

und Jochen unterhalten sich über die Programmiersprache Python

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 eine komplexe

User,

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

Serverseitrendering und den ganzen Späßen.

Moment, was ist Hydration, was ist Dehydration,

was ist Serverseitrendering in dem Fall?

Gemeint?

Ja, also du benutzt im Grunde

Node.js auf dem Server, um halt

dein, also du hast ja

meistens dann auch so eine Templatesprache, so ähnlich wie

Django-Templates, bloß halt in JavaScript,

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

keine Ahnung. Und du kannst

das ja jetzt, du kannst es im Browser rendern,

da läuft JavaScript, was seine

Templates nimmt und dann halt

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

halt dann HTML rausrendert.

Du kannst es aber auch auf dem Server rendern.

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

und dann halt auch HTML rausrendern.

Und das HTML, was du da rausrenderst, kannst du

auch einfach so an den Kleinen schicken.

Sodass das Rendering halt nicht bei dir im Browser

passiert, sondern auf dem Server.

Das ist halt dann für kürzere Antwortzeiten.

Ja, ja, also dann

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

eine klassische, wie so

eine Django-Webseite oder so.

Und dann aber schiebt der Server

ja doch dann noch irgendwie so ein JavaScript-Bundle

dahin und dann wird das ersetzt.

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

funktioniert mit dem Hydration oder so.

Aber was ist jetzt das Hydration?

Ich nehme mal an, dass es irgendwie so

sozusagen

diese reine, das HTML-Wass gekriegt ist,

ist quasi in Anführungszeichen irgendwie trocken.

Und weil es halt so

statisch ist. Und ich nehme mal an, dass sie mit Hydration

meinen, du schickst halt den Bundle

dahin und wenn das Wandel da ist, dann sagt es, okay, jetzt gibt

man die Daten per JSON und dann rendert es das

halt auf den Client selber.

Dann ist das, was zum Beispiel bei Vue.js in den Komponenten passiert,

wenn da bestimmte Teile

im DOM getauscht werden, so HTML-Stipsel

von Antworten vom Server dann auch.

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,

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.

Und sozusagen als Browser, wenn du auf so eine

Seite, wenn du jetzt zum Beispiel NUX

nimmst bei Vue und machst da

Server-Site-Rendering, dann dein

Browser kriegt einfach nur HTML und zeigt

das an, wie bei jeder anderen Seite auch.

Für den

führt kein JavaScript

erstmal aus.

Nur dann später. Also

die Frage ist, wo es gerendert wird. Bei Server-Site-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 das ist, denke ich, das, was mit

Hydration gemeint ist.

Und die Sache ist, es ist ja schön, dass man das alles

machen kann. Und die

Frage ist aber, ob man 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 dem Server einsetze oder irgendwas,

habe ich eben persönlich keinen Bock drauf.

Und darum habe ich das Schöne, ich habe da angefangen im privaten Kontext auch,

ich habe für jemanden eine Seite machen wollen und so ein Bestellsystem.

Und das Schöne, da hatte ich einfach Zeit und es war auch kein Druck irgendwie da

und auch keiner, der gesagt hat, Thomas, nimm die oder jene Tools.

Wenn man da Zeit hat, kann man wirklich nochmal recherchieren

und auch sagen, nee, so möchte ich es jetzt nicht machen,

ich will es jetzt so machen.

Und dann habe ich erstmal ewig gesucht,

bis ich überhaupt was gefunden habe

und durch Zufall bin ich eben auf das HTMX dann gestoßen.

Inzwischen ist es auch populärer,

inzwischen steuert man selbstständig zu,

aber vor mehr als einem Jahr war das eben noch recht unbekannt.

Gut, und da war es halt eine coole Sache

und gerade wenn man halt

eh sagt,

man selber ist in einem

Backendsprache damit vertraut,

dann

macht das eigentlich großen Sinn,

weil dann kann man das auch sehr

leicht verwalten, diesen Stack.

Ansonsten, ja, sicherlich

kann man das machen. Ich glaube auch, dass das

prima funktioniert mit dem Vue und React und so alles.

Aber wenn man das selber

alles in der Kontrolle haben will,

also ich kenne es selber jetzt beruflich zum Beispiel,

nutzen wir auch Vue.js

und ja, das ist dann

manchmal so, hm, dann ist der

Frontend-Entwickler sozusagen

oder da ist da einer mal krank oder im Urlaub

oder irgendwas und dann klemmt es Frontend-seitig,

obwohl Backend-Kapazität dabei ist

und dann ist es gleich mal andersrum oder irgendwas.

Ist doch eigentlich schöner, wenn man

da sagt, okay, ich mache wirklich eben

Fullstack vom HTML bis

zur Datenbank, habe ich alles unter Kontrolle

und da finde ich diese Trennung

zwischen Frontend-Entwickler und Backend-Entwickler,

das ist so wie

so eine komische Diskriminierung,

irgendwie, ja,

muss eigentlich nicht sein.

Ja.

Ja, ja, ich würde auch sagen,

also normalerweise ist diese Unterscheidung von

Webpacking eigentlich halt hauptsächlich irgendwie, es gibt halt Leute,

JavaScript mögen und es gibt andere Leute, die

JavaScript free-bail finden und

das war jetzt auch schon mal, also

ja.

Alle, die JavaScript-Liebe haben,

die bitte einmal aufzeigen.

Ja, naja, gut, also ich,

das ist übrigens auch so ein Ding,

Also ich meine, im Grunde die Entwicklung wird da getrieben von, also weil in der JavaScript-Welt und ich höre da ja auch ab und zu Dinge, da geht man jetzt sozusagen schon in die Richtung zu sagen, ah ja, also wir sind jetzt eigentlich weit genug, warum machen wir nicht JavaScript also komplett, also auch im Server vor allen Dingen.

Es gibt 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 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

Serversite-Rendering machen, nur das löst

die Probleme nicht. Also

wenn alle Webseiten

irgendwie fette

irgendwie Dinger wären

mit Serversite-Rendering, würde das

Web so nicht mehr funktionieren. Das würde kaputt

gehen. Also und das ist

halt irgendwie, weil du musst diese Megabyte-Daten ja

immer noch durch die Gegend schieben.

Auch wenn dir das jetzt nicht mehr so auffällt,

aber da werden halt dauernd

die gleichen

minifizierten JavaScript-Dinger durch die Gegend geschoben.

Wenn du von einer Seite auf die andere gehst,

immer das gleiche Zeug, megabyteweise.

Das ist total verrückt.

Weil ich nicht die Einzelteile

vom Dom nur tausche?

Ja, weil du musst halt die komplette Applikation

schickst du halt in der Gegend rum.

Ja?

Und die Applikation ist ja in weiten Teilen immer die gleiche.

Okay.

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

gecached und ich kann mir vorstellen,

dass die ersten drei Bilder

jeder Webseite dann größer sind

als das ganze JavaScript-Spaß.

Also ich hätte jetzt auch tatsächlich irgendwie

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

so löst, dass man dann eben nur

den einzelnen kleinen Bestandteil

dann innerhalb dieser Komponente

neu rendert.

Ich weiß nicht genau, es gibt noch so

Geschichten, da bin ich jetzt aber auch nicht vertraut mit,

dass du so dieses Hot-Module

du kannst halt teilweise

mit, es gibt so Exima Script jetzt Module irgendwie auch und manchmal kannst du halt,

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

der klassische Weg war halt, du baust deine komplette Applikation in einen JavaScript-File

und das lieferst du aus. Und solange du das nicht hast, geht gar nichts.

Und ja, also

wenn deine Applikation, also ich meine gut, sie muss nicht über Megabyte groß sein, aber

ja, also es ist schon groß und

und ja, oft ist View drin oder React und dann halt die Bibliotheken, die alle verwenden

und das Zeug wird halt bei jedem, wenn du auf eine andere Seite gehst, wird das halt immer mit übermittelt.

Und das ist ja eigentlich vollkommen verrückt ineffizient.

Also es ist ja eigentlich, tut einem ja weh, wenn man sich das so überlegt.

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

Nicht was anderes irgendwie.

Ja, okay.

Genau.

auf.

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 das zu sehen,

ein paar Examples und

ein. Beispiel ist zum Beispiel Click2Edit. Das ist, glaube ich, mit das erste. Da hat man erstmal so eine ganz normale HTML-Seite und da unten ist so ein kleiner Block und da steht irgendwie Click2Edit und in diesem Block sieht man irgendwie Name, sage ich mal, Peter oder irgendwas oder irgendein Name, Vorname, sogar ein ganz einfaches Nutzerdaten irgendwie. Da kann man hinklicken und wenn man hinklickt, dann tut sich dieser kleine Bereich aktualisieren und man hat einen HTML-Block.

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

Speichern, schwupp, ändert sich wieder dieser kleine Block und der ist sozusagen wieder Read-Only,

wie er am Anfang war, bloß mit den aktualisierten Daten. Und das Ganze funktioniert natürlich so,

dass kein, der gesamte Browser immer auf dieser Seite bleibt, also nicht die gesamte Seite wird

neu geladen. Also sprich, ich würde mal irgendwo hingescrollt haben oder irgendwas und es dann unten

auf einer Seite machen, würde die Scrollposition oder irgend sowas alles gleich bleiben.

Da ist die Frage, wie das funktioniert.

Mit dem Click to Edit wird dann der Server kontaktiert und der Server schickt dann ein kleines HTML-Schnipselchen an den Client

und entsprechend der Angabe in dem HTML und das HTMLx erweitert im Endeffekt das HTML bloß um ganz einfache neue Attribute.

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

Gibt es verschiedene Swap-Methoden, da kann man sagen, innerHTML soll ausgetauscht werden,

also dass in dem Tag oder outerHTML, sprich das Tag selber, auch mit ersetzt werden.

Und dann kriegt man eben dieses HTML-Schnipselchen vom Server und das wird dann durch HTMLX 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 ein 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, tauschen wir bitte dieses oder jenes aus und dann hat man das Ganze schon.

Also man muss sich da nicht mit JavaScript beschäftigen oder so.

Und ja, das ist sozusagen diese Grundidee der Bibliothek, dass man HTML-Schnipsel über die Leitung schickt und das deklarativ im HTML verfügbar macht.

Ja, sehr spannend. Das macht doch auch solche Sachen wie möglich, dass man dann...

Das ist auch ein weiteres Beispiel

auf der Seite, dass man Infidelscrollen

machen kann, dass er dann in diesem HXWeb-Attribut

einfach After End sagt und dann wird das einfach

angehängt.

Das ist auch ein schönes Beispiel.

Da kriegt man

den besten Eindruck, wenn man einfach mal

durchgeht.

Das ist schon super.

Eigentlich ist die Idee,

mich wundert, dass das nicht schon viel früher

passiert.

Das ist ehrlich gesagt.

Das ist genau von dem ich

eigentlich geträumt habe, gerade vor Jahren,

als ich mit Jake Ferry da so, sagen wir mal,

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.

Es 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 anderer Prozess dann darum,

dass das dann auch umgesetzt

wird und so. Und das macht es im Endeffekt dann einfacher.

Ja und im Grunde

behandelt es eigentlich, macht es

genau das gleiche, was man im Browser auf einer Webseite

tut, nur halt nicht jetzt

dass man zum Beispiel, wenn man im Browser halt auf einer Webseite

ist, kann man ja immer nur das komplette

HTML-Element ersetzen

und jetzt hat man sozusagen per JavaScript

in HTMLX halt die Dinge

die man nur auf dem einen großen Ding machen kann, kann man

jetzt auf allen kleinen Elementen halt auch machen

man kann das halt irgendwie durch was anderes

ersetzen, man kann

also normalerweise im Browser lösen halt nur

zwei Events

lösen halt irgendwie ein Request aus.

Das eine ist halt anchor, anchor-tag

und das andere ist halt irgendwie

submit, also form.

Und es gibt nur

get und post, aber es gibt ja noch

viel mehr HTTP-Werben.

Es gibt ja noch die lead-put-patch

und das habe ich mich auch früher gefragt.

Da gab es auch so bei Django REST Framework

ja irgendwie über diese browsable-api

und dann wollte ich halt mal so, da drinnen

kann man ja auch Dinge hinzufügen und so.

Okay, und jetzt muss ich noch put testen und so.

Komisch, put geht irgendwie nicht.

und Jochen unterhalten sich über die Programmiersprache Python

wächst. Also zum Beispiel

Django, was ich jetzt hier eben

einsetze für die Serverseite,

kann man ja auch auf einer HTML-Seite

mehrere Formulare dann

reintun und mit Präfixen das dann

auswerten und so weiter.

Und es war auch, wenn ich mich da

zurückerinnere, rechter Krampf irgendwie immer.

Und hier ist es einfach

entkoppelt.

Ich kann ja auch auf einer Seite drei Formulare haben

und die submitten sich eben

einzeln individuell. Da brauche ich

da nicht ein großes

Formular machen mit drei

Unterbereichen oder so. Das macht es

auch serverseitig deutlich

einfacher, das zu handeln.

Ja.

Naja, und es ist jetzt

tatsächlich auch nicht nur, also

hat demnächst vielleicht zu der Geschichte, dass

der Autor hatte vorher

eine Bibliothek geschrieben als jQuery

Plugin. Das nennt sich

irgendwie Ethercooler.js.

Daher, das hat auch mit

jQuery relativ viel zu tun.

Und das war halt

dann quasi auch halt,

HTMX ist jetzt noch in der Nachfolge davon, der dann halt ohne

JQuery auskommt und diesen ganzen Kram nicht mehr macht.

Und

was ich auch,

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 JunkoCren US

Es war auch, glaube ich, mit TalkPython2Me

Interview mit dem Entwickler von

HTMX, sagt 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 LiveView

und ich habe den auch nochmal woanders gehört.

Und zwar, der Satz ist, ja, also ehrlich gesagt,

dafür, dass ich kein JavaScript schreiben wollte, habe ich jetzt ganz schön viel JavaScript geschrieben.

und das

sagen, also das ist halt

dieses Thema, also ganz viele Backend-Leute,

die eigentlich nie JavaScript schreiben wollten,

haben jetzt

dann doch viel JavaScript geschrieben, um das loszuwerden

und wenn

das viele Leute machen und

quasi zu einem ähnlichen Ergebnis kommen und

das tatsächlich funktioniert, dann wird das wahrscheinlich

auch so bleiben und das sieht danach aus, als hätte

man da was gefunden, was tatsächlich gut funktioniert und das

macht es dann natürlich auch interessant, also wenn das jetzt nur

eine Geschichte wäre, aber ich weiß

nicht ob mir jetzt die ganzen Namen einfallen, aber

in der Ruby on Rails Welt

also bei HTMLX wird ja auch viel mit Ruby on Rails

zusammenverwendet, gibt es halt noch Hotwire

also ist auch Akronym

für HTML over the wire

und Turbolinks, wo

halt dann quasi schon die

Seite hinter dem Link gefetcht wird

sodass wenn man auf den Link draufklickt, das halt dann

direkt da ist

dann gibt es

eben bei

Elixier

in der Elixier Welt Phoenix gibt es LiveView

wo auch HTML-Snippets halt über den Websocket

geschickt werden, dann gibt es das

in PHP,

da heißt das irgendwie Livewire in Laravel

und

ja,

ich weiß es gar nicht, da gibt es

also auf jeden Fall in vielen unterschiedlichen

Communities machen Leute jetzt gerade sowas

und ja,

das scheint irgendwie ein sehr, sehr

breiter Trend zu sein, ja.

Der Schöne an dem HTML-X ist ja auch,

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

ist es Hotwire

und drum war das,

ich habe es mir angeschaut und hätte

eigentlich da Interesse gehabt, aber das war dann

irgendwie schon wieder irgendwie kompliziert

und nicht so einfach. Das

HTMX hat es, glaube ich, der Carson Cross

hat es da sehr, sehr schön

nochmal reduziert von der Komplexität

und das ist ja auch im Endeffekt sein Ziel.

und Jochen unterhalten sich über die Programmiersprache Python

von Adam Johnson,

der hat irgendwie ein Ding geschrieben,

Django HTMX,

das ist eben als

Integration jetzt auch in Django als Framework,

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

das macht nur

sozusagen eine Middleware dabei,

die an den Request halt ein Attribut

dran bappt,

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

kann, weil man muss auf der Serverseite halt

unterscheiden können, war das jetzt ein Request,

der von HTMX gekommen ist oder nicht und dann

je nachdem, rendert man eben

die komplette, das ist auch sowas, wenn

ein Browser kein JavaScript kann, das ist gar kein Problem

das funktioniert einfach so weiter

weil auf der Serverseite rendert

man halt, wenn man sieht, okay

es war kein HTMLX-Request, dann rendert man einfach

die komplette Seite raus, das ist gar kein Problem

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

rendert man halt nur das Fragment raus, das halt

ersetzt werden muss und das heißt

es funktioniert in beiden Fällen und irgendwie

man hat halt diese Windelware dann, um halt

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

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

oder nicht.

Und dann hat das Ding auch noch so Teile drin

für, damit diese

Fehlerviews halt

ordentlich funktionieren. Also wenn halt ein Fragment

nicht ordentlich gerendert wird, dann ist

wenn man sonst nichts macht,

ignoriert, also wenn dann zum Beispiel

ein 400 zurückkommt auf ein

HTMLX-Request, dann sieht man nichts, weil

HTMLX schmei einfach die Antwort dann weg Und vielleicht will man die Standard Django aber haben mit dem Stacktrace oder so Und das ist halt auch noch so ein bisschen das ist glaube ich eine HTMLX

in JavaScript, die

in Django-HTMLX drin ist,

die dann halt dafür sorgt, dass man eben die normale

Django-Fehler-Seite sieht,

auch wenn ein HTMLX-Request

halt aus der Seite schiebgegangen 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

und 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 dem HTML-Tag, Head-Tag, Poly-Tag und HTML wieder zu.

Und ab dann werden eigentlich meistens Schnipsel ausgetauscht.

Und die URLs, wo ich eben ein Schnipsel bekommen will,

die liefern immer ein Schnipsel zurück und die werden immer über HTMLX aufgerufen.

Ob das ist diese Fallunterscheidung, selber seit ich gar nicht habe,

von wegen, ist das jetzt ein HTMLX-Request oder nicht.

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

Ah, okay. Das kann ich noch gar nicht.

Das ist irgendwie auch ganz cool dazu.

Cool, ja.

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

Das ist immer ganz hilfreich.

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

Interessant.

Ja.

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

die Syntax gesprochen, über das Beispiel und das, was alles Schönes gibt

also man macht meistens halt mit diesem Swap-Target oder sowas, ja, also Moment, es gibt

Swap und Target glaube ich, ja, also das heißt wir haben, wir sagen quasi, was getauscht werden

soll, wohin das getauscht werden soll und wann es

getauscht werden soll. Genau, richtig, das mit dem Trigger geht sozusagen los

also bei einem Form muss man den Trigger jetzt gar nicht angeben, weil bei einem Form ist es

das Drücken auf den Submit-Button.

Aber es gibt eben andere Trigger, wie du vorhin

Dominik angesprochen hast, den Revealed-Trigger

zum Beispiel. Also ich kann so einen Infinite-Scroll

implementieren, indem ich ganz unten eben

einen HTML-Schnipsel habe mit dem

Trigger Revealed und der feuert dann,

sobald dieses Schnipselchen in den sichtbaren Bereich

kommt im Browser. Und das ist natürlich dann

relativ cool. Dann kriege ich das Event, dann hole ich mir

neue Daten, dann kann ich 5, 6, 7

neue Einträge unten

machen und wenn der Nutzer nach unten

scrollt, kommt er wieder nach

unten, kommt wieder das Revealed Event,

und er holt sich die nächsten Einträge.

Dann kann man ohne eine Zeile JavaScript

zu schreiben, so ein Endless

Scrolling implementieren.

Das ist eine feine Sache.

Wir haben

Swap.

Swapmesser in der HTML, tauschen out der HTML.

Target

und out of band gibt es auch noch.

und Jochen unterhalten sich über die Programmiersprache Python

und Out of Band kommt dann noch dazu, bitte tausche außerdem hier das Element mit der ID aus

und dann kommt dann dort die neue Zahl für die gesamte Summe.

Das gibt es auch noch, das Out of Band Aktualisierung von Daten angekommen ist.

Also man kann eben zusätzlich Out of Band, also wenn der Server weiß, hier ich möchte noch was aktualisieren,

was aber jetzt nicht in dem aktuellen Schnipsel mit aktualisiert wird

kann der Server out of band noch zusätzliche 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 Einkaufswagensymbol

und da will ich die Summe aller Waren anzeigen

dann kann ich damit eben das auch aktualisieren

sondern zwei Stellen, einmal diese

unten bei der eigentlichen Ware

und oben im Warenkorb.

Das ist auch so ein ganz nettes Feature

von dem HTMX.

Ja, was gibt's

sonst noch zu sagen?

Ja, auch solche Sachen, dass man

da fand ich auch nett

sagen kann, okay

lad mal dieses Element

alle zwei Sekunden nach, das ist halt auch so ein

Anwendungsfall

für Autoharte, man könnte sich auch fragen, wozu

brauchen wir eigentlich Autoharte und Inner?

weil wenn man das komplette

Element ersetzt, dann werden halt auch

die HTMLX Attribute mit ersetzt

und man kann zum Beispiel dann von der

Serverseite her steuern

wie lange irgendwas dann

also man könnte zum Beispiel, man hat halt irgendwie einen Newsticker 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 10 Minuten oder so

und dann werden halt keine neuen

wird halt nicht mehr gepollt quasi.

Und dafür muss man dann das komplette

Element ersetzen. Dann braucht man halt out HTML.

Ja, also genau. Solche Sachen kann man

auch sehr einfach machen.

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, das hält die

Bibliothek klein. Ja, die meisten Leute brauchen

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

auslagern. Ja,

ich glaube,

Server-Sent-Events

Support dafür ist auch irgendwie drin.

Da dachte ich auch so,

habe ich irgendwann letztens

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

das ist zwar schon uralt und gibt es total lang,

aber ich wusste nie so richtig, was das ist.

Aber ja, es ist halt auch eigentlich nichts Besonderes.

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

man muss halt eine Verbindung offen halten, nur

dass man halt vom

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

eine Verbindung, die immer offen bleibt,

wo man vom Server halt irgendwie Daten

und klein schicken kann.

Aber ja,

mit Django geht das nicht gut.

Aber man muss halt dafür

Django Channels verwenden.

Ja, genau.

Eine Sache fällt mir noch

ein, mehr so eine allgemeine

Sache.

Viele sind ja Freunde dieser JSON

APIs, weil sie sich dann denken, ah super,

dann habe ich ja eine

API und damit kann ich zum

einen ein Webfrontend machen und

zum anderen kann ich da eine API

anbieten für eine Maschine-Maschine-Kommunikation.

Und das ist aus meiner Sicht

Blödsinn.

Weil man

zwei ganz verschiedene Anwendungsfelder

zusammenwürfelt.

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 zu Maschinenkommunikation haben,

ist sowas wie

A-B-Testing vollkommener Schwachsinn.

Natürlich, ich werde ja nicht

einer Maschine sagen,

du kriegst die API und

der andere Client kriegt

diese APIs und diese Daten.

Das ist ja vollkommen konträre, ganz

verschiedene Anwendungsfälle.

Und drum, das war bei mir

anfangs bei Angular, wo ich dachte, oh cool,

eine API und da kann ich dann

GUI entwickeln und außerdem

eben da einen maschinellen

Zugriff auf dieser Seite haben. Aber es sind eben

zwei ganz getrennte Dinge, die auch

ganz getrennt

behandelt werden sollten.

Da könnte man

ja dann auch dann sagen, na gut, wenn ich Maschine-Maschine-Kommunikation

machen will, könnte man ja

sowas wie gRPC einsetzen,

was dann im Endeffekt auch

mehr Datentypen unterstützt und insgesamt

optimaler ist.

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

Das muss man erklären, was das ist.

Das gRPC ist eine Technologie von Google

und das ist ein binäres RPC, also Remote Procedure Call

Methode und das ist sehr effizient

und schnell. Es ist auch

schema-basiert, also du musst klar, der Server sagt klar,

was für Daten er austauscht

und das wird

im Kubernetes-Bereich

oder so ähnlich dann auch stark

verwendet. Aber halt bei den

Web-Entwicklern ist gRPC noch nicht angekommen

und das wird wahrscheinlich auch noch

ein bisschen dauern, bis das

da bekannt und verstanden wird,

um was es da eigentlich geht.

Ja.

Naja, da ist

JSON schon so das Ding,

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 irgendwie nahe liegt, wenn man

jetzt JavaScript macht, aber

ansonsten gibt es ja gar keinen

Grund dafür, dass man könnte halt auch irgendwie

andere

Datenformate halt benutzen.

Ich meine, bei Django 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 üblich, da zu sagen, okay,

ich rendere meinen Kram nicht nach JSON,

sondern nach XML.

Oder wie heißt dieses

Es gibt auch einen Binär-JSON.

B-JSON?

Jason B.

Ja, nee, das ist es.

Ach, ich hab's wieder vergessen.

Aber ja,

es gibt irgendwie auch eine

binäre Variante davon, die

man auch mit Django Resolver ganz gut verwenden konnte.

Da wurde es halt ein bisschen kleiner.

Aber ja, tatsächlich

benutzen aber doch irgendwie alle JSONs letztlich.

Ja, aktuell.

Ich bin ehrlich gesagt ganz tiefenentspannt.

also um 2001

habe ich meine Diplomarbeit

geschrieben und klar, was war das Thema? XML.

Damals ging alles um

XML und auch das HTML

sollte XML werden und so weiter.

Da bin ich ja so froh, dass dann dort

irgendwie die Vernunft gesiegt hat und

das XHTML sich nicht

durchgesetzt hat,

weil das ist am Endeffekt dann auch nur

Krampf, wenn man das zu sehr

in die Richtung treibt und wie gesagt,

damals war alles mit XML,

aktuell ist alles mit JSON

und da bin ich auch ganz 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

alle

gehandelt hätten.

Ehrlich gesagt, ich finde es

persönlich angenehmer als XML. XML war nochmal

ein Stück schrecklicher.

Das ist der Grund, wo ich sage,

den Computer will ich nicht anfassen.

Das ist komisch, ganz komisch.

Wirklich.

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

komischen Sachen wie XLT

und sowas.

Viel schlimmer als Assembly oder sowas.

Tja, ja. Aber wir haben doch einige Sachen nicht

erklärt und zwar, wie hieß der nochmal?

Carsten Gross?

Carsten Gross, glaube ich,

weil er möchte wahrscheinlich vermeiden, dass wir

ihn towern.

Sorry.

jedenfalls hat er so ein Talk gehalten und da hat er auch viel über Haters gesprochen.

Das Akronym ist auch ein bisschen unglücklich.

Ja, sehr gut.

Was ist denn das und worum geht es denn da?

Da hatten wir eigentlich schon drüber gesprochen.

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

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

Das ist ein Steckenpferd und er zählt viel und redet viel.

Aber mir ist das zu abstrakt.

Ich halte mich aus den Diskussionen

da auch raus, was ist REST, was ist

HATEOs oder irgendwas.

Für mich ist HTTP greifbar,

HTML ist für mich greifbar und so weiter.

Aber das ist mir dann

zu abstrakt und

kann ich nicht viel zu sagen.

Ich glaube,

die Übersetzung von

HATEOs ist

Hypermedia as the Engine of Application State.

Da geht es so ein bisschen darum, dass

tatsächlich die

und Jochen unterhalten sich über die Programmiersprache Python

eine Perspektive.

Ja, aber genau,

das sind dann halt deine

Datenhaltung, aber

der Application State ist ja jetzt nicht

unbedingt in der,

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

dein Cache

oder du hast halt vielleicht irgendwelche

Queues und du hast halt auch noch irgendwie

eine Session und

ganz viel Zeugs.

Aber klar, natürlich, also

Die Frage ist halt,

bei alles, was sozusagen im Browser passiert, ist halt

in dem HTML halt irgendwie drin.

Das ist halt so eine Hattie-S-Geschichte.

Aber ja, ich finde das auch ziemlich

kompliziert und theoretisch und das ist

sehr schwer, das zu erklären.

Wenn du es ehrlich 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.

Ja, weil man den Talk

schaut und erklärt das halt so ein bisschen.

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

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

Der ist natürlich sehr bannrecht.

Ja, das ist wahr.

Ja, okay.

Ja, aber da am besten

hört man sich genau den Talk dann an

und nicht uns, wie wir da hochgelegt werden.

Ja, das ist wahrscheinlich so.

Ich kann da nicht mitreden.

Ja.

Ja, dann habe ich noch eine Frage

irgendwo. Ich sehe da,

wo sind die Grenzen

oder irgendwann, wann sollte man tatsächlich auf React oder Vue umsteigen.

Da kam dann mal vorher so eine Frage.

Und da sehe ich aktuell eigentlich keinerlei Grenzen.

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

Und da war eben so eine Sache in der Firma.

Da meinte ich, wollen wir das nicht lieber mit Python machen,

anstatt aus einer Mischung aus C, C++ und Shell-Skripten.

Und dann hieß es, naja, da konnte ich bloß herausboxen,

dass wir für den Prototypen Python nehmen.

aber danach muss es sozusagen

dann mal richtig gemacht werden.

Eine richtige Programmiersprache.

Ja,

und das war ich sehr froh,

dass ich diesen Kompromiss rausboxen

konnte und im Endeffekt

hat nie jemand dann

nochmal nachgefragt, wir sollten das ja

in C oder C++ machen, weil einfach die Kunden

zufrieden waren.

Das hat schnell funktioniert, war alles prima und da

kamen reihenweise 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.

Ähnlich 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, ich sehe da jetzt

keinerlei Grenzen.

Ja.

Ne, würde ich auch sagen.

Man kann damit wahrscheinlich

für die allermeisten Sachen

ausreichend viel machen.

Das einzige Problem ist wahrscheinlich, dass man wieder wie immer von vorne anfangen muss,

und das einmal alles wieder in schönen, mit der eine 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 C++ schreibt man bessere Webanwendungen oder so.

Wenn es eine Webanwendung war, das war das natürlich nicht.

Ja, das war damals auch im Web basiert, aber auch viele Backends.

Aber das war halt einfach so üblich, das war unüblich.

Und das Unübliche wird natürlich erstmal in Frage gestellt.

Und da ist klar, es ist erstmal kein Vertrauen da.

und Jochen unterhalten sich über die Programmiersprache Python

ehrlich gesagt sagen würde, das will ich

gar nicht haben.

Frameworks sind nicht meine Freunde.

Und das ist mir durchaus klar.

Ich will eigentlich möglichst wenig mit Frameworks zu tun

haben. Also 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,

enge Kopplung 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

Das sind halt irgendwie

Firmen, die halt

vorher eine Applikation haben

Das habe ich jetzt auch aus der Nähe

in letzter Zeit irgendwie oft bestaunen dürfen

gerade was irgendwie

in dieser Pandemie-Zeit halt

Die haben halt Applikationen so

tatsächlich in C++ geschrieben oder Java

oder sowas,

die auf Clients laufen,

also die 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

den kannst du dann zum Beispiel einfach nicht mehr so gut,

also deren Rechner hast du nicht so richtig unter Kontrolle,

dann irgendwie

Netzwerk ist oft schlecht,

irgendwie, das funktioniert

alles nicht so super. Dann hilft bloß halt so ein

Citrix oder so. Genau, das war

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

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 50, 100 Leuten, keine Ahnung,

irgendwie ein paar Teams aufgeteilt

und die haben halt ihren

Bildprozess und keine Ahnung, ihre Tools

und die Architektur-Patterns, die sie halt irgendwie verwenden.

Gibt es da nicht vielleicht irgendeinen Enterprise

Web-Framework, das ich verwenden kann,

wo ich das dann quasi genauso machen kann?

Und dann greifen wir halt vielleicht zu Angular

irgendwie oder so, weil das halt

so ähnlich ist und halt auch dieses ganze

Framework irgendwie Sprech

und Enterprise Sprech halt

damit drin ist.

und das Problem dabei ist aber natürlich,

dass man das eben nicht machen kann.

Du kannst nicht einfach irgendwie eine große Applikation nehmen

und dann das

quasi genauso, wie du es vorher gemacht hast,

mit JavaScript machen und dann ist es halt eine Web-Anwendung.

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

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

der Umstellung auf irgendwas Webbasiertes?

Ohne, dass

du die ein Jahr lang schulen musst oder keine Ahnung

wie der Produktivität so beeinträchtigt ist.

Das geht nicht so einfach. Ja, aber wenn du

halt dann ganz verzweifelt genug bist, denkst du dir,

vielleicht geht es mit Angular.

Ich würde sagen, ohne diese Schulung geht das

nicht so einfach.

Also es ist einfach eine schwierige Situation auch.

Also wenn du die Sprache

wechseln musst, ist 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 TestDjango

schon sehr anders ist als GUI-Sache

in Python schreiben, was man ja bestimmt unbedingt machen will.

Naja.

Also ich glaube, diesen Plattform-Wechsel,

den kriegst du nicht so einfach hin.

Also ich wüsste jetzt auch nicht so genau, wie ich jetzt eine Android-Anwendung entwickeln will in gut.

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

Aber langsam 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 Native GUI habe ich nur noch den PyCharm.

Und ansonsten eigentlich nichts.

Du bist auch einer von diesen PyCharm-Nutzern, okay, verstehe.

Ja.

Ach, das kann man schon machen.

Du hast ja auch in letzter Zeit viel PyCharm benutzt, ja.

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.

Letztens habe ich irgendwo gelesen,

David Beasley hat das, glaube ich,

in einem

seiner Readmes zu irgendeinem anderen Softwareprojekt

hat er sehr bösartige Dinge über Java

gesagt, und zwar meinte er so,

ja, Java, ach, der spricht nicht

für Java, sondern er sagte, es gibt

diese Programmiersprache, ihr wisst schon, sie

reint sich auf Lava.

Und da ist es immer so,

die erkennt man immer daran, dass

an diesem

Moment peinlicher Stille,

bevor die Lüfter dann losheulen.

Das ist halt...

Das

Python ist flüssig zu bedienen.

Echt, findest du?

Nein.

SSD, so und

also doch, läuft eigentlich schon.

Naja.

Ich meine vor allen Dingen bei PyCharm solche Sachen, wie man drückt auf irgendeinen Button oder man macht halt eine Tastenkombination. Also man macht zum Beispiel sowas wie, bei mir ist es Command 0 oder Command 1 für den Verzeichnisbaum aufmachen oder halt Git-Dings aufmachen, zumachen. Und ich habe immer das Gefühl, wenn ich das draufdrücke, da sind so 100 Millisekunden Verzögerung oder so, bevor da irgendwas passiert. Und das nervt fürchterlich.

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ünftig zu laufen kriege.

Ja, muss man machen.

Ja, es nervt ein bisschen.

Ansonsten, PyCharm finde ich

eigentlich tatsächlich, nachdem ich das jetzt eine ganze Zeit lang benutzt

habe, ziemlich gut. Also von den Features

her finde ich das total super. Da ist es echt gut.

Es ist ziemlich

komplett und

Ja, ist alles durchdacht, aber

irgendwie, dass es halt so ein bisschen, sich so ein bisschen

äh, ja

Ich find's hässlich. Langsam anfühlt, ja gut,

das ist halt eine andere, ja

Persönliches Empfinden,

aber vielleicht kann ich das so stylen, wie ich meine anderen Sachen style

und dann macht das doch gar keinen Unterschied mehr.

Ja, aber tatsächlich,

das mit Chromium ist halt neu, deshalb, ich meine,

da auch da irgendwie VS Code, ich weiß nicht,

ob du schon mal VS Code ausprobiert hast?

Ich hab's mal ausprobiert,

aber

Ja, mehr kann ich nicht dazu sagen

Ja, ich habe Python zum Beispiel auch

eigentlich gar keine Ahnung, ich muss das auch meistens auch auf der Liste

aber kommt nach wie eitern

Ja, weil

da ist es 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 irgendwie skutt

es ist nicht so komplett wie PyCharm, es ist auch nicht

so durchsacht und so, aber

es ist tatsächlich, wenn man da irgendwie

Command-B oder das ist schneller

als bei PyCharm

Okay, ja, kann schon sein, aber 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 rein indizieren 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 hat er auch oft damit und ging es eigentlich, kann ich erstmal nicht klar.

Vielleicht habe ich auch irgendwas falsch konfiguriert, das kann natürlich auch sein.

Was ich auch mal hatte, da hat es mir immer den Akku leergesaugt,

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

Da dachte ich mir so, hä, warum zieht denn das so viel Akku?

Dann musste ich eine andere

JVM nehmen und dann war es gut

und dann funktioniert es auch.

Aber ja.

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

zum Beispiel ein Datepicker

oder irgendwas, wenn man danach sucht, da gibt es

tausend Implantierungen

von Datepickern

aber ich als Web-Anwender will

einfach dann nur fertig werden und da

Es ist einfach schön, wenn ich sagen kann, Input-Type ist gleich Date zum Beispiel oder eben Input-Date-Time-Local, um eben Date und Zeit 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 Ban,

aber kann durchaus

sein, dass da die EU

dem bald einen Riegel

vorschiebt mit dem Digital Market Act.

Es wäre sehr

schön, wenn da, weil das ist

Da kannst du als einzelner Webentwickler

ja auch von 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 das

absichtlich blockieren können. Das 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 darü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 Progressive Web App,

Progester... Gut, okay, das ist natürlich

wieder eine Sache. Aufhänger

HTMLX, also HTMLX

ist sozusagen

auf keinen Fall offline first oder

irgendwas, man braucht die Verbindung zum Server.

Das ist sozusagen, ja,

sind ganz zentrale

Sachen an dieser Stelle.

Wenn man dann

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, 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 SQLite 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

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

Verzehnfacht einfach

die Komplexität und den Aufwand.

Und drum geht

eigentlich alles Richtung ständige

Verbindung zum Internet.

Es gibt ja ganz wenige Sachen, wo es eigentlich

wirklich braucht, wenn ich will. Ich will, wenn ich in der Bahn bin und habe kein Netz,