Transkript: Javascript Frontends

Ja, herzlich willkommen, liebe Hörer und Hörer.

Willkommen beim Python Podcast in der 20.

Episode heute.

Wir sind wieder im Homeoffice, wie man es so macht, dieser Tage.

Remote dabei.

Ich hoffe, wir können uns gut verstehen.

Letzte Folge war etwas mehr.

Da war quasi inhaltlich sehr toll.

Wir haben uns vergessen, den Podcast zu erwähnen.

Das war auch echt blöd.

Genau, das ist der Podcast von Thomas heißt Pi Data Deep Dive.

Und ja, sehr empfehlenswert.

Ja, genau.

Kann man das schon hören.

Was machen wir heute?

Jochen ist natürlich wieder da.

Ich bin in meiner Hauptstentrale, Jochen im Wintergarten.

Ja, willkommen, Dominik.

Es ist jetzt so eine etwas ungewohnte Situation.

Wir sind irgendwie beide remot und wir haben hier auch noch so ein Video dabei laufen, aber das ist irgendwie so ein bisschen eigenartig.

Das ist nicht so richtig zum Anfassen.

Normalerweise sitzt man in meinem Podcast ja immer bei sich gegenseitig auf der Couch.

Und ich kenne das auch, wenn ich Podcasts höre, dass man immer bei den Menschen, die es machen, irgendwie mit dabei ist.

Und das ist gerade so ein bisschen schwierig, aber nett.

Natürlich nicht so richtig.

Heute machen wir Frontend mit Python und oder wie man das verbindet mit Python.

Ja.

So zumindest der Plan.

Weil da irgendwie wir beide halt so ein bisschen irgendwie mehr mit zu tun haben im Moment.

Struggle.

Ja, genau.

Aber vielleicht, ich habe auch noch so, ich weiß nicht, du hattest da ganz viele Fragen da in diese Themenliste reingeschrieben.

Und ich hatte mir dir auch mal, ich habe dann auch selber noch Sachen reingeschrieben, haha.

Und zwar zum Beispiel könnte man auch so ein bisschen metamäßig über Podcasts und Audio-Hardware und so reden, weil der hat sich ja ausgetan.

Oh ja, oh ja.

Ich meine, das ist natürlich jetzt irgendwie, alle Leute beschäftigen sich jetzt so ein bisschen mit, oh, man macht ganz viel mehr mit Video und Homeoffice und so.

Und komisch wäre eigentlich ganz nett, wenn man mal Internet hätte und man hat es aber irgendwie keins und so.

Und da ist das auch ein bisschen schwierig, jetzt so Audio-Hardware zu kriegen, weil das ist alles irgendwie ausverkauft.

Ja, ich wollte auch sagen, wir wollten das tatsächlich schon, ja.

Ja, sagt mal, wie ihr es Bescheid fandet jetzt hier mit dem Remote, mit dem Setup, wie sich das anhört im Vergleich zu sonst.

Übrigens die Liste, die du da geschrieben hast, ja auch, ne?

Also es gibt so ein paar Menschen, die mir dann eine Einkaufsliste schreiben, was ich alles so mitbringen soll.

Und ich schreibe es auch völlig durcheinander.

Also ich organisiere das so, dass ich den Supermarkt durchlaufe von Anfang bis zum Ende.

Da muss ich nicht die Liste immer durchscrollen.

Ja, ja, ja, es gibt auch offenbar unterschiedliche Strategien und ich wage nicht zu beurteilen, ob jetzt die eine sinnvoller ist als die andere.

Aber es geht ja nicht.

Es sind alle valide.

Genau, aber das ist das Problem.

Wir machen das sowieso immer, wir reden ja immer durcheinander und kommen dann wieder zurück zum eigentlichen Thema von daher.

Wir kriegen das schon irgendwie alles hin, genau.

Also zum Beispiel, was ich an neuer Audio-Hardware habe, ist, was ich schon immer mal ausprobieren wollte und jetzt habe ich halt irgendwie das dann auch mal besorgt, ist ein neues Headset.

Normalerweise verwenden wir immer diese DT297 von Bayer Dynamic.

Und die funktionieren auch super, also habe ich eigentlich nichts dran auszusetzen.

Nur das Problem ist, also ich bin, ich bin so Brillenträger und habe große Ohren.

Eine etwas ungünstige Kombination, die drücken mir, mir drücken die so ein bisschen auf die Ohren.

Also auch unangenehm.

Bei dir sieht man auch die Haare gar nicht, die sind auch länger geworden.

Wir waren alle in diesen Zeiten jetzt alle nicht beim Friseur alle so Mathe und Bart.

Wie heißt der bei Harry Potter so?

Ich werde immer so ein bisschen nach und nach Hagrid ähnlicher.

Vor allem die Statur, jetzt habe ich auch die anderen Attribute.

Ja, tatsächlich.

Also würde auch sagen, dass das der Charakter in Harry Potter, den du am nächsten kommst von der Optik, ja, ja.

Und genau, ich brauche halt große Kopfhörer-Muscheln und das bei dem DT797 ist auch ein Bayer Dynamic-Headset und da ist das halt irgendwie so ein bisschen größer, das ist ein geschlossenes.

Ich wollte ja gerade welche rein, aber der hat das leider kein Mikrofon.

Ah, okay.

Das ist mein Studio Kopfhörer.

Das kann man jetzt natürlich im Podcast nicht sehen.

Aber genau, ja, das sind auch so Studio-Aphörer.

Also das ist auch die Headset-Variante von einem, von dem DT790 Pro oder so, das ist auch eigentlich ein Studio-Kopfhörer.

Und da ist halt noch so ein Mikrofon dran gebastelt und ein Kabel dran.

Und ehrlich gesagt gefällt mir das, und das Problem, was ich auch habe, ist halt dadurch, dass das halt nicht so richtig auf die Ohren passt und dann liegt das halt auch auf der Brille so ein bisschen auf und dann quetscht mir das die Brille so ein bisschen.

Und das ist jetzt tatsächlich mit dem hier deutlich besser.

Also ich bin mal gespannt.

Das Mikrofon sollte das gleiche sein, also da sollte es keinen großen Unterschied geben.

Ja, okay, aber immerhin Komfort ist ja auch wichtig.

Genau.

Wenn man jetzt so lange sitzt und die ganz langen Folgen immer aufnimmt, weil wir viel zu erzählen haben, dann sollte das auch beim Tragekomfort entsprechend, ja.

Ja.

Und dann hatten wir noch ein.

Du hast gebastelt.

Du meinst diese mit dem HMC66, diese Bastelgeschichte?

Also du hast irgendwas gebastelt, du hast was zusammengesteckt und hast dann so eine Klinke an so einen XLR-Kopfhörer dran gemacht und hast das Ganze in ein Handy reingesteckt.

Ah, das genau, das ist total cool.

Das ist, denkt man sich eigentlich diese ganzen Geschichten, das sollten nochmal inzwischen gelöste Probleme sein, ne, irgendwie Headsets für Computergeschichten, das gibt es doch alles schon lange.

Aber es ist irgendwie gar nicht so.

Also wenn man das so haben möchte, dass es ordentlich klingt, dann ist das immer noch eine ziemliche Bastelei, beziehungsweise da muss man halt viele Dinge einfach wissen.

Und selbst wenn man sich damit so ein bisschen beschäftigt, reicht das nicht.

Ich kann auch sein, dass ich jetzt total einen Unsinn alles erzähle, weil so ein totaler Experte für diesen ganzen Audiokram bin ich natürlich auch überhaupt gar nicht, aber so nach und nach bekommt man dann halt Dinge mit.

Und eine sehr interessante Geschichte, die ich halt letztens gesehen habe, war, dass es gibt ein Headset, das so äh, das auch sehr gut klingt.

Das ist das HMC66X Superlux, weiß nicht, was das für eine Firma ist, keine Ahnung.

Das ist auch super billig.

Und klingt trotzdem super, also eigentlich alles ganz toll, ist natürlich nicht so gut verarbeitet wie die Bayer Dynamik-Dinger.

Aber eigentlich sehr empfehlenswert und verwenden auch ganz viele Leute.

Und das hat so ein Problem.

Also, was einem immer dazu gesagt wird, wenn Leute das benutzen, sagen sie so, ja, das ist total toll.

Und eigentlich ideal, aber man muss so ein bisschen, es hat so ein paar Probleme, wie zum Beispiel normalerweise, also müsste man eigentlich mal ausholen, wo ist eigentlich der Unterschied zwischen dynamischen und Kondensatormikrofonen.

Also nur mal so, um die Klammer aufzumachen, wir machen die gleich wieder zu.

Ich wollte davon eine extra Folge hören.

Ja, also die meisten, äh, die meisten kleinen Mikrofone sind tatsächlich Kondensatormikrofone, weil man sie deutlich kleiner bauen kann.

Und der Unterschied ist eigentlich in der Bauart sozusagen dynamische Mikrofone sind so ein bisschen wie ein umgekehrter Lautsprecher.

Die funktionieren auch, ohne dass man da irgendwie, ohne dass sie irgendwie selber aktiv sein müssen.

Das heißt, man kriegt ein Signal raus, ohne dass das irgendwie selber irgendwas macht.

Und das ist ganz praktisch.

Und sie haben halt so als Charakteristik, sie sind unempfindlicher gegenüber Störgeräuschen.

Und ja, so reagieren da einfach so ein bisschen gutmütiger oft.

Sind aber auch nicht so, kriegen nicht so feine Unterschiede hin und lösen nicht so fein auf wie jetzt ein Kondensatormikrofon.

Kondensatormikrofone sind so ein bisschen anders.

Die sind nicht passiv, sondern da muss Strom dran sein, sonst funktionieren die gar nicht.

Und da kommt dann halt aktiv ein Signal raus, das die dann halt erzeugen.

Und das Problem dabei ist, dass wenn das, also man kann sie sehr klein bauen, das ist eigentlich schön, aber wenn sie sehr klein sind, dann je kleiner die sind, desto mehr muss man das Signal verstärken.

Was dann natürlich auch wieder Rauschen reinbringt und so.

Also es gibt auch sehr gute, sehr kleine Kondensatormikrofone, aber die werden dann halt sehr teuer, sehr schnell.

Was man normalerweise macht, wenn man guten Klang haben möchte, ist halt, man nimmt dann halt Großmembran-Kondensatormikrofone, die halt dann schon mehr Signal, wo man halt weniger verstärken muss sozusagen.

Das ist halt so das ist so das, was man in Studios verwendet für Sprachaufnahmen.

Und so ein Ding habe ich auch umliegen, könnte man auch verwenden, aber man hat das normalerweise an so einem Arm und dann in so einer Spinne hängen und das ist so ein bisschen unhandlich, weil man irgendwie immer den gleichen Abstand einhalten muss dazu und so.

Wenn du das nicht machst, dann steht das irgendwie vor dem Bildschirm und versperrt den ganzen Sichtvektor.

Genau, also das ist alles so ein bisschen, hm.

Daher mag ich das mit den Headsets eigentlich lieber.

Aber die klingen halt dann vielleicht nicht ganz so gut, aber auch schon ziemlich klasse.

Und jetzt kommt der Heck und wir sind übrigens beim Python-Podcast, die bei Jochen.

Ach ja.

Naja, also der Witz ist eigentlich, also deswegen, warum ich das eigentlich erzähle, ist, man braucht, also die brauchen halt Strom, ja, sonst funktionieren die nicht.

Und Standard für Stromversorgung, man nennt das dann irgendwie von Atomspeisung bei Kondensatornmikrofonen, ist halt irgendwie 48, 24, 48 Volt normalerweise, sag ich mal so.

Es gibt aber auch 24 Volt und es gibt sogar 12 Volt.

Und dieses HC66X, das klingt bei 48 Volt und 24 Volt, also funktioniert es zwar, aber es klingt schrecklich.

Weshalb, da muss man immer aufpassen, da gibt so ein paar Reviews, unter denen, wenn man das irgendwo in einem Online-Shop sieht oder so, meistens oft ist dann so ein oder zwei dabei, die sagen: Das wird immer so gelobt, das klingt ganz scheußlich, ich verstehe das gar nicht.

Wie kommen Leute auf die Idee, dass das gut ist?

Das klingt doch ganz, ganz, klingt doch total elend.

Und ich fürchte, der Grund dafür ist meistens, dass die Leute das dann halt irgendwie an einem Audio-Interface betreiben, das halt dann die falsche Phantomspannung hat, sozusagen.

Und dann geht es halt nicht richtig.

Womit das gut funktioniert, ist halt 12 Volt Phantomspannung.

Und was man halt tun kann, ist entweder man lütet sich da so einen Widerstand rein, das ist halt so eine beliebte Lösung.

Jetzt wird es interessant.

Das ist aber für mich auch schon zu, das ist zu weit.

Nee, mach ich halt nicht.

Ich bin dann in den einfachen Weg gegangen und hab dann so eine, man kann da irgendwie so eine Box zwischen Mikrofoneingang von dem Audiointerface und das Headset schalten.

Das kostet dann auch nochmal 20 Euro oder so, keine Ahnung.

Und dann halt auf 12 Volt Phantomspannung das runterriegeln.

Oder da kann man das dann auch in dieser Box kann man das irgendwie einstellen.

Und ja, das habe ich dann halt benutzt und dachte mir da so, eigentlich, naja, selbst plus dieses Ding und plus den ganzen Kabelaufwand, ist es immer noch für den Preis eigentlich ziemlich unschlagbar.

Und was ich aber, und ich dachte immer, bitte?

Wie teuer ist denn das?

Ich gucke gerade.

Das kostet 39 Euro oder so.

Also es ist echt nicht teuer.

Und ich dachte Albert immer diese Kondensatormikrofone, die brauchen halt immer einen XLR-Anschluss, ne, also dieses dreipolige Ding da.

Und ja, das ist halt, du brauchst halt immer ein eigenes Audio-Interface eigentlich.

Normalerweise hat man an seinem Computer nichts sofort oder als Standard-Anschluss sagen.

Und dann hast du dir was gebaut, was richtig toll ist.

Nee, das habe ich auch gesehen.

Das habe ich auch in diesem Sender Gate-Forum gesehen.

Ich habe da nichts gebaut, ich habe es auch wieder nur gekauft.

Man kann das bauen auch selber, wenn man das mag.

Aber ich habe es nicht gebaut, ich habe es auch wieder nur gekauft.

DD, kauft dir die Welt, wie die DD gefällt.

Ja, es ist, also wenn mir das jetzt Spaß machen würde, das selber zu löten oder so, aber es macht keinen Spaß und ich kann es auch nicht adapten.

Jedenfalls hast du das Ding auf eine Klinke adaptiert.

Und jetzt kannst du das tolle Headset sogar in dein Telefon stecken.

Genau.

Und kannst mit dem coolen Headset Podcast aufnehmen über das Telefon.

Genau, ich dachte immer, irgendwie an der Klinke gehen nur dynamische Mikrofone.

Auch die meisten Mikrofone, die man über Klinke anschließt, sind dynamisch und die klingen halt nicht so gut.

Und das stimmt aber gar nicht.

Zum Beispiel ist es halt so, dass die meisten wirklich kleinen Mikrofone, also auch diese Dinge, die man sich so ans Hemd steckt oder so.

