Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode 38.
Dieses Mal wollen wir etwas über HTMX sprechen.
Hier ist der Dominik, bei mir ist wieder der Jochen.
Ja, hallihallo, willkommen Dominik.
Und wir haben heute einen neuen Gast, und zwar den Thomas. Hi Thomas.
Hallo, grüß dich.
Jo, hallihallo.
Schön, dass du da bist.
Ja, fangen wir wie immer an mit ein bisschen News aus der Szene.
Ja, oder vielleicht kann sich Thomas kurz vorstellen, so ganz...
Das wollte ich dann bei HTMX machen, aber weißt du was, du hast recht.
Eigentlich müssten wir das am Anfang stellen und sagen, Leute, hallo, und man weiß gar nicht, wer das ist.
Deswegen sag doch mal, Thomas, was machst du denn?
Ja, ich mache Softwareentwicklung. Das schon eine ganze Menge Jahre. Habe vor 20 Jahren mal Informatik studiert und vorher schon auch als Kind daran Spaß gehabt. Und ja, mache hauptsächlich eben Webentwicklung mit Python und Django, PostgreSQL und eben seit neuestem auch mit HTMLX. Und ja, hier, Jochen hat mich mal angesprochen, wollen wir nicht einen Podcast machen? Dachte ich, ja, schön, bin ich dabei. Und ja, jetzt bin ich hier.
Ja, sehr schön. Ja, sehr cool.
Ja, okay. Dann gehen wir noch
zu den News über. Erstmal ein bisschen News, ja.
Ich glaube, ich habe auch fast gar nichts
aufgeschrieben. Oh doch, Python 3.6
ist draußen, end of life.
Ich glaube, es war am 23.
Dezember oder so.
Also Weihnachten.
Weihnachtsgeschenk, eure Version ist duplicated.
Ja, das heißt
quasi die erste
Version Python 3, wo
viele Leute irgendwie das Gefühl
hatten, das ist jetzt besser als Python 2.
Ist jetzt auch End of Life.
Das heißt, ja, also
krass. Als ich das gesehen habe, dachte ich so, wow,
das ist schon wieder so lange her.
Bei 3.6 habe ich, glaube ich, angefangen.
Das ist schon gar nicht so lange her.
3.7 kam dann relativ fix und jetzt, ja, ging es schnell.
Also meine News,
ich habe noch gelesen, dass Python Programmiersprache
des Jahres 21 geworden ist.
Wir werden famous und beruhigt.
Ganz wichtige News.
Ja, es gab jetzt auch wieder eine neue Version
von diesem TOB
Index, wo Python
auf Platz 1 ist.
Allerdings muss man dazu sagen,
vielleicht, dass das irgendwie, also
so wahnsinnig viel kann man da nicht draus lesen.
Ja, ist doch eigentlich relativ wurscht.
Ja, ich habe letztens, wo habe ich das gehört?
Ein programmierbarer Podcast war es, glaube ich.
Dass da jemand meinte so, ja, das ist irgendeine
niederländische Firma und das, was die machen, ist,
sie machen irgendwie
neben den Namen der Programmiersprache,
machen Programming dahinter und
googeln dann danach und dann zählen sie die
Anzahl der Suchergebnisse. Das ist mehr oder weniger, was
sie tun. Und das ist
natürlich irgendwie, ja, gut, ob das jetzt so
einem wahnsinnig viel sagt, ist halt
unklar.
Das habe ich von dir noch nicht gehört.
Ja, ich höre
immer so, was es an anderen Podcasts auch so gibt.
Ja, deswegen, vielleicht ist das auch mal interessant, dass man
mal kurz darüber erzählt. Ja, also
da geht es meistens so um Frontend-Themen.
Also es gibt erstaunlich, das ist auch so was,
das finde ich immer ein bisschen komisch,
dass es, es gibt einige
Podcasts, die sich mit dem Thema Programmierung
und so beschäftigen, aber
fast alle eher so Frontend.
Also es gibt zum Beispiel Webwork,
nee, nicht Webwork, das ist ein Meetup hier in Düsseldorf.
Working Draft
heißt einer, auch einer
der vielleicht der älteste
Webentwicklungspodcast und
sicherlich einer der bekanntesten,
auch mit Leuten hier aus Düsseldorf
und ja,
das ist aber auch sehr Frontend-lastig
und
genau, programmierbar,
ist relativ neu, ist halt auch
sehr frontendlastig. Folge 116,
die machen häufig Dinge,
ja, aber, achso, vielleicht auch nicht so neu.
Ja, aber gut, Moment, wenn ich hier gerade sehe,
3. November, 2. November, 10. November, 12. November,
17. November, 24. November,
also ja, die Page ist relativ häufig.
Ja, Working Draft
hat irgendwie über 500, 531
sind es jetzt irgendwie oder so, weil
wir machen einmal die Woche.
Das ist schon, ja. Ja, da brauchen
wir noch ein bisschen.
ja. Wie sagt jemand mit dem
Gameboy, kann man jetzt in 50.000 Jahren
einen Bitcoin meinen?
Ah ja, okay. Irgendwie so,
die Zahl ist jetzt auch noch rein aus der Luft.
Ja, und dann gibt's, also
was ich auch manchmal noch höre, ist sowas, also
wenn es deutschsprachige Geschichten sind, Englischsprache
gibt's natürlich endlos jede Menge, aber
gibt's noch sowas wie Software-Architektur
im Stream.
Höre ich manchmal.
Und
InnoQ hat ein paar Podcasts,
ist eine Firma und die hat auch was mit dem, also
der Mensch, der
Software-Architektur im Stream macht, der
arbeitet da auch.
Und da
arbeitet auch jemand, also der
Stefan Tilkoff arbeitet da auch und
der ist auch viel
in anderen Podcasts unterwegs, da habe ich auch
einen Working Graph zum Beispiel.
Mal ein sehr schöner,
auch passend zum Thema, was wir gleich,
worüber wir gleich reden wollen,
da gibt es eine Episode zum Thema
Single-Page-Apps und
irgendwie, was ist eigentlich REST und so und die ist
sehr empfehlenswert. Oh ja, was eigentlich
REST ist, darüber wollen wir auch gleich sprechen. Ja,
genau, darüber haben wir auch schon mal
eine Episode gemacht.
Ja, aber also so in dem,
also so ganz kurz muss man es ja gleich wieder erwähnen, weil
das ja so ein bisschen heute auch darum geht. Ja,
stimmt. Dann gibt es noch
Wo wir sind ist vorne.
Das ist eigentlich ein sehr super, super
produziertes Ding. Der Titel ist toll.
Ja, der Titel ist toll und die Grafiken
sind toll und das sieht alles toll aus und die Webseite
das toll. Aber ja, es ist halt auch ein sehr frontendlastiger
Ding. Die machen halt auch
Streams und ja.
Genau. Und ich
meine, das sind so fast, dann gibt es noch so ein paar
KI-Geschichten,
die ich höre, da habe ich die Namen jetzt nicht und die
höre ich auch sehr unregelmäßig, weil meistens gefällt mir das
gar nicht so gut. Oh, aber das mit den BVC sind vorne
sieht so gut aus. KI in der Industrie, glaube ich, ist eine.
Das gefällt mir eigentlich ganz gut, da bin ich gespannt.
Ja. Ansonsten mehr fällt mir jetzt ehrlich
gesagt nicht ein, was es da auf Deutsch gibt.
Ja. Fällt dir noch was ein,
Thomas, dazu?
Nö, meine Überlegung gerade war bloß,
ob es im DevOps-Bereich
über Kubernetes oder irgend sowas, also
im deutschsprachigen Raum noch was gibt.
Naja,
keine Ahnung. Vielleicht gibt es das,
aber das ist auch etwas, wo ich gar nicht nachgucken würde
oder weil es mich gar nicht
so sehr interessiert.
Glaube ich, würde ich das auch gar nicht mitbekommen.
Niko hatte, glaube ich, so ein, zwei Sachen da
in den Techniken gemacht, aber der hat auch
glaube ich schon ein halbes Jahr nicht mehr neue
Folgen released. Also weiß ich nicht, ob es die noch gibt.
von dem habe ich letztens gehört,
da macht er irgendwie so ein Live-Webinar-Ding,
Stream, auch eher so Richtung Stream geht das.
Okay, okay.
Aber ja, stimmt, der macht natürlich,
also Tech-Tiefen, vorher hieß das irgendwie anders.
Ja, der macht auch nicht nur Frontend-Themen,
sondern alles Mögliche.
Auch so ein bisschen mit Schwerpunkt auf Data Science, aber...
Mhm, cool, ja.
Ja, ja.
Ja, ansonsten weiß ich nicht.
Gab es in der Python-Welt irgendwelche Neuigkeiten,
irgendwelche interessanten Dinge?
Hm, sonst...
War ja so eine Jahrespause, ne?
Ja, der Jahreswechsel ist immer ein bisschen ruhiger.
Ja, nö, ansonsten weiß ich da auch nichts mehr.
Dann sind wir dieses Mal mit dem Erstaunlichen früh durch.
Jo, und wie wir ja schon angekündigt hatten, angedroht,
gibt es nur noch ein bisschen Werbung.
Der Sponsor für diese Episode ist NordVPN.
Das ist ein VPN-Anbieter.
und da könnt ihr etwa auf notbpn.com
slash pythonpodcast gehen
und bekommt da 73% Rabatt
auf ein Zwei-Jahres-Paket
und noch einen Gratis-Monat extra.
Und genau, wenn euch
das nicht zusagen sollte, könnt ihr das auch
innerhalb von 30 Tagen kündigen,
ohne dass euch da Zusatzkosten entstehen.
Und ja, könnt euch immer angucken.
Ist vielleicht ganz nett. Manchmal braucht man das ja schon.
Also ich war zum Beispiel letztens
im Urlaub und
wollte da die Dinge weitergucken, die ich normalerweise so gucke
und musste dann feststellen,
Nee, das geht nicht, weil Streaming-Dienstleister
hat festgestellt, man ist woanders, als man normalerweise ist
und dann geht das halt nicht mehr.
Und da möchte man dann vielleicht doch
eher nur so auf irgendwo
V4N aktivieren, klicken und dann geht das halt
einfach weiter und
hatte ich nicht, muss ich mir überlegen,
ob ich das nicht vielleicht mal haben möchte
für den Fall.
Ja, auch wenn ihr
einen lokalen Internet-Service-Provider
habt, der vielleicht nicht so auf der Höhe
ist, was seine Peerings angeht, dann könnt ihr
da euch zu einem besseren Internet-Erlebnis
verhelfen, indem ihr einen VPN benutzt.
Ja, genau.
Und wenn ihr das mal ausprobieren möchtet, einfach auf
nordvpn.com slash pythonpodcast gehen
und ausprobieren.
Vielen Dank an NordVPN
für die Unterstützung.
Und dann geht es direkt in das Thema rein.
HTMX.
Was ist denn das?
Oh, das weiß ich auch nicht so genau.
Das sind die High-Power-Tools für
HTML, so hat es denn der Mensch
genannt, der das erfunden hat,
um einfach HTML so zu erweitern,
wie es der Standard bis jetzt nicht zugelassen hat.
Also, dass man keinen JavaScript mehr braucht,
um coole, responsivee Sachen im Web zu bauen.
Doch, JavaScript brauchst du schon.
Ja, aber du musst es nicht mehr schreiben, so wirklich.
Ja.
Ja, es wird dann so deklarativ.
Das ist eigentlich schon nicht schlecht.
Es entwickelt sich ja alles,
so ein bisschen in die Richtung spricht.
Ja, vielleicht noch mal ganz kurz, was das so ist.
also, worum es da geht, also
wie machen wir denn normalerweise jetzt Frontend
und Backend? Trennen wir das? Wie war das denn
früher? Und
ja, warum dann
HTMX? Also was ist das so die Idee dahinter? Also ich glaube,
früher war es einfach nur so, du hast
den Server gefragt und der hat dir dann die Webseite fertig
geschickt.
Nein, weil ganz früher,
ganz, ganz früher. Also das ist die Frage,
wie früh hättest du es denn gehabt?
Anfang der 90er oder so. Also ich würde
ja sagen, also das Web ist ja im Grunde
ein sehr neues Modell.
Also insofern, das ist das Gute.
Fangen wir gerade mit dem harten theoretischen Kram
an. Ich frage, ob das so ein guter Einstieg ist, aber
Ich weiß nicht.
Naja, also Web ist ja
eigentlich revolutionär in vielen
Eigenschaften, die es so hat
und halt ganz anders als irgendwie
die Dinge, die man vorher gemacht hat. Was man vorher gemacht hat,
ist halt so Client-Server zum Beispiel.
Oder Remote-Procedure-Calls
oder sowas. Solche Dinge.
Das ist halt alles deutlich älter als das Web.
Und Web ist halt eigentlich was anderes.
Aber ich glaube, die Geschichte erzählen wir gleich.
Und dann, was ist denn Web?
Dann erzähl doch erstmal, was denn Web ist.
Ja, naja, also Web ist halt sozusagen da, ja, wie definiert man das?
Es gibt halt diese, das hatten wir, wie gesagt, in der Restepisode,
diese Dissertation von Roy Fielding, der halt auch an dem Startenarzt
da maßgeblich mitgearbeitet hat mit Tim Berners-Lee.
Und der hat da seine Dissertation irgendwann drüber geschrieben.
Und da definiert er, was er quasi meint, was das ist,
so als REST, also Representational State Transfer oder so.
Aber es ist halt die Frage, ob das so interessant ist.
Ja, ich glaube, das hatten wir ja schon in der REST-Episode.
Ich glaube, da müssen wir es gar nicht sagen.
Ja, im Grunde so ganz, ganz, ganz grob ist es halt irgendwie,
es geht darum, dass der Client im Grunde nicht mehr viel wissen muss.
Dass man halt alles, was an Informationen man braucht,
um halt irgendwie einen Client betreiben zu können,
ja, sozusagen, dass das halt alles mitkommt.
Also sozusagen, dass man halt auch mit einem alten Browser halt zum Beispiel Dinge machen kann, dass man jetzt nicht immer den neuesten Browser haben muss. Bei Client-Server war das Problem früher immer, wenn man da irgendwie was geändert hat, dann muss man immer dafür sorgen, dass auch die aktuellste Version vom Client irgendwie geschippt wird, weil ansonsten funktioniert das halt nicht mehr.
Genau, genau.
Und das ist mit Web, also mit REST und Web ist es eigentlich dann insofern besser, als es halt auch mit alten Browsern noch funktioniert.
Man muss sich nicht darum kümmern, dass die Leute halt immer den aktuellsten Browser haben.
Und es sollte eigentlich mit jedem Browser funktionieren und so.
Und der Browser muss nicht wissen, was da kommt.
Also wenn ich jetzt zum Beispiel, das ist halt genau eine von diesen Geschichten, die halt jetzt bei diesen ganz modernen Geschichten in Anführungsstrichen,
also dieses Single-Page-App-mäßigen Teilen, halt wieder so ist wie ganz, ganz früher.
Jetzt hast du wieder was gesagt, das Single-Page-App-Teil.
Und ich glaube, das müsste so ein bisschen strukturierter sein.
Ich glaube, wir sind ja gerade schon wieder sehr in der Historie drin.
Ja, du hast danach gefragt.
Ja, ja, ich habe ja gesagt, wir müssen das auf jeden Fall später auch noch mal erzählen.
Gerade was Kleinserver und so ist.
Aber der, glaube ich, der entscheidende Unterschied, was hat MX, das halt macht,
diesen modernen Trend, dass man halt eine Single-Page-Application braucht,
um Frontend schön darzustellen, ersetzen kann.
Und zwar mit Auslieferung vom Backend, also so Server-Seiten.
Aber vielleicht will ja Thomas das gerade genau da jetzt noch mal einsteigen.
Also bei HTMLX, das ist sicherlich auf JavaScript basiert, anders kommt man ja in den Browser nicht wirklich rein, um dort irgendwas zu programmieren im Browser, aber Ziel der Übung ist eigentlich, dass der Endanwender, also der Entwickler dann kein JavaScript mehr schreibt oder wenig JavaScript und da wird HTML erweitert um neue Attribute,
Sodass man es HTML klassisch verwenden kann, also wie es eben vor 20 Jahren gemacht wurde, sprich vom Server zum Client kommt HTML, gegebenenfalls auch HTML-Schnipsel oder so ähnliches und man braucht das jetzt nicht in ein JSON-Format erstmal konvertieren und dann am Client wieder aus dem JSON dann irgendwie HTML machen oder DOM-Objekte machen.
Das ist eben so recht revolutionär eigentlich. Revolutionär so hingegen, weil es halt wie das Wort revolutionär ist, am Ende rückwälzend, wird zurückgewälzt auf den Status, wo wir eben vom Server zum Client HTML geschickt haben und geht dann da sozusagen einen anderen Weg.
Und mir persönlich hat es sehr gut gefallen, dass man dann sagt, man hat eben eine übliche HTML-Seite und kann dann kleine Schnipselchen eben interaktiver und ähnliches gestalten und muss sich das nicht so komplizierte Frameworks ranziehen wie React oder Vue. Das kann man mit einfachen Mitteln eine ganze Menge erreichen und das fand ich ganz cool, hab's mal ausprobiert in einem kleinen Projekt. Ja, und da bin ich jetzt hier, um ein bisschen davon zu erzählen.
Ja, ich finde es auch super spannend. Ich habe ja schon seit einiger Zeit davon und genau, also wenn man sich anguckt, was sind die meistgesehenen Talks eben auf sowas wie, das ist auch der Grund, warum wir auf dich Thomas gekommen sind, irgendwie bei DjangoCon EU oder DjangoCon US, das ist halt HTMX, das ist halt ganz heiß irgendwie und ja, ich kann es auch sehr gut verstehen.
Also ich habe irgendwann mal angefangen, mich auch mit diesen Frontend-Frameworks so ein bisschen zu beschäftigen und für mich war damals der Grund, warum ich das gemacht habe, dass ich gerne so ein UI-Anmutung gerne hätte wie bei einer nativen Applikation sozusagen.
Also das hat man ja halt so früher eigentlich bei Webseiten nicht so wirklich gehabt, weil, naja, da hat man immer Request-Response-Cycle irgendwie und das dauert dann halt einfach und man sieht das auf jeden Fall, dass da was passiert und es ist halt nicht so schnell, als wenn man jetzt halt irgendwie eine, irgendwie in Anführungsstrichen klassische App hat, die halt irgendwie lokal auf dem Rechner läuft.
Und für mich war das halt so, das Versprechen dieser quasi Frameworks, dass man das halt auch im Browser so hinkriegen kann, dass man da keine Latenz mehr hat und dass das halt alles super schnell ist und dass sich das anfühlt wie was Natives.
Und das hatte mich interessiert und da dachte ich, okay, naja gut, wenn man das halt so machen muss, dann geht das halt nicht anders und dann muss ich halt dieses komische JavaScript-Zeugs da mitmachen. Okay, aber wenn ich dafür diese UI-Geschichte kriege, dann ist es das ja vielleicht wert.
Weil das ist ja tatsächlich so ein bisschen so eine nervige Geschichte. Und ja, ich dachte eigentlich immer, der Grund, warum das bei normalen Web-Anwendungen oder Webseiten so ein Problem ist, lag an diesem Request-Response.
weil es dauert halt irgendwie, je nachdem, wo ein Server
steht, hat man allein Latenz
bei einem Request von, weiß ich nicht,
mindestens mal so 50 Millisekunden oder sowas
und ich dachte, das liegt dann halt, das
führt dann schon dazu, dass man das irgendwie dann,
dass sich das dann langsam anfühlt und
hab dann sogar solche Sachen eingebaut
in meine ersten Versuche mit so
diesen, also ich glaube, das erste
hab ich tatsächlich React irgendwie am Anfang
verwendet und
hab dann immer irgendwie
die Daten für,
ich hatte so eine Liste
von Dingen, wo ich Pagination hatte
und dann habe ich die Daten für die nächsten,
immer für die paar Seiten außen rum,
immer schon gleich mitgefetcht, damit ich die nicht holen
muss, weil ich dachte, wenn ich da auf einen
sozusagen Link
in Anführungsstrichen klicke und dann müssen Daten
geholt werden, dann dauert das ja wieder lange und das will ich ja
gar nicht, sondern ich will, dass das sofort da ist.
Genau. Ja, und
tatsächlich
das habe ich jetzt auch, ich habe jetzt auch mit
HTMLX so ein bisschen rumgespielt oder so und dann habe ich gemerkt,
oh, das ist gar nicht der Punkt, das ist halt schnell genug.
Also wenn das 50 Millisekunden dauert,
dann reicht das vollkommen aus,
dass sich das halt schnell anfühlt.
Und...
Also vielleicht hast du zu viele Daten
dann sonst am Kleinen drin,
die der dann handeln muss, oder?
Nö, nö.
Das ist einfach...
Also meine Vorstellung,
dass das halt daran liegt,
dass die Langsamkeit von dem Netzwerk festkommt,
war so nicht ganz korrekt.
Okay.
Sondern das liegt eigentlich...
An der Interaktivität, oder?
Das liegt daran,
dass das komplette Browserfenster
immer ausgetauscht wird.
Das ist halt der Punkt.
Und dass der Browser teilweise
auch bei komplizierteren Seiten
halt einfach lange braucht,
um das wieder komplett neu zu rendern, was er ja tut.
Ja, aber das Ganze rendern so lange dauert.
Was ich ganz interessant fand von dem, was der Thomas gerade gesagt hat,
war, dass er sagte, man muss das
erst in JSON umwandeln von dem
alten Zustand, damit man es wieder zurückdrehen
kann. Das heißt, so der Urzustand
ist halt ein anderer dann gewesen
als JSON. Was ich jetzt, muss ich sagen, weil ich bin
auch nicht so lange dabei wie ihr,
gar nicht so unnatürlich finde, weil ich zum Beispiel
jetzt aus Django Models immer direkt in JSON reinrendere
oder so und halt diesen Umweg über die
Templates gar nicht so häufig gehen musste.
Deswegen
ist das für mich so ein bisschen Umgewöhnung. Also ich finde
das Django-Template-System sehr angenehm,
weil es halt die ganzen Features von Django
zurückholt, die man sonst verliert, wenn man
halt Js macht. Aber ansonsten
hat es für mich auch so einen Sinn, wenn man halt
diese serialisierten Objekte durch die Gegend schicken kann.
Und deswegen,
also was meintest du denn, wenn du sagst, dass wir
zurückdrehen? Also was wäre für dich denn so die...
Also zurückdrehen, das war eher so
zeitlich gemeint. Also dass man eben
es so ähnlich
macht, wie man es vor 10 Jahren
oder so gemacht hat.
Und das ist witzig, wenn man sich mit Leuten unterhält,
die eben jetzt vor
rund sieben, acht Jahren
oder irgendwas Web-Anwendungen geschrieben haben,
hatten die meistens alle
eine kleine Hilfsbibliothek, die auf
jQuery aufbaut.
Und mit der hatten sie damals so HTML-Schnipsel
irgendwie in bestimmten
ja,
ab und zu hin und her geschickt.
Und alle dachten, oh, das ist
dirty irgendwie und das ist nicht schön.
Als das Angiola dann aufkam, dann dachte man, ah, das ist sauber, weil Jason geht da über die Leitung und deshalb ist das einfach besser, weil es schön ist und sauber ist.
Aber diese Gleichung hat bei mir ein bisschen gebraucht, um dir aus dem Kopf rauszustreichen, dass das eigentlich Käse ist.
Also warum soll das Jason jetzt besser sein oder schöner sein oder irgendwas?
Also es ist viel pragmatischer, HTML-Schnipsel über die Leitung zu schicken.
Ja, und das habe ich bei so einem kleinen oder zwei kleinen Projekten ausprobiert und funktioniert prima.
Und ja, ich kann bloß sagen, dass es auch eine ganze Menge anderer Leute eben sozusagen auch sehen,
die ihr gerade halt Leute, die aus dem eher Backend-Sprachen kommen,
die eben Python oder Ruby oder irgendwas anderes programmieren,
die haben in dem Bereich eben Spaß dran,
weil sie dann in ihrer gewohnten Programmierumgebung bleiben können
und brauchen jetzt nicht da sich diesen großen JavaScript-Stack anzutun.
Sicherlich, das HTMLX selber ist auch in JavaScript geschrieben,
aber das heißt jetzt ja nicht bloß, dass man dann mit JavaScript schreiben muss.
Man kann es einfach, weil es rein deklarativ ist und das finde ich halt sehr schön.
Da gibt es ein paar Attribute, mit denen man das HTML erweitern kann und dann kann man eben auch einzelne Bereiche auf so einer Seite austauschen. Man hat also eine große Seite und dann kann man eben drei, vier Bereiche haben und dann kann man in diesen Bereichen Interaktivität schaffen, indem man dort einen Button hat und dann tut sich aber halt auch bloß nur dieser kleine Bereich austauschen. Und das macht halt die Seite irgendwie, ja, sehr interaktiv.
Ja, ja, das, was ich jetzt, ich habe gestern, vorgestern mal so ein bisschen damit rumgespielt und was ich, ich habe mein altes, meinen alten Use Case mir nochmal quasi versucht damit umzusetzen und das ist halt gar nicht so einen kleinen Teil austauschen, sondern quasi so den Hauptcontent auf einer Seite, also man hat quasi eine Liste von Dingen und zum Beispiel wie bei einem Podcast so die Episoden oder bei einem Blog die Artikel und jetzt paginated man da so durch.
Und das hat, für mich war der Grund früher mal, warum ich gedacht habe, okay, ich muss mir das mal angucken mit den JavaScript-Frameworks, dass das halt dann schneller geht, wenn man das halt irgendwie schon, wenn man da nicht jedes Mal die Seite neu laden muss.
Und das habe ich jetzt mit HTMLX gemacht und auch selbst, wenn man den kompletten Content der Seite austauscht, ist es immer noch sauschnell und man spürt da keinen Unterschied oder man hat nicht das Gefühl, dass man den kompletten Content ausgetauscht hat, sondern erst, wenn man tatsächlich die komplette Seite austauscht, dann wird es langsam.
Ja, also Latenz ab so 100 Millisekunden merkst du halt dann
und vorher ein bisschen drunter, also unter 50 oder
ist auch super. Da merkt man das eigentlich nicht und das
kann man durchaus schaffen, da drunter zu bleiben und das ist
natürlich dann, und da dachte ich so, als ich das gemerkt
habe, so okay, dass dieser Use-Kit geht auch damit,
dachte ich so, wow, okay, dann
entfällt für mich eigentlich der
Grund für diese JavaScript-Dinger
und dann. Also was mich halt noch interessieren würde,
was ich jetzt noch nicht genau gesehen habe, aber es liegt wahrscheinlich
daran, dass ich das nicht so eingebaut habe, kann ich das
trotzdem so in Komponenten strukturieren, wie
ich mir das vorstelle aus dem Vue.js raus
und wie läuft das mit den ganzen
netten Animation-Plugins
und sowas ganzes irgendwie, muss ich
das dann kleinteilig einbauen vom Server, hängt das dann
drüber und wie werden die Sachen da wieder
reingerendert, das habe ich immer noch nicht so ganz begriffen, weil
also Vue.js rendert das ja auch irgendwie
im Hintergrund einmal durch
und tauscht dann die Teile aus
im DOM
und auf welcher Ebene muss ich das denn machen?
Ja, man hat ja
die ganz normalen HTML-Tags,
also wenn du eine Seite hast
und da sind irgendein
drei interaktive Bereiche
drin, dann wäre es
eigentlich sinnvoll, du machst eine große Seite
und dann da dreimal
ein Form-Tag zum Beispiel
und wenn du ein Submit
für dieses Form macht, also für eins dieser
Forms, dann werden
die Daten dieses einzelnen,
dieses einen Forms zum Server geschickt
und kriegst die Antwort wieder zurück.
Also dann, die Komponenten
sind sozusagen HTML-Tags.
Ja, also
Also wenn du meinst, dass du sowas hast, also eben Vue und React, die machen das, da ist ja genau das, das ist ja ein ganz anderes Modell und wahlweise je nachdem aus welcher Geschichte man kommt, selber kommt es ein moderneres oder älteres, also eigentlich würde ich sagen, ist es halt ein ganz altes Modell, das ist halt eigentlich Client-Server und das ist eigentlich eher so Remote-Procedure-Call und der Client, der State bei den sozusagen in Anführungsstrichen modernen, aber eigentlich architekturmäßig alten,
Anwendungen, die halt so ein bisschen
wie die Client Server, der State der Applikation
liegt halt in JavaScript, deswegen
musst du auch, musst View das rendern, deswegen gibt es
die Tablet-Sprache in, also JSX
in React und so. Aber genau
an der Stelle müssen wir jetzt vielleicht nochmal in die Historie
gehen, weil ich glaube, jetzt haben wir so ein bisschen die kleine Einleitung gemacht,
aber das wäre jetzt genau nochmal interessant zu wissen,
was ist denn jetzt genau der Unterschied
zwischen RPC
und Client Server und
Naja, also auch der Unterschied
sozusagen zwischen JSON und HTML,
ich muss auch sagen, ich finde
JSON, ehrlich gesagt, so als
Entwickler viel angenehmer,
um damit zu arbeiten, als jetzt sowas wie
XML oder HTML oder sowas.
Oder überhaupt Markup Languages.
Einfach deswegen, weil JSON
halt viel einfacher ist.
Zum Beispiel, also einer der wesentlichen Unterschiede,
ein bisschen subtil, aber tatsächlich ist es halt das,
was einem dann so extrem
auf die Füße fallen kann oder
was halt sehr viel Aufwand erzeugt, ist halt
XML oder
oder HTML, das ist halt ein Dokumentformat.
Das ist halt nicht so, dass das einfach
nur Daten sind.
Das Gute ist natürlich auch, als Backend-Entwickler kann man natürlich sagen,
wenn man sich mit dem Pixel-Schubser beschäftigt, sichert sich Frontend
damit, man gibt denen einfach die Daten und dann ist gut,
dann hat man damit nichts mehr zu tun. Das heißt, es gibt ja auch
diese zwei Karton von Entwicklern.
Das führt halt auch dazu, dass es nicht so
mächtig ist,
in gewisser Weise. Also der Hauptunterschied zwischen
Dokument und Daten ist halt
zum Beispiel die Reihenfolge.
Du hast halt in einem Dokument eine Reihenfolge
von Dingen. Da spielt es eine Rolle,
ob Sachen vorne stehen oder hinten.
Wenn ich in JSON irgendwie ein Objekt habe,
dann ist das egal, ob das vorne
steht oder hinten. Das sind immer die gleichen Daten.
Und
das macht es sehr schwer zu handeln,
weil ich dann beim Parsen halt aufpassen muss
und so. Aber auf der anderen Seite
macht es halt auch sehr mächtig. Ich kann halt auch
ja, also
die Dinge quasi, die ich
da anzeigen möchte, direkt drin beschreiben. Das kann ich
so in JSON ja nicht machen. Aber in HTML
kann ich das.
Also in HTML kann ich halt ein Formular hinschreiben,
das halt irgendwie
einen Kontakt zum Beispiel anzeigt oder halt
mir anzeigt, wie ich den ändern kann,
ohne dass ich dazu sonst irgendwas
wissen muss. Ja, genau, also du kannst ja tatsächlich auch den ganzen
Datentyp verändern. Du musst ja jetzt nicht nur irgendwie
ein JSON-Objekt durch ein anderes austauschen,
sondern du kannst ja was ganz anderes dahin stellen auf einmal.
Das heißt so magisch irgendwie.
Ja, genau. Und bei JSON
geht das halt nicht. Bei JSON musst du halt wissen,
was das ist. Ansonsten funktioniert es nicht.
Was mir bei JSON
jetzt nicht so gefällt, dass halt
Datentypen sind recht eingeschränkt. Also ordentliches Timedelta oder irgendwas.
Ja.
Da bin ich persönlich halt großer Freund von Postgres. Das ist enorm,
was es da alles gibt in der relationalen Datenbank. Und da sind meine Daten eben
gespeichert. Da kommen die her. Und dann will ich aus der SQL-Datenbank,
irgendwie das beim Client anzeigen
und da ist es
relativ klar, wenn ich sage, ich mache
aus dem SQL, mache ich
HTML und das schicke ich zum Browser.
Das ist relativ einfach.
Also wenn ich da erstmal aus dem
SQL JSON mache
und dann mache ich aus dem JSON HTML,
ist es einfach ein Schritt mehr.
Und da frage ich mich, warum?
Ja und
es ist halt auch so, dass man dann
die ganzen Probleme aus der alten Welt
wiederbekommt, nämlich zum Beispiel, was ist
wie, also deine
Applikation muss jetzt natürlich das
JSON verstehen und hat
jetzt auch Versionen zum Beispiel. Also was ist denn,
wenn jetzt kommt das JSON
von heute sozusagen,
aus irgendeinem Backend, aus irgendeiner Datenbank
und die Applikation ist
aber ein Jahr alt, weil ich halt jetzt, weiß ich nicht, keine Ahnung,
ein Browserfenster irgendwie,
ich habe einen Rechner irgendwie in die Ecke gelegt,
der dann ein Jahr lang gelingen hat, jetzt klippe ich den wieder auf
und jetzt, was macht die Applikation denn jetzt
mit den Daten?
Das wird wahrscheinlich nicht funktionieren.
Das haut nicht hin und das hat man
ja auch eigentlich in allen
von diesen frontendlastigen
Anwendungen, dass dann ab und zu
so ein Pop-up kommt, bitte Seite neu
laden, weil
neue Software-Update oder irgendwas
anders, so ein Browser-Reload dann sozusagen
wie so ein Software-Update.
Genau, das hat man in dem
HTMX-Fall eigentlich
Ja, das hat man in dem Rest-Web
irgendwie sozusagen Fall.
In dieser Architektur hat man das nicht, weil da gibt es das einfach nicht.
Man kann prinzipiell
auch auseinanderlaufen. Also wenn ich jetzt ein Formular
einmal erstmal mir lade,
ein HTML-Formular,
und dann vergeht wirklich eine Menge,
vergeht eben Zeit und es gibt ein Software-Update
und dann mache ich bei mir einen Post
von meinen Formulardaten, kann das prinzipiell
ja auch gegen den Baum gehen, weil es dann nicht mehr hinhaut
auf Server-Seite.
Wenn sich tatsächlich an der Datenschema
oder so irgendwas geändert hat.
Okay, ja.
Aber tatsächlich, ja, ja gut, okay, insofern.
Ja, wir gehen einfach mal davon aus,
dass man, wenn man Dinge irgendwie jahrelang da liegen lässt,
man nicht davon ausgehen sollte,
dass die einwandfrei so funktionieren wie am ersten Tag.
Ja, ja, okay, aber du kriegst das Problem auch deutlich schneller.
Also du hast halt dieses Problem plötzlich wieder.
Du hast das Problem wieder,
dass du deine Clients aktuell halten musst.
Das war eigentlich sozusagen eine der großen Versprechungen
von Webgeschichten, dass man sagt, das musst du nicht mehr machen.
Also um nochmal zu drücken,
also die alte Client-Server-Architektur bedeutet,
Ich habe eine Hauptanwendung, einen Server, auf dem die ganzen Daten, die ganze Datenbank liegt und die Clients, die selbstgeschriebene Anwendungen sind, die auf anderen Rechnern laufen, die dann halt mit dem Server kommunizieren, die halt eine bestimmte Version haben.
Und wenn ich jetzt irgendwas Neues veröffentliche, dann muss ich dafür sorgen, dass der jeweilige Client sich ein Update herunterlädt, seine Applikation aktualisiert, um wieder mit dem Server reden zu dürfen.
Der Kern der Applikation ist eben nicht auf dem Server, sondern der Kern der Applikation ist halt auf dem Client. Und vom Server kommen nur Daten.
Okay, also der Kern der Applikation bedeutet tatsächlich, ja, okay.
Der State der Applikation, die Logik.
Jetzt hast du schon wieder State gesagt.
Ich glaube, das haben wir auch noch nicht so richtig beschrieben.
Was ist denn ein State überhaupt?
Also die Wahrheit vielleicht über das, was gerade ist.
Ja, also sozusagen die Information, wenn du jetzt eine Liste von Kontakten hast,
zum Beispiel irgendwie in einer Applikation, wo liegt diese Liste?
wie hast du die sortiert, welche hast du wieder rausgeschmissen
und wer kennt das? Kennt das
der Client selber oder kennt
das auch oder nur der Server?
Und das ist der Unterschied. Ja, quasi bei
Client-Server liegt es halt beim Client.
Ja, oder es könnte auch vom Server liegen. Also der große
Unterschied zu Web ist jetzt sozusagen,
okay, jetzt rede ich über Dinge, von denen ich keine Ahnung habe,
aber der große Unterschied ist halt, das liegt
halt in dem
HTML selber.
Das ist halt der große Unterschied
zu allem, was früher war. Das ist halt sozusagen dieser
revolutionäre Schritt. Das
hat man vorher, soweit ich weiß,
noch nie gemacht.
Und das ist neu in HTML.
Und mit REST, sozusagen.
Na gut, ich kenne
auch die Frage, was
man will. Also, ob man jetzt so
eine Seite will,
eine Seite, die sich eben super
schnell lädt, weil der Nutzer
bei Google was danach gesucht hat und
dann folgt er dem Link, der ihm angezeigt
wird und dann, zack, will er die Seite da haben
und will die Seite geöffnet haben und sehen.
Und da ist halt ganz wichtig,
dass, ja,
was jetzt Google mit den Web-Visals oder
irgendwas so abprüft, dass zack,
diese First-Time-User-Experience gut ist,
zack, die Seite soll sich schnell laden.
Und witzigerweise gibt es
ein Produkt von dem gleichen
Großkonzern, Google,
zum Beispiel Gmail.
Und wenn ich Gmail starte, sehe ich erstmal
einen Wartebalken.
Das geht mir natürlich als Nutzer eigentlich
Eier auf den Keks.
Sehe ich erstmal, wie sich die ganze
Anwendung lädt und das will ich
nicht. Also ich will im Endeffekt, will ich auch
gar nicht so eine Native GUI
im Web haben eigentlich.
Ich will zack, dass die Seite da ist.
Und
drum ist die Frage eigentlich,
was man will. Sicherlich gibt es Anwendungen,
gibt es Anwendungen, die tut man
als Anwender eben morgens starten
und die tut man abends dann wieder schließen
oder so.
Dann ist es okay.
Was ich will, ist ein Nutzererlebnis.
Also ja, das ist natürlich schon, dass es schnell da ist.
Es muss schnell irgendwas passieren.
Aber ich brauche nicht direkt sofort den ganzen Content,
sondern ich will da so reingeführt werden,
dass ich willkommen bin, dass ich eingestimmt werde,
auf was da funktioniert.
Na gut, aber das liegt halt im Use Case.
Da denke ich drauf an, was das für eine Applikation ist,
die man da, oder was der Use Case ist.
Und für die allermeisten Web-Use Cases ist es halt wichtiger,
dass man quasi von, dass man
das auch, dass man zum Beispiel auf Links klicken kann
und dann halt auf eine andere Seite kommt und da irgendwas macht.
Ja, genau, dass man halt einfach was
Und das geht ja auch mit
diesem Modell, dass dein
Client halt irgendwie
eine richtige Applikation ist, funktioniert das
halt nicht mehr. Das bricht halt
die Links im Web im Grunde, weil
wenn du jetzt hinter jedem
Link erstmal irgendwie ein paar Megabyte
großes JavaScript-Wandel liegt, was du laden
musst und dann erstmal ein Ladebalken eingezeigt wird
und dann ich initialisiere die Applikation,
dann macht es keinen Spaß mehr, auf Links zu klicken.
Also das mit den Links und dass man von einer Seite auf die andere kommt,
das funktioniert nur, wenn da nicht jedes Mal megabyteweise Zeugs rüberkommt
und initialisiert werden muss und nicht irgendwie ein komplexes User-Interface hochgefahren wird,
sondern wenn es halt was Einfaches ist.
Auf der anderen Seite ist natürlich diese Vernetzung auch total interessant und cool.
Ja, ich meine, die großen
Web-Frameworks, die
wie React und Vue, die haben das ja auch erkannt
und jetzt versuchen die
serverseitig zu rendern.
Dann gibt es dieses mit Hydration und
Dehydration oder
Serverseit-Rendering und den ganzen Späßen.
Moment, was ist Hydration, was ist Dehydration,
was ist Serverseit-Rendering in dem Fall?
Gemeint?
Naja, also du benutzt im Grunde
Node.js auf dem Server, um halt
dein, also du hast ja
meistens dann auch so eine Template-Sprache, so ähnlich wie
Django-Templates bloß halt in JavaScript, also
JSX oder weiß nicht, wie das bei Vue heißt,
keine Ahnung. Und du kannst
das ja jetzt, du kannst es im Browser rendern,
ja, da läuft JavaScript, was seine
Templates nimmt und dann halt
quasi mit den Daten, die es über JSON oder sonst irgendwie bekommt,
halt dann HTML rausrendert.
Du kannst das aber auch auf dem Server rendern. Du kannst
ja da ja Node.js laufen lassen, dann kannst du auch Templates nehmen
und dann halt auch HTML rausrendern.
Und das HTML, was du da rausrenderst, kannst du
auch einfach so an den Kleinen schicken.
Sodass das Rendering halt nicht bei dir im Browser
passiert, sondern auf dem Server. Deswegen Server
Side Rendering. Das ist halt dann für kürzere
Antwortzeiten. Ja, ja, also
dann fühlt es sich für deinen Browser, ist es dann so wie
eine klassische, wie so
eine Django-Webseite oder so und
dann aber schiebt der Server
dir ja doch dann doch irgendwie so ein JavaScript-Bundle
dahin und dann wird das ersetzt und
ich weiß nicht, ehrlich gesagt, ich weiß jetzt auch nicht genau, wie das
funktioniert mit dem Hydration oder so. Genau, aber
was ist jetzt das Hydration? Ich nehme mal an,
dass das ist irgendwie so
sozusagen, dass
dieser reine, das hat ja mal etwas gekriegt,
das ist quasi in Anführungszeichen irgendwie trocken
und weil es halt so statisch ist
und ich nehme mal an, dass sie mit Hydration meinen,
du schickst halt den Bundle dahin
und wenn das Bundle da ist, dann sagst du, okay, jetzt gib mir die Daten
per JSON und dann rendert es das halt auf den
Client selber. Das ist das, was zum Beispiel
bei Vue.js in so Komponenten passiert, wenn da
bestimmte Teile im DOM
getauscht werden, so HTML-Schnipsel von
Antworten vom Server dann auch.
Nee, nee, das muss man bloß, das ist bloß
on top sozusagen, also
das ist bloß, wenn du es optimieren willst, also
das ist bloß für den
Fall, wenn du feststellst, eine Vue-Anwendung,
die ist eben jetzt nicht so schnell
für den First-Time-User,
dann kannst du dieses Hydration-Dehydration
einsetzen, um
diesen ersten Seitenaufruf zu
beschleunigen. Ja, und sozusagen als Browser,
wenn du auf so eine Seite,
wenn du jetzt zum Beispiel Nuxt nimmst bei Vue
und machst da Server-Site-Rendering,
dann dein Browser kriegt einfach nur
HTML und zeigt das an, wie bei jeder anderen Seite
auch.
Für den, der führt kein
JavaScript erstmal aus.
Nur dann später.
Also die Frage ist, wo es gerendert wird.
Bei Server-Side-Rendering wird es auf dem Server gerendert
und bei irgendwann später,
wenn das Bundle da ist, was halt aber
megabyteweise Zeug sein kann, ja das dauert halt,
bis das da ist, dann wird wieder
auf dem Client gerendert und dann werden nur die Daten
per JSON geholt und das ist,
denke ich, das, was mit Hydration gemeint ist.
Und die Sache ist,
es ist ja schön, dass man das alles machen kann.
Und die Frage ist aber, ob man
will. Und da
bin ich eben vielleicht auch
zu alt oder zu steif.
Ich verwende seit Jahren
Python und bin mit der Sprache sehr zufrieden.
Und dass ich jetzt
JavaScript, die Sprache, die mir
eh nicht so 100% sympathisch ist,
jetzt auch noch auf dem Server einsetze
oder irgendwas, habe ich eben
persönlich keinen Bock drauf.
Und darum habe ich
das Schöne ist ja, ich habe da angefangen
im privaten Kontext auch
für jemanden eine Seite machen
wollen und
so ein Bestellsystem
und das Schöne, da hatte ich einfach Zeit
und es war auch kein Druck
irgendwie da und auch keiner, der gesagt
hat, Thomas, nimm die oder jene Tools.
Wenn man da Zeit hat, kann man wirklich mal nochmal recherchieren
und auch sagen, nee, so möchte
ich es jetzt nicht machen, ich will es jetzt so
machen und dann habe ich erstmal ewig
gesucht, bis ich überhaupt was gefunden habe
und durch Zufall bin ich eben auf das
HTMX dann gestoßen. Inzwischen ist es
auch populärer, inzwischen wird man
steuert man selbstständig
drüber. Vor mehr als einem Jahr war das
eben noch recht unbekannt.
Gut, und da war es halt eine coole
Sache und gerade wenn man
halt
sagt, man selber ist in
Backendsprache
damit vertraut,
dann macht das eigentlich großen Sinn,
weil dann kann man das auch sehr
leicht verwalten, diesen Stack.
Ansonsten, ja,
sicherlich kann man das machen. Ich glaube auch, dass das
prima funktioniert mit dem Vue und React
und so alles. Aber wenn
man das selber alles in der Kontrolle haben
will, also ich kenne es selber jetzt beruflich
zum Beispiel, nutzen wir auch
VGS und
das ist dann manchmal so,
dann ist der Frontend-Entwickler
sozusagen oder dass da einer mal krank
oder im Urlaub oder irgendwas und dann klemmt es
Frontend-seitig, obwohl Backend-Kapazität
dabei und dann ist es vielleicht mal andersrum oder
irgendwas. Das ist doch eigentlich
schöner, wenn man da sagt, okay, ich mache wirklich
eben Fullstack vom HTML
bis zur Datenbank, habe ich
alles unter Kontrolle und da finde ich
diese Trennung zwischen Frontend-Entwickler
und Backend-Entwickler, das ist so wie
so eine komische Diskriminierung,
wie, ja,
muss eigentlich nicht sein, also ja.
Ja.
Ja, ja, ich würde auch
sagen, also normalerweise ist diese Unterscheidung
von der Backend eigentlich halt hauptsächlich irgendwie, es gibt halt
Leute, die
JavaScript mögen und es gibt andere Leute, die
JavaScript fullback finden und
das ist halt so schon mal, also
ja.
Alle Leute, die liebe JavaScript-Liebe haben,
die bitte einmal aufzeigen.
Ja, na ja, gut.
Das ist übrigens auch so ein Ding.
Also ich meine, im Grunde die Entwicklung
wird da getrieben von, also weil in der
JavaScript-Welt, und ich höre da ja auch
ab und zu Dinge, da
geht man jetzt sozusagen schon in die Richtung zu
sagen, ah ja, also wir sind jetzt eigentlich
weit genug, warum machen wir nicht JavaScript
also komplett, also auch im Server vor allen Dingen.
Es gibt ja eigentlich keinen Grund mehr, das nicht zu verwenden.
Ich würde sagen, schon, doch gibt es Gründe, das nicht
zu verwenden. Aber
diesen Druck, den gibt es
schon sehr stark.
Aber nochmal vielleicht ganz kurz, ich würde
ganz kurz nochmal
da ansetzen, wo wir eben waren,
weil man kann
jetzt mit diesen Frameworks natürlich auch Server-Side-Rendering machen,
nur das löst die Probleme nicht.
Also wenn
alle Webseiten
irgendwie fette
Dinger wären mit Server-Side-Rendering,
würde das Web so nicht mehr funktionieren.
Das würde kaputt gehen.
Und das ist halt irgendwie, weil du musst
diese Megabyte-Daten ja immer noch durch die Gegend
schieben. Auch wenn das dir jetzt nicht mehr so
auffällt, aber
werden halt dauernd die gleichen
minifizierten JavaScript-Dinger
durch die Gegend geschoben. Wenn du von einer Seite auf die
andere gehst, immer das gleiche Zeug, Megabyte-weise.
Das ist einfach total verrückt.
Weil ich nicht die einzelnen Teile
vom Dom nur tausche?
Ja, weil du musst halt die komplette Applikation
schickst du halt in der Gegend rum.
Ja?
Und die Applikation ist ja in weiten Teilen
immer die gleiche.
Aber so viel ist es ja nicht. Ich meine, es wird ja dann
gecached und ich kann mir vorstellen,
dass die ersten drei Bilder
jeder Webseite dann größer sind
als das ganze JavaScript-Spaß.
Also ich hätte jetzt auch tatsächlich irgendwie
intuitiv gedacht, dass man das halt auch mit VJS zum Beispiel
so löst, dass man dann eben nur
den einzelnen kleinen Bestandteil
dann innerhalb dieser Komponente
neu rendert.
Nee, du musst immer, also ich weiß nicht genau,
es gibt noch so Geschichten,
da bin ich jetzt aber auch nicht vertraut mit, dass du
so dieses Hot-Module, du kannst halt
teilweise mit, es gibt so
Exima-Skript jetzt Module irgendwie auch
und manchmal kannst du halt, musst du
für manche Seiten, kannst du Module nachladen und so,
aber bisher der klassische Weg
war halt, du baust deine komplette
Applikation in einen JavaScript-File und das
lieferst du aus.
Und solange du das nicht hast, geht gar nichts.
Und ja, also wenn deine
Applikation, also ich meine gut,
sie muss nicht über Megabyte groß sein, aber
ja, wenn, also
ist schon groß und
oft ist View
drin oder React und dann halt die
Bibliotheken, die alle verwenden. Und das Zeug wird halt
bei jedem, wenn du auf eine andere Seite gehst,
wird das halt immer mit übermittelt. Und das ist ja
eigentlich vollkommen verrückt ineffizient.
Also das ist ja eigentlich,
tut einem ja weh, wenn man sich das so überlegt.
Das ist das, was das bedeutet.
Eigentlich wollten wir ja über HDMIX reden und nicht über
nicht über Renderfix. Genau, richtig.
Nicht was anderes irgendwie.
Ja, okay.
Genau.
Ja, wie funktioniert das denn bei HTMX?
Ja, wollen wir mal so ein Beispiel besprechen?
Ja, also wir können mal ein Beispiel besprechen.
Am besten, man gibt dann selber mal HTMX einfach in seine bevorzugte Suchmaschine ein
und dann kommt man auf die Seite und da gibt es auch ein paar Beispiele.
Oben in der Kopfleiste ist es zu sehen, ein paar Examples.
Und ein Beispiel ist zum Beispiel Click2Edit. Das ist glaube ich mit das erste. Da hat man erstmal so eine ganz normale HTML-Seite und da unten ist so ein kleiner Block und da steht irgendwie Click2Edit und in diesem Block sieht man irgendwie Name, sage ich mal Peter oder irgendwas oder irgendein Name, Vorname, sogar ein ganz einfaches Nutzerdaten.
Irgendwann kann man hinklicken und wenn man hinklickt, dann tut sich dieser kleine Bereich aktualisieren und man hat ein HTML-Formular.
Dann kann man dieses HTML-Formular eben befüllen und sagen speichern.
Und mit dem Speichern, schwupp, ändert sich wieder dieser kleine Block und der ist sozusagen wieder Read-Only, wie er am Anfang war, bloß mit den aktualisierten Daten.
Und das Ganze funktioniert natürlich so, dass kein, der gesamte Browser immer auf dieser Seite bleibt, also nicht die gesamte Seite wird neu geladen.
Also sprich, würde man irgendwo hingescrollt haben oder irgendwas und es dann unten auf einer Seite machen, würde die Scrollposition oder irgend sowas alles gleich bleiben.
Und da ist die Frage, wie das funktioniert.
Mit dem Klick to edit wird dann der Server kontaktiert und der Server schickt dann ein kleines HTML-Schnipselchen an den Client und entsprechend der Angabe in dem HTML und das HTMLx erweitert im Endeffekt das HTML bloß um ganz einfache neue Attribute.
Anhand dieser Attribute stellt eben diese Library fest, aha, das soll hier eingefügt werden.
Es gibt verschiedene Swap-Methoden, da kann man sagen, innerHTML soll ausgetauscht werden, also das in dem Tag oder outerHTML, sprich das Tag selber soll auch mit ersetzt werden.
Na gut, und dann kriegt man eben dieses HTML-Schnipselchen vom Server und das wird dann durch HTMX dort eingebaut und dann hat man das Formular, kann es befüllen und am Endeffekt passiert der gleiche Spaß wieder.
Ich kann das als Nutzer dann ausfüllen.
Und wenn ich auf Speichern klicke, dann wird eben auch nur dieser kleine Bereich zum Server hingeschickt
und man erhält wieder einen HTML-Schnipselchen, der dort an dieser Stelle eingebaut wird.
Und das Schöne für den Anwender ist, dass es halt super simpel ist.
Man muss dann bloß mit ganz wenigen Attributen sagen, hier, tausche mir bitte dieses oder jenes aus
und dann hat man das Ganze schon, also man muss sich da
nicht mit JavaScript beschäftigen oder so
und ja, das ist
sozusagen diese
Grundidee der Bibliothek, dass man
HTML-Schnipsel
über die Leitung schickt
und das deklarativ im HTML
verfügbar macht.
Ja, sehr spannend, das macht auch solche
Sachen wie möglich, dass man dann,
also das ist auch ein weiteres Beispiel, zum Beispiel
auf der Seite, dass man Infidelscroll machen kann,
dass er dann in diesem HXWeb-Attribut
einfach After End sagt und dann wird das einfach
angehängt, dann das, was man
bekommt und so.
Also da kriegt man eigentlich
den besten Eindruck, wenn man einfach mal diese Beispiele
durchgeht. Genau, das ist
schon super.
Ja, also ich meine, im Grunde, also
eigentlich ist die Idee, also mich wundert, dass
das nicht schon viel früher passiert
ist, ehrlich gesagt. Mir ging es genauso, ich dachte
man, das ist ja genau, von dem ich eigentlich
geträumt habe, gerade vor Jahren, als ich
mit Jake Ferry da so, sag mal, dass du selber
irgendwie was gelöst, irgendwie
und das ist eigentlich die Idee
dieses Deklarativen auch, also das ist eben
das HTML ist da
sehr schön, diese Beschreibungssprache
sicherlich ist es keine Programmiersprache, eine Beschreibungssprache
aber im Endeffekt
geht ja vieles hin in das Deklarative
also man will ja einfach bloß sagen
das soll so und so sein und
dann kümmert sich irgendein anderer Prozess
dann darum, dass das dann
auch umgesetzt wird und so und das macht es im Endeffekt
dann einfacher
Ja und im Grunde behandelt das
eigentlich macht es genau das gleiche, was man
im Browser auf einer Webseite tut, nur
halt nicht jetzt, dass man zum Beispiel
wenn man im Browser halt auf einer Webseite ist, kann man ja
immer nur das komplette HTML
Element ersetzen. Und jetzt hat man sozusagen
per JavaScript in HTMLX
halt die Dinge, die man nur auf dem
einen großen Ding machen kann, kann man jetzt auf allen
kleinen Elementen halt auch machen. Man kann das halt
irgendwie durch was anderes ersetzen.
Man kann, also es ist
normalerweise im Browser lösen halt nur zwei
Events, lösen
halt irgendwie in Requests aus. Das eine ist halt
Anchor-Tag und das andere
ist halt irgendwie Submit, also
Form. Und
es gibt nur Get und Post,
aber es gibt ja noch viel mehr
HTTP-Werben. Es gibt ja noch die Lead-Put-Patch
und das habe ich
mich auch früher gefragt. Also es gab es auch
so bei Jungle-Rest-Framework ja irgendwie bei dieser
Browsable-API und dann wollte ich halt mal
so, da drinnen kann man ja auch
Dinge hinzufügen und so. Ich so, okay, und jetzt
muss ich noch Put testen und so, hm, komisch.
Put geht irgendwie nicht. Wieso geht denn Put nicht?
Und das war mir auch gar nicht klar, dass halt Browser
können halt keinen Put irgendwie
an Zauber schicken, sondern das muss man halt mit JavaScript machen,
weil es geht einfach nicht.
Und es gibt ja eigentlich gar keinen Grund, warum das jetzt
nicht weiter standardisiert wurde. Und HTMX
ersetzt sozusagen das, was da noch fehlt,
durch JavaScript.
Und das ist eigentlich eine sau, sau coole Idee.
Also, bei mir
hat es auch relativ schnell Klick gemacht, nachdem ich
die ersten Beispiele dann mir angeschaut habe.
Und es ist
enorm, wie da auch das
Interesse daran wächst. Also zum Beispiel
im Django, was ich jetzt hier eben
einsetze für die Serverseite,
kann man ja auch auf einer HTML-Seite
mehrere Formulare
dann reintun und mit Präfixen das
dann auswerten und so weiter.
Und das war auch, wenn ich mich da
zurückerinnere, rechter Krampf irgendwie immer.
Und hier ist es
einfach entkoppelt.
Ich kann ja auch auf einer Seite drei Formulare
haben und die submitten sich eben
einzeln individuell. Da brauche
ich da nicht ein großes
Formular machen mit drei
Unterbereichen oder so. Das macht's
auch serverseitig deutlich
einfacher, das zu handeln.
Ja.
Naja, und es ist ja jetzt
tatsächlich auch nicht nur, also
hat demnächst vielleicht zu der Geschichte, dass
der Autor hatte vorher
eine Bibliothek geschrieben als jQuery
Plugin. Das nennt sich
irgendwie intercooler.js.
Daher, das hat auch mit
jQuery relativ viel zu tun.
Ähm, äh, und das war halt dann
quasi auch halt, äh, HTMLX ist jetzt
sogar der Nachfolger davon, der dann halt ohne JQuery
auskommt und diesen ganzen Kram nicht mehr macht.
Ähm, und
äh, was ich auch, äh,
wo ich auch denke, das ist, äh, halt
ein sehr, äh, also
ein breiter Trend, das macht es auch so
interessant, weil es ist halt nicht nur diese eine Geschichte,
es ist nicht nur HTMLX, sondern, äh,
diesen Ansatz verfolgen ganz viele
Projekte in ganz vielen unterschiedlichen Sprachen, ne?
Und, ähm, ich weiß nicht, in
welchem Talk das war, ob das der
von der Jungle Queen US war
oder nee, es war auch, glaube ich, mit TalkPython
to me, Interview
mit dem Entwickler von
HTMX,
sagte er einen Satz, den ich von
unterschiedlichen Leuten aus unterschiedlichen Communities
schon ganz oft gehört habe.
Den habe ich auch schon gehört von Chris
McCord von Phoenix Live View
in der Elexia und ich habe den auch
nochmal woanders gehört und zwar der Satz ist
ja, also ehrlich gesagt, dafür
dass ich kein JavaScript schreiben wollte, habe ich jetzt
ganz schön viel JavaScript geschrieben.
Und das sagen, also das ist halt dieses Thema, so ganz viele Backend-Leute, die eigentlich nie JavaScript schreiben wollten, haben jetzt dann doch viel JavaScript geschrieben, um das loszuwerden.
Und wenn das viele Leute machen und quasi zu einem ähnlichen Ergebnis kommen und das tatsächlich funktioniert, dann wird das wahrscheinlich auch so bleiben und das sieht danach aus, als hätte man da was gefunden, was tatsächlich gut funktioniert und das macht es dann natürlich auch interessant.
Also wenn das jetzt nur eine Geschichte wäre, aber ich weiß nicht, ob mir jetzt die ganzen Namen einfallen, aber in der Ruby on Rails Welt, also wobei HTMX wird ja auch viel mit Ruby on Rails zusammenverwendet, gibt es halt noch Hotwire, also ist auch Akronym für HTML over the wire und Turbolinks, wo halt dann quasi schon die Seite hinter dem Link gefetcht wird, sodass wenn man auf den Link draufklickt, das halt dann direkt da ist.
Dann gibt es eben bei Elixier, in der Elixier-Welt Phoenix gibt es Liveview, wo auch HTML-Snippets halt über einen Websocket geschickt werden. Dann gibt es das in PHP, da heißt das irgendwie Livewire in Laravel.
Und ja, ich weiß es gar nicht, da gibt es, also auf jeden Fall in vielen unterschiedlichen Communities machen Leute jetzt gerade sowas und ja, das scheint irgendwie ein sehr, sehr breiter Trend zu sein.
Der Schöne an dem HTMX ist halt, dass es sich da vollkommen raushält. Also das kann man mit jedem Backend-Framework nutzen, wie man möchte. Und die anderen, die sind halt oft Backend-spezifisch.
Also bei Ruby on Rails, das ist Hotwire und drum war das, ja, ich habe es mir angeschaut und hätte eigentlich da Interesse gehabt, aber das war dann irgendwie schon wieder irgendwie kompliziert und nicht so einfach. Das HTMX hat es, glaube ich, der Carson Cross hat es da sehr, sehr schön nochmal reduziert von der Komplexität und das ist ja auch im Endeffekt sein Ziel.
sein Ziel ist es, die Komplexität
zu reduzieren, dass es
schön einfach ist.
Und das hat er aus meiner Sicht sehr
gut geschafft. Das sind eine Handvoll
Attribute, die hat man schnell
verstanden oder auch noch nachgeschlagen
und dann kann man da ganz
gut eine Menge Dinge machen.
Man muss natürlich erstmal umdenken, um überhaupt
erstmal reinzukommen, aber
das macht Spaß.
Also das kann ich nur empfehlen.
Ja.
Es gibt auch
eine jetzt von Adam Johnson,
der hat irgendwie ein Ding geschrieben,
Django HTMX,
das ist eben
als Integration jetzt auch in Django als Framework,
aber das macht auch fast nichts, das macht ganz wenig,
das macht nur
sozusagen, es ist eine Middleware dabei,
die an den Requests halt ein Attribut
dran wappt,
ich weiß nicht, ist HTMX oder sowas, wo man dann einfach
nachgucken kann, weil man muss auf der Serverseite
halt unterscheiden können, war das jetzt ein
Request, der von HTMX gekommen ist oder nicht, und dann
je nachdem, erinnert man
die komplette, das ist auch sowas, wenn
ein Browser kein JavaScript kann, das ist gar kein
Problem, das funktioniert einfach so weiter,
weil auf der Serverseite
rendert man halt, wenn man sieht,
okay, es war kein HTMLX-Request, dann rendert man
einfach die komplette Seite raus, ist gar kein Problem.
Und wenn es ein HTMLX-Request war, gut, dann
rendert man halt nur das Fragment raus, das
halt ersetzt werden muss. Und
das heißt, es funktioniert in beiden Fällen und
irgendwie, man hat halt diese Windelware dann, um
halt da quasi sich nicht selber überlegen zu müssen,
wie man jetzt erkennt, ob das jetzt ein HTMLX-Request war
oder nicht und dann hat das ding auch noch so teile drin für damit diese fehler views halt
ordentlich funktionieren also wenn halt ein fragment nicht ordentlich gerendert wird dann
ist wenn man sonst nichts macht ignoriert also wenn dann wenn er zum beispiel 400 zurückkommt
dann sieht man nichts weil hat im extra ist einfach die antworten weg und vielleicht die standard junk
Fehlermeldung aber haben mit einem Stacktrace oder so.
Und genau, dafür ist halt
auch noch so ein bisschen, das ist glaube ich
eine HTMLX-Extension in JavaScript,
die in Django HTMLX drin ist,
die dann halt dafür sorgt, dass man
eben die normale Django-Fehler-
Seite sieht, wenn man, auch wenn
HTMLX-Requests halt außerhalb der Seite schiefgegangen ist.
Genau, also ich habe es mir auch
angeschaut, die Bibliothek,
habe das gleiche festgestellt wie du, es ist relativ
wenig eigentlich drin und
es ist auch wenig notwendig
und darum nutze ich es ja auch gar nicht,
weil ich habe mir für mich dann nochmal überlegt,
wie willst du deine Anwendung gestalten?
Also zum einen unterstütze ich nicht JavaScript-lose Browser.
Also JavaScript ist für meine Seite jetzt notwendig.
Also da ist es schon im 21. Jahrhundert.
Aber das ist dann so, dass ich die URLs trenne.
Also es gibt den ersten Seitenaufruf
und der erste Seitenaufruf bringt eben eine ganz normale HTML-Seite
mit einem HTML-Tag, Head-Tag, Body-Tag
und HTML wieder zu
und ab dann werden eigentlich
meistens Schnipsel
ausgetauscht und
die URLs, wo ich
eben ein Schnipsel bekommen will,
die liefern immer ein Schnipsel
zurück und die werden immer über HTMLX aufgerufen,
sodass ich diese Fallunterscheidung
serverseitig gar nicht habe, von wegen
ist das jetzt ein HTMLX-Request
oder nicht. Es gibt glaube ich auch
von Django Forms, Django Forms Dynamic
oder sowas, dass man da quasi Dango Forms
nutzen kann, direkt als HTML Mix Forms.
Ah, okay. Das kannte ich noch gar nicht.
Das haben wir auch ganz cool dazu.
Cool, ja.
Das heißt, also Dango Forms kennt ihr vielleicht,
da kann man das direkt so einbauen.
Das ist immer ganz hilfreich.
Ja, ich habe letztens auch das irgendwo gesehen, aber ich habe es
mir noch nicht angeguckt.
Interessant.
Ja.
Ja,
wir haben so ein bisschen jetzt, glaube ich, über
die Syntax gesprochen,
das Beispiel und das, was da alles Schönes gibt.
Also man macht meistens halt mit diesem
Swap-Target oder sowas, ja, also
Moment, es gibt Swap und Target, glaube ich, ja.
Also das heißt, wir haben, wir sagen quasi, was
getauscht werden soll, wohin
das getauscht werden soll und
wann es getauscht werden soll.
Genau, richtig, das mit dem Trigger geht sozusagen
los, also bei einem Form muss
man den Trigger jetzt gar nicht angeben, weil bei einem Form
ist es das Drücken auf den
Submit-Button.
Aber es gibt eben andere Trigger, wie du
vorhin Dominik angesprochen hast,
den Revealed-Trigger zum Beispiel.
Also ich kann so einen Infinite-Scroll
implementieren, indem ich ganz unten
eben einen HTML-Schnipsel
habe, mit dem
Trigger Revealed und der
feuert dann, sobald dieses
Schnipselchen in den sichtbaren Bereich
kommt im Browser.
Und das ist natürlich dann relativ cool.
Dann kriege ich das Event, dann hole ich mir
neue Daten, dann kann ich 5, 6, 7
neue Einträge unten
machen. Und wenn der Nutzer nach unten
scrollt, kommt er wieder nach
unten, kommt wieder das Revealed-Event
und er holt sich den nächsten Eintrag. Und dann kann man
ohne eine Zeile
JavaScript zu schreiben, so ein Endless
Scrolling implementieren.
Und das ist ja eine feine
Sache.
Wir haben Swap.
Swap-Message in der HTML tauschen,
Auto-HTML, Target
und Out-of-Band gibt es auch noch.
Also wenn man zum Beispiel,
ich hatte bei mir so eine Art Warenkorb
Und wenn ich jetzt bei dem Warenkorb sage, ich kaufe irgendwas ein und sage, ich möchte davon jetzt mehr haben, mache ich sozusagen einen Plus. Dann habe ich erstmal diesen Bereich aktualisiert, wo der Nutzer geklickt hat, weil ich dort will ich statt einer 1 eine 2 anzeigen. Aber jetzt gibt es vielleicht rechts oben noch irgendwie ein Symbol mit Summe aller Waren im Warenkorb oder so.
mache ich mit dem ersten, also mit dem
eigentlichen Event, tue ich diese eine Zeile austauschen
und out of band kommt dann noch
dazu, bitte tausche
außerdem hier das Element
mit der und der ID aus und dann
kommt dann dort die neue Zahl
für die gesamte Summe.
Das gibt es auch noch, das out of band
Aktualisierung von Daten
angekommen ist. Also man kann eben zusätzlich
out of band, also wenn der Server
weiß, hier ich möchte noch was aktualisieren,
Was aber jetzt nicht in dem aktuellen Schnipsel mit aktualisiert wird, kann der Server out of band noch ein zusätzliches Schnipsel mitschicken, was dann eben am Client aktualisiert wird.
Der Anwendungsfall war eben so eine Art Warenkorb. Man klickt unten bei dem einen Artikel plus, dann weiß ich, jetzt habe ich jetzt zweimal diesen einen Artikel.
Aber oben, rechts oben als Beispiel, ist so ein Einkaufswagensymbol und da will ich die Summe aller Waren anzeigen.
kann ich damit eben das auch aktualisieren.
Also an zwei Stellen. Einmal diese
unten bei der eigentlichen Ware
und oben im Warenkorb.
Das ist auch nur so ein ganz nettes Feature
von dem HTMX.
Ja, was gibt's
sonst noch zu sagen?
Ja, auch solche Sachen, dass man
da fand ich auch nett
sagen kann, okay,
lad mal dieses Element
alle zwei Sekunden nach. Das ist halt auch so ein
Anwendungsfall
für Outer-HTML, da könnte man sich auch fragen, wozu braucht man eigentlich
Outer und Inner? Weil
wenn man das komplette Element ersetzt,
dann werden halt auch die
HTMLX-Attribute mit ersetzt. Und man kann zum Beispiel
dann von der Server-Seite her
steuern, wie lange
irgendwas dann, also man könnte zum Beispiel
machen halt irgendwie einen Newsticker oder sowas
und sagt halt, alle zwei Sekunden
werden da neue Daten geladen.
Und dann kann man von der Server-Seite aber sagen, wenn man das
komplette Element austauscht, okay, man nimmt diesen
Trigger raus, irgendwann
nach zehn Minuten oder so, und dann
halt keine neuen, wird halt
nicht mehr gepollt quasi.
Und dafür muss man dann das komplette Element
ersetzen, dann braucht man halt Auto-HTML.
Ja, also genau, solche Sachen kann man auch
sehr einfach machen.
Was gibt's noch?
Ja, genau,
überhaupt diese Geschichten, wenn vom Server
Sachen kommen, da weiß ich auch noch
nicht so genau, wie das dann, gibt's
Support für Websockets oder solche Sachen?
Ja, ja, WebSocket-Support
gibt's, habe ich aber selber jetzt noch
nicht ausprobiert. Und es wird
aktuell eben die Bibliothek
aktualisiert, dass WebSockets zu einem
externen Paket wird.
Dass man also das gar nicht mehr per Default
drin hat, sondern
dann sich selber nachladen muss.
Ich persönlich finde es gut, das hält die
Bibliothek klein. Ja, die meisten Leute brauchen
das halt nicht, denke ich mal. Genau, und dann kann man es auch
auslagern.
Ja, ich glaube,
Server-Send-Events
Support dafür ist auch irgendwie drin.
Da dachte ich auch so,
habe ich irgendwann letztens nochmal
geguckt, was das denn wirklich ist, weil das habe ich nie so,
das ist zwar schon uralt und gibt es total lang, aber
ich wusste nie so richtig, was das ist.
Aber ja, es ist halt auch eigentlich nichts Besonderes.
Und vor allen Dingen, es belegt halt auf dem Server auch,
man muss halt eine Verbindung offen halten, nur
dass man halt vom Client
aus nichts zurückschicken kann, sondern es ist halt eine
Verbindung, die immer offen bleibt, wo man
vom Server halt irgendwie Daten
an den Client schicken kann.
Aber ja, also mit Django geht das nicht gut.
Aber man muss halt dafür Django Channels halt verwenden.
Ja, genau.
Eine Sache fällt mir noch ein,
mehr so eine allgemeine Sache.
Viele sind ja Freunde dieser JSON-APIs,
weil sie sich dann denken,
ah, super, dann habe ich ja eine API
und damit kann ich zum einen ein Webfrontend machen
und zum anderen kann ich da eine API anbieten
für eine Maschine, Maschinenkommunikation.
Und das ist aus meiner Sicht Blödsinn.
Weil man da zwei ganz verschiedene Anwendungsfälle zusammenwürfelt.
Also bei einer GUI, da will ich super agil sein,
die will ich täglich aktualisieren können,
da will ich täglich deployen können
und da sollen sich auch täglich kleine Änderungen ergeben können.
Weil das den Nutzer in der Regel nicht stört,
wenn das so ein kleines bisschen irgendwie anders ist,
nur ein kleines bisschen verbessert wird
kontinuierlich.
Wenn ich aber eine Maschine zur Maschinenkommunikation
haben, ist sowas wie
A-B-Testing vollkommener Schwachsinn.
Natürlich, ich werde ja nicht
einer Maschine sagen,
du kriegst die API und
der andere Client kriegt
diese APIs und diese Daten.
Das ist ja vollkommen konträre, ganz
verschiedene Anwendungsfälle.
Und drum, das war bei mir
anfangs bei Angular, wo ich dachte, oh cool,
eine API und da kann ich dann
GUI entwickeln und außerdem
eben da einen maschinellen
Zugriff auf dieser Seite haben. Aber es sind eben
zwei ganz getrennte Dinge, die auch
ganz
getrennt behandelt werden sollten.
Und da
könnte man ja dann auch dann sagen, na gut, wenn ich
Maschine-Maschine-Kommunikation machen will,
könnte man ja sowas wie gRPC
einsetzen, was dann im Endeffekt
auch mehr Datentypen unterstützt
und insgesamt optimaler ist.
Jetzt sind wir wieder, wir haben noch nicht genau
RPC erklärt und jetzt kommst du gleich mit gRPC an.
Ich muss erklären, was das ist.
Das gRPC ist
eine Technologie von Google
und das ist ein binäres
RPC, also Remote Procedure Call
Methode
und das ist
sehr effizient und schnell.
Es ist auch
Arschima-basiert, also du musst
klar, der Server
sagt klar, was für Daten er austauscht
und das wird
im Kubernetes-Bereich
oder so ähnlich
dann auch stark verwendet.
Aber halt bei den Web-Entwicklern ist
gRPC noch nicht angekommen und
das wird wahrscheinlich auch noch ein bisschen dauern,
bis das da bekannt
und verstanden wird, um was es da eigentlich geht.
Ja.
Naja, da ist JSON
schon so das Ding, was man...
Also ich meine, es gibt ja im Grunde keinen
wirklichen Grund, warum man jetzt irgendwie...
Außer, dass man halt das JSON irgendwie nahe
liegt, wenn man jetzt
JavaScript macht, aber ansonsten
gibt es ja gar keinen Grund dafür,
dass man könnte halt auch irgendwie
andere
Datenformate halt benutzen.
Bei Jungle REST Framework war das ja auch mal so, da konnte man halt auch
ich glaube, ich weiß nicht, ob das heutzutage noch
jemand macht, aber früher war das halt durchaus
üblich da zu sagen, okay, ich rendere
meinen Kram nicht nach JSON, sondern nach XML.
Oder wie heißt dieses, es gibt auch
ein Binär-JSON.
B-JSON?
JSON-B gibt es.
Ja, nee, das ist, ach, ich hab's wieder vergessen, aber ja, es gibt irgendwie auch eine binäre Variante davon, die man auch mit Jungle Wrestling ganz gut verwenden konnte, da wurde es halt ein bisschen kleiner, aber ja, tatsächlich benutzen aber doch irgendwie alle JSON letztlich.
Ja, aktuell. Ich bin da ehrlich gesagt ganz tiefenentspannt. Also um 2001 habe ich meine Diplomarbeit geschrieben und klar, was war das Thema? XML. Also damals ging alles um XML und auch das HTML sollte XML werden und so weiter. Dann bin ich ja so froh, dass dann dort irgendwie die Vernunft gesiegt hat und das XHTML sich nicht durchgesetzt hat.
und eben, weil das ist
am Endeffekt dann auch nur Krampf, wenn man
das zu sehr in die Richtung treibt
und wie gesagt, damals war
alles mit XML, aktuell
ist alles mit JSON und
da bin ich auch ganz tiefenentspannt, dass da dann
irgendwie auch nochmal was Neues kommt.
So ist auf jeden Fall
die Entwicklung aus meiner Sicht.
Ja, naja, da ist
noch nicht
aller Tage Abend, was diese
jetzt alle auf JSON geeinigt hätten,
das sehe ich auch nicht so.
Ich meine, ehrlich gesagt, ich finde es
persönlich angenehmer als XML. XML war doch mal
ein Stück schrecklicher.
Das ist so ein Grund, wo ich sage, den Computer
will ich nicht anfassen.
Das ist komisch, ganz komisch.
Wirklich.
Ja, klar, da gab es die größten
komischen Sachen wie XSLT
und sowas, aber das ist lange her.
Viel schlimmer als Assembly oder sowas.
Tja, ja. Aber wir haben doch einige Sachen nicht erklärt.
Und zwar, wie hieß der nochmal?
Carsten Gross, glaube ich,
weil er möchte wahrscheinlich vermeiden,
dass man ihn tauern muss.
Sorry.
Jedenfalls hat er so einen Talk gehalten
und da hat er auch viel über Haters gesprochen.
Also Hater, ich habe einen noch.
Entschuldigung.
Das Akronym ist auch ein bisschen unglücklich.
Ja, sehr gut.
Was ist denn das und worum geht es denn da?
Da hatten wir eigentlich schon drüber gesprochen.
Ja, weil da gibt es ja schon Beispiele auch
auf der Seite von htmx.
Ich persönlich kann dazu halt nur sagen,
dass ich es nicht weiß und mich interessiert es auch nicht.
Das ist sein Steckenpferd
und er zählt viel und redet viel.
Aber mir ist es zu abstrakt.
Ich halte mich aus den Diskussionen
da auch raus, was das heißt, was das Hato ist
oder irgendwas.
Für mich ist HTTP greifbar,
HTML ist für mich greifbar und so weiter.
Aber das ist mir dann
zu abstrakt und
da kann ich nicht viel zu sagen.
Wahrscheinlich haben wir
tatsächlich darüber geredet, wenn das halt, also die Übersetzung
von Haters ist
Hypermedia at the Engine of Application State.
Also da geht es so ein bisschen darum, dass halt
tatsächlich die
Quelle der Wahrheit dann
an der richtigen Stelle steht, und zwar
im HTML, und ich weiß auch nicht mehr,
was er mit Hypermedia meint.
Hypermedia ist im
Webkontext HTML.
Obwohl, die Quelle
der Wahrheit ist für mich einfach Postgres.
Das sind die Daten, da kann man den Strom
ausschalten, dann kann man den Strom wieder
anschalten, dann weiß ich, wo meine
Daten sind, die sind im Postgres drin.
Und ja, das ist
dort, das ist eben
meine Perspektive.
Ja, aber genau, gut, das sind dann halt
deine Datenhaltung, aber
der Application State
ist ja jetzt nicht unbedingt in der,
da hast du ja auch noch andere Sachen, da hast du ja auch noch
solche Sachen wie
dein Cache oder du hast halt vielleicht
irgendwelche Queues und
du hast halt auch noch irgendwie eine Session
und ganz viel Zeugs.
Aber klar, natürlich,
also, ja, die Frage ist halt,
ja, also bei alles, was sozusagen im Browser
passiert, ist halt in dem HTML halt irgendwie drin.
Das ist halt so ein Ding, diese HATI
ist Geschichte, aber ja, ich finde das auch
ziemlich kompliziert und theoretisch
und das ist sehr schwer, das zu erklären.
Ich finde das ähnlich wie
Dependency Injection, da kann man sich
das hundertmal erklären lassen und dann
sage ich immer, für mich ist es wie Konfigurierung.
Aber keine Ahnung,
das ist mir zu abstrakt dann einfach.
Ja, weil man
den Talk schaut und erklärt das halt so ein bisschen,
das ist vielleicht ganz gut, wenn man das vielleicht so ein bisschen versteht.
Aber den Talk müssen wir natürlich auch verlinken,
der ist ja natürlich sehr bahnrecht.
Ja, okay.
Ja, aber da am besten hört man sich genau
den Talk dann an und nicht uns, wie wir
darüber reden.
Ja, das ist wahrscheinlich so.
Ich kann da nicht mitreden.
Dann habe ich noch eine Frage irgendwo.
Ich sehe da, wo sind die Grenzen?
Wann sollte man tatsächlich auf React oder Vue umsteigen?
Da kam vorher mal so eine Frage.
Da sehe ich aktuell eigentlich keinerlei Grenzen.
Es erinnert mich so, wie ich vor 20 Jahren mit Python angefangen habe.
Und da war eben so eine Sache in der Firma.
Wollen wir das nicht lieber mit Python machen, anstatt aus einer Mischung aus C, C++ und Shell-Skripten? Und dann hieß es, naja, da konnte ich ja bloß herausboxen, dass wir für den Prototypen Python nehmen. Aber danach muss es sozusagen dann mal richtig gemacht werden.
Richtig, richtig, C++ und so.
Ja, und das war ich sehr froh, dass ich diesen Kompromiss rausboxen konnte.
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 und ähnliches
ist es jetzt auch hier. Jetzt könnte man sagen,
ja dann, wenn man es richtig macht, dann müsste man es doch
in Vue oder React machen, aber
keine Ahnung, ich sehe da jetzt keinerlei
Grenzen.
Ja.
Ich würde auch sagen,
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, dass
einmal alles wieder schön mit der
anderen Technologie bauen muss oder so, dass
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
Web-Anwendungen oder so?
Wenn es eine Web-Anwendung war, das war das natürlich nicht.
Ja, das war damals auch
im Web passiert, aber auch viel
Backend, 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, ist erstmal kein Vertrauen da.
Es ist ja immer so, wenn irgendwas neu ist, ist erstmal kein Vertrauen
da und wenn
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 ist, der Lösung.
Ja, aber ich würde auch sagen,
dass es halt sehr, sehr mächtig, also ich würde
auch sagen, dass es halt vielleicht
einer der Gründe,
warum halt so viel
Frameworks,
ja, Frameworks sind ja auch schon
so Dinge, wo ich jetzt als Entwickler
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.
Bitte? Eins, das du kannst.
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. Jetzt gerade was
irgendwie in dieser Pandemie-Zeit
halt irgendwie, die haben halt Applikationen
so irgendwie halt tatsächlich in C++ geschrieben
oder Java oder sowas,
die auf
Clients laufen,
die 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
eine 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.
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 Build-Prozess und keine Ahnung,
ihre Tools und die Architektur-Patterns, 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 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 da mit 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, du kannst halt irgendwie dann
das quasi genauso, wie du es
vorher gemacht hast, halt 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-Ideen. 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 Web-basiertes?
Ohne, dass du die ein Jahr lang schulen
musst oder keine Ahnung, wie der
Produktivität so beeinträchtigt. Ich würde fürchten, das geht nicht so einfach.
Ja, aber wenn du halt dann ganz verzweifelt
genug bist, denkst du dir, vielleicht geht es mit Angular.
Und dann sagst du... Ich würde sagen, ohne
diese Schulung geht das nicht so einfach.
Ja. Also es ist einfach eine schwierige Situation
auch. Genau.
Also wenn du die Sprache wechseln musst, ist das 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 jetzt 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 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, 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
Native GUI habe ich nur noch den
PyCharm und ansonsten
eigentlich nichts.
Du bist auch einer von diesen PyCharm-Nutzern, okay, verstehe.
Ja.
Ach, finde ich, kann man schon machen.
Du hast ja auch in letzter Zeit viel PyCharm benutzt,
ja, ja, ich habe das 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 Readmes zu irgendeinem anderen Softwareprojekt,
hat er da sehr, sehr, sehr bösartige Dinge über Java gesagt.
Und zwar meinte er so, ja, Java, ach, der spricht nicht von Java,
sondern er sagte, es gibt ja so diese
Programmiersprache, ihr wisst schon, sie reimt sich auf
Lava und
da ist es immer so, die erkennt man
immer daran, dass
also an diesem Moment
peinlicher Stille,
bevor die Lüfter dann losheulen,
das ist halt...
Obwohl, das
Weitscham ist flüssig zu bedienen, also da kann man
echt, findest du?
Braucht man halt den aktuellen
SSD, so und
also doch, läuft eigentlich schon.
Nee, also ich meine vor allen Dingen bei Pyjamas solche Sachen, wie man drückt auf irgendeinen Button oder man macht halt eine Tastenkombination. 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 draufdrücke, da sind so 100 Millisekunden Verzögerung oder so, bevor da irgendwas passiert. Und das nervt fürchterlich, weil das halt, ja.
Ich habe übrigens angefangen,
Jochen, dieses Jahr, und das habe ich mir auch
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, also von den Features
und so, finde ich das total super. Da ist das echt gut.
Es ist
ziemlich complete 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 auch so stylen, wie ich meine anderen Sachen style
und dann macht das auch 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 hab meistens auch, eigentlich gar keine Ahnung,
ich muss das auch mal, es steht auch auf der Liste,
aber kommt nach wie ein dran.
Ja, weil da ist
es ja auch irgendwie ein Krumm drunter und das
funktioniert eigentlich tatsächlich auch ziemlich
gut. Ich würde sagen, tatsächlich,
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.
Ja, kann schon sein, aber
beim Laptop und auch selbst auf meinem
Vorgänger ging es eigentlich gut. Er hatte
mal irgendwie Probleme, also 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 auf dem Wettbewerb.
Kann ich erstmal nicht glauben.
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 leer gesaugt.
Da habe ich die
JVM für Intel
auf meinem
ARM
Mac verwendet.
das lief dann in der Emulation und das war
irgendwie auch ganz schrecklich, das hatte, da dachte ich mir 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.
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 Date-Picker
oder irgendwas. Wenn man danach sucht, da gibt es
tausend Implementierungen
von Date-Pickern.
Aber ich als Web-Anwender 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 Spezifikation
gibst. 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,
weil da kannst du
als einzelner Webentwickler ja auch von nieder springen
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. 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
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 Apps. Gut, okay,
das ist natürlich wieder eine Sache.
Aufhänger HTMX, also
HDMI-XS ist sozusagen
auf keinen Fall
Offline-First oder irgendwas, was man braucht,
die Verbindung zum Server,
das ist sozusagen, ja,
sind ganz zentrale Sachen
an dieser Stelle.
Wenn man dann richtografisch 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.
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
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.
Verzehnfacht
einfach die Komplexität
und den Aufwand.
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
Anbindung, 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 halt eben
die Zwergverbindung.
Und drum klappt das 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 ich habe da jetzt, aktuell verwende ich von Django zum Beispiel das Format unterstrich HTML.
Das finde ich ganz praktisch, weil da eben dieses Save-String ausgewertet wird.
Also da wird alles, was gequotet werden soll, wird automatisch gequotet, außer es ist eben ein Save-String, 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 da nicht immer zwischen zwei Dateien hin und her wechseln, einmal in 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 nicht, 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
gibt. Aber so einen Teil gibt es das nicht.
Ja.
Ja, ja, ja, ja, ne.
Ne, weiß ich auch nicht.
Aber ja, das stimmt.
Ich meine, ja, das ist die Frage, ob das
ist es, alle machen das jetzt halt
über diese Tablet-Geschichten,
aber ob das jetzt
der beste Weg ist, weiß ich
auch nicht.
Also im Kontext von HTMX ist es
bei mir so, ich erstelle kleine Methoden,
die kleine Schnipsel zurückgeben.
Ja, warum brauchen die einen extra Pfeil?
Und dann sind das eben 6-7 Zeilen und für diese 6-7 Zeilen
dann nochmal eine extra Datei
öffnen, das tut dann den Fluss
beim Softwareentwicklung,
bei der Softwareentwicklung irgendwie behindern.
Aber kannst du nicht auch einfach ein Django-Template
quasi in den String reinschreiben und
den dann rendern? Weil du musst es ja nicht in den
File 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 der
seine Variablen bekommen.
Man könnte da vielleicht einfach Globals übergeben.
Ja, aber dann
weiß die IDE 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, auch nicht ideal.
Gibt es noch
Entwicklungsmöglichkeiten an der Stelle?
Ja, aber
genau das hat mich gerade
diese Offline-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,
man kann ja auch,
das ist wieder dann das Problem mit der Paketierung.
Man kann in Python nicht einfach ein Binary bauen,
aber wenn ich mir jetzt so überlege,
SQLite ist ja, also klar,
kann man nicht so concurrent
draufschreiben, 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 Web-Applikation
shippen mit einer SQLite 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 es ja einmal in SQLite schreiben, aber halt auch nochmal
irgendwie übers Netz oder so oder man synchronisiert die Daten
irgendwie.
Das ist natürlich viel möglich, weil prinzipiell kannst du das
also, weil da wird sich auch noch viel entwickeln
nach WebAssembly alles kompilieren und kannst
prinzipiell auch wahrscheinlich Python nach WebAssembly
kompilieren. Ja, das haben ja auch schon Leute gemacht.
Wuppdiwupps, alles paketieren und dann
haust du schon noch ein Postgres hinterher und
dann
lädt der Kunde erstmal hier
50 Megabyte runter.
Und ich meine, obwohl 50 Megabyte
sind auch schnell runtergeladen.
Und dann hast du dort
alles drinnen im WebAssembly
aus. Ich bin
gespannt, was sich da entwickelt.
Ja.
Naja.
Tja, tja.
Kann man auf jeden Fall sich auch noch eine Menge interessante
Dinge überlegen, was man damit alles machen kann.
Ja, ich glaube, im Platinum X
sind wir so ein bisschen fast ruhig.
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 Pausen-Tipps entdeckt
und so, wo mich einige Sachen an Jochen's
Philosophie erinnerten. Und was
ich entdeckt habe, war, du, den
PDM, den kannte
ich tatsächlich noch nicht. Was ist denn das?
Nochmal, jetzt habe ich dich schlecht verstanden.
den PDM, das ist ein Python-Distro-Manager
oder sowas.
Oder was macht der eigentlich? Ich muss mal gucken.
PDM. PDM, ja. Also ein
Paketmanager, den du entdeckt hast. Als Alternative
zu Poetry hast du den beworben.
Beworben habe ich den, glaube ich, nicht.
Ich habe das mal aufgelistet. Also ja, genau.
Genau. Nee, ich war einfach da
unsicher. Genau.
Bei mir ist es öfter 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
seit einer Weile mache ich das so, dann
gehe ich zu GitHub, zu meinem Account, erstelle da ein Repository,
was im Endeffekt aus einer Readme 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 eigentlich fast
ein Zettel für mich, das ich dann da habe und wenn ich die Web-Recherche
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 am Schreibtisch oder so
nicht finden.
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, Karl.
Jetzt ist das M wieder weg.
Das hast du
bei den Python-Tipps gefunden.
Ja, PDM.
Moment.
Python Development Master
heißt es.
Als Alternative für
Poetry. Ich habe noch nicht genau verstanden, wovor das ist.
Deswegen war ich neugierig, weil
wir ja mit Poetry in letzter Zeit so ein paar
Probleme hatten.
Und ob das vernünftig
funktioniert. Aber wenn es
dir nicht sofort einfällt, dann hast du es wahrscheinlich auch gar nicht.
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 tu 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 finde nur, man muss halt
die blöden Bugs fixen, die uns allen auf die Nerven gehen.
Ja.
Also ich bin, wie gesagt, mit den PIP-Tools
quasi auch nicht warm.
Also ich finde, vom User-Interface her ist Poetry
schon deutlich schöner. Das Problem ist nur halt,
es funktioniert nicht.
Ja, aber man muss ja nicht immer alles
auf der Dreck wegschmeißen, wenn sie kaputt ist.
Manchmal kann man sich auch ein bisschen reparieren.
Aber hörst du mal,
ich meine, ich habe
letztens auch 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 tausend oder sowas.
Und das ist ja nur ein einzelner.
Monat einlegen und alle gemeinsam an Poetrys
Verbesserung arbeiten und dann ist das Problem
endlich allemal aus der Welt geschafft.
Tja, tja. Ja, genau.
Offene Issues über tausend, also das ist halt schon, ja.
Und es ist halt nur ein einzelner Typ, der das in seiner
Freizeit macht, ne? Also. Ja, klar, kann man
ihm ja auch keinen Vorwurf machen. Nee, eigentlich nicht.
Überhaupt nicht. Das ist alles prima, ne?
Ja, ja, also ich meine, aber es ist halt so beliebt,
dass halt so Sachen so finden, ne? Und dann
braucht er eigentlich halt Hilfe, ne?
Ja. Ich hab hier
Pip und dann für Sachen
kann man auch Pip-Tools oben drauf nehmen.
reicht erst mal voll aus.
Ja,
PIP-Tools habe ich jetzt auch letztens,
fand ich eigentlich, also das hat auch ganz gut funktioniert,
es ist halt so ein bisschen hakliger zu benutzen,
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 Portree hat halt nicht, aber ehrlich gesagt,
die brauche ich auch nicht. Ja, also
was ich halt eigentlich nur brauche, sind eigentlich
zwei Sachen, PortreeAdd, PortreeRemove,
Pultree Update und Pultree
Install. Ja gut, aber dann bist du ja auch
ungefähr bei dem, was PIP-Tools können, nur
dass PIP-Tools das halt sehr unkomfortabel machen.
Ja, genau.
Naja, gut.
Aber irgendwie ist das
noch nicht aller Tage Abend, was das
angeht, tatsächlich.
Ja, ich weiß nicht, habt ihr noch was?
Habt ihr noch was auf eurer Liste stehen?
Nö, ich bin durch.
Nö, also wir könnten ja noch Pics machen.
Dann kommen die Pics 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 das jetzt mal aufschreiben.
Die Python DevTools, kennt ihr die?
Das ist so
Python DevTools, da kann man sich einloggen.
Das sind ganz einfache Sachen, wie statt Print
ein Debug-Statement in Python, was dann PrettyPrint
macht und so, so einfach so ein paar Kleinigkeiten.
Nö, nutze ich noch nicht.
Nö, kenne ich noch nicht. Wofür nennt man das?
Oder was ist das? Einfach Python.
Ach ja, ich glaube, ich habe es.
Was macht das? Ich glaube, das ist
ein anderes. Guck mal kurz, ist das
Kannst du kurz auf die
doc-help-manual.io irgendwie
Python-DevTools einworten?
Achso. Nee, ist das eine andere?
Minus DevTools
.help-manual.io
Nee, okay, krieg 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, noch ein Pick der Woche. Ich hab meine
.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 jetzt nicht so Python-spezifisch.
Aber auch Virtual Entwrapper
habe ich eingebaut, jetzt nur die Funktion, die ich nutze,
dass es nicht viele sind.
Damit es ein bisschen kompatibler ist, weil
Virtual Entwrapper PowerShell irgendwie nicht so richtig funktioniert hat.
Ja, da habe ich jetzt 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 .files?
Naja, wenn du jetzt auf einer,
du hast einen neuen Account irgendwie auf einer anderen Maschine,
loggst dich da ein,
setzt du gerne deine .files da so wie überall sonst auch.
Genau, ich habe in meinem .files-Repo für die jeweiligen Systeme,
also im Moment ist es halt POSIX und Windows
und Phoenix 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 klont er mir die eigentlich an die richtige Stelle,
die meistens einfach home.dot
files ist.
Dann im Insights-Skript
führt er dann das Simulink-Skript aus, das heißt
der linkt quasi von meinen
Config-Files komplett auf die
Configs von dem Programm, die ich natürlich installieren muss
auch in dem Insights-Skript. Das heißt, er installiert alle
Programme mit Simulink-T und fertig.
Okay, aber
welches Skript ist das dann? Hast du
es selber geschrieben? Ja. Ah, okay.
Ja, weil da gibt es ja dann schon
einige Sachen. Also ich habe bisher
immer .bot verwendet dafür.
Aber das ist mir letztens irgendwie,
als ich, ich weiß gar nicht,
was der 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 gibt.
Vielleicht möchte ich auch sowas benutzen, weiß ich nicht.
Ich habe es alles noch ganz einfach selber geschrieben,
mal so viel ich das halt nicht ist.
Ja, ja, gut.
20 Sim-Links oder was der da setzt
und dann einmal Software mit dem jeweiligen System-Paket-Manager installieren,
den du ja auch auf Windows installieren kannst.
Dann musst du halt nur zuerst den Paket-Manager installieren
und dann ist ja alles eh open source,
dann macht er 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 auch was ganz Tolles, das ist auch in der DotFile
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 Fischshell da sehr dran gewöhnt bin,
weil man sehr viel Zeit sparen kann.
Ja, genau,
und das Ergebnis
das war dann mein
Pick, was ich jetzt versuche zu
verwenden. Also ich bin gerade dabei, das auszuprobieren
und zu gucken, wie ich das so hin
biegen kann, dass es das tut, was ich
gerne davon hätte. Und zwar das Tool heißt
ChessMoi.
ChessMoi. Ja.
ChessMoi, genau.
Und
das
ist so ein Go geschrieben.
Das ist halt so wie so ein, auch eines
von den, wir haben ja momentan ganz
viele System-Tools
macht tatsächlich keine
SimLink-Geschichte, oder macht halt auch unter Umständen
SimLinks, ich glaube aber eigentlich nicht.
Das
guckt sich an, wie der Zustand
deiner aktuellen Verhaltens 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
das Go ist, halt
so ein statisches Binary, was keine
Abhängigkeiten hat, relativ leicht auf jede
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 das Umfeldsein 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 das hat halt auch Anbindung
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 hab ein neues, neues
Ja, und das
ist ziemlich cool und es gibt
How-To's da für alle möglichen Anwendungsfälle,
wo man sich das,
die man sich da angucken kann. Also ich
verwende es jetzt, oder ich probiere damit
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 hatte da noch eine andere Frage
an der Stelle. Ich weiß nicht, ob das jetzt hier hinpasst, aber
wo ich gerade
versuche umzustellen, ist die ganzen Keys, weil du gerade
vorhin geredet hast mit Key-Repos und so,
mit YubiKeys zu schützen,
also eine Zwei-Faktor-Identifizierung da reinzubauen.
Geht das auch
einfach so? Weil ganz ruhig, bei mir
funktioniert es auch so mittelgut.
Also ich habe jetzt meine wichtigsten Applikationen da mit drin,
aber das könnte,
das wäre natürlich noch richtig klasse, wenn ich dann einfach irgendwie an die
richtigen Ställe den richtigen Stick
stecke oder sowas. Ja, ja, das müsste eigentlich
funktionieren. Also
YubiKey ist halt die Frage, wie man das
wie, ja,
ich meine,
ich würde sowieso, ich meine, ich verwende ja
One Password, auch wenn ich das
natürlich irgendwie auch
ein bisschen unangenehm ist, dass er so teuer ist
und dass es so ein substrativistisches 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 Chesmois.
Chesmois, meine Güte, französisch.
Franz-Rosen, ja.
How to...
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 ganze Skripte, dass ich mich alles nicht mehr machen muss,
weil es alles schon automatisch weiß.
Dann muss ich mich an der Struktur halten von meinen .files,
dann irgendwie standardisiert oder so.
Wahrscheinlich, ne?
Ja, mal gucken, vielleicht mag ich das.
Das sieht auf jeden Fall sehr toll aus, dass man einfach sagt,
Chemois und dann die gleiche Line mit install dein Username
und dann einfach nur Chemois update, das ist schon cool.
Ja, ja.
Ja.
Und du?
Ich?
Ja.
Ich nutze da kein Tool.
Also ich hatte da früher mal das wenigstens noch
irgendwie weggesichert oder irgendwie so.
Also speziell noch mal 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 Emacs mal weggewechselt.
Da war das auch noch beim Emacs.
Musste man da eine ganze Menge machen.
Aber jetzt habe ich eigentlich
nichts, was ich da
groß verwalten sollte.
Da musst du jetzt mit deinem Pick
der Folge noch...
Hast du einen?
Nö,
habe ich nicht.
Kein Pies, wo du drüber gestolpert hast,
wo du sagst, das muss die ganze Welt kennen.
Ganz kurz, zum Beispiel
eine Sache, die ich gerade gesehen habe,
wo du sagst, Sachen installieren, wenn man
das macht, also ich habe
das ist eine der Geschichten, die ich gestern, glaube ich, gemacht habe,
schon mal, 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
man kann
bei Mac gibt es ja Homebrew,
nicht Chocolaty, ist es bei Windows,
bei Mac ist es 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...
Update, genau. Dann wird
dieses Skript ausgeführt, zieht sich das
File rein und wenn sich das geändert hat,
dann installiert es das 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 paketierte
Paket-Packages quasi
installieren, wenn ich das dann will.
Aber ja, ich finde das ganz
interessant, weil ich finde, man will vielleicht auf verschiedenen Maschinen auch nicht
immer alle Pakete gleichzeitig, aber egal,
dass das so ein bisschen, ich muss mir das auf jeden Fall mal angucken,
wie so der Use Case davon ist. Mir ist noch was eingefallen,
ich habe das Tool
CopyQ verwendet, also
wie Copy und dann in Q
und das ist ein Keyboard-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 hin und her genommen 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 so eine Art
Rucksack mit dabei hat, da kann man gut alles reingeben.
Also so ein Copy, also Buffer
mit mehreren Buffern halt, das ist 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, über alle
Anwendungen hin. Ja genau, gibt es halt auch irgendwie
ist gut. Sogar auf Windows. Ich habe auch das mal gesucht
für so eine Alternative für Windows und das
funktioniert alles einigermaßen cool.
Ah, schön. Ja, genau. Das ist ganz praktisch.
Ja, sehr gut.
Ah, 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
Speed Up Your Django Tests. Da haben wir bestimmt auch schon
mal drüber geredet. Das ist irgendwie ganz toll.
Wir haben über Tests von HTMX noch gar nicht gesprochen. Das ist mir
eingefallen. Ach, äh...
Ja. 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... Klar, natürlich.
Ja? Ja, du testest das
wie in jedem anderen Video auch. Ach so.
Da musst du gar nichts machen. Das ist ja das Tolle, du musst gar nichts machen.
Ah, okay. Dann hab ich's gesagt.
Ja, das ist
tatsächlich sehr nett. Also dieses Problem wird man auch
los. Dann wollte ich dich nicht weiter bei deinem
Buch picken. Ja, ja, Moment, aber ich würde gerne abschweifen
und nochmal über JavaScript herziehen,
weil das noch nicht genau passiert ist. Also ich hab ja
jetzt in letzter Zeit auch so ein bisschen
Vue, so Vue ist halt das Framework, was ich
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 viel Tests gemacht
und das ist echt, also das ist,
das hat wirklich keinen Spaß gemacht.
Ist das dem Wohl von Jest nicht, diese Clowns-Gaukler-Mütze
auf dem Kopf?
Ich weiß es nicht genau.
Ich weiß nicht, guck mal kurz bitte nach.
Kann sein. Ja, ich musste auch Tests
mit ihr schreiben.
Ja, auf jeden Fall, das war halt echt
oh, also
Also das ist ja jetzt auch quasi gar nicht mehr so neu und so und dann, ich bin mehrfach in Sachen eingelaufen, wo ich dachte, 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-GitHub-Issues, wo seit Jahren Leute sagen, das ist aber nicht so schön hier, was ist denn da los, geht das nicht und dann geht es tatsächlich nicht und zwar immer noch nicht.
Und es ist halt auch, und dann die
Integration mit Vite
ist dann halt schwierig und
also
die Developer-Experience
war eher so mittelmäßig
und genau, ich würde allen Leuten,
die glauben, dass JavaScript-Entwicklung
voll gut ist und dass das noch die Zukunft ist
und dass man das unbedingt auf dem Server machen
möchte, dann die würde ich fragen, also
ihr kennt schon so ordentliche
Web-Frameworks auf dem Server, habt ihr schon mal
verwendet, ja? Habt ihr euch das mal angeguckt,
wie das da so geht?
Wenn nein, guckt es euch mal an.
Aber auch, das wird ja besser.
Du hast ja letztens auch noch eine Sache gelinkt,
Pinja als Ersatz für VX, das ist ja schon
eine Verbesserung. Für den VX-Store, genau.
Mit DevTools-Support und so, das ist ja auch, ja.
Aber das braucht man halt nicht, wenn man das
bei uns übermacht.
Ja, naja,
jedenfalls, genau, da wollte ich noch mal kurz,
genau,
genau, Adam Johnson, der hat
ein neues Buch geschrieben,
Boost Your
Developer
Experience und
genau, ich habe es noch nicht gelesen, weil es ist so frisch.
Es kam jetzt am Montag raus, dass ich es noch nicht dazu
gekommen bin, aber kann man sich
mal angucken. Es ist auf jeden Fall
wahrscheinlich eine Menge tolle Sachen drin. Also es geht halt
um viel, auch jetzt eben solche Dinge
wie halt
Pricometux oder halt
PyUpgrade
und ja,
auch viel Nicht-Django-Zeugs ist da halt auch
drin. Ja, ich kann es auch empfehlen.
habe ich schon gelesen. Ach so, das ist ja gut.
Ja, ich habe es zufälligerweise zugeschickt
bekommen vom Autor,
zum Probelesen.
Und
es ist okay, genau.
Also ich finde es auch schön, also auch das
vorhergehende Buch von ihm,
Speed-Up-Python-Tests.
Ich finde es schön, wie er schreibt,
ganz pragmatisch, also ohne großes
Blablabla, schön.
Ja, lohnt sich.
Ja, ja, ja.
Na gut, dann
noch mit diesen Worten als
Schlusssatz. Bleibt uns doch gewogen und
schaltet wieder rein, das nächste Mal.
Ja, klar. Und ja,
hört uns gerne immer, wenn ihr mögt.
Wünschen euch noch einen schönen Tag, Abend, Nacht, wo auch immer ihr seid.
Und bis dann. Tschüss.
Ciao, ciao. Danke, Thomas.