Ja, hallo liebe Hörer und Hörer, willkommen beim Python-Podcast Episode 38.
Dieses Mal wollen wir etwas über HTMLX sprechen.
Hier ist der Dominik, bei mir ist wieder der Jochen.
Ja, hallihallo, willkommen Dominik.
Und wir haben heute einen neuen Gast, und zwar den Thomas. Hi Thomas.
Hallo, grüß dich.
Jo, hallihallo.
Schön, dass du da bist.
Ja, fangen wir wie immer an mit ein bisschen News aus der Szene.
Ja, oder vielleicht kann sich Thomas kurz vorstellen.
Das wollte ich dann bei HTMLX machen, aber weißt du was, du hast recht.
Eigentlich müssten wir das am Anfang stellen und sagen, Leute, hallo, und man weiß gar nicht, wer das ist.
Deswegen sag doch mal, Thomas, was machst du denn?
Ja, ich mache Softwareentwicklung. Das schon eine ganze Menge Jahre. Habe vor 20 Jahren mal Informatik studiert und vorher schon auch als Kind daran Spaß gehabt. Und ja, mache hauptsächlich eben Webentwicklung mit Python und Django, PostgreSQL und eben seit neuestem auch mit HTMX.
Und ja, Jochen hat mich mal angesprochen, wollen wir nicht einen Podcast machen? Dachte ich, ja, schön, bin ich dabei. Und ja, jetzt bin ich hier.
Sehr schön. Ja, sehr cool.
Ja, okay
Dann geben wir ein bisschen News über
Erstmal ein bisschen News, ja
Ich glaube, ich habe
fast gar nichts aufgeschrieben, oh doch
Python 3.6 ist draußen
End of Life, ich glaube es war am 23.
Dezember oder so
Weihnachtsgeschenk, eure Version ist duplicated
Ja, das heißt
quasi die erste
Version Python 3, wo
viele Leute irgendwie
das Gefühl hatten, das ist jetzt besser als Python 2.
Ist jetzt auch
End of Life. Das heißt, ja, also
krass. Als ich das gesehen habe,
dachte ich so, wow, das ist schon wieder so lange her.
Ich glaube, bei 3.6 habe ich angefangen.
Das ist schon gar nicht so lange her.
3.7 kam dann relativ fix und
ging schnell.
Also meine News, ich habe noch gelesen, dass Python
Programmiersprache des Jahres 21 geworden ist.
Yay! Wir werden
famous und berühmt.
Ganz wichtige News.
Ja, es gab jetzt auch wieder eine neue Version
von diesem TOB-Index,
wo Python auf Platz 1 ist.
Allerdings
muss man dazu sagen,
so wahnsinnig viel
kann man da nicht daraus lesen.
Ja, ist doch eigentlich relativ wurscht.
Ich habe letztens, wo habe ich das gehört?
Ein programmierbarer Podcast war es, glaube ich.
Dass da jemand meinte, das ist eine
niederländische Firma und das, was sie machen, ist,
sie machen irgendwie
neben den Namen der Programmiersprache
Programming dahinter und
googeln dann danach und dann zählen sie
die Anzahl der Suchergebnisse.
Das ist mehr oder weniger, was sie tun.
Und das ist natürlich irgendwie, ja, gut,
ob das jetzt so einem wahnsinnig viel sagt, ist halt
unklar.
Das habe ich von dir noch nicht gehört.
Ja, ich
höre immer so, was es an anderen Podcasts
auch so gibt. Ja, deswegen, vielleicht ist das doch mal
interessant, dass man mal kurz darüber erzählt.
Ja, also, da geht es meistens
so um Frontend-Themen. Also es gibt erstaunlich,
das ist auch sowas, das finde ich immer ein bisschen komisch,
dass es, also es gibt einige
ja, Podcasts,
sich mit dem Thema Programmierung und so beschäftigen,
aber fast alle eher so
Frontend. Also es gibt zum Beispiel
Webwork, äh, nee, nicht Webwork.
Working Draft
heißt einer.
Auch einer der, vielleicht der älteste
Webentwicklungspodcast
und sicherlich einer der bekanntesten.
Auch mit Leuten hier aus
Düsseldorf und
ja, das ist aber auch sehr Frontend-lastig.
Und
genau, programmierbar
ist relativ neu.
ist halt auch sehr frontend lastig.
Folge 116.
Die machen häufig Dinge, ja, aber
achso, vielleicht auch nicht so neu.
Ja, aber gut, auf den Moment werde ich ja gerade sehen.
3. November, 2. November, 10. November, 12. November,
17. November, 24. November.
Also ja, die Pay ist relativ häufig.
Ja, Working Draft hat
irgendwie über 500, 531 sind sie jetzt
irgendwie oder so.
Und die machen einmal die Woche.
Da hast du schon.
Ja, da brauchen wir noch ein bisschen.
Wie sagt jemand mit dem Gameboy,
kann man jetzt in 50.000 Jahren einen Bitcoin
meinen. Ah ja,
okay. Irgendwie so, die
Zahl ist jetzt auch rein aus der Luft.
Ja, und dann gibt es, also was ich auch
manchmal noch höre, ist sowas, also wenn es
deutschsprachige Geschichten sind, Englischsprache gibt es natürlich
endlos jede Menge, aber es gibt noch
sowas wie Softwarearchitektur im Stream.
Höre ich
manchmal.
Und
InnoQ hat ein paar Podcasts,
das ist eine Firma und die hat auch was mit dem, also der
Mensch, der
Software-Aspektoren im Stream macht, der arbeitet da auch.
Jeder hat Wohl.
Und da arbeitet auch jemand, also der
Stefan Tilkoff arbeitet da auch und der
ist auch viel in anderen Podcasts unterwegs. Da habe ich auch
einen Working Graph zum Beispiel.
Mal ein sehr schöner, auch passend zum Thema,
worüber wir gleich reden wollen. Da gibt es eine Episode
zum Thema Single-Page-Apps und
was ist eigentlich REST und so und die ist sehr empfehlenswert.
Oh ja, was eigentlich REST ist, darüber wollen wir auch gleich sprechen
Ja, genau, darüber haben wir auch schon mal
eine Episode gemacht
Ja, aber also so in dem
also ganz kurz muss man es ja gleich wieder erwähnen
weil es ja so ein bisschen heute auch darum geht
Ja, stimmt, dann gibt es
noch, wo wir sind, ist vorne
das ist eigentlich ein sehr super
produziertes Ding, der Titel ist toll
Ja, der Titel ist toll und die Grafiken
sind toll und das sieht alles toll aus
die Website ist toll, aber ja, es ist halt auch ein sehr vorne
entlastiger Ding, die machen halt
auf Streams und ja.
Genau. Und ich
meine, das sind so fast, dann gibt es noch
so ein paar KI-Geschichten.
Die höre ich, da habe ich die Namen jetzt nicht.
Und die höre ich auch sehr unregelmäßig, weil meistens gefällt mir
das gar nicht so gut. Oh, aber das mit dem
Season 4 sieht gut aus. KI in der Industrie, glaube ich,
ist einer. Das gefällt mir echt ganz gut, da bin ich gespannt.
Ja. Ansonsten mehr fällt mir jetzt
ehrlich gesagt nicht ein, was es da auf Deutsch gibt.
Ja. Fällt dir noch was ein,
Thomas, dazu?
Du hast gar nicht so viel Podcasts erzählt
Nö, meine Überlegung gerade war bloß, ob es
im DevOps-Bereich über Kubernetes
oder irgend sowas, also im deutschsprachigen
Raum noch was gibt
Naja, keine Ahnung
Vielleicht gibt es was, aber das ist auch etwas, wo ich
gar nicht nachgucken würde oder weil es mich
gar nicht so sehr interessiert
da glaube ich, würde ich das auch gar nicht mitbekommen
Niko hatte glaube ich so ein, zwei Sachen
für den Niko natürlich
Aber der hat auch schon ein halbes Jahr nicht mehr
neue Folgen released, also weiß ich nicht
von dem habe ich letztens gehört,
da macht er irgendwie so ein Live-Webinar-Ding,
Stream, auch eher so Richtung Stream geht das.
Okay, okay.
Aber ja, stimmt, der macht natürlich,
also Tech-Thiefen, vorher hieß das irgendwie anders,
ja, der macht auch nicht nur
Frontend-Themen, sondern alles Mögliche,
auch so ein bisschen mit Schwerpunkt auf Data Science, aber
ja.
Cool, ja.
Ja, ansonsten weiß ich nicht, gab es in der Python-Welt
irgendwelche Neuigkeiten,
irgendwelche interessanten Dinge?
sonst.
War ja so
Jahrespause, ne?
Ja, Jahreswechsel ist immer ein bisschen ruhiger.
Ja, nö.
Ansonsten weiß ich da auch nichts mehr.
Dann können wir
fast mit dem Thema
nicht früh durch.
Und wie wir ja schon angekündigt
hatten, angedroht, gibt es
nun auch ein bisschen Werbung.
Der Sponsor für diese Episode
ist NordVPN.
Das ist ein VPN-Anbieter
und da könnt ihr etwa auf
vpn.com slash pythonpodcast gehen
und bekommt da 73% Rabatt
auf ein 2-Jahres-Paket
und noch einen Gratis-Monat extra
und genau, wenn euch
das nicht zusagen sollte, könnt ihr das auch
innerhalb von 30 Tagen kündigen
ohne, dass euch da Zusatzkosten entstehen
und ja, könnt euch das mal angucken
ist vielleicht ganz nett, manchmal braucht man das ja schon
also ich war zum Beispiel letztens
im Urlaub und
und wollte da die Dinge weitergucken, die ich normalerweise so gucke und musste dann feststellen,
nee, das geht nicht, weil Streaming-Dienstleister hat festgestellt, man ist woanders, als man normalerweise ist
und dann geht das halt nicht mehr.
Und da möchte man dann vielleicht doch eher nur so auf irgendwo VPN aktivieren klicken
und dann geht das halt einfach weiter.
Und hatte ich nicht, muss ich überlegen, wie ich das nicht vielleicht mal haben möchte für den Fall.
und ja,
auch wenn ihr einen
lokalen Internet-Service-Provider habt, der
vielleicht nicht so auf der Höhe ist, was seine
Peerings angeht, dann könnt ihr da euch
zu einem besseren Internet-Erlebnis
verhelfen, indem ihr einen VPN benutzt.
Ja, genau.
Und wenn ihr das mal ausprobieren möchtet, einfach auf
nordVPN.com slash pythonpodcast gehen
und ja, ausprobieren.
Vielen Dank an NordVPN
für die Unterstützung.
Und dann geht es direkt in das Thema rein.
HTMX.
Was ist denn das?
Oh, das weiß ich auch nicht so genau.
Das sind die High-Power-Codes für HTML.
So hat es denn der Mensch genannt,
der das erfunden hat.
Um einfach
HTML so zu erweitern,
wie es der Standard bis jetzt nicht zugelassen hat.
Also, dass man keinen
JavaScript mehr braucht, um coole,
responsivee Sachen im Web zu bauen.
Na doch, JavaScript brauchst du schon.
Ja, aber du musst das nicht mehr
schreiben, so wirklich.
Ja.
Ja, es wird dann so deklarativ.
Das ist eigentlich schon
nicht schlecht. Es entwickelt sich ja alles so ein bisschen
in die Richtung spricht.
Ja, vielleicht noch mal ganz kurz,
was das so ist.
Wie machen
wir denn normalerweise jetzt Frontend und Backend?
Trennen wir das? Wie war das denn früher?
Und
warum dann HTMX?
Also was ist das so?
Früher war es einfach nur so, du hast den Server gefragt
und der hat dir dann die Webseite fertig geschickt.
Ja...
Nein, weil ganz früher...
Wie früh hättest du es denn gehabt?
Anfang der 90er oder so.
Also ich würde ja sagen,
das Web ist ja im Grunde ein sehr neues
Modell. Also insofern,
fangen wir gerade mit dem
harten theoretischen Kram an.
Ich weiß nicht, ob das ein guter Einstieg ist, aber...
Ich weiß nicht.
Naja, also Web ist ja eigentlich revolutionär
in vielen
Eigenschaften, die es so hat. Und halt ganz
anders als irgendwie die Dinge, die man vorgemacht hat.
vorher, was man vorher gemacht hat, ist halt so
Client-Server zum Beispiel.
Oder Remote-Procedure-Calls
oder sowas. Solche Dinge.
Das ist halt alles deutlich älter als das Web.
Und Web ist halt eigentlich was anderes.
Aber ich glaube, die Geschichte erzählen wir gleich.
Und dann, was ist denn Web?
Dann erzähl doch erstmal, was denn Web ist.
Ja, naja, also Web
ist halt sozusagen
da, ja,
wie definiert man das?
Es gibt halt diese, das hatten wir, wie gesagt,
in der Rest-Episode, diese Dissertation von
Roy Fielding, der halt auch an Startnards da maßgeblich mitgearbeitet hat mit Tim Berners-Lee und der hat da seine Dissertation irgendwann drüber geschrieben und da definiert er, was er quasi meint, was das ist, so als Representational State Transfer oder so. Aber es ist halt die Frage, ob das so interessant ist.
Ja, ich glaube, das hatten wir ja schon in der Restepisode. Ich glaube, da müssen wir es gar nicht sagen.
Ja, im Grunde so ganz, ganz, ganz grob ist es halt irgendwie, es geht darum, dass der Client im Grunde nicht mehr viel wissen muss, dass man halt alles, was an Informationen man braucht, um halt irgendwie einen Client betreiben zu können, ja sozusagen, dass das halt alles mitkommt.
also sozusagen, dass man halt auch mit einem alten Browser
halt zum Beispiel Dinge machen kann, dass man
jetzt nicht immer den neuesten Browser haben muss, also
bei kleinen Server war das Problem früher immer,
wenn man da irgendwie was geändert
hat, dann muss man immer dafür sorgen, dass
auch die aktuellste Version vom
Client irgendwie geschippt wird, weil
ansonsten funktioniert das halt nicht mehr.
Und das ist mit Web,
also mit REST und Web ist es eigentlich
dann insofern besser, als
es halt auch mit alten Browsern noch funktioniert, man muss sich nicht
darum kümmern, dass die Leute halt immer
den aktuellsten Browser haben und
und es sollte eigentlich mit jedem Browser funktionieren und so.
Und der Browser muss nicht wissen, was da kommt.
Also wenn ich jetzt zum Beispiel, das ist halt genau eine von diesen Geschichten,
die halt jetzt bei diesen ganz modernen Geschichten in Anführungsstrichen,
also dieses Single-Page-App-mäßigen Teilen, halt wieder so ist wie ganz, ganz früher.
Jetzt hast du wieder was gesagt, das Single-Page-App-Teil.
Und ich glaube, das müsste so ein bisschen strukturierter sein.
Ich glaube, wir sind ja gerade schon wieder sehr in der Historie drin.
Ja, du hast danach gefragt.
Ja, ja, ich habe ja gesagt, wir müssen das auf jeden Fall später auch nochmal erzählen.
gerade was kein Server ist, aber der
glaube ich der entscheidende Unterschied, was HTMLX
halt macht, diesen modernen Trend,
dass man halt eine Single-Page-Application braucht,
um Frontend schön darzustellen,
ersetzen kann und zwar mit
Auslieferung vom Backend, also so Servers halt dann.
Aber vielleicht will der Thomas das
gerade genau da jetzt nochmal einsteigen.
Ja, also
bei HTMLX, das ist
sicherlich auf JavaScript basiert, anders
kommt man ja in den Browser nicht wirklich
rein, um dort irgendwas
zu programmieren im Browser.
aber Ziel der Übung ist eigentlich, dass der Endanwender, also der Entwickler dann kein JavaScript mehr schreibt oder wenig JavaScript und da wird HTML erweitert um neue Attribute, sodass man das HTML klassisch verwenden kann, also wie es eben vor 20 Jahren gemacht wurde, sprich vom Server zum Client kommt HTML, gegebenenfalls auch HTML Schnipsel oder so ähnliches
und man braucht das jetzt nicht in ein JSON-Format erstmal konvertieren
und dann am Client wieder aus dem JSON dann irgendwie HTML machen oder DOM-Objekte machen.
Das ist eben so recht revolutionär eigentlich.
Revolutionär so hingegen, weil es halt wie das Wort Revolutionär ist,
am Ende wird zurückgewälzt auf den Status, wo wir eben vom Server zum Client HTML geschickt haben
und geht dann da sozusagen einen anderen Weg.
Und mir persönlich hat es sehr gut gefallen, dass man dann sagt,
man hat eben eine übliche HTML-Seite und kann dann kleine Schnipselchen
eben interaktiver und ähnliches gestalten und muss sich
das nicht so komplizierte Frameworks ranziehen
wie React oder Vue. Das kann man mit einfachen Mitteln
eine ganze Menge erreichen und das fand ich ganz cool, habe es mal ausprobiert in einem kleinen Projekt.
und da bin ich jetzt hier, um ein bisschen davon zu erzählen.
Ja, ich finde es super spannend.
Ich höre ja schon seit einiger Zeit davon.
Wenn man sich anguckt, was sind die meistgesehenen Talks auf sowas wie,
das ist auch der Grund, auf den Thomas gekommen ist,
bei DjangoCon EU oder DjangoCon US, das ist halt HTMX, das ist halt ganz heiß.
Ja, ich kann es auch sehr gut verstehen.
also ich habe irgendwann mal angefangen mich auch mit
diesen sozusagen
Frontend Frameworks so ein bisschen zu beschäftigen
für mich war damals der Grund, warum ich das gemacht habe
dass ich gerne so
ja
so ein
UI
Anmutung gerne hätte, wie bei
einer nativen
Applikation sozusagen
das hat man ja halt so früher eigentlich bei Webseiten
nicht so wirklich gehabt, weil
naja, da
hat man immer
Request-Response-Cycle
irgendwie und das dauert dann halt einfach
und man sieht das auf jeden Fall, dass da was passiert und es ist halt
nicht so schnell, als wenn man jetzt halt irgendwie
eine
in Anführungsstrichen klassische App hat,
die halt irgendwie lokal auf dem Rechner läuft
und
für mich war das halt so,
das Versprechen dieser
quasi Frameworks, dass man das halt
auch im Browser so hinkriegen kann, dass man da
keine Latenz mehr hat und dass das halt alles
super schnell ist und dass sich das anfühlt
wie was natives.
und das hatte mich interessiert und da dachte ich,
okay, naja gut, wenn man das halt so
machen muss, dann geht das halt nicht anders und
dann muss ich halt dieses komische JavaScript
da mitmachen. Okay,
aber wenn ich dafür diese
UI-Geschichte
kriege, dann ist es das ja vielleicht
wert, weil das ist ja tatsächlich
so ein bisschen so eine nervige Geschichte.
Und ja,
ich dachte eigentlich immer, der Grund, warum
das bei normalen Web-Anwendungen
halt so ein, oder bei Webseiten
so ein Problem ist, lag an diesem Request-Response,
weil es dauert halt irgendwie, je nachdem wo ein Server
steht, hat man alleine eine Latenz
bei einem Request von, weiß ich nicht,
mindestens mal so 50 Millisekunden oder sowas
und ich dachte, das liegt dann halt, das
führt dann schon dazu, dass man das irgendwie dann,
dass sich das dann langsam anfühlt und
hab dann sogar solche Sachen eingebaut
in meine ersten Versuche mit so
diesen, also ich glaube, das erste
hab ich tatsächlich React irgendwie am Anfang
verwendet und
hab dann immer irgendwie die
Daten für, so, ich hatte
so eine Liste von Dingen, wo ich
Pagination hatte und dann habe ich die Daten
für die nächsten, immer für die paar Seiten außenrum
immer schon gleich mitgeflatscht,
damit ich die nicht holen muss, weil ich dachte, wenn ich da auf
einen
sozusagen Link in Anführungsstrichen klicke
und dann müssen Daten geholt werden, dann dauert das ja
wieder lange und das will ich ja gar nicht, sondern ich will, dass das sofort
da ist. Genau.
Und tatsächlich
das habe ich jetzt auch
mit HTMLX ein bisschen rumgespielt oder so
und da habe ich gemerkt, oh, das ist gar nicht der Punkt, das ist halt
schnell genug. Also wenn das 50 Millisekunden
dauert, dann reicht das vollkommen aus, dass
sich das halt schnell anfühlt.
Also vielleicht hast du
zu viele Daten dann sonst am Kleinen drin, die der
dann handeln muss?
Nö, nö. Das ist einfach, also meine Vorstellung,
dass das halt daran liegt, dass die Langsamkeit
von dem Netzwerk festkommt, war so
nicht ganz korrekt.
An der Interaktivität?
Das liegt daran, dass
das komplette Browserfenster immer ausgetauscht wird.
Das ist halt der Punkt. Und dass der
Browser teilweise auch bei komplizierteren
halt einfach lange braucht, um das
wieder komplett neu zu rendern.
Ja, aber das Ganze rendern, solange dauert.
Was ich ganz interessant fand von dem, was der Thomas gerade gesagt hat, war, dass er
sagte, man muss das erst in
JSON umwandeln von dem alten Zustand,
damit man es wieder zurückdrehen kann.
Das heißt, so der Urzustand
ist halt ein anderer dann gewesen als JSON.
Was ich jetzt, muss ich sagen, weil ich bin auch nicht so lange
dabei wie ihr, gar nicht
so unintuitiv finde, weil ich zum Beispiel jetzt aus
Django Models immer direkt in JSON reinrendere oder so
und halt diesen Umweg über die Templates
gar nicht so häufig gehen musste.
Deswegen ist das für mich so ein bisschen
Umgewöhnung, also ich finde das Django-Template-System sehr
angenehm, weil es halt die ganzen
Features von Django zurückholt,
die man sonst verliert, wenn man halt Js macht,
aber ansonsten hat es für mich
auch so einen Sinn, wenn man halt irgendwie diese serialisierten
Objekte durch die Gegend schicken kann.
Und deswegen, also was meintest du denn damit,
wenn du sagst, dass wir zurückdrehen, also was wäre für dich
denn so die... Also zurückdrehen, das war
eher so zeitlich gemeint, also dass
man eben so
ähnlich macht, wie man es vor
und Jochen unterhalten sich über die Programmiersprache Python
ficken.
Ja, und das
habe ich bei so einem kleinen
oder zwei kleinen Projekten ausprobiert und
funktioniert prima
und
kann bloß sagen, dass es auch eine ganze Menge
anderer Leute eben sozusagen auch sehen,
die gerade halt Leute, die aus dem
eher Backend-Sprachen kommen,
die eben Python oder
Ruby oder irgendwas anderes programmieren,
die haben halt in dem Bereich
eben Spaß dran, weil sie dann in ihrer
gewohnten Programmierumgebung bleiben
können und brauchen jetzt nicht
da sich diesen großen
JavaScript-Stack
anzutun. Sicherlich, das HTML
selber ist auch in JavaScript geschrieben, aber
das heißt jetzt ja nicht bloß, dass
man dann mit JavaScript
schreiben muss. Man kann es einfach, weil es rein
deklarativ ist und das finde ich halt sehr schön.
Es gibt ein paar Attribute, mit denen
man das HTML erweitern kann und dann
kann man eben auch einzelne Bereiche
auf so einer Seite austauschen.
Man hat also eine große Seite und dann kann man eben
drei, vier Bereiche haben
und dann kann man in diesen Bereichen
Interaktivität schaffen, indem man dort
einen Button hat und dann tut sich aber halt auch bloß nur
dieser kleine Bereich austauschen.
Und das macht halt die Seite
irgendwie, ja,
intern interaktiv.
Ja, ja, das was ich jetzt, ich hab
gestern, vorgestern mal so ein bisschen
damit rumgespielt
und was ich, ich hab
mein altes, meinen alten Use Case
mir nochmal quasi
versucht damit umzusetzen und das ist halt
gar nicht so einen kleinen Teil austauschen, sondern
quasi so den Hauptcontent
auf einer Seite. Also man kann quasi eine
Liste von Dingen und zum Beispiel wie
bei einem Podcast so die Episoden
oder bei einem Blog die Artikel und jetzt
paginated man da so durch
und das hat
für mich war der Grund früher mal, warum
ich gedacht habe, okay, ich muss mir das mal
angucken mit den JavaScript-Frameworks, dass das halt
dann schneller geht, wenn man das halt irgendwie
schon, wenn man da nicht jedes Mal
die Seite neu laden muss.
Und das habe ich jetzt mit HTMLX gemacht und auch selbst
wenn man den kompletten Content der
auszutauschen. Es ist immer noch sauschnell und man
spürt da keinen Unterschied.
Oder man hat nicht das Gefühl,
dass man den
kompletten Content ausgetauscht hat, sondern
erst wenn man tatsächlich die komplette
Seite austauscht, dann wird es langsam.
Also Lizenz hast du 100 Millisekunden, merkst du
halt, ein bisschen unter, so unter 50
oder ist schon super. Da merkt man das eigentlich nicht und
das kann man durchaus schaffen, da drunter zu bleiben.
Und das ist natürlich dann, und da dachte ich so, als ich das
gemerkt habe, okay, dieser Use-Kit geht auch
damit, dachte ich so, wow, okay.
Dann entfällt für mich
eigentlich der Grund für diese JavaScript-Dinge
Also was mich interessieren würde
was ich jetzt noch nicht genau gesehen habe
aber es liegt wahrscheinlich daran, dass ich das noch nicht so eingebaut habe
Kann ich das trotzdem so in Komponenten strukturieren
wie ich mir das vorstelle aus dem Vue.js raus
und wie läuft das mit den ganzen
netten
Animation-Plugins und sowas
muss ich das dann kleinteilig einbauen
vom Server, hängt das dann drüber
und wie werden die Sachen da wieder reingerendert
das habe ich immer noch nicht so ganz begriffen
weil also VDS rendert das ja auch irgendwie im Hintergrund einmal durch
und tauscht dann die Teile aus im DOM.
Und auf welcher Ebene muss ich das denn machen?
Ja, man hat ja die ganz normalen HTML-Tags.
Also wenn du eine Seite hast und da sind eben drei interaktive Bereiche drin,
dann wäre es eigentlich sinnvoll, du machst eine große Seite
und dann hat die da dreimal ein Form-Tag zum Beispiel.
und wenn du ein Submit für dieses Form macht, also für eins dieser Forms,
dann werden die Daten dieses einzelnen,
des einen Forms zum Server geschickt und kriegst die Antwort wieder zurück.
Also dann, die Komponenten sind sozusagen
HTML-Tags.
Ja, also wenn du meinst, dass du sowas hast, also eben
Vue und React, die machen das, da ist ja genau das,
das ist ja ein ganz anderes Modell und wahlweise, je nachdem aus welcher Geschichte
und Jochen unterhalten sich über die Programmiersprache Python
und so. Aber genau an der Stelle
müssen wir jetzt vielleicht nochmal einiges hochgehen, weil ich glaube,
jetzt haben wir ein bisschen die kleine Einleitung gemacht, aber
das wäre jetzt genau nochmal interessant zu wissen,
was ist denn jetzt genau der Unterschied zwischen
RPC und
Client-Server und...
Naja, also auch der Unterschied sozusagen
zwischen JSON und HTML,
also ich muss
auch sagen, ich finde JSON
ehrlich gesagt so als Entwickler
viel angenehmer, um damit zu arbeiten,
als jetzt sowas wie XML oder
HTML oder sowas.
oder überhaupt Markup Languages
einfach deswegen, weil JSON
halt viel einfacher ist,
zum Beispiel, also einer der wesentlichen Unterschiede,
das ist ein bisschen subtil, aber tatsächlich ist es halt das,
was einem dann so extrem
auf die Füße fallen kann oder
was halt sehr viel Aufwand erzeugt, ist halt
XML oder HTML
ist halt ein Dokumentformat.
Es ist halt nicht so, dass das einfach nur Daten sind.
Und das Gute ist natürlich auch,
als Backend-Entwickler kann man natürlich sagen,
wenn man sich mit dem Pixel-Schubschrauber beschäftigt,
sichert sich Frontend damit. Man gibt denen einfach die Daten
und dann ist gut, dann hat man damit nichts mehr zu tun.
Das heißt, es gibt ja auch diese Zweigattung von Entwicklern.
Das führt halt auch dazu,
dass es halt nicht so mächtig
ist in gewisser Weise. Also der Hauptunterschied
zwischen Dokument und Daten
ist halt zum Beispiel die Reihenfolge.
Du hast halt in einem Dokument
eine Reihenfolge von Dingen.
Da spielt es eine Rolle, ob Sachen vorne stehen oder hinten.
Wenn ich in JSON
ein Objekt habe, dann ist das egal,
ob das vorne steht oder hinten.
Das sind immer die gleichen Daten.
und ja, das
macht es sehr schwer zu handeln, weil
ich dann beim Parseln halt aufpassen muss und so,
aber auf der anderen Seite macht es halt auch
sehr mächtig. Ich kann halt auch
ja, also
die Dinge quasi, die ich da anzeigen
möchte, direkt drin beschreiben. Das kann ich so in JSON
ja nicht machen, aber in HTML kann ich das.
Also in HTML kann ich
halt ein Formular hinschreiben, das halt irgendwie
einen Kontakt
zum Beispiel anzeigt oder halt mir anzeigt,
wie ich den ändern kann, ohne dass
dazu sonst irgendwas wissen muss.
Du kannst ja tatsächlich auch den ganzen Datentyp verändern.
Du musst ja jetzt nicht nur irgendwie ein JSON-Objekt durch ein anderes
austauschen, sondern du kannst ja was ganz anderes
dahin stellen auf einmal.
Das ist ja so magisch irgendwie.
Ja genau, und bei JSON geht das halt nicht.
Bei JSON musst du halt wissen, was das ist.
Ansonsten funktioniert es nicht.
Was mir bei JSON jetzt nicht so gefällt,
ist halt, die Datentypen
sind recht eingeschränkt.
Ordentliches
Timedelta oder irgendwas.
Ja.
und Python und dann will ich aus dem SQL irgendwie das beim Client anzeigen und da ist es f mich relativ klar wenn ich sage ich mache aus dem SQL
mache ich HTML und das schicke ich zum Browser.
Das ist relativ einfach.
Also wenn ich da erstmal aus dem SQL JSON mache und dann mache ich aus dem JSON HTML,
ist es einfach ein Schritt mehr.
Und da frage ich mich, warum?
Ja und
es ist halt auch so, dass man dann die ganzen
Probleme aus der alten Welt wiederbekommt
nämlich zum Beispiel, was ist wie
also deine Applikation
muss jetzt natürlich das JSON verstehen
und hat jetzt auch
Versionen zum Beispiel, also was ist denn
wenn jetzt kommt das JSON
von heute sozusagen
aus irgendeinem Backend, aus irgendeiner Datenbank
und die Applikation ist aber ein Jahr alt
weil ich halt jetzt, weiß ich nicht, keine Ahnung
ein Browserfenster irgendwie
Ich habe einen Rechner irgendwie in die Ecke gelegt, der dann ein Jahr lang gelegen hat, jetzt kreufe ich den wieder auf und was macht die Applikation denn jetzt mit den Daten?
Das wird wahrscheinlich nicht funktionieren.
Das haut nicht hin und das hat man ja auch eigentlich in allen von diesen frontendlastigen Anwendungen, dass dann ab und zu irgendwo so ein Popup kommt, bitte Seite neu laden, weil neue Software-Update oder irgendwas anderes, so ein Browser-Reload dann sozusagen wie so ein Software-Update.
Genau, das hat man in dem
HTMLX-Fall eigentlich
Ja, das hat man in dem
Rest-Web irgendwie sozusagen
Fall, in dieser Architektur hat man das nicht, weil da gibt es
das einfach nicht
Man kann prinzipiell auch auseinanderlaufen, also wenn ich jetzt
ein Formular einmal erstmal mir
lade, ein HTML-Formular
und dann vergeht wirklich
eine Menge, vergeht eben Zeit und es gibt
ein Software-Update und dann mache ich bei mir
einen Post von meinen Formulardaten
kann das prinzipiell ja auch gegen den Baum gehen, weil
es dann nicht mehr hinhaut auf Server-Seite
wenn sich tatsächlich an der
Datenschema oder so irgendwas geändert hat.
Und ja, okay.
Aber tatsächlich,
ja gut, okay.
Wir gehen einfach mal davon aus, dass man, wenn man
Dinge irgendwie jahrelang da liegen lässt, man nicht davon
ausgehen sollte, dass die einwandfrei so funktionieren wie am ersten Tag.
Ja, ja, okay.
Aber du kriegst das Problem auch
deutlich schneller. Und du hast halt dieses Problem
plötzlich wieder. Du hast das Problem wieder, dass
du deine Clients aktuell halten musst.
Das war eigentlich,
Das ist eine der großen Versprechungen von Webgeschichten, dass man sagt, das musst du nicht mehr machen.
Also um nochmal zurück zu kommen, die alte Client-Server-Architektur bedeutet,
ich habe eine Hauptanwendung, einen Server, auf dem die ganzen Daten, die ganze Datenbank liegt
und die Clients, die selbstgeschriebene Anwendungen sind, die auf anderen Rechnern laufen,
die dann halt mit dem Server kommunizieren, die halt eine bestimmte Version haben.
Und wenn ich jetzt irgendwas Neues veröffentliche, dann muss ich dafür sorgen,
dass der jeweilige Client sich ein Update herunterlädt, seine Applikation aktualisiert,
um wieder mit dem Server reden zu dürfen.
Der Kern der Applikation ist eben nicht auf dem Server,
sondern der Kern der Applikation ist halt auf dem Client.
Und vom Server kommen nur Daten.
Okay, also der Kern der Applikation bedeutet
tatsächlich
der State der Applikation.
Jetzt hast du schon wieder State gesagt,
ich glaube, das haben wir auch noch nicht so richtig
beschrieben. Was ist denn ein
State überhaupt? Also
die Wahrheit
vielleicht über das, was gerade
ist?
Ja, also sozusagen die Information,
und wenn du jetzt eine Liste von Kontakten hast, zum Beispiel
irgendwie in einer Applikation,
wo liegt diese
Liste? Also auch wie hast du die
sortiert, welche hast du wieder rausgeschmissen und
wer kennt das? Kennt das der Client
selber oder kennt das auch oder nur
der Server? Genau.
Und das ist der Unterschied. Ja, quasi bei Client-Server liegt es
halt beim Client. Ja, oder es könnte
auf dem Server liegen, also der große Unterschied zu Web
ist jetzt sozusagen, okay, jetzt rede ich über
Dinge, von denen ich keine Ahnung habe, aber der große Unterschied
ist halt, das liegt halt in dem
HTML selber.
Das ist halt der große
Unterschied zu allem, was früher war
Das ist halt sozusagen dieser revolutionäre Schritt
Das hat man vorher, soweit ich weiß
noch nie gemacht
Und das ist neu in HTML
und mit REST
Ich kenne halt auch die
Frage, was man will
Ob man jetzt so eine
Seite will, eine Seite, die sich
eben super schnell lädt, weil
der Nutzer bei Google was danach gesucht hat
und dann folgt er dem Link, der ihm
angezeigt wird und dann zack, will er die Seite da haben
und will die Seite geöffnet haben
und sehen und da ist halt ganz wichtig,
dass
was jetzt Google mit den Webvices
oder irgendwas so abprüft, dass
zack, diese First-Time-User-Experience
gut ist, zack, die Seite soll sich schnell laden.
Und witzigerweise
gibt es ein Produkt von dem gleichen
Großkonzern, Google,
zum Beispiel Gmail
und wenn ich Gmail starte, sehe ich
erstmal einen Wartebalken.
Das geht mir natürlich als so zu Eichei auf den Keks.
Sehe ich erstmal,
wie sich die ganze Anwendung lädt.
Das will ich nicht.
Im Endeffekt will ich auch gar nicht so eine
Native GUI
im Web haben. Ich will, zack, dass die Seite
da ist.
Und drum ist
die Frage eigentlich, was man
will. Sicherlich gibt es Anwendungen,
die tut man als Anwender eben
morgens starten und die tut man
abends dann wieder schließen oder so.
Da ist ja noch
Das ist okay.
Was ich will, ist ein Nutzererlebnis.
Also ja, das ist natürlich schon, dass es schnell
da ist. Es muss schnell irgendwas passieren.
Aber ich brauche nicht direkt sofort den ganzen Content,
sondern ich will da so reingeführt werden,
dass ich willkommen bin, dass ich
eingeschubt werde, auch was da funktioniert.
Na gut, aber das ist halt, das liegt halt
im Use Case. Da denke ich drauf an, was das für
eine Applikation ist,
die man da, oder was der Use Case ist.
Und für die allermeisten Web-Use
Cases ist es halt wichtiger, dass man
quasi von, dass man das auch
und Jochen unterhalten sich über die Programmiersprache Python
zu klicken. Also das mit den Links
und dass man von einer Seite auf die andere kommt, das funktioniert
nur, wenn es halt diese,
wenn da nicht jedes Mal
megabyteweise Zeugs rüberkommt und initialisiert
werden muss und nicht irgendwie eine komplexe
User,
ein komplexes User-Interface hochgefahren wird, sondern
wenn es halt was Einfaches ist. Auf der anderen Seite
ist natürlich diese Vernetzung auch total
interessant und cool.
Ja, ich meine, die großen
Web-Frameworks, die
wie React und Vue, die haben das ja auch erkannt
und jetzt versuchen die,
serverseitig zu rendern.
Dann gibt es dieses mit Hydration
und Dehydration oder
Serverseitrendering und den ganzen Späßen.
Moment, was ist Hydration, was ist Dehydration,
was ist Serverseitrendering in dem Fall?
Gemeint?
Ja, also du benutzt im Grunde
Node.js auf dem Server, um halt
dein, also du hast ja
meistens dann auch so eine Templatesprache, so ähnlich wie
Django-Templates, bloß halt in JavaScript,
also JSX oder weiß nicht, wie das bei Vue heißt,
keine Ahnung. Und du kannst
das ja jetzt, du kannst es im Browser rendern,
da läuft JavaScript, was seine
Templates nimmt und dann halt
quasi mit den Daten, die es über JSON oder sonst irgendwie bekommt,
halt dann HTML rausrendert.
Du kannst es aber auch auf dem Server rendern.
Du kannst ja da Node.js laufen lassen, dann kannst du auch Templates nehmen
und dann halt auch HTML rausrendern.
Und das HTML, was du da rausrenderst, kannst du
auch einfach so an den Kleinen schicken.
Sodass das Rendering halt nicht bei dir im Browser
passiert, sondern auf dem Server.
Das ist halt dann für kürzere Antwortzeiten.
Ja, ja, also dann
fühlt es sich für deinen Browser, ist es dann so wie
eine klassische, wie so
eine Django-Webseite oder so.
Und dann aber schiebt der Server
ja doch dann noch irgendwie so ein JavaScript-Bundle
dahin und dann wird das ersetzt.
Und ich weiß nicht, ehrlich gesagt, ich weiß jetzt auch nicht genau, wie das
funktioniert mit dem Hydration oder so.
Aber was ist jetzt das Hydration?
Ich nehme mal an, dass es irgendwie so
sozusagen
diese reine, das HTML-Wass gekriegt ist,
ist quasi in Anführungszeichen irgendwie trocken.
Und weil es halt so
statisch ist. Und ich nehme mal an, dass sie mit Hydration
meinen, du schickst halt den Bundle
dahin und wenn das Wandel da ist, dann sagt es, okay, jetzt gibt
man die Daten per JSON und dann rendert es das
halt auf den Client selber.
Dann ist das, was zum Beispiel bei Vue.js in den Komponenten passiert,
wenn da bestimmte Teile
im DOM getauscht werden, so HTML-Stipsel
von Antworten vom Server dann auch.
Nee, das muss man bloß,
das ist bloß on top sozusagen.
Das ist bloß, wenn du es optimieren willst.
Also das ist bloß für
den Fall, wenn du feststellst,
eine Vue-Anwendung, die ist eben
jetzt nicht so schnell für den First-Time-User,
dann kannst du dieses
Hydration, Dehydration einsetzen,
um diesen ersten Seitenaufruf
zu beschleunigen.
Und sozusagen als Browser, wenn du auf so eine
Seite, wenn du jetzt zum Beispiel NUX
nimmst bei Vue und machst da
Server-Site-Rendering, dann dein
Browser kriegt einfach nur HTML und zeigt
das an, wie bei jeder anderen Seite auch.
Für den
führt kein JavaScript
erstmal aus.
Nur dann später. Also
die Frage ist, wo es gerendert wird. Bei Server-Site-Rendering
wird es auf dem Server gerendert und bei
irgendwann später, wenn das Bundle da ist,
was halt aber megabyteweise Zeug sein kann,
ja, das dauert halt, bis das da ist,
dann wird wieder auf den Client gerendert
und dann werden nur die Daten per JSON geholt
und das ist, denke ich, das, was mit
Hydration gemeint ist.
Und die Sache ist, es ist ja schön, dass man das alles
machen kann. Und die
Frage ist aber, ob man es will.
Und da bin ich eben
vielleicht auch zu alt oder zu
steif. Ich verwende
seit Jahren Python und bin mit der Sprache
sehr zufrieden.
und dass ich jetzt JavaScript, die Sprache, die mir eh nicht so 100% sympathisch ist,
jetzt auch noch auf dem Server einsetze oder irgendwas,
habe ich eben persönlich keinen Bock drauf.
Und darum habe ich das Schöne, ich habe da angefangen im privaten Kontext auch,
ich habe für jemanden eine Seite machen wollen und so ein Bestellsystem.
Und das Schöne, da hatte ich einfach Zeit und es war auch kein Druck irgendwie da
und auch keiner, der gesagt hat, Thomas, nimm die oder jene Tools.
Wenn man da Zeit hat, kann man wirklich nochmal recherchieren
und auch sagen, nee, so möchte ich es jetzt nicht machen,
ich will es jetzt so machen.
Und dann habe ich erstmal ewig gesucht,
bis ich überhaupt was gefunden habe
und durch Zufall bin ich eben auf das HTMX dann gestoßen.
Inzwischen ist es auch populärer,
inzwischen steuert man selbstständig zu,
aber vor mehr als einem Jahr war das eben noch recht unbekannt.
Gut, und da war es halt eine coole Sache
und gerade wenn man halt
eh sagt,
man selber ist in einem
Backendsprache damit vertraut,
dann
macht das eigentlich großen Sinn,
weil dann kann man das auch sehr
leicht verwalten, diesen Stack.
Ansonsten, ja, sicherlich
kann man das machen. Ich glaube auch, dass das
prima funktioniert mit dem Vue und React und so alles.
Aber wenn man das selber
alles in der Kontrolle haben will,
also ich kenne es selber jetzt beruflich zum Beispiel,
nutzen wir auch Vue.js
und ja, das ist dann
manchmal so, hm, dann ist der
Frontend-Entwickler sozusagen
oder da ist da einer mal krank oder im Urlaub
oder irgendwas und dann klemmt es Frontend-seitig,
obwohl Backend-Kapazität dabei ist
und dann ist es gleich mal andersrum oder irgendwas.
Ist doch eigentlich schöner, wenn man
da sagt, okay, ich mache wirklich eben
Fullstack vom HTML bis
zur Datenbank, habe ich alles unter Kontrolle
und da finde ich diese Trennung
zwischen Frontend-Entwickler und Backend-Entwickler,
das ist so wie
so eine komische Diskriminierung,
irgendwie, ja,
muss eigentlich nicht sein.
Ja.
Ja, ja, ich würde auch sagen,
also normalerweise ist diese Unterscheidung von
Webpacking eigentlich halt hauptsächlich irgendwie, es gibt halt Leute,
JavaScript mögen und es gibt andere Leute, die
JavaScript free-bail finden und
das war jetzt auch schon mal, also
ja.
Alle, die JavaScript-Liebe haben,
die bitte einmal aufzeigen.
Ja, naja, gut, also ich,
das ist übrigens auch so ein Ding,
Also ich meine, im Grunde die Entwicklung wird da getrieben von, also weil in der JavaScript-Welt und ich höre da ja auch ab und zu Dinge, da geht man jetzt sozusagen schon in die Richtung zu sagen, ah ja, also wir sind jetzt eigentlich weit genug, warum machen wir nicht JavaScript also komplett, also auch im Server vor allen Dingen.
Es gibt eigentlich keinen Grund mehr, das nicht zu verwenden. Ich würde sagen, schon, doch gibt es Gründe, das nicht zu verwenden. Aber sagen wir so, diesen Druck, den gibt es schon sehr stark.
und aber nochmal vielleicht ganz kurz,
ich würde ganz kurz nochmal
da ansetzen, wo wir
eben waren, weil auch
man kann jetzt mit diesen Frameworks natürlich auch
Serversite-Rendering machen, nur das löst
die Probleme nicht. Also
wenn alle Webseiten
irgendwie fette
irgendwie Dinger wären
mit Serversite-Rendering, würde das
Web so nicht mehr funktionieren. Das würde kaputt
gehen. Also und das ist
halt irgendwie, weil du musst diese Megabyte-Daten ja
immer noch durch die Gegend schieben.
Auch wenn dir das jetzt nicht mehr so auffällt,
aber da werden halt dauernd
die gleichen
minifizierten JavaScript-Dinger durch die Gegend geschoben.
Wenn du von einer Seite auf die andere gehst,
immer das gleiche Zeug, megabyteweise.
Das ist total verrückt.
Weil ich nicht die Einzelteile
vom Dom nur tausche?
Ja, weil du musst halt die komplette Applikation
schickst du halt in der Gegend rum.
Ja?
Und die Applikation ist ja in weiten Teilen immer die gleiche.
Okay.
Aber so viel ist es ja nicht. Ich meine, es wird ja dann
gecached und ich kann mir vorstellen,
dass die ersten drei Bilder
jeder Webseite dann größer sind
als das ganze JavaScript-Spaß.
Also ich hätte jetzt auch tatsächlich irgendwie
intuitiv gedacht, dass man das halt auch mit VJS zum Beispiel
so löst, dass man dann eben nur
den einzelnen kleinen Bestandteil
dann innerhalb dieser Komponente
neu rendert.
Ich weiß nicht genau, es gibt noch so
Geschichten, da bin ich jetzt aber auch nicht vertraut mit,
dass du so dieses Hot-Module
du kannst halt teilweise
mit, es gibt so Exima Script jetzt Module irgendwie auch und manchmal kannst du halt,
musst du für manche Seiten, kannst du Module nachladen und so, aber bisher
der klassische Weg war halt, du baust deine komplette Applikation in einen JavaScript-File
und das lieferst du aus. Und solange du das nicht hast, geht gar nichts.
Und ja, also
wenn deine Applikation, also ich meine gut, sie muss nicht über Megabyte groß sein, aber
ja, also es ist schon groß und
und ja, oft ist View drin oder React und dann halt die Bibliotheken, die alle verwenden
und das Zeug wird halt bei jedem, wenn du auf eine andere Seite gehst, wird das halt immer mit übermittelt.
Und das ist ja eigentlich vollkommen verrückt ineffizient.
Also es ist ja eigentlich, tut einem ja weh, wenn man sich das so überlegt.
Eigentlich wollten wir ja über HDMIX reden und nicht über Render.
Nicht was anderes irgendwie.
Ja, okay.
Genau.
auf.
Ja,
wie
funktioniert das denn bei
HTMX?
Ja, wollen wir mal so ein Beispiel
besprechen?
Ja, also wir können mal ein Beispiel
besprechen. Also am
besten, man gibt dann selber mal
HTMX einfach in seine bevorzugte
Suchmaschine ein und dann kommt man
auf die Seite und da gibt es auch ein paar Beispiele
oben in der Kopfleiste ist das zu sehen,
ein paar Examples und
ein. Beispiel ist zum Beispiel Click2Edit. Das ist, glaube ich, mit das erste. Da hat man erstmal so eine ganz normale HTML-Seite und da unten ist so ein kleiner Block und da steht irgendwie Click2Edit und in diesem Block sieht man irgendwie Name, sage ich mal, Peter oder irgendwas oder irgendein Name, Vorname, sogar ein ganz einfaches Nutzerdaten irgendwie. Da kann man hinklicken und wenn man hinklickt, dann tut sich dieser kleine Bereich aktualisieren und man hat einen HTML-Block.
HTML-Formular. Dann kann man dieses HTML-Formular eben befüllen und sagen speichern und mit dem
Speichern, schwupp, ändert sich wieder dieser kleine Block und der ist sozusagen wieder Read-Only,
wie er am Anfang war, bloß mit den aktualisierten Daten. Und das Ganze funktioniert natürlich so,
dass kein, der gesamte Browser immer auf dieser Seite bleibt, also nicht die gesamte Seite wird
neu geladen. Also sprich, ich würde mal irgendwo hingescrollt haben oder irgendwas und es dann unten
auf einer Seite machen, würde die Scrollposition oder irgend sowas alles gleich bleiben.
Da ist die Frage, wie das funktioniert.
Mit dem Click to Edit wird dann der Server kontaktiert und der Server schickt dann ein kleines HTML-Schnipselchen an den Client
und entsprechend der Angabe in dem HTML und das HTMLx erweitert im Endeffekt das HTML bloß um ganz einfache neue Attribute.
anhand dieser Attribute stellt eben diese Library fest, aha, das soll hier eingefügt werden.
Gibt es verschiedene Swap-Methoden, da kann man sagen, innerHTML soll ausgetauscht werden,
also dass in dem Tag oder outerHTML, sprich das Tag selber, auch mit ersetzt werden.
Und dann kriegt man eben dieses HTML-Schnipselchen vom Server und das wird dann durch HTMLX dort eingebaut.
und dann hat man das Formular, kann es befüllen und am Endeffekt passiert der gleiche Spaß wieder.
Also ich kann das als Nutzer dann ausfüllen und wenn ich auf Speichern klicke,
dann wird eben auch nur dieser kleine Bereich zum Server hingeschickt
und man erhält wieder ein HTML-Schnipselchen, der dort an dieser Stelle eingebaut wird.
Und das Schöne für den Anwender ist, dass es halt super simpel ist.
Man muss dann bloß mit ganz wenigen Attributen sagen, hier, tauschen wir bitte dieses oder jenes aus und dann hat man das Ganze schon.
Also man muss sich da nicht mit JavaScript beschäftigen oder so.
Und ja, das ist sozusagen diese Grundidee der Bibliothek, dass man HTML-Schnipsel über die Leitung schickt und das deklarativ im HTML verfügbar macht.
Ja, sehr spannend. Das macht doch auch solche Sachen wie möglich, dass man dann...
Das ist auch ein weiteres Beispiel
auf der Seite, dass man Infidelscrollen
machen kann, dass er dann in diesem HXWeb-Attribut
einfach After End sagt und dann wird das einfach
angehängt.
Das ist auch ein schönes Beispiel.
Da kriegt man
den besten Eindruck, wenn man einfach mal
durchgeht.
Das ist schon super.
Eigentlich ist die Idee,
mich wundert, dass das nicht schon viel früher
passiert.
Das ist ehrlich gesagt.
Das ist genau von dem ich
eigentlich geträumt habe, gerade vor Jahren,
als ich mit Jake Ferry da so, sagen wir mal,
selber irgendwie was gelöst, irgendwie.
Und das ist eigentlich die Idee dieses Deklarativen
auch. Also das ist eben,
das HTML ist da sehr schön,
diese Beschreibungssprache.
Es ist keine Programmiersprache, eine Beschreibungssprache.
Aber im Endeffekt geht ja
vieles hin in das Deklarative.
Also man will ja einfach bloß sagen, das soll
so und so sein und dann kümmert
sich irgendein anderer Prozess dann darum,
dass das dann auch umgesetzt
wird und so. Und das macht es im Endeffekt dann einfacher.
Ja und im Grunde
behandelt es eigentlich, macht es
genau das gleiche, was man im Browser auf einer Webseite
tut, nur halt nicht jetzt
dass man zum Beispiel, wenn man im Browser halt auf einer Webseite
ist, kann man ja immer nur das komplette
HTML-Element ersetzen
und jetzt hat man sozusagen per JavaScript
in HTMLX halt die Dinge
die man nur auf dem einen großen Ding machen kann, kann man
jetzt auf allen kleinen Elementen halt auch machen
man kann das halt irgendwie durch was anderes
ersetzen, man kann
also normalerweise im Browser lösen halt nur
zwei Events
lösen halt irgendwie ein Request aus.
Das eine ist halt anchor, anchor-tag
und das andere ist halt irgendwie
submit, also form.
Und es gibt nur
get und post, aber es gibt ja noch
viel mehr HTTP-Werben.
Es gibt ja noch die lead-put-patch
und das habe ich mich auch früher gefragt.
Da gab es auch so bei Django REST Framework
ja irgendwie über diese browsable-api
und dann wollte ich halt mal so, da drinnen
kann man ja auch Dinge hinzufügen und so.
Okay, und jetzt muss ich noch put testen und so.
Komisch, put geht irgendwie nicht.
und Jochen unterhalten sich über die Programmiersprache Python
wächst. Also zum Beispiel
Django, was ich jetzt hier eben
einsetze für die Serverseite,
kann man ja auch auf einer HTML-Seite
mehrere Formulare dann
reintun und mit Präfixen das dann
auswerten und so weiter.
Und es war auch, wenn ich mich da
zurückerinnere, rechter Krampf irgendwie immer.
Und hier ist es einfach
entkoppelt.
Ich kann ja auch auf einer Seite drei Formulare haben
und die submitten sich eben
einzeln individuell. Da brauche ich
da nicht ein großes
Formular machen mit drei
Unterbereichen oder so. Das macht es
auch serverseitig deutlich
einfacher, das zu handeln.
Ja.
Naja, und es ist jetzt
tatsächlich auch nicht nur, also
hat demnächst vielleicht zu der Geschichte, dass
der Autor hatte vorher
eine Bibliothek geschrieben als jQuery
Plugin. Das nennt sich
irgendwie Ethercooler.js.
Daher, das hat auch mit
jQuery relativ viel zu tun.
Und das war halt
dann quasi auch halt,
HTMX ist jetzt noch in der Nachfolge davon, der dann halt ohne
JQuery auskommt und diesen ganzen Kram nicht mehr macht.
Und
was ich auch,
wo ich auch denke, das ist
halt ein sehr
breiter Trend, das macht es auch
so interessant, weil es ist halt nicht nur diese eine
Geschichte, es ist nicht nur HTMX, sondern
diesen Ansatz verfolgen ganz
viele Projekte in ganz vielen unterschiedlichen Sprachen.
Und ich weiß nicht,
in welchem Talk das war, ob das
der von der JunkoCren US
Es war auch, glaube ich, mit TalkPython2Me
Interview mit dem Entwickler von
HTMX, sagt er einen Satz,
den ich von unterschiedlichen Leuten aus unterschiedlichen Communities
schon ganz oft gehört habe. Den habe ich auch schon gehört
von Chris McCord von Phoenix LiveView
und ich habe den auch nochmal woanders gehört.
Und zwar, der Satz ist, ja, also ehrlich gesagt,
dafür, dass ich kein JavaScript schreiben wollte, habe ich jetzt ganz schön viel JavaScript geschrieben.
und das
sagen, also das ist halt
dieses Thema, also ganz viele Backend-Leute,
die eigentlich nie JavaScript schreiben wollten,
haben jetzt
dann doch viel JavaScript geschrieben, um das loszuwerden
und wenn
das viele Leute machen und
quasi zu einem ähnlichen Ergebnis kommen und
das tatsächlich funktioniert, dann wird das wahrscheinlich
auch so bleiben und das sieht danach aus, als hätte
man da was gefunden, was tatsächlich gut funktioniert und das
macht es dann natürlich auch interessant, also wenn das jetzt nur
eine Geschichte wäre, aber ich weiß
nicht ob mir jetzt die ganzen Namen einfallen, aber
in der Ruby on Rails Welt
also bei HTMLX wird ja auch viel mit Ruby on Rails
zusammenverwendet, gibt es halt noch Hotwire
also ist auch Akronym
für HTML over the wire
und Turbolinks, wo
halt dann quasi schon die
Seite hinter dem Link gefetcht wird
sodass wenn man auf den Link draufklickt, das halt dann
direkt da ist
dann gibt es
eben bei
Elixier
in der Elixier Welt Phoenix gibt es LiveView
wo auch HTML-Snippets halt über den Websocket
geschickt werden, dann gibt es das
in PHP,
da heißt das irgendwie Livewire in Laravel
und
ja,
ich weiß es gar nicht, da gibt es
also auf jeden Fall in vielen unterschiedlichen
Communities machen Leute jetzt gerade sowas
und ja,
das scheint irgendwie ein sehr, sehr
breiter Trend zu sein, ja.
Der Schöne an dem HTML-X ist ja auch,
dass es
sich da vollkommen raushält, also das
kann man mit jedem
Backend-Framework nutzen, wie man möchte
und die anderen, die sind halt
oft Backend-spezifisch,
also bei Ruby und Rails
ist es Hotwire
und drum war das,
ich habe es mir angeschaut und hätte
eigentlich da Interesse gehabt, aber das war dann
irgendwie schon wieder irgendwie kompliziert
und nicht so einfach. Das
HTMX hat es, glaube ich, der Carson Cross
hat es da sehr, sehr schön
nochmal reduziert von der Komplexität
und das ist ja auch im Endeffekt sein Ziel.
und Jochen unterhalten sich über die Programmiersprache Python
von Adam Johnson,
der hat irgendwie ein Ding geschrieben,
Django HTMX,
das ist eben als
Integration jetzt auch in Django als Framework,
aber das macht auch fast nichts, das macht ganz wenig,
das macht nur
sozusagen eine Middleware dabei,
die an den Request halt ein Attribut
dran bappt,
ich weiß nicht, ist HTMX oder sowas, wo man dann einfach nachgucken
kann, weil man muss auf der Serverseite halt
unterscheiden können, war das jetzt ein Request,
der von HTMX gekommen ist oder nicht und dann
je nachdem, rendert man eben
die komplette, das ist auch sowas, wenn
ein Browser kein JavaScript kann, das ist gar kein Problem
das funktioniert einfach so weiter
weil auf der Serverseite rendert
man halt, wenn man sieht, okay
es war kein HTMLX-Request, dann rendert man einfach
die komplette Seite raus, das ist gar kein Problem
und wenn es ein HTMLX-Request war, gut, dann
rendert man halt nur das Fragment raus, das halt
ersetzt werden muss und das heißt
es funktioniert in beiden Fällen und irgendwie
man hat halt diese Windelware dann, um halt
da quasi sich nicht selber überlegen zu müssen, wie
man jetzt erkennt, ob das jetzt ein HTMLX-Request war
oder nicht.
Und dann hat das Ding auch noch so Teile drin
für, damit diese
Fehlerviews halt
ordentlich funktionieren. Also wenn halt ein Fragment
nicht ordentlich gerendert wird, dann ist
wenn man sonst nichts macht,
ignoriert, also wenn dann zum Beispiel
ein 400 zurückkommt auf ein
HTMLX-Request, dann sieht man nichts, weil
HTMLX schmei einfach die Antwort dann weg Und vielleicht will man die Standard Django aber haben mit dem Stacktrace oder so Und das ist halt auch noch so ein bisschen das ist glaube ich eine HTMLX
in JavaScript, die
in Django-HTMLX drin ist,
die dann halt dafür sorgt, dass man eben die normale
Django-Fehler-Seite sieht,
auch wenn ein HTMLX-Request
halt aus der Seite schiebgegangen ist.
Genau. Also ich habe es mir auch angeschaut, die Bibliothek,
habe eher das gleiche festgestellt
wie du. Es ist relativ wenig
eigentlich drin und es ist auch wenig notwendig
und darum nutze ich es ja auch
gar nicht, weil ich habe mir für mich dann
nochmal überlegt, wie willst du deine
Anwendung gestalten? Also zum einen
unterstütze ich nicht
JavaScript-lose Browser,
also JavaScript ist für meine Seite
jetzt notwendig, also
da ist es schon im 21. Jahrhundert
und aber das ist dann
so, dass ich die
URLs trenne, also
es gibt den ersten Seitenaufruf
und der erste Seitenaufruf bringt eben eine ganz normale HTML-Seite
mit dem HTML-Tag, Head-Tag, Poly-Tag und HTML wieder zu.
Und ab dann werden eigentlich meistens Schnipsel ausgetauscht.
Und die URLs, wo ich eben ein Schnipsel bekommen will,
die liefern immer ein Schnipsel zurück und die werden immer über HTMLX aufgerufen.
Ob das ist diese Fallunterscheidung, selber seit ich gar nicht habe,
von wegen, ist das jetzt ein HTMLX-Request oder nicht.
Es gibt glaube ich auch sowas von Django Forms, irgendwie Django Forms Dynamic oder sowas, dass man da quasi Django Forms nutzen kann, direkt als HTMLX Forms.
Ah, okay. Das kann ich noch gar nicht.
Das ist irgendwie auch ganz cool dazu.
Cool, ja.
Das heißt, also Django Forms kennt ihr vielleicht, da kann man das direkt so einbauen.
Das ist immer ganz hilfreich.
Ja, ich habe letztens auch das irgendwo gesehen, aber ich habe es mir noch nicht angeguckt.
Interessant.
Ja.
Ja, also wir haben so ein bisschen jetzt glaube ich über
die Syntax gesprochen, über das Beispiel und das, was alles Schönes gibt
also man macht meistens halt mit diesem Swap-Target oder sowas, ja, also Moment, es gibt
Swap und Target glaube ich, ja, also das heißt wir haben, wir sagen quasi, was getauscht werden
soll, wohin das getauscht werden soll und wann es
getauscht werden soll. Genau, richtig, das mit dem Trigger geht sozusagen los
also bei einem Form muss man den Trigger jetzt gar nicht angeben, weil bei einem Form ist es
das Drücken auf den Submit-Button.
Aber es gibt eben andere Trigger, wie du vorhin
Dominik angesprochen hast, den Revealed-Trigger
zum Beispiel. Also ich kann so einen Infinite-Scroll
implementieren, indem ich ganz unten eben
einen HTML-Schnipsel habe mit dem
Trigger Revealed und der feuert dann,
sobald dieses Schnipselchen in den sichtbaren Bereich
kommt im Browser. Und das ist natürlich dann
relativ cool. Dann kriege ich das Event, dann hole ich mir
neue Daten, dann kann ich 5, 6, 7
neue Einträge unten
machen und wenn der Nutzer nach unten
scrollt, kommt er wieder nach
unten, kommt wieder das Revealed Event,
und er holt sich die nächsten Einträge.
Dann kann man ohne eine Zeile JavaScript
zu schreiben, so ein Endless
Scrolling implementieren.
Das ist eine feine Sache.
Wir haben
Swap.
Swapmesser in der HTML, tauschen out der HTML.
Target
und out of band gibt es auch noch.
und Jochen unterhalten sich über die Programmiersprache Python
und Out of Band kommt dann noch dazu, bitte tausche außerdem hier das Element mit der ID aus
und dann kommt dann dort die neue Zahl für die gesamte Summe.
Das gibt es auch noch, das Out of Band Aktualisierung von Daten angekommen ist.
Also man kann eben zusätzlich Out of Band, also wenn der Server weiß, hier ich möchte noch was aktualisieren,
was aber jetzt nicht in dem aktuellen Schnipsel mit aktualisiert wird
kann der Server out of band noch zusätzliche Schnipsel mitschicken
was dann eben am Client aktualisiert wird
Anwendungsfall war eben so eine Art Warenkorb
man klickt unten bei dem einen Artikel plus
dann weiß ich, jetzt habe ich jetzt zweimal diesen einen Artikel
aber oben, rechts oben als Beispiel ist so ein Einkaufswagensymbol
und da will ich die Summe aller Waren anzeigen
dann kann ich damit eben das auch aktualisieren
sondern zwei Stellen, einmal diese
unten bei der eigentlichen Ware
und oben im Warenkorb.
Das ist auch so ein ganz nettes Feature
von dem HTMX.
Ja, was gibt's
sonst noch zu sagen?
Ja, auch solche Sachen, dass man
da fand ich auch nett
sagen kann, okay
lad mal dieses Element
alle zwei Sekunden nach, das ist halt auch so ein
Anwendungsfall
für Autoharte, man könnte sich auch fragen, wozu
brauchen wir eigentlich Autoharte und Inner?
weil wenn man das komplette
Element ersetzt, dann werden halt auch
die HTMLX Attribute mit ersetzt
und man kann zum Beispiel dann von der
Serverseite her steuern
wie lange irgendwas dann
also man könnte zum Beispiel, man hat halt irgendwie einen Newsticker oder sowas
und sagt halt alle zwei Sekunden
werden da neue Daten geladen
und dann kann man von der Serverseite aber sagen
wenn man das komplette Element austauscht, okay man nimmt
diesen Trigger raus
irgendwann nach 10 Minuten oder so
und dann werden halt keine neuen
wird halt nicht mehr gepollt quasi.
Und dafür muss man dann das komplette
Element ersetzen. Dann braucht man halt out HTML.
Ja, also genau. Solche Sachen kann man
auch sehr einfach machen.
Was gibt es noch?
Ja, genau.
Überhaupt diese Geschichten, wenn
vom Server Sachen kommen, da weiß ich
auch noch nicht so genau, wie das dann...
Gibt es Support für Websockets oder solche
Sachen?
irgendwie? Ja, ja, WebSocket-Support
gibt es, habe ich aber selber jetzt noch
nicht ausprobiert. Und es wird
aktuell eben die Bibliothek
aktualisiert, dass WebSockets zu einem
externen Paket wird.
Dass man also das gar nicht mehr per Default
drin hat, sondern
dann sich selber nachladen muss.
Ich persönlich finde es gut, das hält die
Bibliothek klein. Ja, die meisten Leute brauchen
das halt nicht, denke ich mal. Genau, und dann kann man es auch
auslagern. Ja,
ich glaube,
Server-Sent-Events
Support dafür ist auch irgendwie drin.
Da dachte ich auch so,
habe ich irgendwann letztens
nochmal geguckt, was das denn wirklich ist, weil das habe ich nie so,
das ist zwar schon uralt und gibt es total lang,
aber ich wusste nie so richtig, was das ist.
Aber ja, es ist halt auch eigentlich nichts Besonderes.
Und vor allen Dingen, es belegt halt auf dem Server auch,
man muss halt eine Verbindung offen halten, nur
dass man halt vom
Client aus nichts zurückschicken kann, sondern es ist halt
eine Verbindung, die immer offen bleibt,
wo man vom Server halt irgendwie Daten
und klein schicken kann.
Aber ja,
mit Django geht das nicht gut.
Aber man muss halt dafür
Django Channels verwenden.
Ja, genau.
Eine Sache fällt mir noch
ein, mehr so eine allgemeine
Sache.
Viele sind ja Freunde dieser JSON
APIs, weil sie sich dann denken, ah super,
dann habe ich ja eine
API und damit kann ich zum
einen ein Webfrontend machen und
zum anderen kann ich da eine API
anbieten für eine Maschine-Maschine-Kommunikation.
Und das ist aus meiner Sicht
Blödsinn.
Weil man
zwei ganz verschiedene Anwendungsfelder
zusammenwürfelt.
Bei einer GUI,
da will ich super agil sein, die will ich
täglich aktualisieren können, da will ich
täglich deployen können und da sollen
sich auch täglich kleine Änderungen ergeben
können. Weil das den Nutzer
in der Regel nicht stört,
wenn es so ein kleines bisschen irgendwie anders ist
und ein kleines bisschen verbessert wird
kontinuierlich.
Will ich aber eine Maschine zu Maschinenkommunikation haben,
ist sowas wie
A-B-Testing vollkommener Schwachsinn.
Natürlich, ich werde ja nicht
einer Maschine sagen,
du kriegst die API und
der andere Client kriegt
diese APIs und diese Daten.
Das ist ja vollkommen konträre, ganz
verschiedene Anwendungsfälle.
Und drum, das war bei mir
anfangs bei Angular, wo ich dachte, oh cool,
eine API und da kann ich dann
GUI entwickeln und außerdem
eben da einen maschinellen
Zugriff auf dieser Seite haben. Aber es sind eben
zwei ganz getrennte Dinge, die auch
ganz getrennt
behandelt werden sollten.
Da könnte man
ja dann auch dann sagen, na gut, wenn ich Maschine-Maschine-Kommunikation
machen will, könnte man ja
sowas wie gRPC einsetzen,
was dann im Endeffekt auch
mehr Datentypen unterstützt und insgesamt
optimaler ist.
Wir haben noch nicht genau RPC erklärt und jetzt kommst du mit gRPC an.
Das muss man erklären, was das ist.
Das gRPC ist eine Technologie von Google
und das ist ein binäres RPC, also Remote Procedure Call
Methode und das ist sehr effizient
und schnell. Es ist auch
schema-basiert, also du musst klar, der Server sagt klar,
was für Daten er austauscht
und das wird
im Kubernetes-Bereich
oder so ähnlich dann auch stark
verwendet. Aber halt bei den
Web-Entwicklern ist gRPC noch nicht angekommen
und das wird wahrscheinlich auch noch
ein bisschen dauern, bis das
da bekannt und verstanden wird,
um was es da eigentlich geht.
Ja.
Naja, da ist
JSON schon so das Ding,
also ich meine, es gibt ja im Grunde
keinen großen, keinen wirklichen Grund, warum man
jetzt irgendwie, außer dass man halt
das JSON irgendwie nahe liegt, wenn man
jetzt JavaScript macht, aber
ansonsten gibt es ja gar keinen
Grund dafür, dass man könnte halt auch irgendwie
andere
Datenformate halt benutzen.
Ich meine, bei Django REST Framework war das ja auch mal so,
da konnte man halt auch, ich glaube, ich weiß nicht,
ob das heutzutage noch jemand macht, aber früher war das halt
durchaus auch üblich, da zu sagen, okay,
ich rendere meinen Kram nicht nach JSON,
sondern nach XML.
Oder wie heißt dieses
Es gibt auch einen Binär-JSON.
B-JSON?
Jason B.
Ja, nee, das ist es.
Ach, ich hab's wieder vergessen.
Aber ja,
es gibt irgendwie auch eine
binäre Variante davon, die
man auch mit Django Resolver ganz gut verwenden konnte.
Da wurde es halt ein bisschen kleiner.
Aber ja, tatsächlich
benutzen aber doch irgendwie alle JSONs letztlich.
Ja, aktuell.
Ich bin ehrlich gesagt ganz tiefenentspannt.
also um 2001
habe ich meine Diplomarbeit
geschrieben und klar, was war das Thema? XML.
Damals ging alles um
XML und auch das HTML
sollte XML werden und so weiter.
Da bin ich ja so froh, dass dann dort
irgendwie die Vernunft gesiegt hat und
das XHTML sich nicht
durchgesetzt hat,
weil das ist am Endeffekt dann auch nur
Krampf, wenn man das zu sehr
in die Richtung treibt und wie gesagt,
damals war alles mit XML,
aktuell ist alles mit JSON
und da bin ich auch ganz tief
entspannt, dass da dann irgendwie auch nochmal
was Neues kommt. So ist auf jeden Fall
die Entwicklung aus meiner Sicht.
Ja.
Naja, da ist noch nicht
aller Tage Abend, was diese
alle
gehandelt hätten.
Ehrlich gesagt, ich finde es
persönlich angenehmer als XML. XML war nochmal
ein Stück schrecklicher.
Das ist der Grund, wo ich sage,
den Computer will ich nicht anfassen.
Das ist komisch, ganz komisch.
Wirklich.
Ja, klar, da gab es die größten
komischen Sachen wie XLT
und sowas.
Viel schlimmer als Assembly oder sowas.
Tja, ja. Aber wir haben doch einige Sachen nicht
erklärt und zwar, wie hieß der nochmal?
Carsten Gross?
Carsten Gross, glaube ich,
weil er möchte wahrscheinlich vermeiden, dass wir
ihn towern.
Sorry.
jedenfalls hat er so ein Talk gehalten und da hat er auch viel über Haters gesprochen.
Das Akronym ist auch ein bisschen unglücklich.
Ja, sehr gut.
Was ist denn das und worum geht es denn da?
Da hatten wir eigentlich schon drüber gesprochen.
Ja, weil da gibt es ja schon Beispiele auch auf der Seite von HTMX.
Ich persönlich kann dazu halt nur sagen, dass ich es nicht weiß und mich interessiert es auch nicht.
Das ist ein Steckenpferd und er zählt viel und redet viel.
Aber mir ist das zu abstrakt.
Ich halte mich aus den Diskussionen
da auch raus, was ist REST, was ist
HATEOs oder irgendwas.
Für mich ist HTTP greifbar,
HTML ist für mich greifbar und so weiter.
Aber das ist mir dann
zu abstrakt und
kann ich nicht viel zu sagen.
Ich glaube,
die Übersetzung von
HATEOs ist
Hypermedia as the Engine of Application State.
Da geht es so ein bisschen darum, dass
tatsächlich die
und Jochen unterhalten sich über die Programmiersprache Python
eine Perspektive.
Ja, aber genau,
das sind dann halt deine
Datenhaltung, aber
der Application State ist ja jetzt nicht
unbedingt in der,
da hast du ja auch noch andere Sachen, da hast du ja auch noch solche Sachen wie
dein Cache
oder du hast halt vielleicht irgendwelche
Queues und du hast halt auch noch irgendwie
eine Session und
ganz viel Zeugs.
Aber klar, natürlich, also
Die Frage ist halt,
bei alles, was sozusagen im Browser passiert, ist halt
in dem HTML halt irgendwie drin.
Das ist halt so eine Hattie-S-Geschichte.
Aber ja, ich finde das auch ziemlich
kompliziert und theoretisch und das ist
sehr schwer, das zu erklären.
Wenn du es ehrlich wie Dependency
Injection, da kann man sich das hundertmal
erklären lassen und dann sage ich immer,
für mich ist es wie Konfigurierung.
Aber keine Ahnung, das ist
mir zu abstrakt.
Ja, weil man den Talk
schaut und erklärt das halt so ein bisschen.
Das ist vielleicht ganz gut, wenn man das vielleicht ein bisschen versteht.
Aber den Talk müssen wir natürlich auch verlinken.
Der ist natürlich sehr bannrecht.
Ja, das ist wahr.
Ja, okay.
Ja, aber da am besten
hört man sich genau den Talk dann an
und nicht uns, wie wir da hochgelegt werden.
Ja, das ist wahrscheinlich so.
Ich kann da nicht mitreden.
Ja.
Ja, dann habe ich noch eine Frage
irgendwo. Ich sehe da,
wo sind die Grenzen
oder irgendwann, wann sollte man tatsächlich auf React oder Vue umsteigen.
Da kam dann mal vorher so eine Frage.
Und da sehe ich aktuell eigentlich keinerlei Grenzen.
Es erinnert mich so, wie ich vor 20 Jahren mit Python angefangen habe.
Und da war eben so eine Sache in der Firma.
Da meinte ich, wollen wir das nicht lieber mit Python machen,
anstatt aus einer Mischung aus C, C++ und Shell-Skripten.
Und dann hieß es, naja, da konnte ich bloß herausboxen,
dass wir für den Prototypen Python nehmen.
aber danach muss es sozusagen
dann mal richtig gemacht werden.
Eine richtige Programmiersprache.
Ja,
und das war ich sehr froh,
dass ich diesen Kompromiss rausboxen
konnte und im Endeffekt
hat nie jemand dann
nochmal nachgefragt, wir sollten das ja
in C oder C++ machen, weil einfach die Kunden
zufrieden waren.
Das hat schnell funktioniert, war alles prima und da
kamen reihenweise neue Wünsche von
den Kunden, sodass dann
das
eben nie wirklich richtig gemacht werden musste,
wo ich auch sehr froh
drüber bin und so.
Ähnlich ist es jetzt auch hier. Jetzt könnte man sagen,
ja dann, wenn man es richtig macht, dann müssten wir es
doch in Vue oder React machen, aber
keine Ahnung, ich sehe da jetzt
keinerlei Grenzen.
Ja.
Ne, würde ich auch sagen.
Man kann damit wahrscheinlich
für die allermeisten Sachen
ausreichend viel machen.
Das einzige Problem ist wahrscheinlich, dass man wieder wie immer von vorne anfangen muss,
und das einmal alles wieder in schönen, mit der eine Technologie bauen muss oder so,
dass das Change immer das Pain ist.
Das war wahrscheinlich auch der Grund, warum die Leute und die Menschen bei dir dachten,
mit C++ schreibt man bessere Webanwendungen oder so.
Wenn es eine Webanwendung war, das war das natürlich nicht.
Ja, das war damals auch im Web basiert, aber auch viele Backends.
Aber das war halt einfach so üblich, das war unüblich.
Und das Unübliche wird natürlich erstmal in Frage gestellt.
Und da ist klar, es ist erstmal kein Vertrauen da.
und Jochen unterhalten sich über die Programmiersprache Python
ehrlich gesagt sagen würde, das will ich
gar nicht haben.
Frameworks sind nicht meine Freunde.
Und das ist mir durchaus klar.
Ich will eigentlich möglichst wenig mit Frameworks zu tun
haben. Also eins, das du kannst?
Nee, ich will
eigentlich keine Frameworks verwenden.
Weil das Problem bei Frameworks
ist natürlich, dass ich da halt eine richtig fiese,
harte Kopplung,
enge Kopplung dran habe und dass ich
davon nicht mehr wegkomme. Und deswegen
finde ich als Entwickler das natürlich
gar nicht so angenehm.
Auf der anderen Seite gibt es halt einen großen Druck, die zu verwenden
Aber der kommt ja meistens nicht von den Entwicklern
sondern der kommt ja meistens dann halt
und ich würde denken, dass bei den JavaScript-Frameworks
ist das halt so
Das sind halt irgendwie
Firmen, die halt
vorher eine Applikation haben
Das habe ich jetzt auch aus der Nähe
in letzter Zeit irgendwie oft bestaunen dürfen
gerade was irgendwie
in dieser Pandemie-Zeit halt
Die haben halt Applikationen so
tatsächlich in C++ geschrieben oder Java
oder sowas,
die auf Clients laufen,
also die irgendwie auf dem Desktop laufen
und die dann halt irgendwie mit einem
Server reden oder halt irgendwas,
was auch immer die dann tun. Und das
funktioniert aber nicht so gut, weil
irgendwie, wenn die Leute jetzt zu Hause sitzen, dann
den kannst du dann zum Beispiel einfach nicht mehr so gut,
also deren Rechner hast du nicht so richtig unter Kontrolle,
dann irgendwie
Netzwerk ist oft schlecht,
irgendwie, das funktioniert
alles nicht so super. Dann hilft bloß halt so ein
Citrix oder so. Genau, das war
und das ist dann eine Lösung, aber das ist halt auch schrecklich
und
im Zuge
dieses Erkenntnisprozesses, dass dann viele
sagen, oh, das ist ja alles ganz furchtbar, das funktioniert ja gar nicht,
stellen jetzt ganz viele um
auf webbasierte Geschichten, weil
mit webbasierten Geschichten geht das halt.
Und
naja, wenn ich jetzt sozusagen
irgendwie eine große
grafische GUI
Anwendung umstelle, halt
auf irgendwas webbasiertes, naja,
Dann ist halt sehr naheliegend zu sagen, okay, ich habe hier
mein Team mit irgendwie 50, 100 Leuten, keine Ahnung,
irgendwie ein paar Teams aufgeteilt
und die haben halt ihren
Bildprozess und keine Ahnung, ihre Tools
und die Architektur-Patterns, die sie halt irgendwie verwenden.
Gibt es da nicht vielleicht irgendeinen Enterprise
Web-Framework, das ich verwenden kann,
wo ich das dann quasi genauso machen kann?
Und dann greifen wir halt vielleicht zu Angular
irgendwie oder so, weil das halt
so ähnlich ist und halt auch dieses ganze
Framework irgendwie Sprech
und Enterprise Sprech halt
damit drin ist.
und das Problem dabei ist aber natürlich,
dass man das eben nicht machen kann.
Du kannst nicht einfach irgendwie eine große Applikation nehmen
und dann das
quasi genauso, wie du es vorher gemacht hast,
mit JavaScript machen und dann ist es halt eine Web-Anwendung.
Das funktioniert halt nicht, sondern du musst eigentlich
dir überlegen, okay, die muss dann halt anders
funktionieren, weil Web-Anwendungen halt nun mal einfach
anders funktionieren als diese
klassischen Desktop-UI-Integrale.
Ja, dann müsste jemand auf jeden Fall erstmal den Unterschied verstehen,
was vielleicht schon eine Herausforderung ist
und dann muss ja jemand, der den Unterschied
verstanden hat, den Leuten, die das entscheiden, auch
erklären, dass das auch die richtige Idee ist, das zu tun.
Aber das Problem ist jetzt, stell dir vor, du bist derjenige,
der zuständig ist für diese Entwickler und du weißt, die
kennen jetzt aber ihr sonst was
Framework halt und wie kriegst du
die beschäftigt mit
der Umstellung auf irgendwas Webbasiertes?
Ohne, dass
du die ein Jahr lang schulen musst oder keine Ahnung
wie der Produktivität so beeinträchtigt ist.
Das geht nicht so einfach. Ja, aber wenn du
halt dann ganz verzweifelt genug bist, denkst du dir,
vielleicht geht es mit Angular.
Ich würde sagen, ohne diese Schulung geht das
nicht so einfach.
Also es ist einfach eine schwierige Situation auch.
Also wenn du die Sprache
wechseln musst, ist natürlich schon mal schwierig.
Das heißt, vielleicht ist es gut tatsächlich,
wenn man irgendwie vor Desktop-GUI-Anwendung
in Python geschrieben hat,
dann kann man vielleicht auch Web-Anwendung in Python
schreiben, obwohl ich auch schon finde, dass TestDjango
schon sehr anders ist als GUI-Sache
in Python schreiben, was man ja bestimmt unbedingt machen will.
Naja.
Also ich glaube, diesen Plattform-Wechsel,
den kriegst du nicht so einfach hin.
Also ich wüsste jetzt auch nicht so genau, wie ich jetzt eine Android-Anwendung entwickeln will in gut.
Ja klar, das ist nicht einfach, aber das ist eine Aufgabe.
Aber langsam geht alles Richtung Web.
Also für mich ist der Chromium mein neuer Desktop.
Also ich schalte zwischen Tabs hin und her, die im Chromium drin sind.
Und Native GUI habe ich nur noch den PyCharm.
Und ansonsten eigentlich nichts.
Du bist auch einer von diesen PyCharm-Nutzern, okay, verstehe.
Ja.
Ach, das kann man schon machen.
Du hast ja auch in letzter Zeit viel PyCharm benutzt, ja.
Ja, wobei, also ich meine, ich weiß nicht, wie dir das geht,
also tatsächlich mich benervt bei PyCharm, dass es halt
relativ langsam reagiert.
Letztens habe ich irgendwo gelesen,
David Beasley hat das, glaube ich,
in einem
seiner Readmes zu irgendeinem anderen Softwareprojekt
hat er sehr bösartige Dinge über Java
gesagt, und zwar meinte er so,
ja, Java, ach, der spricht nicht
für Java, sondern er sagte, es gibt
diese Programmiersprache, ihr wisst schon, sie
reint sich auf Lava.
Und da ist es immer so,
die erkennt man immer daran, dass
an diesem
Moment peinlicher Stille,
bevor die Lüfter dann losheulen.
Das ist halt...
Das
Python ist flüssig zu bedienen.
Echt, findest du?
Nein.
SSD, so und
also doch, läuft eigentlich schon.
Naja.
Ich meine vor allen Dingen bei PyCharm solche Sachen, wie man drückt auf irgendeinen Button oder man macht halt eine Tastenkombination. Also man macht zum Beispiel sowas wie, bei mir ist es Command 0 oder Command 1 für den Verzeichnisbaum aufmachen oder halt Git-Dings aufmachen, zumachen. Und ich habe immer das Gefühl, wenn ich das draufdrücke, da sind so 100 Millisekunden Verzögerung oder so, bevor da irgendwas passiert. Und das nervt fürchterlich.
Ich habe übrigens angefangen,
Jochen, dieses Jahr, und das habe ich mir
fest vorgenommen, mein VI einzurichten
und mal zu gucken, ob ich den
vernünftig zu laufen kriege.
Ja, muss man machen.
Ja, es nervt ein bisschen.
Ansonsten, PyCharm finde ich
eigentlich tatsächlich, nachdem ich das jetzt eine ganze Zeit lang benutzt
habe, ziemlich gut. Also von den Features
her finde ich das total super. Da ist es echt gut.
Es ist ziemlich
komplett und
Ja, ist alles durchdacht, aber
irgendwie, dass es halt so ein bisschen, sich so ein bisschen
äh, ja
Ich find's hässlich. Langsam anfühlt, ja gut,
das ist halt eine andere, ja
Persönliches Empfinden,
aber vielleicht kann ich das so stylen, wie ich meine anderen Sachen style
und dann macht das doch gar keinen Unterschied mehr.
Ja, aber tatsächlich,
das mit Chromium ist halt neu, deshalb, ich meine,
da auch da irgendwie VS Code, ich weiß nicht,
ob du schon mal VS Code ausprobiert hast?
Ich hab's mal ausprobiert,
aber
Ja, mehr kann ich nicht dazu sagen
Ja, ich habe Python zum Beispiel auch
eigentlich gar keine Ahnung, ich muss das auch meistens auch auf der Liste
aber kommt nach wie eitern
Ja, weil
da ist es ja auch irgendwie krumm drunter
und das funktioniert eigentlich tatsächlich auch
ziemlich gut, ich würde sagen
tatsächlich, ich habe jetzt auch eine ganze Zeit irgendwie skutt
es ist nicht so komplett wie PyCharm, es ist auch nicht
so durchsacht und so, aber
es ist tatsächlich, wenn man da irgendwie
Command-B oder das ist schneller
als bei PyCharm
Okay, ja, kann schon sein, aber beim Laptop und auch selbst auf meinem Vorgänger ging es eigentlich gut, er hatte mal irgendwie Probleme, als er irgendein Verzeichnis indiziert hat, wo er eigentlich rein indizieren sollte, da hat er ganz schön zu tun gehabt, aber das kann man dann auch exkluden, dass er da nicht reingucken soll, weil da eben zigtausend Dateien drin sind und dann hat er auch oft damit und ging es eigentlich, kann ich erstmal nicht klar.
Vielleicht habe ich auch irgendwas falsch konfiguriert, das kann natürlich auch sein.
Was ich auch mal hatte, da hat es mir immer den Akku leergesaugt,
da habe ich die
JVM für Intel
auf meinem
ARM
Mac verwendet
und das lief dann in der Emulation
und das war irgendwie auch ganz schrecklich.
Da dachte ich mir so, hä, warum zieht denn das so viel Akku?
Dann musste ich eine andere
JVM nehmen und dann war es gut
und dann funktioniert es auch.
Aber ja.
Ja, aber ein was
fiel mir noch ein zu
JavaScript und den ganzen
Spaßsachen, was ich ja
schön finde, dass das HTML sich immer
noch weiterentwickelt
und vorangetrieben wird
sodass man im Endeffekt dann
weniger schreiben muss
zum Beispiel ein Datepicker
oder irgendwas, wenn man danach sucht, da gibt es
tausend Implantierungen
von Datepickern
aber ich als Web-Anwender will
einfach dann nur fertig werden und da
Es ist einfach schön, wenn ich sagen kann, Input-Type ist gleich Date zum Beispiel oder eben Input-Date-Time-Local, um eben Date und Zeit zu picken.
Und das finde ich spannend dass sich da halt das immer noch alles entwickelt und die Spezifikationen gibt es und sicherlich ist es leider noch so dass eben unter iOS
kein richtiger
Chrome verfügbar ist, das ist ein bisschen
schade, dieses
Apple Browser Ban,
aber kann durchaus
sein, dass da die EU
dem bald einen Riegel
vorschiebt mit dem Digital Market Act.
Es wäre sehr
schön, wenn da, weil das ist
Da kannst du als einzelner Webentwickler
ja auch von niederspringen und vielleicht
kommt auch doch mal von der Legislative
da irgendwas, weil es ist einfach ein Markt
der Apple Play Store und
es ist ein globaler Markt und
das dann dort zu diskriminieren
gegenüber anderen Browsern
ist einfach nicht in Ordnung.
Also hoffen wir mal,
dass dort das vorwärts geht,
weil dann ist nochmal mehr Druck da,
dass die Safari
Engine mal vorwärts macht und dass die
da nicht das
absichtlich blockieren können. Das wird ja absichtlich
blockiert, damit sie weiterhin
schön Geld verdienen innerhalb ihres
App-Stores. Und darum hat Apple
überhaupt keinen Bock drauf auf Progressive Web Apps.
Das ist halt vielen Leuten
nicht bekannt.
Wenn man mit Leuten darüber spricht,
die jetzt nicht aus dem Software-Bereich kommen, die verstehen das
erstmal gar nicht, von was man da spricht.
Und naja, hoffen wir mal,
dass da irgendwie das in der Richtung auch
weitergeht.
Weil dann geht es eben
Richtung Progressive Web App,
Progester... Gut, okay, das ist natürlich
wieder eine Sache. Aufhänger
HTMLX, also HTMLX
ist sozusagen
auf keinen Fall offline first oder
irgendwas, man braucht die Verbindung zum Server.
Das ist sozusagen, ja,
sind ganz zentrale
Sachen an dieser Stelle.
Wenn man dann
Web-App schaut, dass man sagt, okay,
man hat eine offline-fähige
Web-Anwendung, klar,
dann ist es mit JavaScript natürlich besser.
Aber
99% der Fälle braucht man das eigentlich auch gar nicht.
Ja, offline-first war auch mal eine ganze Zeit lang, das kam irgendwie so aus dieser ganzen Couch-DB-Ecke und
eigentlich finde ich den Ansatz ja auch ganz interessant irgendwie,
halt quasi auch eine Datenbank einfach auf der kleinen Seite zu haben und
da gibt es ja auch diverse Geschichten in den Browsern, also gibt es ja auch irgendwie, weiß ich nicht mehr,
quasi so ein SQLite haben die meisten irgendwie drin, was man verwenden kann
und dann synchronisiert man das halt wieder zurück
irgendwie und so. Das ist eigentlich auch alles ganz nett.
Aber
ja, tatsächlich
genau war das dann aber
doch nie so nötig, weil inzwischen ist ja doch
fast überall Netz und es funktioniert eigentlich auch ganz gut.
Genau.
Verzehnfacht einfach
die Komplexität und den Aufwand.
Und drum geht
eigentlich alles Richtung ständige
Verbindung zum Internet.
Es gibt ja ganz wenige Sachen, wo es eigentlich
wirklich braucht, wenn ich will. Ich will, wenn ich in der Bahn bin und habe kein Netz,
kein Netzanbinder, 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. Du kannst ja nicht aus den Fingern saugen.
Du brauchst halt eben die Netzwerkverbindung.
Und darum 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 stellen
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
eben da dieses SaveString
ausgewertet wird. Also da wird
alles, was gequotet
werden soll, wird automatisch gequotet,
außer es ist eben ein SaveString, 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, hab ich auch noch
nichts, ich weiß nicht genau, ob das
mit F-Strings, also
tatsächlich in JavaScript geht das wahrscheinlich
da gibt es ja diese Template Literal Strings
damit könnte man das
wahrscheinlich machen
Ja, wäre schön, wenn sowas
Aber so im Python gibt es das nicht
Ja
Ja, ja, ja, ja, ja, ne
Ne, weiß ich auch nicht
Aber ja, es stimmt
Ich meine, ja, das ist die Frage, ob das
Alle machen das jetzt halt
über diese Template-Geschichten, ne
Aber ob das jetzt der
der beste Weg ist, weiß ich auch nicht
Ja, aber
im Kontext von HTMLX ist es bei mir
solcher Stelle kleine Methoden, die
kleine Schnipsel zurückgeben
Ja, warum brauchen die denn so viel?
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
irgendwie behindern
Aber kannst du nicht auch einfach ein Django-Template
quasi in den Spring reinschreiben und den dann
rendern, weil du musst es ja nicht in den File reinführen
Könnte ich auch, ja
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.
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 überlege, SQLite ist ja, also klar, kann man nicht so concurrent draufschreiben, aber ist auch sehr mächtig und kann man auch so ein bisschen auf die Seite bringen.
wahrscheinlich irgendwie das meiste, was man so
braucht, wenn man jetzt irgendwie eine Datenbank
für eine Webgeschichte hat, kann man
nicht einfach die komplette Webapplikation schippen
mit einer 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 Datenbanken irgendwie.
Das ist natürlich viel möglicher,
prinzipiell kannst du das, also
überwaltet. Da wird sich noch viel entwickeln.
Nach WebAssembly alles kompilieren. Du kannst
prinzipiell auch bei Python nach WebAssembly
kompilieren. Ja, das haben wir auch schon losgemacht.
Puppi-Pupps alles paketieren und dann
haust du noch ein Postgres hinterher und
dann hast du
leider der Kunde erstmal hier
50 Megabyte runter.
Ich meine, obwohl 50 Megabyte sind auch
schnell runtergeladen.
Und dann hast du dort alles
drinnen im WebAssembly.
Ich bin gespannt,
was sich da entwickelt.
Ja, naja.
Tja, tja.
Da kann man auf jeden Fall sich auch noch eine Menge interessante Dinge überlegen,
was man damit alles machen kann.
Ja, ich glaube, im Platin-Mix sind wir so ein bisschen fast zu 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 sich 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?
Nochmals, habe ich dich schlecht verstanden.
Den PDM, das ist ein Python-Distro-Manager
oder sowas.
Was war der? Ich muss mal gucken.
PDM.
PDM, also ein Paketmanager,
den du entdeckt hast. Als Alternative zu Poetry
hast du den beworben.
Beworben habe ich den, glaube ich, nicht.
Ja, genau.
Ich war einfach da unsicher.
oder was, 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 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,
und
hat, über das PDM, also das heißt
Python Development
Habe ich auch noch nicht gehört, Karl.
Jetzt ist das M wieder weg,
das ist nicht dein.
Das hast du bei den Python-Tipps
gefunden. Ja, PDM
Moment, ich muss das wieder zurückführen.
Python Development Master heißt es.
Genau. 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 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.
Ich habe damals recherchiert an einem Abend, das mal so aufgeschrieben,
aber ich kann da jetzt keine Details
dazu sagen. Und genau, mir geht es
genauso. Ich tue nämlich den Artikel jetzt hier mal kurz
aktualisieren mit dem Poetry.
Ich bin aktuell einfach
bei Pip und das
klappt auch soweit eigentlich ganz gut.
Das Poetry konnte ich
nicht so richtig da...
Also ich verwende es nach wie vor, ich finde nur, man muss ja die blöden Bugs fixen, die uns allen auf die Nerven gehen.
Ja.
Also ich bin, wie gesagt, mit den PIP-Tools quasi auch nicht warm, dass das irgendwie...
Also ich meine, vom User-Interface her ist Poetry schon deutlich schöner.
Das Problem ist nur halt, es funktioniert nicht.
Ja, genau.
Ja, aber man muss ja nicht immer alles noch verdreckt wegschmeißen, wenn es kaputt ist.
Manchmal kann man sich auch ein bisschen zuverlässigieren.
Ja, gut.
Aber hast 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 viele Leuten, dass das
auch bei mir nicht funktioniert und
da habe ich dann, also wenn man da, ich weiß nicht
wie viele offene Issues da sind gerade
irgendwie
1000 oder sowas
und das ist ja nur ein einzelner...
Und alle gemeinsam an Poetrys Verbesserung arbeiten
und dann ist das Problem endlich alle mal aus der Welt
geschafft. Tja, tja
ja genau, offene Issues über 1000
also das ist halt schon, ja
und das ist halt nur ein einzelner Typ, der das in seiner Freizeit macht
Ja klar, kann man ihm ja auch keinen Vorwurf machen
Nein, eigentlich nicht.
Das ist alles prima.
Ja, aber es ist halt so beliebt, dass
so Sachen gefunden werden.
Ich brauche eigentlich Hilfe.
Ich habe hier Pip
und dann für Sachen kann man
noch Pip-Tools oben drauf nehmen.
Reicht erstmal voll aus.
Ja, Pip-Tools
habe ich jetzt auch letztens.
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 es funktioniert tatsächlich
ziemlich gut, muss ich auch sagen. Und das hat halt die ganzen
Paketfunktionen, die
Pultree hat halt nicht. Aber ehrlich gesagt, die brauche ich
auch nicht. Ja, also was
ich halt eigentlich nur brauche, sind eigentlich zwei Sachen.
Pultree Add, Pultree Remove,
Pultree Update und
Pultree Install. Ja gut, aber dann
ist es ja auch ungefähr bei dem, was PIP-Tools können.
Nur das PIP-Tool ist halt sehr unkomfortabel.
Ja, genau.
Naja, gut.
Ja. Aber irgendwie ist das noch nicht
aller Tage Abend, was das angeht, tatsächlich.
Ja, ähm,
weiß nicht, habt ihr noch was? Habt ihr eure 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.
Ähm, was habt ihr denn
da ausgesucht? Also ich fang vielleicht einfach an.
Ich weiß nicht, ob ich schon mal gesagt habe, das vergesse ich wie gesagt immer.
Ich muss das jetzt mal aufschreiben. Ähm, die Python
DevTools, kennt ihr die?
Das ist so, ähm,
Python DevTools, da kann man sich einloggen.
einfache Sachen, wie statt Print ein Debugstatement
in Python, was dann Prattit Print macht und so,
so einfach so ein paar Kleinigkeiten.
Ne, kenn ich nicht.
Wofür nennt man das, oder was ist das?
Einfach Python.
Was macht das?
Ich glaub, das ist ein anderes.
Guck mal kurz, ist das
auf die Doc, Help Manual,
I.O., irgendwie, Python minus DevTools,
ein Wort.
Ne, ist ein anderes.
Minus DevTools.
Help Manual.io
Nee, okay, das kriege ich nicht hin.
Ja, egal, auf jeden Fall, das sind nicht viele
Funktionen, aber irgendwie fand ich es ganz nett und das sah ganz
niedlich aus. Und ich mag ja so
moderne Terminal-Sachen sehr gerne.
Ah, noch ein Pick der Woche, ich habe meine
Dot-Files mal ein bisschen aktualisiert.
Die sind ja vor allen Dingen auch für
viele Windows-Nutzer ganz gut geeignet, weil ich muss das
ja auch auf der Arbeit nutzen und so. Und
da kann man sich jetzt, wenn man das vernünftig
installiert, unter einer PowerShell
die ganzen Modern Unix-Commands ziehen
und die alle reinpacken. Ist jetzt nicht so Python-spezifisch.
Aber auch Virtual Entwrapper habe ich eingebaut
nur die Funktion, die ich nutze, dass es nicht viele sind
damit es ein bisschen kompatibel ist, weil Virtual Entwrapper
PowerShell irgendwie nicht so richtig funktioniert hat
Das ist doch eine sehr gute Überleitung
Was benutzt du denn zum Managen deiner Dot-Files?
Tatsächlich Git
Was meinst du mit Managen meiner Dot-Files?
Naja, wenn du jetzt auf einer, du hast einen neuen Account
irgendwie auf einer anderen Maschine, loggst dich die ein
setzst du gerne deine Dot-Files da so wie überall sonst auch
Ich habe in meinem .files Repo für die jeweiligen Systeme, also im Moment ist es halt POSIX und Windows
und für Nix ist es auch was, aber das funktioniert nicht richtig, das ist halt nicht public.
Insideskripte, das heißt ich mache halt eine Admin-Shell auf und starte das Insideskript.
Dann klont er mir die eigentlich an die richtige Stelle, die meistens einfach home.dotfiles ist.
Dann im Insideskript führt er dann das Simulink-Skript aus, das heißt der linkt quasi von meinen
Konfig-Files komplett
auf die Konfigs von dem Programm, die ich natürlich
installieren muss, auch in dem Insidescript. Das heißt,
er installiert alle Programme, hat sie im Link und fertig.
Okay, aber
und welches Skript ist das dann?
Hast du das selber geschrieben? Ja.
Ah, okay. Ja, aber da gibt es
ja dann schon einige Sachen. Also ich habe
bisher immer .bot verwendet dafür.
Okay. Aber das ist
mir letztens irgendwie,
als ich,
ich weiß gar nicht, was der Anlass war, wo es mir dann kaputt
gegangen ist. 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.
Ich habe es alles noch ganz einfach selber geschrieben,
so viel es besser nicht ist.
20 Simlinks oder was der da setzt und dann
einmal Software mit dem jeweiligen
System Paketmanager installieren, den du ja
auch auf Windows installieren kannst. Dann musst du halt nur zuerst
den Paketmanager installieren.
Und dann musst du alles eh umsourcen.
Das macht ja alles drauf.
Und dann hast du immer auf jeden Fall die gleiche Shell, was ich immer sehr super finde.
und 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 Fischshelle da sehr dran gewöhnt bin,
weil ich sehr viel Zeit sparen kann.
Ja, genau,
und das Ergebnis war dann,
wäre dann mein Pick,
was ich jetzt versuche zu verwenden.
Also ich bin gerade dabei, das auszuprobieren und zu gucken,
wie ich das so hin bieten kann,
und das ist das Tool, was ich gerne davon hätte
und zwar das Tool heißt
Chessmois
genau
und
das
das ist so ein Go geschrieben
das ist halt so wie so ein, auch eines von den
wir haben ja momentan ganz viele
Systemtools
das 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 Files 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, ist halt
so ein statisches Binary, was keine Abhängigkeiten
hat, relativ leicht auf jeder Maschine
und
das hat halt
auch noch so eine Templating-Language mit drin,
womit man dann halt
sozusagen je nachdem, was auf der Maschine irgendwie
gesetzt ist, halt Dinge anders machen kann,
und Jochen unterhalten sich über die Programmiersprache Python
und probiert damit seit ein paar Tagen Dinge mitzumachen.
Und ich bin eigentlich sehr angetan.
Also ich glaube, das wird wahrscheinlich demnächst
meine neue Lösung zum Managen
meiner .files.
Das klingt sehr, sehr gut. Ich hätte da noch eine andere
Frage an der Stelle. Ich weiß nicht, ob das jetzt hier hinpasst,
aber
wo ich gerade versuche umzustellen ist, die ganzen
Keys, weil du gerade von geredet hast mit
Key-Repos und so, mit Yubi-Keys zu schützen.
Also zwei Faktor-Antentifizierung
da reinzubauen.
Geht das auch einfach so?
Bei mir funktioniert es auch so
Mittel gut. 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 an der richtigen Stelle
den richtigen Stick stecke.
Das müsste eigentlich funktionieren.
YubiKey ist halt
die Frage, wie man das
ich meine, ich würde es sowieso
ich meine, ich verwende ja OnePassword,
auch wenn es natürlich
irgendwie auch ein bisschen
unangenehm ist, dass er so teuer ist und dass es
ein sub-strukturales 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 durchsachte UI hat. Und das funktioniert auch mit Chinois.
Chinois, meine Güte, Französisch.
Franz, Vorsicht.
How to, ich weiß jetzt nicht genau.
Ja, ich muss mir das einfach mal durchlesen, das sieht auf jeden Fall sehr toll aus, weil genau das ist halt diese ganze Skripte,
weswegen ich alles nicht mehr machen muss, weil es alles schon automatisch weiß,
da muss ich dann eine Struktur halten von meinen .files, dann, irgendwie standardisiert oder so.
Ja.
Wahrscheinlich, ne?
Ja, mal gucken, vielleicht mag ich das, das sieht auf jeden Fall sehr toll aus,
dass man einfach sagt, Chemois und dann die gleiche Line mit Install dein Username und dann einfach nur Chemois update, das ist schon cool.
Ja.
Ja, ja.
Ja.
Und du?
Äh, ich?
Ja.
Ich nutze da kein Tool
also ich hatte da früher mal
das wenigstens noch irgendwie weggesichert
oder irgendwie so
also speziell nochmal extra zu einem normalen Backup
aber ansonsten habe ich da jetzt eigentlich
nichts Spezielles, weil ich da auch nicht viel
anpasse eigentlich
also
ja
ich nutze ja nicht den VI oder so
wo es so viele
Ja, ja, den muss man halt irgendwie ausgiebig konfigurieren
Ich habe vom Emacs mal weggewechselt
und da war das auch noch beim Emacs
Das muss man 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 Python, wo du drüber gestolpert
bist und sagst, das muss die ganze Welt kennen.
Ganz kurz, zum Beispiel
eine Sache, die ich gerade gesehen habe,
wo du sagst, dass Sachen installieren, wenn man
das macht, also ich habe
das ist eine der Geschichten, die ich gestern glaube ich gemacht habe,
schon mal, wenn dann
wenn das, man kann
Dinge skriptetifizieren, 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,
und 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.
Und das ist 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
Egal, dass das so ein bisschen...
Ich muss mir das auch jetzt nochmal angucken, wie der Use Case davon ausgedacht 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
hergenommen habe. Und dann kann ich mit
STRG ALT V
eben gucken, was ist in der Liste drin. Und da hat er
ja sogar auch Bilder drin und mit Formatierung
und so weiter.
Das ist, finde ich,
super praktisch und dann kann man halt natürlich auch in der Liste super schnell suchen, indem ich mit
Autocomplete halt eben hier die ersten Zeichen von der gesuchten Zeichenkette
eingeben kann. Und das finde ich sehr praktisch, dass man da so
eine Art Rucksack mit dabei hat, da kann man gut alles reingeworfen haben.
Also so ein Copy, also Buffer mit bären 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, überall Anwendungen hin. Ja genau, gibt es halt auch irgendwie, ist gut.
oder sogar auf Windows. Ich habe auch 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.
Aber 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.
Wieso? Oder was muss man da?
Das ist nicht so schlimm. Ich glaube, es gibt noch nicht so richtig gute Möglichkeiten,
zu testen.
Klar, natürlich.
Wie in jedem anderen View auch.
Da musst du gar nichts machen.
Das ist toll.
Dann habe ich nichts gesagt.
Ja, das ist tatsächlich sehr nett.
Dann wollte ich dich nicht weiter bei deinem
Boot picken.
Ja, Moment, aber ich würde gerne abschweifen und nochmal über JavaScript herziehen,
weil das noch nicht genau passiert ist.
Also ich habe ja jetzt in letzter Zeit auch so ein bisschen
Vue, Vue ist halt das Framework, was ich
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 denn wohl von Jest nicht, diese Clowns-Gaukler-Mütze
auf dem Kopf?
Ich weiß es nicht genau.
Ich gucke mal kurz bitte nach.
Kann sein.
Ja, ich musste auch Tests mit der schreiben.
Ja.
Ja, auf jeden Fall, das war halt echt,
oh, also.
Das ist der Gaukler-Schuh.
Also das ist ja jetzt auch quasi gar nicht mehr so neu und so und dann, ich bin mehrfach in Sachen reingelaufen, 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 halt tatsächlich nicht und zwar immer noch nicht und es ist halt auch und dann die Integration mit Vite ist dann halt schwierig und oh, also,
Die Developer-Experience
war eher so
mittelmäßig.
Allen Leuten, die glauben, dass
JavaScript-Entwicklung voll gut ist und
dass das noch nicht zugeliefert ist und dass man das unbedingt auf dem Server
machen möchte, dann
würde ich fragen, also ihr kennt schon so ordentliche
Web-Frameworks auf dem Server.
Habt ihr schon mal verwendet? Ja.
Habt ihr euch das mal angeguckt, wie das da so geht?
Und wenn nein,
guckt es euch mal an.
Aber 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 VUX-Store, genau.
Mit DevTools-Support und so, das ist ja auch, ja.
Aber das braucht man halt nicht, wenn man das so ganz
so weit macht.
Ja, naja,
jedenfalls, genau, da wollte ich noch mal kurz...
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
im Montag raus, dass ich noch nicht dazu gekommen bin.
Aber kann man sich mal angucken.
Da 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.
Hab schon gelesen. Ach so, sehr gut.
Ja, ich hab es zufälligerweise zugeschickt bekommen
vom Auto her.
Zum Probelesen.
Ja.
und es ist okay, genau.
Also ich finde es auch schön,
auch das vorgehende Buch von ihm,
Speedup, ja, 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, ja.
Na gut, dann noch mit diesen
Worten als Schlusssatz.
Bleibt es noch gebogen und teilt es wieder rein, das nächste Mal.
Ja, klar.
Und hört uns gerne immer, wenn ihr mögt.
und wünsche euch noch einen schönen Tag, Abend, Nacht, wo auch immer ihr seid.
Und bis dann. Tschüss.
Ciao.
Danke, Thomas.