Wir haben ja auch mal am Anfang damit angefangen, mit diesen Rode, ich weiß nicht, wie man das ausspricht, Lavalier, Lavalier, keine Ahnung, Mikrofon.

Das sind auch üblicherweise Kondensatormikrofone und die kriegen ihre Phantomspeisung halt über die Klinke und da kommen halt so anderthalb Volt raus ungefähr.

Und diese 1,5 Volt reichen halt für dieses HMC-Headset auch.

Das funktioniert.

Das heißt, man braucht eigentlich nur einen Klinke auf XLR-Adapter und dann halt nochmal ein Ding, was halt auch irgendwie dann das zusammenführt, weil man halt ja nochmal einen getrennten Kopfhörer hat.

Wir stellen euch da eine ausführliche und detailische Liste in die Shownotes.

Und aber der Witz ist halt, also was ich jetzt habe, ist halt, man steckt dieses Headset halt in diesen Adapter, aus dem Adapter kommt Klinke, dann steckt man irgendwie die Klinke, die Klinke steckt man dann halt in einen Klinke auf Lightning Adapter und dann steckt man diesen Adapter in halt ein Telefon zum Beispiel.

Und es funktioniert tatsächlich.

Und ich war letztens damit im Park unterwegs, das sieht so ein bisschen komisch aus, ne?

Also ich wollte dich noch fragen, du hast gestern ja aufgenommen, hast einen kleinen Talk gehalten über Poetry beim Pi DDF.

Da warst du im Park wirklich, weil ich habe noch reingeguckt bei YouTube.

Oder hast du deinen Hintergrund geblendet?

Nee, da habe ich den Hintergrund verändert, weil es mir so gerade so ein bisschen umgekehrt ist.

Was machst du das mit OBS Studio?

Was ist das denn?

Das kenne ich gar nicht.

Das ist so eine Software, da kann man das ganz cool mitmachen.

Da kann man sagen.

Das war der Zoom-Client und der macht das dann halt, da kann man das irgendwie ausstellen.

Ach, na dann, okay.

Aber ich war tatsächlich mit dem Headset schon dann halt im Park und hab mit Leuten telefoniert und das Erste, was sie sagten, war so, oh, du klingst aber gut.

Oh ja, na dann hat sich das vielleicht gelohnt.

Und das ist natürlich irgendwie, ich hätte gar nicht mehr gesehen.

Also ich telefoniere auch immer im Park mit meiner Freisprechknopf, der auf dem Display ist.

Da steht dann Ton, laut, spreitwärts.

Ja, aber das funktioniert nicht so richtig gut.

Vor allen Dingen, wenn es windig ist, ist es halt blöd.

Oder wenn ich gehe dann auch manchmal in der Gegend rum und dann zum Beispiel, wo Leute sich regelmäßig beschweren, ist, wenn ich über die Rheinbrücke gehe, weil da ist es windig und es fahren Autos vorbei.

Und da verstehen meistens Leute dann nichts mehr und sagen so, oh, das klingt aber schlecht.

Und naja, muss man gucken.

Vielleicht, das nächste Mal prüfe ich das mit Headset, vielleicht geht das besser.

Ja, okay.

Channels accepted.

Bitte?

Channels accepted.

Und warum geht es über die Rheinbrücke?

Ja, ich weiß nicht, ich gehe da spazieren.

Achso.

Ja, meistens zum.

Zum Telefonieren.

Ja, ja, ja, ja.

Also meistens ist es halt so, wir sind halt im Hofgarten und dann kommt irgendwann die Ansage, ja, Steine ins Wasser werfen, dann müssen wir halt noch zum Rhein.

Und dann gehen wir in die Rheinbrücke und dann unten zum Rhein und dann werfen wir Stein ins Wasser.

Achso.

Als nächstes werft ihr einen Stein für mich mit.

Genau, also dieses Headset ist wirklich cool und was halt mit anderen wahrscheinlich gar nicht gehen würde, dass man das halt einfach so an ein Telefon anschließt oder so, das kann man damit machen.

Und möglicherweise gibt es damit halt eine Möglichkeit, wenn man das jetzt noch irgendwie schaffen würde, irgendwie an Studiolink oder an Ultraschall bzw.

Reaper das anzudocken, dann könnte man Leuten einfach sagen, hier nehmt diese Hardware, steckt das an euer Telefon, setzt euch irgendwo hin, wo es eine Sichtverbindung zwischen eurem WLAN-Access Point und eurem Telefon gibt und benutzt dieses Headset und dann hat man da eine ziemlich gute Audio-Verbindung.

Und das wäre ja eigentlich schon.

Achso, und ja, was auch praktisch ist, wenn man das Zoom H6, das ist auch so ein Audio-Interface, wo man vier Headsets dran stecken kann, wenn man das verwendet, das kann auch 12 Volt direkt Phantomspeiserung.

Also an dem Ding klingen die HMC 660X auch direkt gut.

Was natürlich auch sehr praktisch ist.

Und das wollte ich eigentlich sagen.

Das war mein erster Plan, das Ding einfach zu kaufen.

Und dann habe ich festgestellt, es geht nicht, weil alle Leute Audio-Interfaces kaufen, gerade wegen Corona.

Ich glaube, wir brauchen jetzt einen Webshop für so Audio-Podcast-Hardware.

Denn der haben wir gerade großzügig beworben.

Vielleicht brauchen wir da vielen Dings oder so.

Ja, Moment, Moment, Moment, ich bin noch nicht mit der.

Nein, okay.

Wir machen aber gleich eine Chapter-Marker.

Also Leute, ihr wisst ja, ihr könnt die Chaptermarks und die Sachen, die euch nicht so feucht sind, einfach überspringen und dann direkt aufs Frontend klicken.

Wolltest du mal so als Hinweis machen?

Ja, es gibt nämlich dann noch so ein bisschen mehr.

Wir sind ja jetzt auch mit, das hatten wir letztes Mal auch gemacht, aber, oder benutzen wir ja immer, wenn wir Remote-Geschichten machen, Studio Link, und das Knackste und Knickste und so immer mal so ein bisschen.

Und natürlich gibt es dann halt so gewisse Lösungen, dass man das dann halt lokal so Double-Ender-mäßig irgendwie auch nochmal aufnimmt und in die Spur hinterher irgendwie mitverwendet oder aber das ist alles schwierig und dann gerät das von der Zeit her irgendwie so aus Synchronisation alles nicht so schick.

Und dann haben meistens erschließt man sich dann in der Lebman halt mit den Knacks an.

Aber das klingt schon relativ furchtbar.

Und jetzt haben wir halt hier eine Beta-Version von Studio Link und die knackst praktisch gar nicht.

Jedenfalls.

Ja, wir werden es hören.

Wir werden es dann hören, aber nicht, dass ich das jetzt irgendwie bisher bemerkt hätte.

Also für mich klingt das momentan alles sauber und machen wir schauen.

Weil das ist natürlich das Problem.

Also eigentlich ist es natürlich auch doof, dass wir hier WLAN haben, müsstest eigentlich ein Kabel legen, aber das ist halt alles irgendwie so.

Nee, du hast kein Kabel.

Ich habe ein Kabel gesehen.

Also ich könnte, was ich vielleicht temporär machen könnte, ich kann einfach ein Kabel dann halt immer hier durch die Tür liegen.

Aber das Problem ist ja der Wintergarten, der ist einfach sozusagen getrennt.

Das ist eine Außenmauer dazwischen.

Und ich weiß nicht, wie ich dieses Kabel durch die Außenmauer kriege.

Das geht halt einfach irgendwie nicht.

Bohrmaschine.

Ja, gut.

Ja, wo wir wieder beim Löten werden und so, das ist alles nicht so mein Problem.

Also ich habe hier tatsächlich in die Etage ein LAN-Kabel gelegt.

Okay.

Ja, es gibt bestimmt irgendeine Lösung.

Und wahrscheinlich sollte ich da auch mal was tun, weil WLAN ist auch echt tatsächlich nicht so geil, muss ich sagen.

Also richtig mit in der Wand und Dose und so.

Ja, das ist schon viel cooler.

Ja, das war nicht Bohrmaschine, das war so ein Pressstemmhammer.

Da musste man so die Wand aufruppeln und dann eine Diskabe rein und dann verspachteln und so.

Klingt alles sehr schrecklich.

Was mal anfassen.

Ja.

Okay, lass mal überlegen.

Habe ich da noch, äh, ist da noch irgendwas mit.

Da steht noch Sencaster drin auf der.

Achso, ja, das wäre halt auch noch eine andere Möglichkeit gewesen.

Was das?

Wie man das jetzt macht ohne Studio Link, aber weiß ich gar nicht, ob er.

Also das ist halt, äh, also interessant finde ich es deswegen, weil es einen ganz anderen Ansatz verfolgt, ja, während wir.

Ganz was, was ist das?

Das ist sowas ähnliches wie Ultraschall, sozusagen.

Also die Software, mit der wir das Ganze aufnehmen.

Achso.

Nur nicht, dass es halt eine Applikation ist, die nativ läuft, sondern das läuft alles im Browser.

Und dass alle Leute connecten sich halt zu einem Server sozusagen und dann.

Weil das ja so gut klappt mit dem Browser und Audio und Video, wie man ja jetzt ein GT und.

Es gibt ja so ein paar komische Geschichten.

Also, das zum Beispiel, das hat mich dann gewundert, als ich das dann mal ausprobiert habe, dass irgendwie alles geht dann da auf 44,1 Kilohertz und das ist ja sehr unüblich.

Also normalerweise hast du ja immer Audio-Hardware, das ist immer alles auf 48 Kilohertz.

Und das ist natürlich dann seltsam.

Dann muss man dann halt irgendwie das irgendwie umsampeln und ich weiß nicht.

Aber also Leute verwenden das und finden das gut.

Und ich habe es jetzt tatsächlich noch nicht für einen Podcast, ich habe es jetzt mal ausprobiert, ich fand es auch super und ich finde die Idee halt total toll.

Also eigentlich wäre es natürlich schon saucool, wenn man das alles im Browser machen könnte und nicht noch extra Software installieren müsste und das halt automatisch überall funktioniert.

Aber gerade sowas wie, ich habe hier ja auch so ein Mischpool, das geht alles nicht, sondern es ist halt so, alle verbinden sich halt mit ihrem Ding halt irgendwo hin und dann werden dann auch mehrere Spuren aufgenommen, aber du hast halt nicht die Möglichkeit, das nochmal durch ein eigenes Mischpool zu schleifen oder so und dann da so regeln.

Tragisch, tragisch, tragisch.

Ja, natürlich, wer braucht das auch, ne?

Es ist, ja, ja, ich verstehe schon.

Es ist aber.

Nehmen wir mal an, zum Beispiel eine Geschichte, für die man das schon braucht, ist halt, wenn man jetzt einen Livestream hätte.

Ja, und dann hat man, macht man, hat man da so Dinge drin wie Audiokompression oder so, die man dann halt möglicherweise so hoch und runter regeln will und vielleicht noch irgendwie so eine, weiß ich nicht, eben so ein Soundboard und weißerte Teufel.

Und das ist dann alles ziemlich, das geht dann alles nicht mehr so richtig, ne?

Aber ja, naja, gut, okay.

Also ich weiß es nicht.

Dann überlegen wir uns das nochmal.

Was hältst du eigentlich davon, wenn wir diese Meta-Diskussion, diese Ausufernden an das Ende der Folgen stellen oder schneiden?

Damit unsere Hörer, die sich auf das Frontend und Python freuen, nicht wie lange?

20 Minuten oder.

20 Minuten schon.

Weiß ich nicht.

Ich habe nicht genau gestoppt.

Nein, also ich mag das und ich finde das super, aber es ist halt off-Topic.

Und schreibt uns doch mal an hallo at pythonpodcast.de, was ihr davon haltet, ob ihr gerne vorher so Sachen hört oder einfach sagt, nee, dann lieber vorher das Python-Thema und am Ende dann mache ich einfach aus.

Oder ich höre das sehr gerne und bitte erstmal weiter die ganzen Metasachen.

Ja, gut.

Sollte man vielleicht an den Schluss packen.

Okay, alles klar.

Jochen, welche von den Videokonferenz-Tools nimmst du eigentlich am liebsten?

Also, wenn wir jetzt schon bei dem Thema sind.

Das ist ja gerade ganz aktuell.

Weiß ich nicht.

Also, Zoom hat man jetzt tatsächlich von der Anwendung.

Also man hört immer ganz schreckliche Geschichten davon.

Ja, also man, genau, also was Security angeht und diese Geschichten ist, Zoom natürlich hat er eine ziemlich vernichtende Bilanz so bisher.

Wenn man das bedient, ist es aber tatsächlich relativ nett.

So fast am nettesten.

Also ich habe Zoom mal auf einem Windows-Rechner angemacht und das hat mir direkt Dinge in die Registrie reingeschrieben und Rechte geklaut, die ich niemals erlaubt hatte, dass es hätte haben sollen.

Und es hat auch vor allen Dingen nach Beenden der Applikation nicht alles so entfernt, wie man sich das vorstellt.

Das fand ich ehrlich gesagt ein bisschen frech.

Also was ich sehr cool finde und auch fand, ist Big Blue Button.

Das habe ich tatsächlich selber noch nicht ausprobiert.

Das finde ich tatsächlich bisher am schönsten.

Das hat auch so verschiedene Räume.

Das werden wir jetzt an Python Camp, das am Morgen stattfindet.

Nee, morgen, übermorgen morgen.

Ja, wahrscheinlich benutzen.

Das ist sehr cool.

Das ist auch Open Source, Foss.

Ja, also falls ihr uns noch wollt, ich weiß nicht, wann wir die Folge wieder veröffentlicht bekommen.

Python Camp ist übermorgen.

Das ist, genau, das ist übermorgen.

Könnte knapp werden.

Wir haben ja jetzt so ein bisschen Erfahrung schon, der paar DDF-Sprint war ja auch irgendwie virtuell.

Das hat eigentlich ganz gut geklappt.

Da haben wir Jitsi verwendet.

Ja.

Das war jetzt auch nicht so schlecht.

Ja, Jitsi ist gut, wenn es mit bis zu 10, 15, 20 Leuten ist das ganz gut.

Ja, also sehr gut sogar.

Ja, also Zoom habe ich jetzt, haben wir jetzt bei dem letzten paar DDF-Treffen benutzt.

Fand ich ehrlich gesagt sogar ein bisschen angenehmer.

Aber so viel nimmt sich das alles nicht.

Und dann ansonsten, was ich halt häufig benutze, ist halt Teams.

Eher so, weil es halt, weil halt muss.

Nicht, weil man es sich.

Das benutzt man immer nicht, benutzt man eigentlich fast nie, weil man es sich ausgesucht hat.

Sondern das ist halt halt irgendwie dann so die.

Ich dachte, das wäre bei Zoom so.

Ja, ich glaube, die Idee dabei, das jetzt bei PyTDF zu verwenden, war auch, dass das halt ausprobieren, was für unterschiedliche Dinge, wie unterschiedlich funktionieren, auch im Hinblick auf die Europython, die er da da mitnimmt.

Ja, Europython wird Zoom nehmen.

Ja?

Das ist schon fest, ja?

Achso, das ist schon fest, okay.

Die haben sich auf Zoom geeinigt, ja.

Ja, naja.

Also Jitsi hat es sich geschafft wegen dem Bug in Firefox, das tatsächlich halt noch nicht behoben ist und weil es vor allen Dingen sich nicht so gut skalieren lässt.

BigBoo-Platten ist rausgeflogen, weil das mehrere Server bräuchte dann oder viele, die vom einen Richtungsaufwand her ein bisschen höher sind.

Ja.

Da blieb er nicht mehr so viel übrig.

Ja, keine Ahnung.

Also für mich ist das diese Frage einfach auch noch nicht geklärt.

Das ist halt.

Der Chat von Europe geht übrigens über Discord.

Ach, okay.

Weil er gesperrt werden soll, weil der geflutet worden war, zwischendurch mal von ein paar bösen Buben.

Sowas, sowas.

Naja, also wie gesagt, also Teams funktioniert auch so halbwegs okay, aber ist ansonsten irgendwie nicht so meine favorisierte Software für diesen Kram.

Was ich höre, was super sein soll, ist Miet.

Also die Google-Geschichte.

Habe ich aber selber auch noch nicht probiert.

Hangouts kenne ich.

Habe ich vorher immer gemacht.

Ist dasselbe.

Haben sie umgestellt aufs Miet?

Also Hangouts haben sie geschossen.

Das geht jetzt nur noch bei Miet und das ist eigentlich ganz gut.

Also ich benutze auch öfter mal Wareby.

Ja, Wearbuy finde ich auch gut.

Ja, und das ist auch tatsächlich von der Qualität her in Ordnung, aber das ist halt, ab vier Leuten muss so Premium-Account bezahlen und deswegen.

Ja, und ansonsten nicht, weil gut, es gibt noch Skype und sowas, aber das ist alles, das verwendet eigentlich auch fast niemand mehr.

Ich würde gerade sagen, nimmt das noch jemand.

Aber man kann glaube ich sogar Videokonferenz einen Stack machen, habe ich dessen gehört.

Oh, aber was ich, ah nein, nein, eine Sache, die ich super finde tatsächlich, das benutze ich privat eigentlich.

Ich habe noch nicht erlebt, dass das jemand irgendwie in so einem Berufskontext verwendet hat, aber privat.

WhatsApp-Video.

Naja, gut, das hat also okay, das sind halt.

Sorry, könnten wir sagen.

Nee, das habe ich tatsächlich, glaube ich, noch nie gesehen.

Aber FaceTime, Apple.

Und das funktioniert auch sehr, sehr gut.

Also gerade in Situationen, wo man halt mit mehreren Leuten dann halt um so ein Gerät rumsitzt, ist das eigentlich ziemlich klasse, weil das dann halt auch so, es hat auch so nette Effekte, dass dann die Leute, die reden, werden dann halt größer und angezeigt und solche Sachen.

Und das ist halt, äh, der Client auf den auf iOS-Geräten ist halt super.

Also ich glaube, es gibt ja auch keine anderen, es gibt ja nur die.

Ja, wir wissen ja mittlerweile, dass du diese Firma mit dem Apfel da ganz gerne magst.

Ja, tatsächlich.

Also das funktioniert einfach ziemlich gut.

Ja.

Kann man aber auch eben höchstens dann verwenden, wenn Leute eben zumindest irgendein iOS-Gerät haben oder irgendwie Apple Hardware, ja.

Also insofern.

Also das passiert übrigens, liebe Hörerinnen und Hörer, wenn zwei Backender sich über Frontend unterhalten in einer Folge.

Dann reden wir über Videokonferenzsysteme.

Ich wollte tatsächlich sagen, das Modul aus der Standardbibliothek, was wir noch vorstellen wollten, das wird Unitest Smog sein.

Machen wir tatsächlich diesmal am Ende.

Und fangen jetzt tatsächlich an, ein bisschen über das Thema Frontend zu reden, oder?

Ja.

Alles klar, können wir gerne machen.

Ja, News?

Noch, na komm, News.

War noch die News.

Okay, warte.

News Python jetzt.

Also jetzt geht's los, Leute, ihr dürft jetzt einschalten.

Ja, was hatten wir denn da so?

Aufgeschrieben mit Language Creators Conversation.

Das war das.

Achso, das war das Panel mit Guido und dem Typen von Rust und äh,

nee, nicht Rust.

Ja.

Larry Wall von Pearl.

Dann James Gosling von Java und André Halsberg, der hat Tubo Pascal in den 80ern mal entwickelt.

Auf Delphi und sowas.

Ohne Galaxy Farbe.

Ja, ja, der ist, da hat er so, oh ja, da müsste ja jetzt jemand mit so einem Rückstock und so einem Uraltag greisen.

Das ist ja auch noch gar nicht so alt.

Und der hat jetzt auch irgendwie war da eine der treibenden oder vielleicht die treibenden Kraft hinter TypeScript.

Also ganz interessant.

Ja, und ich weiß gar nicht, in welchem Rahmen diese Veranstaltung da gelaufen ist.

Ich habe es halt eh dann als Podcast quasi gehört.

Die Audioqualität ist leider ziemlich schrecklich.

Also ich benutze dann immer in meinem Podcast-Player so ein Sight-Load-Ding.

Das heißt, ich sage in meinem Browser auf dem Telefon, Sidelot an meinen Podcast-Player und dann leert es das Video runter, schmeißt das Video weg und das Audio geht dann halt als Podcast-Episode in meinen Player rein.

Das heißt, ich habe das Video nicht gesehen, aber das Audio gehört.

Und das ist natürlich ein bisschen, ja, das ist oft, auch bei vielen Talks ist das Audio oft relativ schlecht, sodass entweder muss ich dann die Lautstärke sehr hochdrehen oder man versteht halt nicht mehr.

Wir wissen ja, du bist ein bisschen picky, was das angeht.

Ja, gut, kann sein, aber das ist halt auch, das ist halt der Fluch, wenn man sich damit beschäftigt, dass man das dann plötzlich hört, wenn es nicht gut ist.

Naja, aber das wirklich schrecke, das war teilweise kaum zu verstehen, weil so viele, fiese Nebengeräusche dabei waren.

Aber inhaltlich sehr interessant.

Also ich meine das natürlich auch total toll, dass man da mal irgendwie halt so zumindest vier der wichtigsten Entwickler von Programmiersprachen, die halt halt das, was wir hier so tun, also einen großen Teil von dem, was Leute so machen, halt wesentlich geprägt haben, halt dann die einen und fahren mal alle zusammensitzen und dann halt darüber reden, wie sie das so sehen, was so diverse Dinge angeht.

Und das war, das war schon sehr interessant.

Und ja, kann ich nur empfehlen, sich das mal anzuhören.

Ist toll, ja.

Habe ich noch nicht geschafft tatsächlich reinzuhören.

Ja, also ich weiß nicht, ob es da irgendwas gibt, was man da.

Naja, muss man sich einfach mal anhören.

Also das fand ich als Geschichte, die jetzt gerade passiert ist, die man sich mal angucken kann, irgendwie sehr nett.

Ansonsten, weiß ich nicht, was gab es noch alles für News-Geschichten.

Django 1.1 ist End of Life.

End of Life, ja.

Das ist auch, dass das irgendwann passieren wird, ist klar, weil jetzt ist tatsächlich die letzte Python 2 unterstützende Django-Version weg.

Das heißt, Python <unk> ist wirklich auch bei Django so endgültig raus.

Das heißt ja, also wenn man da noch irgendwie auf so einer Longtime-Support-Version gesessen hat, dann ist jetzt auch mal Zeit, da irgendwie was dran zu machen.

Eine andere Geschichte war noch, dass ich verwende meistens PyTest statt dem Unitest-Modul für, also und Unitest-Mock für Mogs, aber für die normalen Tests, also als eher Py-Test, weil ich das angenehmer finde.

Also weil bei Unitest gibt es so ein paar, also bei dem Unit-Test-Case-Klasse zum Beispiel aus dem Unitest-Modul verwendet, so ein paar Dinge, die ich so ein bisschen komisch finde, wie halt diese Camel-Case-Notation, das kommt halt alles auch so ein bisschen.

Ich glaube, das ist halt auch irgendwie sehr inspiriert von JUnit.

Und das ist halt, das ist halt so ein bisschen komisch, das hinzuschreiben.

Ich meine, man gewöhnt sich zwar auch dran, aber es ist irgendwie.

Und Pytest hat halt eine sehr schicke Art, wie man, wie man Fixtures halt definieren kann.

Das heißt, wie man sozusagen die temporäre Testdaten, die man sich dafür generiert, um halt einen Test ausführen zu können, wie man die halt.

So baut, dass sie für die Fixtures passen und nicht für die reale Welt.

Ja, genau.

Und die kann man auch schön verschachteln und aufeinander abhängen lassen und so.

Und das funktioniert eigentlich ganz.

Es ist halt, ist halt nett und man, und dass man halt irgendwie direkt Assert verwendet und nicht irgendwie Methoden, die man dann aufwendet.

Ja, also jetzt, weil man da halt bei diesen Methoden sieht man nie so direkt, was passiert bei dem Assort, ist halt klar, dass da nicht noch irgendwie versteckt was schief gehen kann, weil da ist nichts mehr.

Das ist halt.

Und ja, also insofern Pi-Test mag ich mag ich durchaus lieber.

Aber das Projekt hat halt irgendwie so auch ein bisschen eine unruhige Gefahr.

Es gibt da gab irgendwie vier Maintainer und jetzt sind drei davon weg.

Oh.

Ja.

Das ist viel.

Ja.

Das sind 75%.

Das sieht nicht so gut aus, ja.

Und keine Ahnung.

Wird das geforgt?

Ja, keine Ahnung.

Vielleicht gibt es dann irgendwas anderes.

Vielleicht, aber das ist halt natürlich, für mich ist es halt blöd, weil jetzt, oder ich meine, für alle ist es ja insgesamt halt blöd, weil jetzt muss man sich natürlich überlegen, okay, hm, was macht man denn jetzt?

Naja, ich hoffe mal, dass sich das alles irgendwie zum Guten wendet, aber das ist natürlich so ein Problem generell, ne, bei Open Source Geschichten.

Wie stellt man das eigentlich sicher, dass so ein Projekt nicht irgendwie plötzlich kaputt geht an irgendwas?

Ja, manche einige Sachen sind ein bisschen nervig.

Ich habe ja Pi Env, ne?

Auch sehr lieb gewonnen eigentlich.

Auch von dir hast du den schönen Tipp gegeben und das habe ich dann auch auf Windows zum Laufen gebracht tatsächlich.

Das ist aber sehr schrottig in Visual Basic implementiert.

Diese Windows-Variante und war nicht so super maintained.

Ich habe es jetzt aber hinbekommen, indem ich mir einzelne unbeantwortete Pull-Requests gezogen habe, die Funktionalität so wiederherzustellen, dass man damit einigermaßen arbeiten kann.

Aber ja, sowas ist ja ein bisschen ein Gefrickel.

Ja.

Ja, aber ich würde sagen, News hast du noch einen?

Hast du noch was?

Lass mal schauen.

Also außer dass es jetzt alles online ist, was wir schon wissen.

Ja, ansonsten, ich habe hier noch einen Punkt aufgeschrieben, weil was halt auch vielleicht für andere interessant ist, halt so, es gab ein paar Artikel zu Django-Architektur.

Ich weiß nicht, ob wir das fast aufmachen wollten.

Lassen wir das auch einmal zu.

Du meinst für heute, du machst das nicht mehr.

Ja, weil wir jetzt eh schon.

Fährt Models und so weiter.

Genau, genau, genau.

Das wäre sozusagen Service Layer und dieser ganze Kram.

Ja, also wir wollten auch unbedingt dringend drüber reden.

Also was war eigentlich, wann ist eigentlich das Django Metup Cologne?

Das war schon.

Das war jetzt, glaube ich, am Dienstag.

Oh, dann habe ich es verpasst.

Ja.

Du auch?

Ich auch, aber ich konnte Dienstag halt nicht.

Ja, ich auch nicht.

Ja.

Ja, so ist das.

Naja, ich würde sagen, das verschieben wir auf irgendeine Django.

Django Folge.

Django reden.

Wir reden jetzt übrigens über Django-Backend und JavaScript Frontend.

Ja.

Ja.

Genau.

Und beim Thema angekommen, Leute, unglaublich.

Super, dass ihr noch da seid.

Manchmal dauert das halt so ein bisschen, da muss man sich auch die Zeit nehmen und da auch mal irgendwie.

Möchtest du jetzt unseren Hörern vorschreiben, wie sie unseren Podcast hören sollen?

Nee, dann kommt Kapitelmarken und da kann man sich das dann naja so sagen.

Also Leute, Kapitelmarken gehen so, ihr klickt so lange auf Weiter, bis ihr das hören wollt, was ihr hören wollt.

Oder auf zurück, um es immer noch mal zu hören, was euch besonders interessiert habt.

Ihr könnt sogar bei bestimmten Podcast-Clients das auf Dauerschleife setzen.

Und zum Einschlafen benutzen.

Genau.

So.

Ja, also wie kamen wir eigentlich auf diese Frontend-Geschichte?

Wie sind wir eigentlich auf den Hund gekommen sozusagen?

Oder was ist dein Problem?

Ja, also wir entwickeln ja relativ viele Webtoys und auch Dango natürlich oder Flask, aber hauptsächlich Dango.

Und das muss man ja, wenn man nicht die Dango-eigene Template-Engine benutzen möchte, was man natürlich machen kann für so grundsätzliche HTML-Dinge mit TSS und ein bisschen Bootstrap vielleicht, funktioniert das ja wunderbar.

Aber wenn man so ein bisschen ein größeres Projekt machen will, dann ist es halt häufig so, dass man Dango mit einem Frontend benutzen möchte, einem Framework.

Da ist dann Vue drin oder React oder Angular.

Und Dango wird auch noch ohne Kopf, also Headless, benutzt und dann per APIs angesprochen.

Und da gibt es immer so ein paar Falltrücke, wie man das implementiert und was da überhaupt alles dazugehört und worüber redet man da überhaupt, was heißt denn der ganze Quatsch?

Und diese ganze JavaScript-Welt ist ja gerade für Python-Entwickler.

Erstmal so ein bisschen ein Buch mit sieben Siegeln.

Also ja, es gibt einige Backends, die sagen, oh, Frontend, aber wenn man da so ein bisschen drin ist, merkt man so, oh, das ist gar nicht so einfach, wie man früher vielleicht dachte, sondern das ist tatsächlich ein ganz schöner Stack da.

Und da muss man auch ganz schon was können, ist ganz schon was wert, wenn man ein guter Frontendler ist.

Und wenn man irgendwann mal diese Fullsteck richtung möchte, dann muss man das mit Sicherheit auch mal zumindest so gesehen haben, dass man weiß, was man da tun könnte.

Und vor allen Dingen muss man das Frontend ja auch irgendwann mit seinem Backend wieder zusammenschnüren können.

Das heißt, man muss zumindest ja dann die Schuhe zubinden und das irgendwo auf den Server packen, dass das dann auch beim Kunden oder bei einem selber auf dem Server irgendwie rennt und nicht wieder auseinanderfällt.

Und wie man das alles macht, das wäre doch eigentlich mal ganz interessant, so ein bisschen zu besprechen.

Ja, genau.

Ja, ich bei mir ist es so vor allen Dingen, dass ich, ja, ich meine, genau, mir schon immer mal View angucken wollte und jetzt kam dann irgendwie so ein Ding vorbei.

Ob ich nicht, äh, ich habe mich dann in diversen View-Meetup-Gruppen irgendwie so angemeldet, aber da ist dann irgendwie nichts passiert.

Die Anmeldung ist immer das Wichtigste, ich habe auch so eine Metup-Gruppe.

Da melde ich mir ganz viele Leute an, die kommen aber nie.

Also 50 Leute ist die für bezahlte Leute die Grenze, die man erreichen darf an Anmeldungen, bevor es noch teurer wird.

Und ja, ich habe halt wirklich 50 Leute in der Gruppe drin, das hört sich immer wieder auf.

Also wir machen Computerspiele Unsinn.

Und es sind drei Leute immer da.

Drei.

Ja, genau, also das passierte nicht, sondern gab es irgendwann so den irgendwie diese Gruppe ist nicht mehr mehr intent.

Möchtest du das nicht übernehmen?

Dann habe ich dann einfach irgendwie, ohne darüber nachzudenken, einfach auf, ja, warum nicht geklickt.

Und jetzt muss ich mal überlegen, was ich damit mache, aber ich wollte ja sowieso View lernen.

Also das wäre auch noch so eine Idee, dass man das eventuell, das wäre einfach eine virtuelle View, Django, weiß ich nicht, Gruppe draus machen, wo man dann halt vielleicht mal so ein bisschen interaktiver versuchen könnte rauszukriegen, wie man das Ganze so benutzt.

Und ja, müssen wir mal überlegen, aber das wäre halt auf jeden Fall eine Möglichkeit.

Und aber View ist sowieso, also aus diversen Gründen, das, was ich mir jetzt mal halt im nächsten Jahr angucken.

Was denn hauptsächlich?

Also ich finde das so, diese Komponenten finde ich sehr intuitiv schön.

Ja, das hast du aber geschmeidig.

Das hast du eigentlich inzwischen.

Also das ist keine.

Also ich muss gestehen, ich habe mir Angular nur so ein bisschen angeguckt und React habe ich noch gar nicht gesehen.

Aber ich finde das mit Vue die Komponenten hervorragend.

Was das Wort macht, was das denn so ein Frontend-Framework oder

ja, ja, genau.

Aber gerade für uns Python-Entwickler ist erstmal so ein bisschen Overhead.

Man installiert sich dann über NPM oder wie auch immer, also Note.js, was man da macht, dann das Paket von Vue und startet dann mit VueCreate ein Projekt und es werden erstmal 20.000 Pakete aus dem Repositorium gezogen und als Module da irgendwie gepackt.

Tja.

Ja, das ist halt, das ist so ein bisschen JavaScript, ne?

Das gibt es halt keine Standardbibliothek und dann muss halt irgendwie alles Anabhängigkeiten bis ganz runtergeholt werden, was man irgendwie brauchen könnte.

Und das ist alles unterstützt

eine Moment.

Das ist schon

naja, so ist es halt.

Da kann man jetzt auch nichts mehr dran machen.

Aber also die Unterschiede, ich glaube, also die drei großen, so wie eben View, React, Angular, oder ich würde eher sagen, React ist das größte Ding zurzeit wahrscheinlich.

Angular und dann Vue oder wie auch immer, ist ja auch egal, die kann man alle benutzen, die sind alle gut und so wahnsinnig groß sind die Unterschiede ja jetzt gar nicht.

Es ist nur so, dass für mich ist View deswegen interessanter, weil halt es nicht irgendwie sozusagen das Spiel, dass das Projekt irgendwie von einer Firma ist, sondern es ist halt sozusagen unter den dreien das einzige Open Source Projekt in dem Sinne.

Weil ich meine, klar, natürlich ist auch Angular und React ist irgendwie Open Source in dem Sinne, dass das halt das sehr code verfügbar ist.

Aber wenn ich jetzt da irgendwas dran erlernen möchte oder möchte, dass sich das mehr in eine Richtung entwickelt, die nützlicher für mich ist und nicht so sehr für Facebook, dann kriege ich meine Pull-Requester ja doch nicht durch, weil die bei Facebook da drauf sitzt und oder bei Angular sitzt halt Google drauf und die entwickeln das halt.

Das heißt, ja, das ist halt vor allen Dingen an die Bedürfnisse von denen angepasst und da sehe ich bei Vue zumindest die Chance, dass das halt so ist, weil ich glaube nämlich tatsächlich, dass die Anforderungen von Firmen wie Facebook oder Google halt unter Umständen ein bisschen anders sein könnten als das, was halt so man braucht, wenn man jetzt halt aus einem kleineren Rahmen irgendwie Dinge hochzieht.

Ja, nicht leckern knotzen, Jochen.

Ja.

Genau, warum nicht das nächste, genau, einfach Google-Konkurrenz.

Ja, also es ist daher denke ich, Sview so für unabhängige Leute irgendwie schon das interessantere Projekt.

Aber keine Ahnung, kann auch vollkommen falsch sein, wer weiß.

Jedenfalls, wenn man sich, wenn man es halt eh mehr oder weniger egal ist, dann kann man ja vielleicht das mal verwenden.

Und React und Angular habe ich auch schon so ein bisschen mit Dingen gemacht und React hat mir tatsächlich ziemlich gut gefallen.

Angular nicht so richtig, ehrlich gesagt.

Und warum?

Und was ist das aber und was macht man da?

Also vielleicht erklärst du nochmal so einen ganz Anfänger, was das denn überhaupt ist und wie man das so macht.

Also ja, was der Witz daran ist eigentlich, also ich, ja, das ist die Frage, wo man ansetzt.

Man könnte natürlich sagen, naja, zunächst einmal gibt es halt nur so Standardweb mit irgendwie HTML, CSS und JavaScript eigentlich mehr oder weniger nur so als unterstützt halt irgendwie bestimmte visuelle Geschichten oder so und dann irgendwann kam halt mit, da hat der Internet Explorer halt diese XHTP-Request-Geschichte mit eingeführt und damit wurde es dann halt interessant.

Das Ganze lief dann so in Richtung, das lief dann halt unter dem Stichwort Web 2.0, weil jetzt halt Webseiten ohne eine komplette Seite neu rendern zu müssen, halt Dinge auf der Seite ändern konnten.

Und dann hat man da irgendwie so ein bisschen dann die Browser-APIs waren alle unterschiedlich.

Dann gab es halt eine Bibliothek, die halt dann irgendwie die unterschiedlichen Browser-APIs halt unter einer gemeinsamen API halt angesteuert hat.

Und das war dann jQuery, das war sozusagen die Standard-API, die man dann verwendet hat.

Und könnte man dann fragen, okay, jQuery, super, dann ist doch alles perfekt, alles Tutti, warum verwendet man das nicht heute immer noch?

Und da ist die Antwort im Grunde, naja, also das wurde halt immer komplexer und irgendwann kriegst du halt, wenn die Applikationen, also ich würde sagen, tatsächlich für kleinere Geschichten kann man das auch immer noch so machen.

Eigentlich ist es gar kein Problem.

Also eine Geschichte, die halt dann irgendwann schwierig wird, ist halt, dass wenn man jetzt ganz viel State halten muss, ne, also wenn man jetzt eine Seite hat, auf der viele komplexe Sachen passieren, dann ist halt die Frage, wie merkt man sich jetzt eigentlich, was man alles tun muss, wenn jetzt jemand per Drag <unk> Drop irgendwas irgendwo hinzieht oder so.

Wo gehen überall die Counter rauf und runter?

Wenn irgendein Event passiert, geht da noch eine Notifikation an, dieses, das wird dann halt, wenn die Applikation sehr komplex wird oder die Webseite sehr komplex wird, dann wird das halt irgendwann sehr, sehr unübersichtlich, wenn man das halt mit jQuery macht.

Also State nochmal für unsere Ganzanfänger ist, der Zustand, den ein Benutzer irgendwie gereicht hat, den er irgendwann wiedersehen will.

Nee, State ist halt sozusagen der Zustand der Seite.

Also den musst du ja selber handeln.

Also wenn du nur HTTP machst, quasi, dann ist der immer am Server.

Da ist es einfacher.

Ja, weil Request Response.

Genau.

Aber wenn du jetzt sozusagen nicht nur das machst, sondern du machst halt auch noch irgendwie X HTTP-Requests.

Das heißt, du schickst irgendwas zum Server, merkst du halt so, musst dir halt dann irgendwie merken, ich habe das jetzt schon da gespeichert oder musst sie halt merken, ich habe es halt noch nicht gespeichert.

Also das ist schon beim Server, das noch nicht, aber trotzdem hast du ja vielleicht schon irgendeine Aktion gemacht.

So diesen, diesen Schutzfehler,

Serververbindung abgebrochen.

Ja, diesen State musst du jetzt irgendwie verwalten.

Und den verwaltest du dann halt nicht mehr nur auf den Server, sondern halt auch auf dem Client.

Und das geht dann halt irgendwann nicht mehr so richtig gut mit jQuery, weil das ist ja auch dann, du hast das ganze Zeug ja irgendwie dann in so JavaScript-Files, du hast nicht so richtig Module oder so.

Geht alles nicht so.

Also du kannst natürlich schon unterschiedliche Files haben, aber also es ist halt irgendwie, mit jQuery wird das halt irgendwie nichts ab einem gewissen Komplexitätslevel.

Und im Grunde diese ganzen Frameworks sind halt alle dafür gebaut, um dieses mit diesem Problem umzugehen, sag ich mal.

Jetzt als jemand, der eigentlich, ehrlich gesagt, keine Ahnung von diesem ganzen Kram hat, ne?

Aber so aus meiner Perspektive von außen ist es so grob, dass wie.

Du hast jetzt Absicht ein bisschen geflüstert.

Ja, es ist schon so, eigentlich, ehrlich gesagt, es ist so ein bisschen außerhalb von dem, was ich normalerweise mache.

Daher, keine Ahnung.

Vielleicht rede ich auch großen Unsinn gerade.

Aber prüf das, schlag das nach und schreib es nicht in die Kommentare.

Genau.

Während jetzt man in jQuery zum Beispiel den DOM, also sozusagen die Baumrepräsentation der Webseite im Browser direkt manipuliert, dann macht man das halt in React View, wie auch immer, üblicherweise nicht direkt, sondern in einer Shadow-Dom oder keine Ahnung.

Der Schatten-Dom.

Ja, das macht man, da gibt es immer Leute, die sagen, so war es so viel schneller, also direkte Dom-Manipulation ist halt viel schneller als irgendwie so einen virtuellen Dom irgendwie.

Aber was einem das halt erlaubt, ist, dass man das halt trennen kann, also den State in dem Gerenderten von dem, was man halt, wo man die Manipulationen macht.

Und das ist halt unter Umständen sehr wertvoll.

Also ich würde sagen, dass...

Kann man noch ein Beispiel dafür nennen, was passiert jetzt, wenn man jetzt einen Schatten, Dom, ein Dokument Operation Model, also irgendwie das, was da hintersteckt, hinter der ganzen gebauten.

Die Idee ist so ein bisschen, dass du halt die Manipulationen da in deinem Schattendings da machst und dann nur guckst, du diffst es halt nur noch dann sozusagen gegen das, was du und dann machst du halt, erzeugst du den, oder machst die eigentlichen Dom-Manipulationen halt dann aus dem Div zwischen dem, was du eigentlich in seinem virtuellen Dom zu dem realen, sozusagen.

Aber du manipulierst den realen nicht tatsächlich.

Also du könntest ja auch, sozusagen, du kannst ja auch deine ganzen Daten im echten Dom halten.

Könntest du ja.

Du kannst ja das in Attribute von irgendwelchen Elementen reinschreiben oder so.

Aber das ist halt nicht so schön.

Weil dann.

Da baue ich lieber ein Schatzendommen.

Verstehe.

Ja, also keine Ahnung.

Also es ist, ja, ich bin da auch nicht der Beste, um das zu erklären, glaube ich.

Jedenfalls, heutzutage kann man für das, was man früher mit JackRary gemacht hat, auch einfach irgendwie React oder View oder so verwenden.

Das geht natürlich alles.

Aber man kann damit natürlich auch noch mehr machen.

Das ist zum Beispiel eine Geschichte, die halt in letzter Zeit sehr populär geworden ist, wobei ich auch mal sagen würde, man muss ein bisschen vorsichtig sein, dass man da nicht zu sehr in diese Hypefalle tappt, weil das hat halt auch, also die Trade-offs sind nicht so ohne.

Also das ist, das sind halt so Single-Page-Apps, dass du sozusagen alle

Komponenten direkt mit ausbeliefert sind.

JavaScript hast und nicht mehr, also praktisch gar keine Requests mehr machst, die halt da zu einem Reload der Seite führen.

Sondern immer nur noch über die API, also deswegen Dango Headless und Rest, Single Page Application und ja, asynchrone Fragen an den Server über das JavaScript.

Man kann das, also früher hat man das dann hatte man da immer noch so ein gewisses Problem, dass man das dann halt unter einer URL hatte und dass die Zurück- und Vor-Buttons irgendwie nicht richtig funktioniert haben, aber es gibt da, ich weiß jetzt gar nicht, wie die heißt, die API, es gibt eine Browser-History, sonst was API.

Und die ist mittlerweile auch stabil in allen Browsern drin.

Und das heißt, man kann auch ordentliche URL-URLs haben, ordentliches URL-Routing und Back und nach vorne Buttons und so, das funktioniert alles und man auf Links klickt, dann, ne, das klappt alles inzwischen super.

Man muss dann nicht mit irgendwelchen komischen Hash-Tag irgendwie Anchor-Tag-Dingern irgendwie rumspielen.

Wobei das, glaube ich, View auch in der Default-Konfiguration noch so macht, das muss man dann halt irgendwie dann umstellen.

Also das sieht dann aus wie eine Webseite und fühlt sich so an wie eine ganz normale Webseite, aber in Wirklichkeit ist es so, das wird nie wirklich neu geladen, sondern die wird immer nur umgebaut, basierend auf dem, was die, was JavaScript, was die JavaScript hat.

Also die ganze Arbeit macht der Client direkt vor Ort.

Genau, da wird es halt auch sozusagen gerendert, ja.

Was halt viel schneller ist, weil so ein kompletter Page-Reload, wenn das halt kompliziert ist, also wenn ich und allein es reicht eigentlich schon, wenn das irgendwie Bootstrap mit allem möglichen Kram drin ist, dann ist das so fett, dass halt, wenn man auf einer bei einer vom Server gerendeten Seite halt irgendwo auf den Link klickt und das dann neu rendert, dann merkt man das eigentlich immer.

Weil, auch wenn der Request selber schnell ist.

So oft ist es so, dass tatsächlich irgendwie alles, auch inklusive Assets, halt innerhalb von, weiß ich nicht, 200 Millisekunden zurückgekommen ist.

Und dann denkt man sich so, ja, das ist so schnell, dass man es eigentlich fast nicht merken sollte.

Und trotzdem bemerkt man das und der Grund, warum man es trotzdem bemerkt, ist halt, dass das Rendern vom DOM halt nicht so schnell.

Das dauert halt.

Und selbst wenn da nichts mit einem Netzwerk passiert, ist es so, dass allein, dass der Browser das alles neu aufbauen muss, das dauert halt und das merkt man und das ist halt nicht so flüssig wie eine native App, die jetzt halt irgendwie auf dem Rechner läuft und die nicht, ja, also die nicht komplett neu gerendet werden muss.

Und wenn man das jetzt in JavaScript sozusagen hat, die Applikation, und dann sich sozusagen für eine neue Seite immer nur neue Daten geholt werden von einer API und man kann dann ja auch so, also wenn man zum Beispiel eine Liste hat, wo man irgendwie so durchpaginiert oder so, dann kann man sich ja auch für die nächsten drei, vier Seiten die Daten schon mal geholt haben.

Und dann drückt man auf den Knopf und dann wird halt nur der, wird halt nicht das komplette Template außenrum alles nochmal neu gerendert, sondern dann wird halt nur der Inhalt der Tabelle, die man halt da sieht, irgendwie vielleicht ausgetauscht.

Und das ist dann halt sehr schnell und das geht dann halt, das sind halt so wenige, ich weiß nicht wie viele Millisekunden, aber so unterhalb der Wahrnehmungsschnelle.

Man drückt da drauf und es ist sofort.

Es hat sich sofort geändert.

Instant.

Und das ist natürlich sehr nett.

Das ist halt etwas, was man mit vom auf einer Serverseite gerinnerten Webseiten nicht hinkriegen kann eigentlich.

Es fühlt sich halt viel mehr an wie eine native App.

Und das ist natürlich schon schön.

Und gerade für kompliziertere Geschichten ist das natürlich schon sehr nett.

Also die sich halt mehr so wie klassische Applikationen auf dem Desktop anfühlen sollen.

Und ja, das ist natürlich alles schön.

Warum macht man nicht alles so?

Man kann die Dinger auch dann irgendwie quasi direkt auf Mobilgeräte und so deployen.

Und so ein bisschen, so diese Progressive-Web-App-Geschichte, sie sehen dann halt auch so ein bisschen aus wie normale Apps, wie so native Apps auf Telefonen und so.

Warum macht man nicht alles so?

Es hat halt auch diverse böse Nachteile.

Ein böser Nachteil ist halt SEO, Google-Suchergebnissen, eine Single-Page-App, das funktioniert halt einfach nicht so gut.

Was auch nicht so schön ist, ist halt, dass der erste Request unter Umständen sehr, sehr langsam ist, weil da halt irgendwie tatsächlich vielleicht megabyte JavaScript und anderer Kram irgendwie geladen werden muss.

Und ja,

das hört sich so im Mittel gut an für Menschen.

Genau, das ist halt

wahrscheinlich, es kommt halt darauf an, was man für ein Problem hat.

Für manche Probleme ist halt irgendwie eine klassische serverseitig gerenderte Geschichte das Allerbeste.

Für manche andere Sachen ist halt irgendwie eine Single Page-App besser.

Aber dass das überhaupt so geht und dass man das machen kann, ist eine relativ neue Geschichte.

Und das, ja, das ist auch etwas, was man halt mit diesen Frameworks halt gut machen kann.

Was halt, was man jetzt mit jQuery nicht machen könnte, ne?

Wobei, ja, doch, so, naja, vielleicht geht es da sogar, ich weiß es nicht genau, aber es macht halt, ich weiß nicht, ob es irgendjemand macht.

Könnte man vielleicht sogar auch, aber es ist, naja, vielleicht keine so gute Idee.

Ja, die Unterschiede.

Also so React, es gab ja früher nochmal sehr große Unterschiede.

Also tatsächlich die ersten JavaScript-Frameworks, die halt dieses Problem insgesamt angenommen haben, die waren sehr unterschiedliche Ansätze.

Da gab es halt irgendwie dieses Angular 1 halt, ne?

Das war eins der ersten, also war vorher React auch da, dann gab es irgendwie Ember und so.

Und dann aber React hatte irgendwie alles so ein bisschen geändert.

Das war halt so das erste, was einen sehr neuen Ansatz hatte.

So diese, diese, ja, wie soll man das beschreiben, eigentlich so einen eher einen funktionalen Ansatz, dass man halt sozusagen den, den, die, die Visualisierung der Seite erzeugt, irgendwie, indem man ein State hat und da einfach dann Funktionen drauf ausführt, die das dann halt hinrendern.

Und dass man halt nicht sozusagen irgendwelche Templates hat, so HTML, man kennt das ja von Django vielleicht oder sonst wie von einer serverseitig gerenderten Geschichte, wo man wo halt dann irgendwie Sachen ersetzt werden.

So, man hat halt irgendwie HTML oder so mit Platzhaltern für, da kommen jetzt dynamische Sachen rein.

Sondern in React ist es eher umgekehrt.

Du hast halt zwar etwas, das so ein bisschen aussieht nach HTML und Template, aber das ist es gar nicht in Wirklichkeit, sondern in Wirklichkeit ist es einfach nur eine Funktion.

Und diese Funktion rendert halt, rendert sich selbst raus zu HTML.

Oder zu irgendwas, was halt irgendwie im DOM angezeigt werden kann.

Und dieser Ansatz hat sich dann durchgesetzt.

Das machen jetzt inzwischen alle anderen auch so.

Und ja, tatsächlich, also ich fand React jetzt auch schon wieder ein bisschen her.

Inzwischen, ich habe nie mit Hooks irgendwie was gemacht.

Also man muss eigentlich viel zu viel erklären.

Das ist so, man kann sagen, also React hat mir eigentlich ganz gut gefallen.

Es ist eigentlich gar nicht groß, ist auch eher so eine kleine Geschichte, aber es gibt natürlich ein riesen Ökosystem drumherum.

Und ja, Angular fand ich ehrlich gesagt, es ist deutlich fetter.

Und mit gewissen Sachen bin ich nie so richtig.

Also man muss relativ viel Boilerplate außenrum schreiben und es passieren komische Sachen manchmal.

Aber ich meine, da kann man auch verwenden.

Also Angular, also letztendlich nimmt sich das alles nicht viel, es ist halt auch so ähnlich.

Und jetzt, View ist, glaube ich, auch so ähnlich.

Das ist auch kein großer Unterschied.

Ja.

Außer jetzt diese URL-Routing-Geschichte, die bei View noch so ein bisschen komisch ist, aber naja.

Tja, ansonsten weiß ich nicht, was das wäre denn noch so interessant.

Ja, ehrlich gesagt, keine Ahnung.

Wenn du keine so eine Use-Story hast, wo halt wir genau wissen, hey, in dem Case ist jetzt Angular total super und da ein Mekt und da lieber, sondern die sind alle austauschbar.

Das heißt, wir können mit Python tatsächlich jedes der Frontends nehmen.

Die Frage ist aber, wie man das implementiert, weil wenn du jetzt versuchst jetzt in der Django-App einfach so ein JavaScript-Framework einzubauen, dann wirst du vor einige Probleme kommen, weil du halt diese dynamische Entwicklung gar nicht richtig machen kannst.

Oder die Features der ganzen Frameworks gar nicht richtig machen.

Nee, du musst halt irgendwie mit dem Backend kommunizieren.

Also dieses Problem hast du natürlich weiterhin, dass du irgendwie ja irgendwo die Daten dann tatsächlich in der Datenbank halten willst und du musst halt irgendwie die da reinkriegen und die da auch wieder rauskriegen und so.

Und gut, vom Server kommt jetzt dann nicht mehr HTML, sondern da kommt dann halt eher irgendwie JSON oder ja, so eigentlich immer JSON, aber gibt es halt auch unterschiedliche APs, die beiden Hauptgeschmacksrichtungen, die es da gibt, sind halt REST oder eben GraphQL.

Etwas neuere Geschichte.

Nimmt sich aber letztlich auch gar nicht so wahnsinnig viel fürchte ich.

Ich habe jetzt auch, ich habe angefangen mit REST und dann das lange gemacht und dann ist halt dann GraphQL, fand ich dann ganz gut und bin jetzt wieder inzwischen wieder bei REST.

Es gibt Leute, die machen dann auch irgendwie, die sagen, naja, gut, also GraphQL zum Lesen ganz gut, zum Schreiben vielleicht nicht so und schreiben dann über Rest und lesen über GraphQL.

Naja, also aber letztlich ist es ja auch egal.

Auf jeden Fall, der Trend geht so ein bisschen.

Dann heißt er nur noch das bereitstellende API übrig und das ganze Frontend-Rendering verwechselst.

Async Django so?

Async Django ist jetzt eine andere Geschichte.

Oder wie man.

Ja, warum ist das eine andere Geschichte?

Dann habe ich wieder Unsinn erzählt.

Nee, also Async heißt ja eigentlich nur, dass du nicht also das Protokoll zwischen Applikationsserver und dem Web-Server außenrum ist jetzt halt ein anderes und es geht nicht nur, es geht nicht nur Request-Response, sondern du kannst halt auch, du kannst halt in beide, dieses ASGI, du kannst halt in beide Richtungen.

Du kannst halt auch vom Server Sachen einen kleinen schicken, das ist halt schon mal ein großer Unterschied.

Genau.

Und es ist halt auch so, dass du fürs IAO-Multiplexen das nicht nur über Threads und Prozesse machen kannst, sondern du kannst es halt auch über ein Event-Group machen.

Und so, also wie Node.js auch.

Das ist halt so der große, aber das ist, das wirkt sich jetzt auf was man, auf API oder nicht API, das wirkt sich alles darauf gar nicht aus.

Also das geht beides.

Ja, okay, das heißt ja trotzdem, ich mache dann halt meine API und ob die Async ist oder nicht, macht ja gar keinen großen Unterschied mehr, weil.

Naja doch, also es gibt natürlich schon einen gewissen Unterschied, was halt mit Django sonst nicht so richtig gehen würde, ist halt, dass du vom Server Benachrichtigung bekommen kannst.

Das geht halt nicht so richtig.

Also ich meine, du kannst natürlich emulieren, du kannst halt irgendwie alle 100 Millisekunden nachfragen, gibt es jetzt irgendwas Neues oder so, dann kannst du es halt wahrscheinlich so ein bisschen, aber du kannst halt nicht eine stehende, also wenn du zum Beispiel einen Chat, wenn du sowas wie Slack nachimplementieren wolltest, das geht nicht so richtig gut mit Django ohne Async.

Weil, wie soll das gehen?

Also wenn jetzt jemand was schreibt und das, die Webseite soll dir, will dir das anzeigen, wie macht sie das?

Ja, die Webseite fragt die ganze Zeit nachher, was ist denn ein Channel?

Was ist in einem Channel?

Was ist mit dem Channel?

Was ist in der Channel?

Aber das ist natürlich generiert einen Riesenhaufen Requests, die für alle völlig unnötig sind.

Aber es funktioniert.

Ja, aber das ist ja, also das ist ja, das ist ja super hässlich.

Also das ist ein, kann man natürlich, aber ich meine, stell dir vor, dein Rechner steht zu Hause und ist halt.

Datenautobahn, ich verstoffte Leitungen auf der Datenautobahn sind das schon.

Das ist gar nicht, das ist gar nicht so das Problem.

Das ist halt eher so, du machst die ganze Zeit Requests völlig.

Also wenn du nicht zu Hause bist und dein Rechner läuft und der macht alle 100 Millisekunden so einen Request, dann macht der halt, keine Ahnung, 10 pro Sekunde und das heißt am Tag 86.400 mal 10, also fast eine Million Requests und die sind alle leer.

Also.

Ja, ich sag ja, Stau auf der Datenautobahn.

Also ich glaube, das ist noch so fast das geringste Problem, dass da Daten übertragen werden, aber der Server muss ja dann jedes Mal irgendwie die Datenbank fragen und keine Ahnung.

Ja, also genau, es ist so ein bisschen, während wenn halt.

Und das ist halt, wenn es jetzt anders gehen würde, mit Asyn geht das halt dann halt, dass der Server, dir halt sagt, so hier ist jetzt, zeig mal diese Nachricht an, die hat dir jemand geschickt, dann passiert halt gar kein Request und wird überhaupt nichts hin und her geschickt, bis zu dem Zeitpunkt, wo das halt passiert.

Und das ist natürlich schon deutlich effizienter.

Und eben es skaliert halt nicht.

Wenn du jetzt mit zehn Leuten ist es egal, wenn du in einem Channel bist, aber wenn du jetzt eben sowas wie Slack betreibst mit hunderttausenden Leuten oder Millionen, dann bringen dich natürlich diese ganzen Requests irgendwann um.

Und ja, da brauchst du irgendwas, was halt irgendwie dir ermöglicht, vom Server aus auch dem Client irgendwas zu sagen.

Also das ist diese Asyn-Geschichte.

Aber das ist mit, ob jetzt APIs oder nicht APIs oder so, das ist alles.

Und eine API kann natürlich auch Async sein.

Du kannst natürlich dich, äh, also aber das geht eine API oder nicht API, das geht beides.

Mit was redet man denn mit der Django-API?

Macht man dann an Axios, irgendwie so ein JavaScript-Framework oder nimmt man da einfach normale Unternehmen.

Also für GraphQL gibt es halt Relay oder Apollo.

Für REST gibt es dieses Axios oder weiß ich nicht, es gibt ja unterschiedliche Geschichten, die man dafür verwenden kann.

Man könnte ganz normale Ajax-Requests machen, oder?

Ja, klar, also das ist genau.

Ist es ja auch mal.

Du kannst auch einfach, du könntest, du müsstest nicht Rest machen.

Du kannst eben, genau, du kannst natürlich in Django könntest du einfach einen JSON einfach einem X HTTP-Request oder Ajax-View machst du halt einfach, irgendwie gibt es eine JSON-Response zurück, fertig, geht auch.

Aber natürlich bietet es sich schon an, das irgendwie halt so halbwegs standardisiert zu machen, weil das natürlich auch diverse Vorteile bringt und man halt auch Sachen so machen sollte, wie man die üblicherweise so tut.

Das musst du jetzt zweimal begründen.

Einmal erstmal, warum man überhaupt Sachen so machen sollte, wie man die üblicherweise tut.

Man kann es ja einfach so machen, wenn man Lust

drauf hat.

Ja, aber das ist auch etwas, was ich halt immer wieder sehe.

Also die meisten Leute denken immer, wenn sie oder denken, oder das ist etwas, was ich oft sehe, dass Leute sich überlegen, wie sie denn jetzt irgendwie Kommunikation zwischen irgendwie einer Webseite oder einem Client und irgendwie ihrem Backend machen.

Und überlegen sich da irgendwas und denken, das ist total kompliziert und das ist total, sie haben irgendwie so ein Hightech-Problem, was sie irgendwie lösen müssen, und überlegen sich dann da irgendwie selber ganz viele Sachen.

Und das ist, ich, also ich hab noch, also, das müssen wir mal überlegen, ob ich das jemals gesehen habe, dass das tatsächlich der Fall war.

Ich glaube nicht.

Ich glaube, das war tatsächlich dann nie so.

Sondern es ist immer so, dass eigentlich ist das alles immer das Gleiche.

Das ist alles irgendwie, du hast immer, es ist immer Crat.

Ja, es ist immer so, also Create-Tech.

Create, Retrieve, Update und Delete.

Genau.

Und du hast immer Listen von Dingen und immer dann Create auf der Liste und immer dann eine Detailansicht, auf die du dann weitergeleitet wirst, oder halt wieder auf die Liste zurück.

Und das ist halt alles immer gleich.

Und ob das jetzt dann, und das kennt man ja auch von Applikationen so, ne?

Ob das jetzt Facebook ist, ob das Twitter ist, die funktionieren alle ganz genauso.

Oder ob das dein Mail-Client ist, der funktioniert auch so.

Oder es ist eigentlich immer, es geht immer so in die Richtung.

Und die Leute, oder viel, man, mir ist es ja am Anfang auch so gegangen, also wenn man das nicht ein paar Mal gesehen hat, dann fällt einem das halt nicht auf, dass das immer so ist.

Sondern denkt man sich so, ich muss das halt irgendwie alles selber erfinden, aber das muss man eigentlich nicht.

Und das ist auch keine gute Idee.

Weil tatsächlich dieses Crud-Ding, also dafür gibt es halt dann Abstraktionen, die sich bewährt haben und das funktioniert dann gut, wenn man das genauso macht.

Und wenn man das halt anders macht, dann hat man halt Schmerzen.

Auha!

Ja.

Ja, also

mit El Fußschießen oder Stolpern fallen, reintreten, große Fehler durch die Ohren sammeln oder mymph.

Ja, ja.

Ja.

Aber ja.

Was halt auch noch interessant ist, wenn man jetzt eine API abfragt, ist halt so, wie macht man dann eigentlich das Statement, man hat jetzt, also was die bösen Trade-offs angeht, nicht nur, dass das halt irgendwie fett ist, also wenn man so eine Single-Page-App baut, ist es halt deutlich fetter, der erste Request ist deutlich größer.

Es ist halt brittle, ich weiß gar nicht, wie man das am besten übersetzt.

Es ist halt so, es ist viel instabiler, als man jetzt einfach nur ein schnelles HTML und CSS verwenden würde.

Weil halt dieses ganze JavaScript funktionieren muss.

Es ist halt irgendwie, wenn du auf einem Telefon bist, irgendwie das schlechte CPU hat, ist es nicht so gut, wenn das auch einer schlechten Leitung ist, nicht so gut.

Also diverse üble Nachteile.

Ein weiterer übler Nachteil ist, dass du jetzt State-Handling halt nicht nur auf einer Seite hast.

Früher, also wenn das serverseitig gerendert wird, hast du das halt nur auf dem Server.

Und da hast du halt dein, weiß ich nicht, Framework, das dafür gebaut ist, mit diesem Problem umzugehen, halt, weiß ich nicht, eben auch so, wenn man das so, also alles all-in-one-Lösung, wäre dann halt sowas wie Ruby und Rails oder halt eben Django.

Aber dieses Problem hast du dann halt nur da und sonst eigentlich nicht mehr.

Und wenn du bei so einer Single Page-App, hast du dieses Problem an der Stelle dann halt auch nochmal.

Das heißt, du hast halt zweimal das Problem, dass du irgendwie mit Logik umgehen können musst.

Zweimal Logik umgehen heißt doppelter Anteil an Fehlern.

Ja.

Und auch doppelte Menge an Code.

Doppelte Menge an Code, bei dem irgendwas schief gehen kann, ja, genau.

Und ein exponentiell Wachstum, das heißt eine vielfache Menge an Bugs.

Exponentiell weiß ich nicht, aber ja, es ist auf jeden Fall.

Je nachdem, wer das denn weggejochen ist.

Ja, das ist ja.

Ich gucke jetzt niemanden an.

Nee, ich habe ja Gott sei Dank kein Spiel.

Ja, aber das ist natürlich ein Problem und das ist halt viel aufwendiger und das ist alles viel schwieriger.

Und natürlich, und die Menge an unterschiedlichen komischen Technologien und so, der Stack wird halt immer größer und das macht es halt auch alles viel schwerer.

Also das ist schon deutlich komplizierter als so eine einfache Webseite.

Und ja, das ist halt, aber auf der anderen Seite kann man damit auch coole Sachen hinkriegen, die man sonst nicht hinkriegt.

Insofern muss man sich halt überlegen, ob sich das für einen lohnt oder nicht.

Aber wenn man das jetzt macht, dann hat man eben genau dieses Problem.

Da kommt jetzt halt irgendwie mit dem State von zum Beispiel einer API, den man jetzt irgendwie in der Applikation verwalten können muss und ja.

Oder sagen wir so, der State ändert sich, wenn halt zum Beispiel ein API-Request zurückkommt.

Also man fragt jetzt, man hat halt irgendwie so eine Applikation, die eine Liste von irgendwelchen Dingen, wie auch immer, die aussehen, anzeigt und macht jetzt einen Request ans Backend und kriegt jetzt zurück, okay, diese 100 Dinger gibt es.

So, diese 100 Dinger ändern jetzt den State der Client-Applikation.

Und wie macht man das jetzt ordentlich?

Und dann braucht man halt da auch irgendwie sowas wie irgendeinen Platz, wo der State gehalten wird.

Bei Django oder Real Wales wäre das halt jetzt die Datenbank.

Hat man jetzt auf der Client-Seite nicht so, aber dann kann man halt auch sowas wie so ein Redux-Store zum Beispiel haben, wo das halt, wo man dann halt den State hält und geordnete Methoden hat, wie man darauf zugreift, wie auch unterschiedliche Teile der Applikation auch darauf zugreifen und wie die halt irgendwie Änderungen daran auslösen.

Und ja, da gibt es dann auch nettes Zusatztooling, dass man halt dann irgendwie auch da durchsteppen kann.

Man kann also man kann sich halt angucken, was, wie sieht die State aus bei davor, danach, man kann auch die Applikation, wenn man das rumgeschafft ist, man kann die in jeden Zustand wieder zurückbringen.

Dadurch, das ist halt sowas, also React zum Beispiel ist relativ funktional, das ist eigentlich sehr nett.

Also da nie, da immer nur die Seite gerendert wird aus dem Zustand, wenn du weißt, wie sich der Zustand immer geändert hat und immer gespeichert hast, kannst du die Seite in jeden Zustand wieder zurückversetzen.

Die nennen das irgendwie der Time-Travel-Debugging zum Beispiel.

Du kannst halt, wenn du jetzt zum Beispiel, da gibt es so eine Browser-Extension, die halt den State irgendwie die ganze Zeit speichert und das mit Redux checkt und da kannst du halt, wenn du ein bisschen auf der Seite rumgesurft bist, die Seite auch wieder in jeden Zustand zurückversetzen.

Du kannst einfach sagen, okay, nimm diesen State und dann sagt man React einfach nur so, okay, ins Render halt die Seite und dann kommt genau die Seite raus zu dem Zustand.

Und das ist natürlich schon sehr nett.

Also dass du halt, ja, dass der Zustand nirgendwo irgendwie, dass da nicht irgendwie noch irgendwelche Daten, die gebraucht werden, in irgendwelchen Dom-Elementen drin rumhängen oder so, sondern die Dom-Elemente werden rein aus blöden Funktionen, die halt State nehmen und Elemente ausgeben, rausgerendert, sodass halt quasi immer klar ist, was passiert.

Das ist natürlich schon.

Also eine Liste von States hast du dann, um tatsächlich zu speichern, wo du gerade bist oder warst oder sowas.

Ja, du hast halt den.

Der State ist halt das, was definiert, wie deine Seite aussieht.

Ja, okay.

Und der State ändert sich halt auch.

Es gibt halt Aktionen, die, bei Redux ist es halt so, du hast halt Actions, die halt den State verändern.

Und wenn du jetzt aber den State vor und nach jeder Action immer speicherst, dann kannst du einfach sagen, okay, hier ist der State, liebes React, rendere alles mal so, dass es wieder wie eine Seite aussieht und dann ist die Seite genau in dem Zustand.

Also, um jetzt nochmal klarzustellen, also ein State ist dann ein Gesamtstatus der gesamten Seite und nicht der einzelnen Komponenten.

Nee, genau, der Gesamtseite.

Die Komponenten kriegen halt nur einen Teil des States, der sie interessiert zu sehen.

Die können dann zum Beispiel sagen, okay, ich hätte jetzt gern alles an State unterhalb von.

State ist halt sowieso ein Baum und man ist üblicherweise immer nur an so einem Teil davon interessiert.

Und den kriegen die halt als Argument dran.

Wenn du als einen Div-Container zum Beispiel aussuchst, an den du jetzt haben willst.

Das ist nicht der gleiche Baum wie der von der Webseite.

Das ist nicht das gleiche, nee.

Der State ist eine andere Geschichte.

Dann musst du mir jetzt nochmal genau erklären, habe ich das noch nicht genau verstanden.

Im Grunde einfach nur so ein Baum von Daten irgendwie.

Was ist denn ein Baum von Daten?

Ein Graph.

Nee, kein Graph.

Nein, kein Graph.

Da können beliebige Dinge darin sein.

Also insofern, aber, ach ja, ich weiß nicht, musste.

Es ist halt irgendwie alles, was letztlich wie ein Python im Dikt.

So, kann man sich das vielleicht vorstellen.

Ja, okay.

So verschachtelt es dickt halt.

Wie so ein JSON-Or-Struktur mit irgendwas.

Ja, ja, exakt.

Und du kannst halt als Komponente kriegst du das halt irgendwie einen Teil davon irgendwie reingereicht, ja.

Und diesen Kram benutzt du halt, um halt letztlich eine Komponente ist in React nichts anderes als eine Funktion, die aufgerufen wird mit bestimmten Daten und die spuckt dann halt irgendwas Gerendertes aus.

Fertig.

Das war's.

Aber die hält keinen eigenen State.

Die kann nicht, ja.

Das ist halt sehr schön, weil solange sich nichts an den Eingaben für diese Funktion ändert, ändert sich auch nichts an der Ausgabe.

Nur wenn sich da irgendwas ändert, muss das neu gerendert werden.

Und da du immer weißt, sozusagen, an welchen Stellen sich am State was geändert hat, weißt du halt auch, welche Teile du neu rendern musst und welche nicht.

Das ist halt schon nett.

Aber naja, also sondern so, das ist halt auch alles viel zu kompliziert für so eine Seite, die irgendwas Kleines macht, also brauchst du das alles eigentlich nicht.

Und es gibt natürlich auch Komponenten, die nur ihren eigenen State, also wenn du jetzt ein Formular hast, das irgendwie so ein bisschen Fehlerbehandlung machst, das muss jetzt nicht irgendwie da unbedingt angebunden sein an den Komplettsstate der Seite, weil das interessiert sowieso.

Wenn es keine andere Komponente interessiert, dann ist es ja sinnlos, das in so ein allgemeines Ding zu schreiben.

Auch noch so eine spannende Frage, wenn du jetzt so ein Formular hast, was ja normalerweise jetzt in Python über so ein Django Form validiert werden würde, unter anderem ja mit den Feedbacks zu Nutzer und so.

Wie macht man das denn dann einfach in so einem JavaScript-Frame?

Damit müsste alles wieder neu implementieren.

Du musst es halt einmal auf Cleanseite machen, du musst es einmal wieder auf Serverseite machen, weil auf Serverseite musst du es natürlich immer noch machen.

Auf Serverseite bekomme ich dann ja aber dann wieder nur meine API, mein Rest oder was auch immer.

Und muss es trotzdem machen.

Wenn man dann irgendwelche Error-Feedbacks nicht geben kann und wo dann irgendeine Message drinsteht und das ist ja dann so ein Dreifach hässlich.

Also da baue ich ja einmal die Formklasse, pipe die da rein, mache dann ein, zwei Widget-Einstellungen und das läuft das Ding.

Und inklusive Feedbacks und.

Aber es ist halt so, also ich meine, da gibt es keinem.

Kommen wir halt nicht drum rum.

Du verwendest halt bei einer API dann nicht irgendwie eine Formklasse, sondern halt einen Serializer, der ist halt so ähnlich wie eine Form.

Aber klar, du musst halt auch das wieder wieder validieren und dann halt eventuell Fehler zurückgeben und das auf der kleinen Seite halt nochmal.

Was macht denn ein Serializer anders als eine Form?

Ich würde sagen, es ist relativ ähnlich, aber es ist serialisiert und Dinge nach sozusagen dickt und von irgendwie dickt nach Objekt nach Dict und von Dict wieder zu Objekt.

Das ist halt das, was Serializer machen.

Und Formulare machen das auch.

Mehr oder aber die Formulare, äh, das wir überlegen.

Keine Ahnung.

Naja, das ist halt so ein bisschen anders, ne?

Das ist halt nicht immer.

Also bei den Serializern, die können natürlich auch nach XML oder so, aber eigentlich ist immer JSON.

Ja.

Und ja, es ist tatsächlich sehr ähnlich, was sie machen.

Also die Validierung ist, glaube ich, vielleicht so ein bisschen anders.

Sehr ähnlich.

Also.

Also ich kann sein, dass man mit Serializern noch ein bisschen mehr machen kann, aber naja, das ist aber so, das ist halt, ja.

Ist aber auch, das sind halt Feinheiten, ne?

Das ist halt nicht mehr so.

Also im Grunde, aber du hast halt sowas wie Formularvalidierung, hast du an der API natürlich auch machen.

Und das musst du auf dem Client halt auch machen.

Das heißt, du musst halt doppelt machen.

Es gibt natürlich unter Umständen, wenn du jetzt rein in JavaScript bleibst, die Möglichkeit, dass halt, dass du das nur einmal hinschreibst.

Und den Code dann sowohl auf dem Server wie auf dem Client verwendet, aber ja, weiß ich gar nicht, ob das jetzt so reibungslos ist, also man hört immer, dass es geht, aber ob das wirklich so reibungslos geht, weiß ich nicht.

Ja.

Und du hast dann ja die ganzen anderen Probleme.

Du hast dann musst das ja auch noch immer irgendwie in der Datenbank wieder speichern.

Das ist quasi nochmal das gleiche Problem.

Du musst ja auch da irgendwie das wieder in eine Tabellenform seralisieren und derealisieren.

Da hast du nochmal ein ORM dazwischen.

Also, und ja, es ist alles nicht so ganz einfach.

Ja, aber

das wird sich auf jeden Fall sein, dass wenn man das sowieso zweimal machen muss, dann musste man ja fast schon zwei unterschiedliche Projekte nehmen.

Wenn ich ja so eine API habe in Django zum Beispiel, dann muss ich die beiden ja gar nicht miteinander reden lassen, wenn ich nicht will.

Also die muss ich ja nun nicht mal im selben Repo halten, weil die voneinander gar nichts wissen brauchen und nichts miteinander zu tun haben, weil die eine Seite ja auch unabhängig von der anderen Seite getestet werden muss.

Nee, ja, also das kommt halt drauf an, auf der Anwendungsfall.

Also würde ich sagen, kann man so oder so machen, je nachdem unter welchen Bedingungen ist es halt das eine oder das andere sinnvoller.

Also kann man nicht so sagen, dass man das jetzt so machen sollte und das ist dann immer richtig für alle Sachen, sondern es ist halt hängt davon ab.

Also kann man.

Also sowieso so.

Es gibt ja Leute, die mögen das eher, wenn Sachen in vielen unterschiedlichen Projekten sind.

Andere Leute mögen es lieber, wenn alles in einem ist.

Hat es halt auch beide so Vor- und Nachteile.

Es ist halt kann man nicht sagen, dass das eine besser ist als das andere.

Also jedenfalls nicht, dass ich wüsste.

Wann würdest du das zusammen machen?

Wann getrennt?

Ich glaube, ich bin eher die.

Ich bin eher in dem Lager, ein großes Repository.

Also ich tendiere eher zu einem Repository als zu vielen kleinen.

Aber naja, ich meine, der Vorteil ist halt, bei kleinen Repositories wäre es halt, dass du zum Beispiel auch Sachen rausgeben kannst.

Du könntest halt zum Beispiel Pakete draus bauen.

Und das halt irgendwie zum Beispiel, wenn du jetzt ein großes Repository hast, kannst du halt nicht so leicht sagen, so, oder den Kram machen wir jetzt mal Open Source.

Geht ja nicht so gut.

Wenn das schon ein Repository ist, dann ist das viel leichter.

Wenn es jetzt ein Teil ist, der nicht dann den Kern, von dem du was, was du tust, irgendwie betrifft oder so.

So war es zum Beispiel.

Ich weiß es nicht so genau.

Aber ja.

Wenn du einen Repository hast, wird es natürlich einfacher, das Ganze zu verwalten.

Ich meine, du musst halt nicht, äh, ja, hast du halt eben nicht das Problem, dass du dann vielleicht noch irgendwie die Sachen, die sowieso alle eigentlich mit zu deiner Software gehören, nochmal alle zusätzlich als Pakete installieren musst, was halt vielleicht nicht so nicht so toll ist.

Also, ja.

Okay, aber Front-end und Backend vielleicht dann wenigstens so ein bisschen drin.

Würde ich nicht machen.

Also ich würde es nicht machen.

Aber Englalter ist Geschmackssache.

Es gibt Leute, die machen das.

Ja.

Also ja, Nachteil ist halt, wenn du das so machst, dann wie kriegst du die ordentlich dazu zusammenzuarbeiten?

Wie machst du dann End-to-End-Tests?

Ist halt schwierig.

Ja.

Also, aber kann man tun?

Also es gibt ja dann, und Hauptstand, wenn du eine größere Applikation hast, dann auch so, dann ist das halt nach Teams unterschiedlich.

Dann gibt es halt vielleicht ein Team, das nur Frontend macht oder Teams, die nur Frontend machen und Teams, die nur Backend machen.

Und ja, dann willst du es vielleicht doch irgendwie auftrennen.

Also nett ist das natürlich tatsächlich, wenn man das auch einfach austauschen kann.

Wenn man jetzt beispielsweise jetzt ein Frontend in Vue gebaut hat und man möchte aber noch eine Elektron-Applikation dazu basteln oder so, dann muss man das Backend ja nicht mehr anfassen, sondern nur den Frontend-Ordner wegschmeißen oder das Reput antauschen oder so.

Oh, das verstehe ich nicht.

Was möchtest du machen?

Also ich habe jetzt mein Django Headless, ja.

Da hast du die API und die ganze Logik und die ganzen Modelle und die ganzen Daten, man kennt links alle für mich erledigt.

Und ich möchte einmal eine Web-Applikation haben mit Vue beispielsweise und einmal eine Native Desktop-Applikation beispielsweise mit Elektronen.

Ich würde jetzt sagen, das sind zwei unterschiedliche Verzeichnisse fertig.

Okay.

Warum muss das ein anderes Repo sein?

Wenn es die gleiche Applikation ist.

Was ist denn jetzt, wenn du testen möchtest?

Die Daten für die Tests, hast du die dann doppelt in beiden Repositories?

Was ist, wenn du die änderst?

Wie sorgst du dafür, dass jetzt die Testdaten synchron bleiben?

Sodass halt auch die Tests aussagekräftig bleiben und so.

Es ist halt irgendwie schwierig, wenn das zwei Repositories sind.

Dann wird das halt.

Also, ich sag mal, also sag mal so, es kann sein, dass das nötig wird, wenn man sehr stark skaliert oder so, aber ich meine, es wird auch sehr viel umständlicher, ne?

Es ist halt dann halt komplizierter.

Und die Frage.

Was wird umständlicher?

Bitte?

Was wird umständlicher und das ist nicht mehr?

Also allein sowas wie, wie testest du denn dann?

Wie testest du deine Desktop-Applikation und deine View-Applikation?

Test gibt es auch gar nicht.

Test gibt es auch gar nicht.

Ja, aber.

Jetzt hast du das in unterschiedlichen Repositories.

Du hast jetzt deine Fixtures, die irgendwie Testdaten sind, mit denen du da deine Tests machst.

Jetzt änderst du, jetzt hast du festgestellt, oh, ich habe hier einen Test-Case, der ganz wichtig ist, den mache ich jetzt bei meiner View-Geschichte dazu.

Wird das jetzt bei, wie wird das, wie sorgt deine Desktop-App dafür, dass das auch getestet wird?

Wie kommt dieser Testcast da rein?

Ja, ich meine, du machst doch sowieso eigene Tests für die Desktop und für View oder ist das?

Ja, aber wenn du jetzt festgestellt hast, oh, dieses Ding muss ich unbedingt testen, das wirst du doch vielleicht in dem anderen Ding auch getestet haben.

Und wie würdest du das machen, wenn die beide gleichzeitig im selben Reposition überall?

Wenn du deine Testdaten beide gleich.

Ja, ja.

Oder eben, ich meine, sowas wie, du musst ja vielleicht, um entweder Tests machen zu können, halt so ein Dummy-Backend hochziehen, wenn das Schema da irgendwo steht.

Wie sorgst du dafür, dass das synchron bleibt?

Also.

Ja, und dann kann man natürlich anfangen, das mit irgendwie Git Sub-Modules zu machen oder weiß der Teufel und dann, also, aber das ist alles.

Ja, also sag mal so, ich kann mir vorstellen, dass es Vorteile hatte, es in mehreren Repositories zu haben, aber es wird halt auch komplizierter.

Und die Frage ist, ob man es ja macht oder nicht.

Hängt halt davon ab, ob die ja diese, ob diese Komplizit gerechtfertigt ist.

Die Vorteile so groß sind, dass die zusätzliche Komplexität halt irgendwie nicht so schlimm ist, demgegenüber.

Ja.

Dockerisiert das Ganze und go, oder?

Nee, das würde ich auch nicht sagen, dass man das unbedingt machen muss.

Es halt hängt halt auch davon ab, was man.

Also ich meine, wenn man jetzt alleine entwickelt, dann braucht man Docker nicht.

Das brauchst du ja nur dann, wenn du mehrere Leute hast, die unterschiedliche Entwicklungsumgebungen haben.

Dann ist halt Docker irgendwie sinnvoll, aber wenn für Sachen, wo ich alleine dran entwickle, habe, benutze ich keinen Docker.

Ja.

Außer ich deploy es halt irgendwie da.

Zum Deployen benutze ich schon Docker, aber.

Ja, ist halt die Frage, ne?

Also wann das halt so ein Macht und wann nicht.

Deploying ist doch noch so eine Sache, ja?

Also, weil wie deploy ich denn überhaupt so ein Frontend?

Also ich habe ja jetzt tatsächlich irgendwie dann diese ganzen Systeme, die Live-Development-Server haben.

Also in JavaScript-Fehter gibt es irgendwie jetzt MPM oder JAN und Node oder Jan, warum benutze ich das eine oder das andere mal hin und her?

Also ich habe jetzt letztes Mal Jarn benutzt, weil es so ein bisschen ähnlich von Poetry ist.

Ja, also Jarntag.

Das ist ja ein bisschen neuer, irgendwie war mal schneller, weil es halt Sachen gecached hat und so.

Aber ich glaube, es macht heute keinen großen Unterschied.

Nimmt sich nicht viel.

Dann installiere ich halt dann da irgendwie meine Projekte und dann kann ich halt irgendwie die bauen und dann oder surfen direkt und gesehen alle Änderungen, das ist ja super.

Aber wenn ich jetzt in meinen Dango zum Beispiel einbauen möchte, dann muss ich die alle packen.

Und mit da ganz, ganz übel jetzt in letzter Zeit so ein bisschen rumgefimmelt mit Webpack und der Konfiguration davon, bis es dann irgendwie mit gehashten JavaScript-Files und so in den Static-Ordnern landete, die ich das gerne wollte.

Und dann ist halt auch die Frage, wenn man das dann in Production ziehen will, wo deployt man das Ganze dann eigentlich hin, liegt das dann einfach auf dem Server rum, irgendwo lokal und wird dann als File ausgeliefert mit Tango Codex Static oder was ist das?

Und dann gibt es irgendwelche Tools-Write-Neues, habe ich gesehen.

Und ich habe wie gesagt diesen Webhack-Loda genommen, dass er automatisch weiß, welche Files denn das sind.

Und das ist schon eine

nochmal so eine Wissenschaft.

Ja, ja, ja.

Das ist halt leider, ich wünsche mir auch, das wäre irgendwie anders, aber es ist leider alles nicht so einfach.

Und ich habe mich auch lange nicht damit beschäftigt, mit diesem ganzen Deployment-Kram und wie setzt man so komplette Systeme auf.

Aber ich fürchte, letztlich kommt man da nicht so richtig drumherum.

Und es ist halt, es ist schlimm.

Es wird dann irgendwann besser.

Zuerst denkt man sich so, das kann doch alles, das ist man sehe kein Land und das wird irgendwie alles nicht besser, aber irgendwann geht es dann doch.

Und zu diesem ganzen, also ich macht man das mit den Assets und so, das ist ein Problem.

Es gab da letzte PyCon, also ungefähr fast ein Jahr her.

2019, einen Vortrag von Jacob Captain Moss, also einem der Klammer-Gründer.

Und der Talk hatte den Titel Acids in Django Without Losing Your Hair.

Oh, dann denken wir sich so, das habe ich mir auch gedacht.

Dann habe ich mir, das ist so super endlich, erklärt mir das jemand, wie man das richtig macht, ohne dass es so kompliziert wird.

Und dann sagte er dann halt so an den ersten Sätze, die da sagten, so, ja, der Titel ist so ein bisschen Bait <unk> Switch.

Also tatsächlich, ich habe mir das, ich habe das auch nie so, also ich fand das auch mal kompliziert und dachte mir, ach, dann halte ich mal einen Vortrag drüber.

Und dann muss ich es halt lernen und dann habe ich auch einen Grund, das zu tun und mir das alles nochmal genau anzugucken.

Und jetzt habe ich das halt gemacht.

Und ich hatte den Titel aber vorher schon hingeschrieben.

Und ich muss aber sagen, nachdem ich das jetzt alles gemacht habe, ist es leider nicht einfach.

Man kann nichts machen.

Insofern, ja, leider verloren.

Aber ich erzähle euch jetzt immer trotzdem, was ich alles rausgefunden habe.

Und ja, es ist leider nicht einfach.

Und das ist, also eine Geschichte bei Django ist zum Beispiel blöd, dass das halt Static heißt, das ist halt so komisch, ne?

Weil es halt damals gab es noch keinen etablierten Begriff dafür.

Heute würde man das eher als Assets nennen.

Aber.

Unbedingt, man kann ja Static-Files dir ident of Assets setzen, Dango?

Ja, kann man schon, aber das Problem ist, die Konfigurationspameter, die heißen ja immer noch so, das heißt dann immer noch Static Root und Static weißer Teufel irgendwie, ja, das wird man halt nicht so leicht los, ne?

Man kann aber immerhin da in den Config-Kindern sagen, Asset root gleich, Static Root gleich.

Das kann man natürlich machen, aber na.

Ja, herzlich.

Ja, okay, also okay, wir haben jetzt Assets, die liegen jetzt irgendwo, okay?

Genau, also tatsächlich gibt es in Django einmal die Geschichte, dass der also man, es gibt so eine Indirektion, die so ein bisschen komisch ist.

Es ist nicht so intuitiv.

Wenn man zum Beispiel, das wird auch oft aufgerufen, wenn man jetzt deployt zum Beispiel oder halt auch gibt es so ein Ding, das nennt sich Collect-Static ein Kommando und Management-Kommando.

Management-Mand.

Was das macht, ist, es kopiert halt alle, ich glaube, wenn man das

Static-File zu hol das.

Genau, also die einzelnen Apps, die man da irgendwie, kann man einzelne Static Files hinlegen, einzelne Assets und die sammelt es alle ein, wenn das irgendwie die eingestellte ist richtig und speist das dann alles in die Ordner Static-Files rein, wo man es abrufen kann fürs Deployment.

Ja, nee, es macht sogar auch noch mehr.

Es deployt das Ganze, also du kann man so einstellen, dass es zum Beispiel den Kram auch direkt nach S3 packt und so.

Also wo ist das hin kopiert?

Das ist halt konfigurierbar.

Und es wird

auch modifiziert, also zusammengefasst und so.

Ist da auch Byte Noir schon mit beteiligt?

Was ist das überhaupt?

Ja, nein.

Nein, ganz andere Geschichte.

Also diese Static-Files-Geschichte in Django ist halt, also diese Indirektion gibt es halt deswegen, weil Third-Party-Apps ihre eigenen Geschichten mitbringen.

Ansonsten könnte man sich ja sagen, warum surft man nicht einfach das Static Directory?

Das ist ja, dann hat man es doch schon.

Ist auch schon fertig.

Aber ist leider nicht so, sondern man muss halt diese ganzen, muss auch die Static Assets, die Assets von allen Apps, die man verwendet, einsammeln.

Daher geht das halt nicht so leicht, sondern das muss halt alles eingesammelt werden.

Und dann gibt es ja auch eventuell Sachen.

Ich könnte ja auch sagen, okay, also meine Assets liegen halt nicht in einem Verzeichnis, sondern die liegen halt irgendwo eben in einem S3-Bucket oder auf Django, irgendwas, was Django Storage das Anbindung hat, also auch auf einem FTP-Server oder sowas.

Könnte auch sein.

Also, genau, das Collect-Setic holt halt Dinge irgendwo her und schreibt sie irgendwo hin.

Ich kann Django mit einem FTP-Server verknüpfen.

Kann man es.

Ich weiß nicht, ob das eine empfehlenswerte Geschichte ist.

Ich möchte ja nicht.

Gut über alte Zeiten hier.

Und ja, das ist halt blöd und das wird man auch nicht so richtig los.

Und ja, das ist nur der eine Aspekt daran, ne?

Das ist halt dieser, was passiert mit den Assets, wie kommen die jetzt eigentlich dahin, wo sie gesurft werden?

Und jetzt kann man das natürlich entweder so machen, dass man sich, dass man das im Entwicklungsumgebungsfall halt einfach dann vom Django Entwicklungsserver ausliefern lässt und dann halt damit lebt, dass das irgendwie anders ist als im Produktionssystem, weil im Produktionssystem surft das natürlich nicht Django, sondern da liegt das halt irgendwie auf S3 oder halt irgendwie in irgendeinem CDN oder halt irgendwie h

inter irgendeinem Nginx oder was auch immer.

Und wenn das jetzt anders ist als in der Entwicklungsversion, dann kann es natürlich sein, dass dann Bugs passieren, weil man das halt in der Entwicklungsgeschichte nicht gesehen hat, dass das so nicht funktioniert.

Was man dann aber machen kann, ist, dass man sozusagen die gleiche Infrastruktur benutzt wie beim Produktions-Bi-Proktionsdeployment auch.

Und dann, was auch in dem Vortrag dann halt gesagt wurde, ist halt, was man tun kann, ist man Prefix das dann halt irgendwie mit, damit man halt nicht Produktionsassets überschreibt oder so, sondern Prefix das halt dann mit Entwicklungsversionen oder sowas.

Mit Developer davor oder so und naja.

Aber und hätte dann halt sozusagen die gleiche Umgebung, Entwicklungssystem und Produktionssystem.

Habe ich bisher noch nicht so gemacht, aber dachte ich mir so, oh ja, okay, stimmt, so kann man das vielleicht machen, dann hat man auf jeden Fall dieses Problem nicht mehr.

Ja.

Aber es ist natürlich auch irgendwie doof, dass man dann immer, wenn sich irgendwas geändert hat, dann das dann plötzlich, dass man dann Collect-Setic aufrufen muss und so.

Ja, irgendwie kleine zwei Pixel geändert und dann einmal bitte schön nach S3 abpen und so.

Ja, genau.

Es ist natürlich auch wieder so, aber es gibt halt keine tolle Lösung dafür irgendwie.

Das ist immer ein bisschen doof, egal wie man es macht.

Dann, genau, das, was halt White Noise macht, ist im Grunde nur eine andere Art.

Also tatsächlich ist es wahrscheinlich das, was man jetzt machen sollte, wenn man statische Files ausliefert.

Früher ging das so gar nicht, aber mittlerweile mit White Noise kann halt der Applikationsserver statische Files ausliefern.

Das ist halt so dann ein Teil von dem, was White Noise macht.

Der andere Teil ist, die Cache Header richtig setzen.

Was man dann tun kann, ist, man liefert irgendwie die Assets aus über den Applikationsserver und packt dann halt ein CDN davor, dem man einfach nur sagt, also da kommen die Files eigentlich her, also wenn du irgendeine URL unter der Domain kriegst, dann frag eigentlich mal den Server danach und dahinter liegt dann halt der Applikationsserver.

Und Cache ist halt.

Und die Cache-Header, die Cache-Control-Header, die werden alle richtig gesetzt von White Noise.

Und damit hast du halt ein System, das gut funktioniert.

Und Whitenus kannst du halt sowohl in deiner Entwicklungsumgebung verwenden, wie auch in deiner Produktionsumgebung.

Also eigentlich ganz, ganz cool.

Wo ich ein Problem, wo ich nicht weiß, wie dieses Problem löst.

Das ist und das sind halt immer so Dinge, so Authentifizierung, ne?

Wie macht man das?

Was ist, wenn ich jetzt?

Es gibt ja noch die Unterscheidung zwischen Static-Files und halt Assets, wie sowas wie CSS, irgendwelche Icons, irgendwelche JavaScript-Geschichten oder so, die sich im Grunde ja auch nicht wirklich ändern, die auch nicht dynamisch sind, wo auch Nutzer irgendwie nichts mitmachen können und halt sowas wie, das ist in der Djungle Welt heißt es dann Media, wo zum Beispiel User-Uploaded hochgeladene Geschichten drin landen.

Und jetzt ist es halt auch so, manche von den Sachen willst du halt nur Leuten, die sich irgendwie authentifiziert haben, zugänglich machen.

Und das ist halt auch so, wie macht man das eigentlich richtig?

Ich habe ehrlich gesagt keine Ahnung, wie mir das mit White Noise richtig geht, weil wenn das jetzt irgendwie ein CDN draußen cached, was ist, wenn da jetzt ein Request von jemand anders kommt?

Keine Ahnung.

Also so wie ich das kenne, was man machen kann, ist, dass du halt irgendwie einen Web-Server hast, davor, der das halt ausliefern kann, theoretisch, also irgendwie in Nginx oder so.

Und der, da geht halt einen Request rein nach jetzt irgendeinem Bild oder nach irgendeiner Datei.

Und der Applikationsserver schickt dann halt bloß zurück, okay, der Request ist autorisiert oder nicht, oder das ist halt.

Und dann nimmt der Nginx das und ersetzt diese Response halt durch die File-Response.

Weil er ja auf die Files zugreifen kann.

Sowas kann man halt machen.

Es ist halt auch alles ganz schön, ganz schön übel.

Wie man das jetzt mit White Noise hinkriegt, ich habe keine Ahnung.

Also das sind alles Dinge, die sind nicht so richtig einfach.

Ja, aber tatsächlich für so städtische Assets ist wohl der Weg zur Zeit White Noise zum Ausliefern und dann halt, wenn man skalieren muss, halt einen CDN davor haben.

Und vorher, wenn man den JavaScript-Frontend dann quasi gebaut hat, wird das mit Webpack so ein Bundle gepackt und einen Chunk-Vendor ist, das ist nochmal nicht ausgeliefert.

Das ist nochmal ein anderes Problem im Grunde.

Also das ist das Problem, dass man halt, wenn man jetzt irgendwie eine JavaScript-Applikation im weitesten Sinne irgendwie entwickelt, dass man dann halt das in einen Bundle zusammen kompiliert haben möchte und halt auch vielleicht transpiliert, weil man schreibt halt ESNEX oder man schreibt halt TypeScript oder sonst irgendwas, was die Browser nicht verstehen.

Und dann muss das halt irgendwie nach ESX oder XS.

Warum verstehen denn die Browser kein ESX?

Also ESX verstehen sie, aber ESNEX zum Beispiel nicht.

Aha.

Ja.

Und halt TypeScript wahrscheinlich auch nicht.

Oder CoffeeScript oder was auch immer man da verwenden möchte.

Weil die das nicht verstehen, dann muss man denen halt sagen, dass das transpiliert wird mit was wie Babel oder was kannst du irgendwie.

Irgendwelche Transformatoren, das Transpiler und.

Das ist die eine Geschichte, dann ist es auch so, dass es halt unter Umständen günstiger ist, wenn es halt alles in einem Ding ist und minifiziert und nicht in vielen unterschiedlichen, sodass der Browser nicht so viele Requests machen muss.

Und ist heutzutage auch nicht mehr

so passt.

Den ganzen neuen Code, wie er schreibt, und was ist gerade nicht alle, die SCSS, SASS oder die ganzen Frontend-Sachen, die man da bauen kann.

Ist jetzt als letztens

das sind Webpack dann und baut daraus dann minifizierte, also auch ohne alle Leerzeichen, damit sie schneller geladen werden können, Pakete, schraubt die zusammen zu verschiedenen Chunk-Vendors, wie sich das nennt, und liefert das mit allen diesen 20.000 Notpaketen, die unbedingt notwendig sind für die ganze Anwendung, insgesamt als Files aus drin.

Ja, also mit Hashes und.

Genau, genau.

Webpack ist im Grunde das Ding, was halt ein Riesenhaufen, also dass es seine Applikation irgendwie nimmt und dann spuckt es halt so ein paar Bundles aus, die dann halt tatsächlich benutzt werden.

Das wäre das dann, was man in die Static-Files reinpacken kann.

Genau, genau.

Aber.

Ja, gar nicht, ganz, also wo ich jetzt schon ein paar Mal nochmal drüber gefallen bin, ist, man könnte diese Files dann ja einfach deployen und dann in Django einfach ganz normal laden, indem man halt die Namen dann so reinpackt.

Aber bei jedem Bild ist natürlich die Hashes anders und das heißt, du wirst das jedes Mal, wenn du das Frontend irgendwas änderst, dann das komplett neu bauen und das dann in Dango wieder anpassen und das willst du eigentlich nicht machen, aber dafür gibt es dann irgendwie so eine Säule.

Genau, deswegen schreibt ja auch die Pfade für die Static-Files und so, da schreibt man ja auch nicht direkt die Pfade rein, sondern dafür hat man ja auch das Static Tablet-Hag.

Sodass halt egal, wenn ich jetzt meine Storage-Engine, wenn ich jetzt von S3 auf Compute-Engine umsteige oder auf sonst irgendwas Minio oder dann muss ich halt nicht überall meine URLs ändern, sondern dann macht das Static-Tag das automatisch.

Ja, aber eventuell dann doch, weil ja nämlich der Bild von Webpack, ähm dir andere Hashes und deswegen auch andere Namen für die einzelnen Files gibt.

Und dann müsstest du dir Dateinamen halt ändern und das ist halt blöd und da braucht man eine Wiederlösung.

Genau, du brauchst halt so eine ähnliche Lösung dann halt jetzt für deine Bundles und da gibt es dann irgendwas Jung Webpack-Loader oder so und dann da sagt man dann irgendwie Render Bundle und genau dann.

Dann funktioniert das auf jeden Fall dann, wenn man die gebildet hat.

Ja, ich bin jetzt gerade noch dabei rauszufinden, wie das zum Beispiel mit Wue so funktioniert, dass dann der Development-Server nicht kaputt geht.

Ja.

Aber äh, ja.

Ja, ja, aber es ist ganz schön kompliziert.

Und ich meine, es gibt ja auch dann, tatsächlich muss man sagen, Webpack ist halt wahrscheinlich das, was man verwenden muss.

Gibt es keinen, nicht so wirklich einen Weg drumherum.

Es gibt auch noch Django Kompressor und so.

Also wenn man jetzt nur CSS und vielleicht ein ganz kleines bisschen JavaScript, aber nee, dann geht das auch alles damit gut.

Aber wenn man jetzt irgendwie kompliziertere Sachen macht, dann kommt man halt um Webpack eigentlich nicht rum.

Auch die ganzen anderen Tools, die es da so gibt, die sind alle nicht vergleichbar mit dem, was Webpack so kann.

Der Kompressor ist auch irgendwie kaputt gegangen, als ich ihn angefasst habe.

Das lag natürlich nur an mir.

Wahrscheinlich einen falschen Gang reingehauen getrieben und

gemacht, wie es immer so ist.

Die Sachen, die es kann, ist es super, aber das Problem ist halt, ja, es ist.

Es gibt ja noch das Kompressor-Tool-Kit.

Ja, also es ist irgendwie nicht, tatsächlich läuft es momentan auf Webpack hinaus.

Es gibt noch ein anderes Ding, das nennt sich Parcel.

Das könnte sein, dass das irgendwann mal Webpack ablöst, aber momentan ist es halt noch Webpack.

Und ja.

Man muss das halt irgendwie alles integriert kriegen, ja.

Das ist ja.

Das ist so eine Geschichte.

Das ist ganz schön hakelig, wenn man da mal so ein bisschen guckt.

Das ist ja nicht nur Pixel-Grumgeschubse, wenn man mal so ehrlich ist.

Es gibt so gute Witze.

Ich habe letztens wieder einen ganz tollen gesehen, wo jemand ganz gemütlich frühstückt.

Müsst die Schale und jetzt ganz gemütlich seine Kornflex.

Dann gibt es jemanden, der stellt Milch hin.

Das ist ein Roboter, der nimmt die Milchkanne und schüttelt das dann so vor ihm so in die Schüssel rein und guckt dabei die Hälfte der Milch so weg.

Das ist also Frontend Nutzer-Experience und Backend der Armt, der dann die Milch.

In die Schüssel gießen muss, ja.

Taja.

Ja, haben wir noch was auf der Liste oder haben wir euch jetzt alles erzählt über das Frontend, was ihr heute wissen wolltet?

Ja, das weiß ich nicht, ob das irgendjemand wissen wollte.

Also mit allen Dingen, die wir immer tun.

Aber im Grunde, ja, was halt interessant wäre, ist, ob da jemand Lust drauf hätte, mal irgendwie so eine View-Lerngruppe vielleicht mitzumachen.

Ich bin ja schon mal freiwillig dabei und melde mich.

Das ist schon mal

super, dann eigentlich sind wir dann ja schon komplett.

Aber genau, halt auch mit viel, viel Python und vielleicht auch Django oder man kann auch mal irgendwas anderes nehmen.

Man könnte auch mal, ich meine, ich hätte auch mal Lust, irgendwie Fast API zum Beispiel auszuprobieren.

So Starlet unten drunter und so.

Da gibt es ja auch ganz, ganz nette Geschichten mittlerweile.

Aber halt View im Frontend genau, dann können wir da, dann schreibe ich das vielleicht mal irgendwie auf und schicke das mal in diese Gruppe.

Das ist ein View-Cologne, glaube ich, irgendwie.

Die könnte man ja dann vielleicht einfach zur virtuellen View machen.

Da müssen wir auch nicht da wieder hinfahren.

Ja.

Und vielleicht kann man es ja dann auch irgendwie wieder in die physische Realität verlegen, wenn es dann mal wieder möglich sein sollte.

Dieser ganze Spuk jemand so weit ist.

Ja, ist ja ganz witzig.

Gerade genau die Sachen, mit denen man sich den ganzen um den Dom kümmert und den Dom, die sind alle da unten in Köln.

Ja, äh, sorry.

Keine Ahnung.

Kann man bestimmt auch noch irgendeinen jede Menge Wortwitze drauf.

Irgendwie.

Ja, ich glaube auch.

Verbrochen zu werden.

Ja, wir haben es schon wieder spät.

Ja, es ist echt genau.

Ja, eigentlich, was haben wir denn auf der Liste?

TypeScript könnte man noch machen, aber ich meine eigentlich, nee, ich glaube, ich würde auch das Unitest Smog vielleicht tatsächlich irgendwie einfach mal erstmal weglassen wieder.

Jetzt haben sich alle darauf gefreut, Jochen.

Ja, aber ich würde auch sowas heißen, wir müssen in letzter Zeit voraufstehen.

Gerade für dich.

Schrecklich, schrecklich.

Ja, ich kann das verstehen.

Ja, also hört uns auf jeden Fall, egal wo ihr seid, bleibt uns gewogen und morgens mittags, abends Nacht wieder eingewandert.

Ja, nicht, ne?

Nicht konkret.

Wir haben nicht, also wir haben gesagt, dass es zwei Tage vor dem Python Barcamp ist.

Wir haben gesagt, dass letztes Jahr 2019 ein, zwei interessante Sachen gewesen sind.

Also das kann man zurückrechnen, wer möchte, ist es der 23.

April 2020.

Ja.

Und genau, demnächst mehr Frontend, Backend-Integration hier.

Noch mehr.

Aber wir haben ja noch ein paar andere Sachen.

Also vielleicht müssen wir uns ein bisschen erhöhen.

Ja, ja.

Wir haben noch einige ganz spannende Sachen.

Wir brauchen Gäste.

Wir hatten noch immer noch keine Frau hier bei uns zu Gast, was daran lag ja.

Ja, wir hätten gerne eine mal da, die etwas erzählen kann über Python.

Ich hatte mal ein paar gefragt, aber die haben sich alle nicht überreden lassen.

Ja, vielleicht ändern wir das mal zu einer Jubiläumsfolge oder sowas, aber ihr kennt das ja wahrscheinlich.

In der Entwicklergemeinde ist es leider die Quote nicht ganz so super, wie wir das gerne hätten.

Oh, naja.

Ja, aber das kommen wir noch hin.

Also in Data Science, ja, ich glaube auch während demnächst müssen wir uns ja mal ein bisschen darauf fokussieren.

Vielleicht liegt es auch einfach an uns und wir sind zu verschoben.

Ja, das kann auch gut sein.

Ja, aber ansonsten, ja.

Alles klar.

Ja, genau.

Vielen Dank, dass ihr eingeschaltet habt.

Macht euch noch einen schönen Abend, Tag, morgen.

Ich auch.

Bleibt weiterhin gesund und hoffentlich bald mal wieder in live auf einem der schönen Events hier in der Ecke.

Alles klar.

Tschüss.

Ciao.