Revision 658: State of JS 2024, Teil 4/4

0:00 Ich würde nie auf die Idee kommen, mir irgendein Programm zu installieren, das ich nicht installieren muss, weil ich es genauso gut im Browser kriege. Ah, witzig.

0:06 Andersrum, komplett andersrum. Ich würde es sofort installieren. Hauptsache, ich muss nicht wieder den Tab suchen, wo das drin liegt. Mir ist es eigentlich egal, ob man Monorebo oder Multirebo hat. Ich muss halt, egal was ich habe, muss ich halt irgendwas Special Dashal machen und habe ein bisschen mehr Arbeit in irgendeine Richtung.

0:20 Dann sollte man sich halt entscheiden, was mache ich denn lieber? Ich mag dieses manuelle Untersuchen, das stört mich gar nicht. Das mache ich in 10 Minuten, dann mache ich halt das Repository, ich checke das aus, dann schreibe ich, oh, übrigens, ich habe schon mal ein Break & Change vorbereitet, ich war schon mal so frei, ihr könnt das ja merchen, wenn auch immer ihr upgraden wollt.

0:35 Fertig ist cool, die Vanessa macht jetzt gerade vor den GitLab Sales Pitch. Aber es stimmt, du hast komplett recht.

0:45 Diese Revision von Working Draft wird euch präsentiert von Mitwald, den Veranstaltern des Head in the Cloud Summits. Liebe Hörerinnen und Hörer, ihr kennt Mitwald ja mittlerweile als den Hoster von Nerds für Nerds. Aber Mitwald macht noch mehr, als nur Server zu bepüchern. So findet am 13. Juni 2015 auf dem Mitwald-Campus in Espelkamp der Head in the Cloud Summit statt.

1:04 Auf dem geht's um Cloud und DevOps, es geht um Tech-Themen allgemein und ganz generell um kreative Vibes. Alle Infos findet ihr auf mitwald.de slash lp slash head strich in strich the strich cloud. Den Link zum Anklicken findet ihr auch in den Shownotes. Hinter diesem Link findet ihr die Ticketbuchung, den Newsletter, Videos des letzten Summits und den noch offenen Call for Papers.

1:29 Wenn ihr Nerd seid, denen Kreativität, Tech, Cloud und DevOps am Herzen liegen, ist euch der Head in the Cloud Summit wie auf den Leib geschneidert. Alle Infos und Links findet ihr in den Shownotes zu dieser Revision. Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft. Hallo und herzlich willkommen zu Working Draft Revision 658.

1:51 Heute am Start die Komponentenkönigin Vanessa. Servus. Und der Rust-Rächer Stefan.

1:59 Guten Morgen, guten Abend, Moizet.

2:01 Und meine Wenigkeit, der Peter. Es ist jetzt nicht ein Tag, nachdem wir die letzte Folge aufgenommen haben, sondern wie wir das immer so machen, eine Woche später am Montagabend.

2:13 Zwei Wochen später.

2:14 Genau, genau.

2:15 Wir hatten zwischenzeitlich eine andere. Okay.

2:16 So, so. Wir haben ja noch hier unseren Geheimpodcast, den wir dann ja auch noch aufnehmen müssen. Ganz, ganz secret. Was jetzt nicht so geheim ist, sind immer noch die Ergebnisse vom State of JS 2024, den wir heute mal zumachen wollen, indem wir über die letzten paar Themen reden. Wir waren stehen geblieben bei Testing, haben uns über Jest aufgeregt im Wesentlichen und festgestellt, dass wir in unterschiedlichen Universen leben, was so Testing angeht.

2:43 Und jetzt müssen wir halt sämtliche anderen Themen noch irgendwie in eine Folge quetschen. Weißt du jetzt nicht, wie interessant jetzt so Sachen wie React Native in eurer Realität so normalerweise sind?

2:53 Also nicht existent.

2:56 Ich habe es gerade schon vorher auch gemeint, hier bei Mobile und Desktop eigentlich habe ich gar nichts dazu zu sagen. außer ich habe gehört, dass Tauri cool ist vor einem Jahr. Und die einzige Frage, die ich aufbringen könnte, wäre überhaupt nicht eben toolspezifisch, sondern wie sinnvoll es generell eben ist, dass wir JavaScript benutzen, um Mobile- und Desktop-Apps zu schreiben.

3:21 Und ich sehe halt einfach den Fall immer noch, dass du hast halt die JavaScript-EntwicklerInnen schon in deiner Firma sitzen und du brauchst halt jetzt eine Desktop-App. Also kannst du das doch mal eben in Elektron reinwerfen. Das klingt jetzt ein bisschen negativ. So hatte ich es mit früher auch behaftet, weil dann immer die Performance so schlecht war und irgendwie hat es alles nicht so richtig nativ gewirkt.

3:40 Und du willst ja schon auf den Devices dein natives Gefühl haben, wie das heutzutage ist. Ich weiß es gar nicht. Ich weiß gar nicht, welche Apps ich da wie benutze, ob die Elektron-Apps sind oder ob das native Apps sind. Keine Ahnung. Ich weiß nicht, was Slack ist. Es wird wahrscheinlich kein Elektron sein. Vielleicht aber doch.

3:56 Ich glaube schon, oder?

3:58 Na, es sind Elektron-Apps, ja.

4:00 Ja, läuft ja irgendwie auch, also kann es auch nicht so schlecht sein.

4:03 Naja, vor allen Dingen brauchst du da ja speziell auf dem Desktop die exakt gleiche User-Experience wie im Browser. Und du brauchst den Browser, weil nicht jeder sich dieses Ding installieren mag oder kann.

4:12 Ja, das finde ich immer ein bisschen, darüber wundere ich mich immer so ein bisschen, wenn man die Tools lieber im Browser verwendet, als die Pseudo-nativen Apps dann. Also ich würde niemals auf die Idee kommen, Slack im Browser zu verwenden, außer wie du gerade gemeint hast, man kann nicht, man darf nicht.

4:31 Ich würde nie auf die Idee kommen, mir irgendein Programm zu installieren, das ich nicht installieren muss, weil ich es genauso gut im Browser kriege.

4:37 Andersrum, komplett andersrum. Ich würde es sofort installieren, hauptsächlich muss ich wieder den Tab suchen, wo das drin liegt. Deswegen wäre ich fast generell ein größerer Fan von so Microsoft Teams und sowas, bevor ich Google Meet verwende, wo ich dann wieder das Browser-Tipp suchen muss.

4:50 Das ist Wahnsinn. Ich lebe in einer komplett anderen Welt als du. Also erstens Microsoft Teams greife ich nicht einmal mit der Beißzange an. Das ist die schrecklichste Software, die je geschrieben worden ist. Und ich bin auch eher im Browser unterwegs. Also es kommt ganz darauf an, wie oft ich die Software verwende.

5:06 Slack habe ich installiert, weil ich habe zehn Channels und ich bin da eigentlich, also das sind diese zehn Workspaces oder Teams oder wie sie sie dort nennen, meine Tabs. Und du brauchst nicht einen Tab im Browser und nachher nur einen Tab im Produkt, dass du das Richtige findest. Das ist okay, wenn ich das installiere. Also Sachen wie Visual Studio Code ja auch eine Elektron-App.

5:30 Ich sage, dass ich das nicht im Browser laufen lasse, weil da fehlt mir halt ein bisschen der Zucker aufs Dateisystem. Aber ansonsten schaue ich halt, dass die anderen Sachen, die laufen alle irgendwie im Browser. Tatsächlich, unser Working-Draft-Channel, unser Working-Draft-Slack, den habe ich jetzt auch nur im Browser offen. Deswegen bin ich auch so langsam in meine Antwort.

5:48 Ja, ich glaube, das ist tatsächlich so die Frage der Intensität der Nutzung. Also ich bin im Prinzip nie mehr als drei Slack-Workspaces drin. Und das passt irgendwie so in Tabs, minimiert, nebeneinander, weil ich dann weiß, der linke ist dieser, der mittlere ist jener, der rechte ist solcher. Aber bei 10 wird das wahrscheinlich nicht skalieren. Da wird es ja irgendwann den Überblick verlieren.

6:14 Also ich verstehe diesen Elektron-Hass auch nicht, das ist halt dann entweder so und ob das UI jetzt beknackt ist, weil es, also mit beknackt meine ich nicht nativ ist, weil es Elektron ist oder weil es halt irgendein seltsames Toolkit verwendet, das ich gerade nicht installiert habe, ist mir ja im Endeffekt egal.

6:29 Die Frage ist halt, brauche ich das Ding und kann ich mit dem arbeiten, so wie es ist, wenn ja, verwende ich es und wenn nicht, dann nicht. Das ist ja ein Werkzeug.

6:37 Ich finde es recht spannend, weil gerade im Bereich Mobile Apps finde ich das immer sehr, sehr schwierig, mit Browser-Technologien sinnvoll Apps auf mobilen Devices zu schreiben. Gerade wenn man in die iOS-Gegend geht. Seit über zehn Jahren versuchen diese Cross-Plattform-Publishing-Tools, das App-Entwickeln auf unterschiedlichen Plattformen einfacher zu machen.

7:11 Und ich glaube, dass sie nicht wirklich erfolgreich sind damit. Im Desktop ist komplett was anderes. Wenn ich Apps installiert habe, sind es entweder der Browser oder Elektron-Apps, die ich verwende. Also da dürfte mittlerweile schon so eine kritische Masse erreicht worden sein, dass wenn du eine Desktop-App machst, ist Elektron oder Tauri, das ist ja jetzt so eine rastbasierte Alternative zu Elektron, die ein bisschen einfacher ist oder ein bisschen leichter ist, was Speichermanagement angeht und nicht ganz so viel RAM benötigt wie die Elektron-Alternativen, durchaus eine Alternative geworden.

7:48 Also ich glaube, dass Leute eher sagen, sie machen jetzt ein Desktop-App mit Web-Technologien, als sie sagen, sie machen ein Desktop-App mit nativen Technologien. Kommt natürlich auf die News gesagt, aber es ist auf jeden Fall eine sehr brauchbare Alternative geworden.

8:05 Ja, da hast du, du hast einen guten Punkt gesagt, da kann man mal unterscheiden zwischen wirklich Desktop und Mobile noch, weil irgendwie finde ich es auch verständnisvoller, wenn ich eine App habe, die im Browser und dann die Elektron oder was auch immer App ziemlich gleich und identisch ist, das erwarte ich dann fast auch so.

8:22 Also auf Mobile habe ich immer noch das Gefühl, da erwartet man schon noch irgendwie entweder die Android- oder iOS-Designs dann auch zusätzlich, dass die Loading-Icon so ausschauen, dass die Button so ausschauen, dass die Tabs so ausschauen. Wie das jetzt heutzutage übrigens ist, wie man da auf die Sensoren von den mobilen Geräten zugreifen kann. Ich glaube, das war früher immer kompliziert, mit wie man dann auf die Kamera und sowas zugreift. Ich habe leider wirklich keine Erfahrung.

8:49 Also wenn auch da jetzt gerade jemand zuhört, der sich damit auskennt, schreibt uns dann gerne mal, wie da der Stand heutzutage ist. Oder wir laden dich dann auch gerne dazu ein. Interessieren wird es mich auf jeden Fall. Ich habe leider keine Info dazu. Außer, dass wenn ich jetzt hier bei dem State of JS nach unten scrolle, ich auch sehe, dass hier der Pain-Point Nummer 1 die Performance ist.

9:08 Und dann der Klassiker, Elektron und React Native werden wahrscheinlich am meisten verwendet. Dementsprechend sind es auch die meisten Pain-Points, Electron und React Native dann.

9:21 Tja, davon ist auszugehen. Ich würde mal sagen, ist halt ein Werkzeug wie jedes andere und dann benutzt man das halt eben oder halt nicht. Wobei Werkzeugen sind, die man entweder benutzt oder nicht. Wollen wir zum nächsten gehen? Build Tools? König der Build Tools ist immer noch Webpack. Das finde ich ein bisschen überraschend.

9:39 Ja, es bricht mein Herz.

9:41 Wirklich überraschend? Es ist nicht so dieser Jake-Very-Effekt. Es ist halt überall drin und bis du das mal weg hast.

9:47 Ja, okay, die Frage ist aber, ob sozusagen diejenigen, bei denen das der Fall ist, also Webpack ist ja zum Beispiel auch der Unterbau von Next.js, wenn ich mich recht erinnere. Wenn ich jetzt hier sozusagen anhake, ich verwende das, ich würde jetzt, wenn ich eine Next.js-App baue, würde ich sagen, Webpack ist da irgendwie eine eingebaute Dependency und möglicherweise muss ich das auch mal direkt konfigurieren, aber ich würde mich jetzt nicht primär als ein Webpack-Nutzer wahrnehmen.

10:11 Deswegen weiß ich nicht, ob das daherkommt, dass das überall eingebaut ist. Das ist ja dann öfter mal eher sekundär. Und wenn ich Probleme habe, dann liegt das ja an dem Überbau meistens, sagt jedenfalls meine sparsame Next.js-Erfahrung. Von daher muss es immer noch Leute geben, die sagen, ich brauche ein Build-Tool, ich gehe als Default-Lösung zu Webpack.

10:28 Und das finde ich ja angesichts der Alternativen schon ein bisschen bemerkenswert.

10:32 Naja, die Usage ist sehr hoch, aber wenn du auf die Positivity gerade drückst, dann geht der ganze Berg nach unten. Ganz steil. Also es war wirklich von Platz 1 auf Platz letzter Platz.

10:43 Ja, okay, das stimmt.

10:49 Also, du gibst einen validen Punkt auch nicht. Wie oft muss ich, wenn ich mich gerade in eines dieser vorgefertigten Framework setze, mit dem Build-Tool tatsächlich herumarbeiten? In all meinen Next.js-Projekten habe ich das nie gemacht. Da habe ich eher so ein Next-Config bearbeitet. Selbst wenn wir noch unseren Angular-Client gehabt haben, der ja auch auf Webpack aufbaut, habe ich nie mit Webpack selbst gearbeitet, sondern immer mit dem Framework rundherum.

11:16 Und zu sagen, dass ich jetzt selbst ein Projekt mache, das ich komplett eigens kreiere, keine zehn Pferde könnten mich dazu zu Webpack bringen. Also wenn das nicht O ist, Legacy-Projekte von 2016 sind, wo die Leute das selbst geschrieben haben und immer noch hingreifen müssen. Oder vielleicht Create Reactive, glaube ich, exposed Webpack ziemlich stark.

11:40 Also es muss irgendwas von dem sein, was die Leute verwenden, dass sie sagen, sie entwickeln täglich oder immer noch Webpack.

11:47 Oder es ist der Enterprise-Effekt, dass das in den ganzen alten Applikationen mittlerweile drin ist.

11:52 Und da hast du dann diese eine Person im Team, die genau das kann und genau das macht und immer auch machen muss, weil nichts funktioniert. Aber das Ding ist übelster Rotz meiner Meinung nach.

12:04 Naja, komm. Ich meine, es ist eines der wenigen Werkzeuge, das alles kann.

12:10 Ja.

12:11 Und außerdem das erste seiner Art. Wie gut kann das schon sein?

12:16 Okay, vielleicht tue ich ihm da Unrecht nicht.

12:19 Also übelster Rotz würde ich das nicht nennen. Ich würde halt irgendwie sagen, so hier, Romo Erectus, hast du soweit gut gemacht, aber jetzt übernehmen wir hier.

12:26 Ja, stimmt. Also ich glaube, ich tue dem Tool da Unrecht. Wobei, ich finde ja Webpack eigentlich nicht das Erste seiner Art. Das wäre ja Browser-Refy. Das Grundkonzept von Webpack, wie du Module lädst und so weiter und was das machen soll, ist genau das Gleiche wie bei Browser-Refy.

12:41 Na gut, aber der Scope von Webpack ist ja ein viel weiterer. Das macht ja auch dein CSS, deine Bilder, alles so. Das ist ja ein Browser-Refy, nicht der Fokus gewesen.

12:48 Ich weiß aber nicht, ob das richtig war.

12:50 Auch schon. Ich glaube auch. Ich bin sehr skeptisch. Da ist in dieser Liste von Tools nämlich was drin, was ich halt sehr gerne verwende. Das ist das zweitunpopulärste, Parcel.

13:05 Ja, Parcel ist speziell.

13:07 Aber Moment, Stefan, Stefan, das ist doch das Gleiche. Dem sagst du ja buchstäblich, als Lademechanismus sagst du, da ist die HTML-Datei, da ist alles reingebunden mit HTML-Standardmitteln. Du machst halt dann eben Script Import meine TS-Datei und CSS Import meine SAS-Datei. Und der macht ja nichts weiter als automatisch dann zu erkennen, okay, dann brauche ich wohl TypeScript und den SAS-Compiler, installiert die von selber.

13:32 Dir entgeht die Konfiguration, aber ansonsten ist es ja das gleiche wie Webpack. Gib mir dein Projekt, ich mach alles.

13:40 Ich muss vielleicht meine Aussage revidieren. Webpack ist vielleicht ein gutes Tool, war vielleicht das erste und hat viele möglich. Was Webpack möglich hat und das ist eigentlich genau das, wo ich dagegen bin, und das ich kritisch finde, ist, dass wir JavaScript als die Single Source of Truth für die gesamte Applikation hergenommen haben.

13:57 Es gibt Leute, die laden ihre Bilder in JavaScript, die laden CSS-Dateien in JavaScript, die laden jedes andere in JavaScript und das JavaScript ist diesen Hauptausgangspunkt. Und dadurch brauchst du diese ganzen unterschiedlichen Loader, die CSS laden, die PNGs laden, die dort dann die ganzen Imageoptimierungen machen und so weiter. Und ich finde, das ist der falsche Platz dafür.

14:17 Ich finde, wir legen dort eine Komplexität auf die JavaScript, falls die dort nicht hingehört und die nicht kompatibel ist mit dem Rest, wie die ganze Maschinerie funktioniert. Und das ist eigentlich das Problem, das ich habe. Wenn ich in Parzl auf eine HTML-Datei gehe und das findet die Sourcen, die ich inkludiere und findet nachher heraus, was da eigentlich dahinter steckt, das ist fein für mich und je weniger ich konfigurieren muss, umso besser.

14:37 Aber dass ich jetzt sage, mein Haupteinstiegspunkt ist die Main-JS-Datei und ich lade dort eine CSS-Datei genauso, wie ich das mit ECMAScript-Modulen machen würde. Ich glaube, dass dieser Weg falsch war. Ich glaube, dass uns dieser Weg mehr Probleme macht, weil wir effektiv eine Zweitsprache neben der tatsächlichen Sprache generieren.

14:57 Gut, machen wir mit GSX von sich aus schon. Macht aber das Wegmigrieren davon ungleich schwieriger.

15:04 Ja, das ist der Punkt, würde ich sagen. Also Webpack verleitet dich eher dazu, originelle Dialekte zu verwenden?

15:11 Ja, im Webpack ist dann auf einmal alles ein Dialekt, weil du halt über diese Loader-Mechanik einfach alles im JavaScript machen kannst. Und das ist eher nicht das Problem vom Tool, sondern das Problem, wie Leute das Tool verwendet haben. Und ich merke das jetzt, wenn ich mit JavaScript-Entwicklerinnen und Entwicklern arbeite, die ein bisschen später angefangen haben wie ich damit.

15:35 Wir haben ein React-basiertes Framework geschrieben und Leute wundern sich, warum sie keine CSS-Dateien da drin laden können. Nicht wissend, dass das ja eigentlich in JavaScript nicht geht. Gehen aber davon aus, dass das ein Standard-Feature ist von ECMAScript-Modulen. Das ist das nicht. Und da sehe ich eigentlich das Problem.

15:55 Ja, ich meine, es existiert zu einem gewissen Grad auch in anderen Sachen, wie zum Beispiel Parcel. Die haben sich ja zum Beispiel auch diese, na hier, was war das denn? Diese Dinger, die zur Compile-Zeit ausgeführt werden, Makros, aus Bann gemobst und da auch eingebaut. Die habe ich noch nie zu funktionieren gebracht.

16:12 Das muss ich googeln.

16:13 Ja, hätte ich halt ganz gerne gehabt für so Web-Components, weil da wäre es ja schon praktisch, wenn du irgendwie sagen würdest, zur Compile-Zeit bitte den CSS-String aus der extra Datei inleinen und dann als Adopted Style-Sheet einhängen, damit du keine Duplizierung hast von dem Zeug. Aber andererseits habe ich dann auch gesagt, ich habe es jetzt nicht zum Funktionieren gebracht und eigentlich finde ich das auch nicht schlecht, weil sobald ich das halt mache...

16:33 Bin ich halt mit meiner Software, die ich geschrieben habe, abhängig davon, dass ich ein Build-Tool habe, was halt diese Makros unterstützt. Und das ist ja kein Standard-Feature. Und der Grund, warum ich zunehmend mich weniger um Build-Tools schere, ist, dass ich halt einfach eine Aversion entwickelt habe gegen diese ganzen Dialekte.

16:48 Ich sag halt, nehm den Standard-Weg und sonst keinen. Und dann ist es mir halt ehrlich gesagt egal, ob es Webpack, Parcel oder sonst was ist. Ganz genau. Weil dann ist es ja einfach. Es wird immer nur dann schwierig und die Tools werden nur zu einem Problem, wenn man halt versucht, Dinge zu machen, die nicht ohnehin Standard sind.

17:03 Ganz genau. Auf einmal wird nämlich das ganze Thema Bundling wieder trivial. Dann kannst du relativ gut steuern, wo du dein Code-Splitting machst über diese Input-Funktion. Du kannst relativ genau steuern, was in deinem Bundle alles drinnen ist. Und es kommt halt nur das JavaScript-Ding rein. Und Leute, es ist nicht so schwierig, dass man eben bei CSS schreibt.

17:19 Es ist echt nicht schwer. Und es gibt auch Tools, die auf Standards funktionieren, damit du das in JavaScript machen kannst. Also das ist auch ein gelöstes Problem. Man muss nicht alles über Import-Direktiven in seinen JavaScript-Source-Files machen.

17:38 Ja, man braucht nicht mal notwendigerweise einen Bundler dieser Tage, würde ich sagen. Also seitdem ich Import-Maps habe, ist halt so, ich baue irgendwie ein NPM-Package und ich will eine Demo-Datei beilegen. Ist total trivial geworden, weil ich halt sagen kann, Import from NPM-Modulname. Und kann einfach sagen, ja, wenn du die halt ausprobieren willst, dann lad halt diese HTML-Datei irgendwie über Localhost.

17:58 Man muss das Ding dafür nicht installiert haben. Es ist halt einfach so ein, es fühlt sich halt eben an. Und ganz ehrlich, für viele Use Cases sind auch so Sachen wie Bundling und Minifying ja nicht wirklich notwendig. Weil, ich meine, der Kram wird doch eh vom Web-Server gezippt ausgeliefert. Und Codesplitting hast du ja ohnehin dann auf Modulebene, so wie es wahrscheinlich grob irgendwie Sinn macht.

18:17 Das ist ja eigentlich auch ein Aktefakt aus der Vergangenheit, als sowas halt eben zwingend notwendig war. Und mittlerweile geht ja so viel einfach gut genug von selbst, dass man sich große Teile von diesem ganzen Krempel echt sparen könnte.

18:29 Ich finde es beeindruckend, weil in meinen ersten Webprojekten, für die ich tatsächlich bezahlt geworden bin, war Bundling immer ein Optimierungsschritt danach. Wir haben einfach auf Fälldateien gearbeitet. Wir haben unterschiedliche Modulsysteme genutzt, wie zum Beispiel dieses Require.js und so weiter, um unseren Code ein bisschen raufzusplitten zu können, haben aber tatsächlich mit den Originaldateien gearbeitet.

18:51 Da war Bundling immer ein optionaler Optimierungsschritt, den wir heute für ein Production-Deploy gemacht haben. Und irgendwann ist es zum Requirement geworden und nicht erst mit den Dialekten wie JSX, also ich habe das Gefühl, das ist schon weit, weit früher passiert, dass man davon ausgegangen ist, dass, ein Bildprozess muss sowieso existieren und das ist eigentlich schon die erste Richtung, wo wir falsch abwogen sind.

19:18 Ja, es ist halt Optimierungswahn, also der alte Spruch hier, premature optimization, bla bla bla, aber da hält sich ja keiner dran, weil einfach so gewisse Dinge als Best Practice vorausgesetzt werden. Man muss das halt so machen. Bevor man überhaupt überlegt, habe ich überhaupt ein Problem, dass es hier lösenswert ist.

19:38 Wenn ich jetzt wieder an meine React-Katastrophe denke, an der ich da arbeite, da ist so viel Premature Optimization drin und so viel Use Callback und hast du nicht gesehen. Das macht es halt so dem Forensiker mir hier nicht einfacher zu verstehen, was da vor sich geht, wenn halt sowieso Unverständliches nochmal in Performance Optimierung gepackt wird.

19:55 Wie wäre es, wenn man das einfach alles sein lassen würde. Wenn man das einfach so nutzen würde, wie es gedacht ist, so, und dann hat man auch kein Problem damit. So, aber trotzdem müssen wir jetzt, glaube ich, alle nochmal kurz nennen, hier aus diesen Build-Tools, was wir verwenden und warum. Ich habe ja schon Parcel gesagt, also No-Brainer-Lösung für die schnelle Mini-App zwischendurch.

20:14 Da ist die HTML-Datei, mach mal. Das verwende ich gerne und wenn ich einfach JavaScript optimieren möchte, nehme ich ES-Bild. Und den Rest da habe ich, glaube ich, seit Ewigkeiten nicht benutzt.

20:25 Ich nehme VEAT oder ich nehme die TypeScript CLI für so kleine Sachen. Und ich, mal davon abgesehen, was ich jetzt nehme, ich habe mir jetzt die ganze Zeit nochmal die Zahlen genau angeschaut. Und bei der USET, wo Webpack auch am meisten verwendet wird, das addiert sich ja nicht auf. Da ist ja nicht irgendwie 80% Webpack und 20% der ganze Rest, sondern wir haben hier halt dann irgendwie 86% Webpack, aber dann 78% VEAT.

20:53 Und einerseits denke ich jetzt, Peter, zu dem, was du vorher gesagt hast, ich glaube, wenn jemand Next.js da verwendet, wird man schon Webpack anhaken, weil was sonst? Du willst hier die Frage vielleicht nicht leerlassen. Und dann könnte ich mir vorstellen, dass man pauschal einfach immer noch Webpack anhakt, weil jeder schon mal irgendwie was mit Webpack da gemacht hat.

21:14 Und wann will man das hier auch abhaken? Aber wie gesagt, wenn ich hier habe, das sind jetzt 4% Unterschied zwischen Webpack und Veed. und wenn ich runterscrolle mit Used at Work, da habe ich 7733 Viet versus 7726 Webpack. Irgendwie habe ich das Gefühl, vielleicht hat man auch einfach von Webpack auf Viet umgestellt und dementsprechend hat man auch Webpack da einfach angefasst.

21:37 Den ganzen anderen, alle anderen habe ich eigentlich nie wirklich verwendet. Also ES-Bild kenne ich, habe ich einmal benutzt. Roll-Up habe ich mir angeschaut, weil habe ich mir halt angeschaut. Turbo-Pack habe ich mir angeschaut, aber benutzt eigentlich jetzt immer nur Webpack und Viet. Oder TypeScript CLI.

21:56 Na Stefan, und jetzt bist du dran.

22:00 Also wir verwenden bei uns im Produkt ES-Bild, also Custom konfiguriert, wir haben da quasi unser eigenes Bild-Tool geschrieben, das taucht natürlich dort jetzt nicht auf, aber da ist ES-Bild die Basis. Wir sind nicht ganz so happy mit ES-Bild, weil potenziell mehr möglich ist mit deinen Bundling-Tools und DS-Bild steht gerade ein bisschen an.

22:24 Also da hoffen wir sehr stark, dass das, was VIT liefert in Zukunft mit dem, RAS-basierten Unterbau, dass wir damit mehr machen können.

22:32 Was wäre das so? Weil ich habe VIT noch nie benutzt. Ich habe keine Ahnung, was das Delta genau ist.

22:38 Naja, VIT, also es ist ja witzig, dass die Sachen zusammengeworfen sind, weil VIT ist ja in meiner Vorstellung als erstes einmal ein Development-Server, ein General-Purpose-Development-Server, der halt nachher diesen Optimierungsschritt machen kann, dass er auch und verwendet, glaube ich, eh dann Rolldown als Unterbau, also jetzt aktuell ES-Bild als Unterbau, will aber auf Rolldown migrieren.

22:57 Und Rolldown, da erwarten wir uns einiges, weil gerade diverse Optimierungsmöglichkeiten im Bereich Tree-Shaking und so weiter in ES-Bild eher schwierig sind und besser funktionieren mit anderen Tools.

23:10 Ach guck, okay.

23:11 Ja, aber das ist, also da sind wir in der, In Mikrooptimierungen drinnen.

23:19 Ja.

23:20 Also du musst den ES-Bild tatsächlich hier und da herum hacken.

23:23 Genau, das erklärt, warum das bei mir noch nicht aufgetaucht ist, bei ES-Bild als Limitierung, weil ich das vor allen Dingen benutze, um halt irgendwie die Bundles von Libraries zu bauen. Und dann ist mir ja Tree-Shaking erstmal egal.

23:32 Ja, genau. Und bei uns ist es halt so, wir haben halt teilweise geteilten Code zwischen Frontend und Backend. Und du willst halt keinen Frontend-Code im Backend haben. Und das passiert mit ES-Bild öfter, weil halt ES-Bild sehr konservativ ist, was das Tree-Shaking angeht. und halt auch keine Anstalten zeigt, das irgendwie zu verändern in Zukunft.

23:48 Das ist Feature komplett. Die wollen da nicht wirklich was machen. Persönlich verwende ich halt dann einfach die TSC CLI und SWC tatsächlich. SWC ist cool, wenn du einfach nur Type Erasure machen willst und JavaScript rauskriegen willst.

24:04 Das wohl wahr. Okay, ich will noch ein Tool erwähnen, das da nicht aufgeführt ist, was ich aber ganz lustig finde. Habe ich möglicherweise auch schon mal erwähnt. Es gibt wirklich diverse Tools, um DTS-Files von eurem TypeScript-Projekt auch zu bundeln. Also normalerweise macht ja der TypeScript-Compiler irgendwie, keine Ahnung, hier sind sieben TypeScript-Dateien, macht da sieben JavaScript-Dateien draus und sieben DTS-Dateien.

24:26 Und die JavaScript-Dateien werden dann ja öfter mal noch durch einen Bundling-Schritt noch zusammengefügt, in eine große Datei, sie alle zu knechten und die DTS-Dateien normalerweise nicht. Und so Kram wie der DTS-Bundler, der macht das tatsächlich. Was ganz lustig ist, wenn man mal so das Requirement hat, wie irgendwie obfuskieren, was da genau die Modulstruktur ist oder ich will das Projekt irgendwem in die Hand geben können mit den Worten, hier sind zwei Dateien, werde glücklich damit.

24:51 Das ist ganz nett. Da gibt es auch eine breite Auswahl, die auch ähnlich wie die Buildtools alle sehr unterschiedliche Trade-offs machen. Und das kann man dann auch mal gebrauchen, wenn man das braucht, was wahrscheinlich fast nie ist. Aber ich will nur erwähnen, sowas existiert auch.

25:02 Dann war das damit dann der letzte Punkt zu den Buildtools.

25:06 Würde ich sagen, oder?

25:07 Ja, wenn man Lauf rette. Das ist der Wahnsinn.

25:10 Wir haben das jetzt alle im Hinterkopf, dass das die letzte ist.

25:15 Naja, und nicht vergessen, wir hatten ja eine ganze Woche Pause, um uns wieder zu erholen.

25:24 Und wir sind zwar jetzt bei dem letzten Punkt von den Libraries, aber es kommen ja irgendwie noch andere Punkte danach, obwohl danach jetzt nur noch die Other Tools, Usage, Resources kommen, wo wir normalerweise schneller drüber springen. Aber jetzt wird es spannend, wie lange wir bei den Monorepos hängenbleiben.

25:41 Ich kann jetzt natürlich wieder die Grundsatzfrage aufmachen von Monorepo versus Multirepo. Ich bin ja immer so ein bisschen für die einfache Variante. Ich finde Monorepos gar nicht so schlecht, Aber ich würde es auch nicht verkomplizieren. Ich finde auch Multi-Repos ganz gut. Man muss halt richtig konfigurieren, gell?

25:57 Ich wüsste ja ganz gerne mal, wie ich das überhaupt entscheide. Weil also irgendwie, ob ich so was haben will. Weil ich habe irgendwie hier so meinen kleinen Zoo an Libraries und die hängen irgendwie zusammen. Und manchmal habe ich halt dieses klassische Szenario, dass irgendwas upstream, ein Update braucht.

26:12 Und dann muss ich das halt eben erst so durch sämtliche Dependents durchziehen für halt so meinen kleinen Zoo. Wo ich normalerweise sagen würde, ja, wunderbar, hätte ich jetzt Monorepo, wäre das Problem jetzt in dem Maße nicht existent. Andererseits hat mein ganzes Set an Dingen, die da existieren, nicht inhärent was miteinander zu tun, sondern das ist halt meine persönliche vertikale Integration.

26:32 Da ist mein Toolkit A, da ist mein Toolkit B, dann verwende ich da irgendwie Library C und in Projekt D verwende ich das. Aber das hat ja erstmal inhärent keinen Zusammenhang. Ist das jetzt was für ein Monorepo oder nicht? Weil es mir Ärger macht, aber es gehört irgendwie nicht zusammen. Was mache ich denn da?

26:48 Ich wünschte, ich könnte einfach drauf antworten.

26:51 Wenn nicht, dann antwortet kompliziert, nehme ich mir auch gerne.

26:55 Ja, die schwierige Antwort ist wahrscheinlich, wie man arbeiten möchte. Denn es wird ja dein Repository nicht interessieren in dem Sinne, ob das jetzt wirklich zusammengehört oder nicht. Das interessiert auch meinen Bild, also ich meine jetzt so ein Picture, so Fotos. Es interessiert auch meinen Fotoordner nicht, ob ich da meine Hochzeit und sonst was zusammengeschmissen habe.

27:16 Wenn ich die lieber zusammen anschaue, dann schaue ich die in einem Folder an. Und wenn ich sie lieber in Subdirectories mache, dann mache ich sie lieber in Subdirectories und suche dann die durch. Ich wollte nur den einen Punkt noch sagen, die Situation, wenn ich lieber zu einem Monorepo raten würde, wäre die, wenn man sonst sehr viel Hickhack machen muss, um die Dependencies zusammen zu testen.

27:38 Also, wenn ich ein Repository habe über eine UI-Library, dann sollte ich die irgendwie, die UI-Library ja einfach so entwickeln können, indem ich da meine Button und meine Boxen mache. Wenn ich jetzt aber so entwickeln muss, dass ich gar nicht unbedingt den Button jetzt implementieren muss, sondern eigentlich einen kompletten Flow und paar Seiten und da in diesem Programmierschritt muss ich eben auch noch den Button dafür schreiben, dann habe ich das schon erlebt, dass man dann mit NPM-Links oder wie das heißt oder Sim-Links irgendwie anfange, auf die Dateien dazu zu greifen.

28:13 Das funktioniert aber eben auch nicht immer glorreich oder muss eingestellt werden und dann geht es wieder kaputt, dann wird halt auch einfach mal das HTML rüberkopiert oder sowas und dann wird halt die Button-Komponente doch wieder in dem eigentlichen Main-Repo implementiert und muss dann irgendwann wieder in das UI-Bibliotheken-Repository umgezogen werden.

28:34 Und wenn das einfach mental von dem Workflow her zu Problemen führt, weil man einfach von den Projekten her nicht so entwickelt, dass man sagt, ich möchte diesen Button bauen, da, ich habe mein Ticket für meinen Button, da, da, da, da, da, Button gebaut, okay, jetzt kann ich den Flow bauen. Wenn das einfach nicht zusammenpasst, dann würde ich es vielleicht so entscheiden zu sagen, da ist jetzt ein Monorepo besser und in dem Fall, wenn man anders entwickeln möchte, ist vielleicht ein Multirepo besser.

28:59 Ja, aber ich meine, bei mir ist es ja noch so, dass die sozusagen Schritte in so einer Pipeline wirklich keinerlei inhaltlichen Zusammenhang haben. Es ist halt nur so, dass alle Dinge, an denen ich schraube, sich halt in einen Graphen sozusagen einpflegen. Weißt du, ich könnte jetzt theoretisch das Monorepo, das reicht das für Peper aufmachen.

29:18 Und das wäre halt noch so eine semantisch sinnvolle Grenze. Aber ansonsten hängt der Kram da drin irgendwie nicht zusammen, weswegen ich da so ein bisschen einfach so eine semantische Aversion verspüre, das zu machen. Das Leben würde halt sehr viel leichter werden, weil also ich habe halt irgendwie so ein Ding, das macht was. Und dann gibt es dieses Ding, was das macht.

29:35 Das hat dann, keine Ahnung, was das dieses Ding in Markdown noch so verarbeitet. Das ist dann so ein Markdown-Parser-Plugin. und dann will ich dieses Markdown-Parser-Plugin in der Präsentationssoftware verwenden, damit man da via Markdown das ursprüngliche Ding drin hat. Und natürlich sollte das so sein, dass das einfach einander einfach so verwendet und einbaut, aber wir wissen, wie das in der Realität ist.

29:57 Ich habe einen Use Case und um halt sozusagen Upstream auch alles bereitzustellen, um den Use Case zu bedienen, muss ich ja sozusagen in jedem dieser Dinge auf die ganzen Dinge stoßen, die nicht funktionieren, damit ich die dann wieder Upstream sagen kann, ey, da muss jetzt hier der Markdown-Parser angepasst werden.

30:13 Yo, dazu brauche ich aber diese extra Option in dem Wurzelding. Und das ist halt das, was mir im Moment halt einfach extrem viel Zeit traut, weil dann mache ich halt genau diesen Krempel hin und her linken und dann bin ich am Laptop und dann radle ich ins Büro. Ist ein anderer Computer, habe ich das da auch schon gelinkt?

30:26 Nee, aber das merke ich erst nach zehn Minuten. Und das ist halt einfach super, super lästig. Aber es hängt halt an sich nicht zusammen. So, das ist so mein Ding. Es ist halt einfach nur mein persönlicher Werkzeugkoffer. Und ich habe extrem die Schmerzen, die Monorepos lösen würden, aber ich kann doch nicht dann einfach sagen, mein Werkzeugkoffer ist einfach ein so ein gewaltiges Repository oder Projekt oder so, gefühlt.

30:51 Das hat ja alles nichts mehr dazu zu tun. Das ist halt einfach nur Kram.

30:53 Ja, der Nachteil davon ist natürlich so ein bisschen von der Code-History, weil du hast ja dann eine Commit-History für deine zehn verschiedenen Tools da drin.

31:01 Ja, gut.

31:03 Ich versuche jetzt gerade mal den Nachteil davon zu finden, dass das alles so eine Monorepo liegt.

31:08 Das gehört halt nicht zusammen. Ich finde das eigentlich ganz cool.

31:10 Ja, es gehört nicht zusammen. Aber das ist ja gerade nur so ein mentales Problem. Oder ist es ein Problem, wenn du die Systeme startest? Ist da irgendwas langsam?

31:18 Nö, aber zum Beispiel so Sachen wie Teile davon will ich halt gerne in GitHub so als Open-Source-Ding rumliegen haben und andere Sachen sollen privat bleiben.

31:25 Ja, gut.

31:28 Aber durch meine spezifische Realitätslinse betrachtet ist das schon alles eins. Und deswegen, alle zwei Wochen denke ich so, Monorepo, lass mal lesen, was dieses Tool so tut. Und dann merke ich halt relativ schnell, das passt auf mich nicht so ganz, dann vergesse ich wieder für zwei Wochen und dann wieder von vorne.

31:45 Ich wollte auch gerade sagen, ich habe deinen Fall eigentlich noch nie gehört. Ich kenne eigentlich schon wirklich nur den Fall, dass halt eben alles zusammen gehört. Nur, dass wenn man das zusammen in einem Repository liegen hat, zum Beispiel die Build-Time oder von deinem Development-Server, das ist einfach viel zu lange, Dauer zu starten und du möchtest halt schon eigentlich nur deinen Teilbereich davon starten.

32:05 Und nicht die komplette Amazon-Webseite, so nach dem Motto. Und dann musst du vielleicht anfangen, dir zu überlegen, ob du jetzt Multi-Repo machst oder ob du verschiedene Mono-Repo-Tools ausprobierst, wie sie hier genannt werden, wie Rush, Turbo, Repo, Yarn, Workspaces, etc.

32:19 Ja, ich habe auch schon drüber nachgedacht.

32:20 Dein Use Case ist eigentlich total neu. Das ist ja spannend.

32:22 Ich habe auch gedacht, man könnte vielleicht mehrere Mono-Repos haben. Aber dann habe ich sozusagen ja auch noch einen Zerfall in sich drin. Ja, Multi-Mono-Repo, warum nicht? Kannst du ja haben irgendwie so. Monorepo öffentlich, Monorepo privat zum Beispiel. Wäre jetzt nicht die beknackteste Idee, aber ist trotzdem beknackt.

32:41 Ich habe auch ein bisschen eine Meinung zu dem Monorepo-Ding.

32:45 Ja, hau raus.

32:46 Hau raus, ich lehne mich mal zurück.

32:51 Ich glaube, es ist technische Lösung für ein Organisationsthema.

32:57 Ja gut.

32:59 Das ist mein Take daran. Also was wollen wir denn mit Monorepos lösen? Wir wollen versuchen, dass mehrere Teams miteinander an dem gleichen Stück Software arbeiten können. Und das ist der große Selling Point von vielen dieser Dingen hier. Ich meine, Sachen wie Package-Manager-bezogene Workspaces, die haben meiner Meinung nach einen Sinn, dass man irgendwie Dependencies innerhalb einer Software sauber managen kann.

33:32 Also Cross-Dependencies von der eigenen geschriebenen Software, das funktioniert in anderen Programmiersprachen auch ganz gut. Ich glaube, in .NET diese Solutions, es gibt Cargo-Workspaces in Rust und so weiter. Und um die eigene Software ein bisschen einfacher zu strukturieren und Cross-Referenzen einfacher zu machen, ist das super.

33:49 Dinge, die da rausfallen, wie Turbo Repo oder NX, die haben ja den großen Anspruch, inkrementelle Updates von großen Softwareprojekten ermöglichen zu können. Das heißt, du kannst ja ein Submodul in deinem NX-Projekt entwickeln, bauen, shippen und das funktioniert nachher super gut mit allen anderen Modulen, die du auch verwendest. Und.

34:24 Das ist für mich ein Conway. Das ist für mich ganz klar einfach nur ein technisches Tool, um irgendwie zu schauen, dass viele, viele Leute in einer gewissen Organisationsstruktur miteinander arbeiten können. Und wenn du diese Organisationsstruktur nicht hast, brauchst du es auch nicht.

34:39 Aber jetzt hat Vanessa doch gerade noch andere Probleme erwähnt, die das lösen kann, wie zum Beispiel, dass ich die ganze Amazon-Webseite hochfahren muss, um was zu testen, was ja vielleicht nicht der Fall wäre, wenn das irgendwie entsprechend modularisiert wäre. Habe ich das richtig verstanden?

34:52 Muss man auch nicht. Das ist eigentlich auch, auch das ist eigentlich unabhängig davon, ob es in einer Monorepo liegt, das einfach nur ein Monorepo ist oder ein Monorepo liegt, das ein Turporepo ist oder ein Multirepo liegt. Du kannst ja auch mit, ich weiß es von Webpack, deswegen sage ich jetzt Webpack, du kannst ja auch in Webpack konfigurieren, dass du, wenn du NPM Start oder sonst was schreibst, dass du eine Reihe an Values mitgeben möchtest, welche Bereiche du davon jetzt eigentlich hofern möchtest und welche du einfach aus dem Cache laden möchtest oder welche du gar nicht laden möchtest.

35:22 Möchtest, weil du jetzt gar nicht drauf zugreifst. Dann geht halt vielleicht auch mal wieder ein bisschen was kaputt, wie A, dann ist das CSS nicht richtig geladen oder irgendwas ist dann nicht mit Hot Module Replacement gemacht, aber dann stirbt man halt den Tod ein bisschen, muss dann halt vielleicht mal ganz altertümlich Command-R auf der Seite drücken oder F5, damit die Seite neu lädt und das neue CSS jetzt da ist, muss mich damit aber eben nicht mit einem Tool dafür auseinandersetzen, dass mir das irgendwie auf magische Weise gelöst hätte.

35:51 Ich glaube auch, das sind Benefits, die mit einem Monorepo mitkommen, dass du dann auch solche Dinge machen kannst. Aber warum es Monorepos grundsätzlich gibt, ist halt, wie gesagt, viele Köche, viel Brei.

36:06 Ja, und dann genau dieses zusätzliche, nicht nur viele Köche, viel Brei, sondern ich finde, es kommt eine gewisse Komplexität dazu, wenn du als nur eine Köchin bei mehreren Küchen was machen musst. Was bei mir sehr, seit vielen Jahren eben der Fall ist, immer mit dieser UI-Bibliothekenarbeit, dass ich da irgendwie in drei Repos so durchhüpfen muss.

36:26 Und bei GitLab bin ich ja auch im Designsystem. Was wir aufgezogen haben mit manueller, nicht automatisierter Arbeit oder so halb automatisierter dann, ist, dass wir eine Liste haben an, wenn wir was in diesem Repository ändern, in welchen anderen Repositories mussten wir das überprüfen, ob das da Änderungen ergibt.

36:46 Natürlich schreiben wir alle Conventional Commit Messages und wir schreiben da rein, Obacht, das hätte jetzt vielleicht diesen Breaking Change. Trotzdem gehen wir noch zusätzlich den proaktiven Schritt zu sagen, wir haben jetzt diese Komponente verändert auf eine Breaking Change Art und Weise und leider kann ein Breaking Change Sehr, sehr klein auch einfach sein, ist trotzdem ein Breaking Change, wenn ich die Property umbenenne, die vielleicht niemand benutzt, ist aber egal, ich hab irgendwas von der API geändert von IO, dann muss ich durch fünf andere Repositories mal kurz durchgucken, ob da denn jemand diese Property verwendet hat.

37:19 Was ich nicht durchgucken kann, ist, ob gerade ein offener Merge-Request zum Code-Review vorliegt, wo jetzt jemand plötzlich eine Property verwendet, die noch nie jemand davor verwendet hatte und ich deswegen einfach diesen Breaking Change machen kann. Und deswegen brauchst du im Endeffekt halt einfach sehr, sehr gutes Testing oder vielleicht auch nur ein rudimentäres Testing, das dir dann meldet, huch, da verwendest du plötzlich eine Property, die gibt's doch jetzt irgendwie gar nicht.

37:41 Deswegen kann's halt ein bisschen schwieriger sein, weil ein Multi-Repo-Ansatz, wenn ich da über mehrere Repositories das ausprobieren muss. Das ist aber nicht unmöglich. Ich muss ja nur dran denken. Und dran denken tue ich dadurch, dass ich beim Code Review ein Template habe, wo Checkboxen stehen, wo steht, hast du ein Break-and-Change gemacht, in dem Bereich hast du dann diese sieben Repositories mal kurz durchgecheckt.

38:06 Dieser kurz durchgecheckt, das sind ja zehn Minuten. Das ist ja in keinem Vergleich zu ich setzte da jetzt ein kompliziertes Monorepo Setup auf. Mir ist eigentlich egal, ob man Monorepo oder Multirepo hat. Ich muss halt egal, was ich hab, muss ich halt irgendwas special-dashle machen und hab ein bisschen mehr Arbeit in irgendeine Richtung.

38:24 Dann sollte man sich halt entscheiden, was mach ich denn lieber. Ich mag dieses manuelle Untersuchen, das stört mich gar nicht. Das mache ich in 10 Minuten, dann schreibe ich halt, dann mache ich halt das Repository, check das aus, dann schreibe ich, oh, übrigens, ich habe schon mal ein Break and Change vorbereitet, ich war schon mal so frei, ihr könnt das ja merchen, wenn auch immer ihr upgraden wollt.

38:39 Finde das cool, die Vanessa

38:41 Macht jetzt gerade voll den GitLab Sales Pitch, weil du kannst jetzt einfach ein Template verwenden, dann kannst du ein Häkchen machen und dann gehst du in das andere Repo rein, das geht alles super cool mit GitLab.

38:52 Ja.

38:53 Aber es stimmt, du hast komplett recht, es ist, Es ist oft an die Lösungen so einfach. Hier nicht entschalten oder vielleicht sich hier und da selbst an gewisse Dinge erinnern, hilft schon sehr. Es hilft auch ungemein.

39:09 Wenn man dann kein Blaming in der Firma betreibt. Da kann mal was schief gehen. Wie gesagt, ich kann einen Breaking Change machen, von dem ich 100% sicher bin, dass der nicht wirklich was breaking kann, weil bisher niemand diese Property verwendet hat, weil die noch nicht mal dokumentiert war. Aber sie war halt irgendwie rein technisch, hat die halt bestanden.

39:26 Und dann kann es immer noch doch sein, dass das doch jemand in einem Merch-Request dann aufgemacht hat. Und dann irgendwie nach drei Tagen werde ich getaggt und dann kriege ich auch mal ein kleines Herzrasen. So, Vanessa, du hast doch was geändert. Ich so, oh Gott, oh Gott, was habe ich gewohnt gemacht?

39:39 Und dann gehe ich halt da rein. Ach so, ja, und dann sage ich, das war der Breaking Change. Und es ist halt schon alles sehr viel einfacher, wenn es dann dokumentiert ist, wenn ich dann einen Link habe zu meinem Breaking Change, das ist der bla bla bla. Und dann sagt die Person, ach cool, danke, dann weiß ich Bescheid.

39:51 Dann benutze ich jetzt die andere Property. Wenn ich jetzt in Teams arbeite, wo das dann wirklich heißt, entschuldigen Sie hier C-Level, die Vanessa, die hat da, ja, deswegen habe ich hier wieder mehr Arbeit, dann ist das vielleicht unangenehm und dann braucht man vielleicht technische Lösungen, wie Stefan, du es schon so häufig heute auch gesagt hast, dann braucht man vielleicht leider technische Lösungen für Organisationslösungen.

40:11 Ich hätte halt immer so ein bisschen mehr vielleicht eher so die organisatorische Lösung, bevor ich mir die technische da irgendwie holen muss.

40:17 Ich glaube, dass das ja auch ein bisschen eine Möglichkeit es ist, dass sie Firmen, Und selbst einreden, an einer Lösung zu arbeiten für irgendwelche Kommunikationsprobleme, die so in der Firmenstruktur herrschen, weil tatsächlich ist es bei einer gewissen Größe auch schwierig, eine Firmenstruktur zu ändern oder eine Organisationsstruktur zu ändern.

40:38 Also von dem her, dieses Wechselspiel zwischen Softwarearchitektur und Firmenorganisation, das ist ja schwierig und das ist ja sehr, sehr delikat in der Umsetzung. Von dem her, verstehe ich das, dass Teams dann sagen, hey cool, da gibt es eine Lösung, das löst zumindest einmal 90% unserer Probleme. Wie immer kaufst du halt damit irgendwelche anderen Probleme oder Meinungen ein, mit denen musst du halt rechnen und von dem her ist das halt auch legitim.

41:04 Wir haben viel Monorepo-Tools ausprobiert. Wir haben auch NX in einigen unserer Projekte drinnen. Das ist ja immer so dieses vorherrschende Monorepo-Tool. Ich bin sehr skeptisch, was das Ding angeht, weil die Probleme, die du dir einkaufst, sind teilweise sehr, sehr groß oder die Schwierigkeiten, die du dir einkaufst, sind sehr, sehr groß oder zumindest zeitfressend.

41:27 Wir haben gesehen, dass wenn zwei oder mehrere Teams versuchen, Software zu konsolidieren über ein Monorepo, das auf Nix-Basis ist, kannst du mindestens eine Person pro Jahr abstellen dafür, um das Monorepo am Leben zu erhalten. Das ist heftig. Die Lösung dafür ist, wenn du nicht eine Person abstellen möchtest dafür, mindestens eine Person abstellen möchtest dafür, ist, dass du den Bezahldienst von NX verwendest, die halt viele Dinge in der Cloud bei denen lösen, wo wir wieder bei dem gleichen Punkt sind wie bei meinem Vasell-Rent vor einer oder zwei Episoden. Naja, das ist halt aber das Bezahlmodell.

42:05 Sie geben dir ein cooles Tool, das funktioniert in vielen Fällen. Wenn du aber gewisse Investments nicht tätigen willst, musst du halt dann das Ding bezahlen und irgendwie wollen sie auch, ihr eigenes Produkt finanzieren wird. Und ja, wir haben tatsächlich in dem, das ist jetzt ein bisschen ironisch, wir haben in dem letzten Projekt, in dem wir drinnen waren, haben wir versucht, diese Monorepo-Diskussion über Softwarearchitektur zu lösen.

42:32 Da haben wir tatsächlich versucht, eine Architektur zu definieren und nachher die Organisation danach zu schneiden. Wir schreiben, glaube ich habe eh schon mal erzählt davon, wir schreiben lauter kleine Apps und diese Apps hängen wir in so eine App-Shell rein. Die App-Shell ist iFrame-basiert, aus dem Grund, dass wir uns nicht auf eine Technologie fixieren wollen.

42:53 Diese Lademechanismen, wie wir diese Apps laden, wie der Lifecycle dieser App ist, wie Aktualisierungen stattfinden, ist alles in plain JavaScript geschrieben, da ist kein Framework dahinter, das ist unser langlebiger Teil und du kannst noch React, Angular, Fuse, Welt, was auch immer verwenden, dass du dich in dieses Framework reinhängst und die UI schreibst, die du willst mit Design-Tokens aus einem Design-System, damit alles irgendwie halbwegs gleich ausschaut.

43:14 Meistens von unserer Sachen ist React passiert, aber ein Großteil davon auch noch Angular passiert, den wir halt einfach neu angemalt haben. Funktioniert irrsinnig gut und hat bis zu einem gewissen Grad auch funktioniert. Jetzt kommen halt Teams drauf, ja, aber irgendwie haben wir doch jetzt Dinge, die wir teilen wollen.

43:28 Wir wollen nicht immer alles neu schreiben zwischen den einzelnen Apps, auch, dass wir Konsistenz behalten und dass die Apps alle irgendwie aus dem gleichen Guss wirken. Na, jetzt machen sie wieder ein Monorepo. Jetzt sind wir wieder dort angelangt Und ich weiß noch nicht, wie wir das lösen. Also ich bin sehr dagegen, weil ich weiß, was das für Aufwand ist.

43:47 Gerade wenn es darum geht, dass wir ein Monorepo haben, das von, also wir haben ja da mehrere Monorepos, es schließen sich ja immer so zwei, drei Teams zusammen und machen das dann. Das heißt, du hast dann in jedem dieser Dreierteams-Konstellationen hast du ein, zwei Leute, die sich nur um Bild und Repo kümmern.

44:02 Das finde ich das falsche Investment. Deswegen habe ich jetzt noch keine Lösung, wie man das eigentlich angeht.

44:06 Warte mal, warte mal. Das war jetzt so, dass ihr habt eine Architektur definiert, dann nach eurer Organisation definiert und das lief so lange bis eine Anforderung rein kam.

44:16 Das lief jetzt vier Jahre gut.

44:17 Genau, dann kam diese Anforderung rein.

44:21 Dann sind wir, na was ist passiert? Wir sind überrascht worden von der Anzahl an Teams, die nachher wirklich tatsächlich mit unserer Architektur arbeiten. Das heißt, das was wir erreichen wollten mit dieser Architektur, dass Teams unabhängig zu unserer Plattform kontributen können und Apps schreiben können, Komplett isoliert, komplett ohne Rücksicht auf irgendwelche anderen Teams, indem wir ein Designsystem zur Verfügung stellen, diese App-Shield zur Verfügung stellen und sagen, ihr könnt dort mit den Tools, die wir euch geben, zu 100% alles erreichen, was ihr wollt.

44:53 Das hat so gut funktioniert, dass wir von den prognostizierten Teams zehnmal mehr Teams jetzt haben, als wir eigentlich gedacht haben. Und die versuchen jetzt untereinander in diesen Teilorganisationen wieder Code zu teilen. Das heißt, unser Ansatz war so erfolgreich, dass wir schneller gewachsen sind als erwartet haben und jetzt Probleme im Detail auftauchen, an denen wir heute noch nicht gedacht haben.

45:18 Ja, aber dann müsste man ja doch theoretisch die Architektur und die damit zusammengehängende Organisationsstruktur an die neue Skalierung anpassen.

45:27 Ja, genau.

45:27 Oder? Und das ist jetzt nicht passiert, wenn ich das richtig verstanden habe.

45:31 Das ist noch nicht passiert, genau. Das ist gerade mein großes Problem.

45:33 Ja, dann knirscht es natürlich. Das macht Sinn.

45:35 Ja.

45:36 Weil an sich schien es ja zu funktionieren. Man muss halt nur, wer sagt, muss auch die sagen und dann halt eben auch die Organisationsstruktur maintainen, so wie die Software.

45:45 Damit ich es einmal an einem konkreten Beispiel festhorte. Wir haben ja gesagt, wir stellen ein Designsystem zur Verfügung, das hat unterschiedliche Ebenen. Da geht es darum, dass wir nicht nur einzelne Kontrolls oder Komponenten schreiben, sondern auch jetzt zum Beispiel ein Document Viewer, der schon Backend-Anbindung hat, wo du jetzt sagen kannst, ich lade ein Dokument in meiner App.

46:01 Die Reihenfolge, wie das mit der Backend-API kommuniziert, ist gegeben. Gewisse Workflows zum Teilen dieses Dokumentes sind schon gegeben, du sagst einfach nur, das ist mein Document Viewer, da hast du deinen Dokumenttyp mit deiner App-ID, damit du das auch filtern kannst und dann funktioniert das. Also so weit gehen wir im Design-System, dass wir sogar solche High-Level-Components bereitstellen.

46:25 Und das funktioniert auch gut, wenn du das auf einer gewissen Abstraktionsebene behältst. Aber dann gibt es zum Beispiel das Team Application Observability. Das sind drei, vier Teams, die arbeiten alle an dem Problem, wie kann ich meine Application gut observen, monitoren, Informationen rauskriegen. Da sind sehr, sehr viele Patterns drinnen, die gleich sind, egal ob du jetzt in Real-User-Monitoring bist oder ob du jetzt im Backend gewisse Call-Graphs anschaust, da sind sehr, sehr viele visuelle Dinge, die ähnlich sind und Abläufe, die ähnlich sind.

46:56 Es ist irrsinnig schwierig, dieses Spezialwissen in das Design-System zu bringen und für alle zur Verfügung zu stellen. Was Leute jetzt machen, ist, dass sie quasi so eine Nebenschiene zum Designsystem machen, wo sie diese Komponenten teilen für diese vier Apps, die sie kreieren. Und es kann gut gehen, es kann auch vielleicht die richtige Lösung jetzt sein dafür, weil wir jetzt auf einmal die Knödel, die quasi dranhängen, an unserer Architektur größer sehen müssen.

47:22 Ich bin mir aber nicht sicher, ob das das Richtige ist. Und ich lasse das Problem jetzt sehr offen. Ich bin halt einfach skeptisch. Aber nachdem ich ja eh schon seit zwei Jahren nur mehr Last mache, bin ich ja eigentlich nur der alte Mann, der von der Seite reinschaut und kritisch ist. Das ist die beste Rolle.

47:40 Ich wollte noch dazu erwähnen, mit den Multi-Repos ganz andere, aber quasi die gleichen Probleme dann geben, die im Endeffekt irgendwie Geld kosten oder dass man die Teamstruktur, Organisationsstruktur ein bisschen umstellen muss. Wenn zurzeit, das ist natürlich jetzt nicht der Standardfall, Aber zurzeit haben wir eben einfach im Design-System bei GitLab relativ viele Breaking Changes, weil wir davon, wir stellen da halt was um, anderes Thema.

48:05 Und jetzt arbeiten hier glücklicherweise nicht so viele Personen an diesem Repository. Denn wenn jetzt Person 1 einen Breaking Change macht, Person 2 einen Breaking Change macht, Person 3 einen Breaking Change macht, dann fängst du an zu diskutieren, sollte man diese Breaking Changes zusammenfügen, weil dann hast du nur einen Major-Version-Bump.

48:25 Dann überlegst du dir, was ist denn das Problem an drei Major-Version-Bumps. Dann fängst du an zu diskutieren, ist das eigentlich ein Problem, wenn wir irgendwann auf Version 100.0.0 laufen oder ist irgendwie 100 so eine magische Grenze. Also das sind ja so Diskussionen, die braucht man irgendwann nicht.

48:39 Aber irgendwie fängt dann sowas an. Und dann haben wir zum Beispiel einen Breaking Change drin und sagen, okay, jetzt möchten wir aber erst in den ganzen Main Repos, die wir haben, auf diese Version upgraden, bevor wir wieder einen Breaking Change haben. Ansonsten muss ja irgendwie so ein Main Repository sonst mal von Nummer 50 auf 55 updaten. Und ist das eigentlich ein Problem?

48:58 So, also das sind keine technischen Probleme, aber dann muss man vielleicht dann drüber diskutieren, wie man das handhabt. Und es ist halt relativ einfach, Hand zu haben, wenn du nur eine gewisse Menge an Personen hast, die überhaupt Breaking Changes machen können, Sodass du das einfach kurz mal in sonst wo, Issue, Slack, sonst wo mal kurz schreiben kannst, wie du es jetzt eigentlich handhaben möchtest.

49:23 Hast du stattdessen eine Struktur, wo du sagst, alle deine Frontend-Developer können jederzeit, können sie bei GitLab auch, aber es passiert halt in der Regel nicht so häufig, aber ist deine Struktur eher so, dass alle Frontend-Developer werden dazu aufgefordert, das auch in dem Design-System, Pattern-Library zu machen, und dann hast du da 50 Frontend-Developer sitzen, die plötzlich alle Breaking Chances machen, dann ist es vielleicht nicht der richtige Weg in dem Fall, und dann hast du es lieber wieder im Monorepo zusammen.

49:49 Hm. Ich denke mir auch gerade, was, glaube ich, mein seltsames Problem lösen könnte, wäre so eine Art temporäres Monorepo, dass ich irgendwie so auf den Knopf drücken kann und sagen kann, ich habe jetzt hier diese sieben NPM-Packages und ab Knopfdruck machen die alle untereinander dieses NPM-Link, dass ich die sozusagen als einen Block betrachten kann und dass ich hinterher auch auf den Knopf drücken kann, um das temporäre Monorepo wieder aufzuheben.

50:13 Und dann habe ich wieder meine ganzen Einzelpackages für, ich muss halt irgendwie super Downstream mal was updaten oder super Upstream einen Bug fixen, der halt jetzt nicht mission-critical ist und dann kann ich das halt wieder so in meinem normalen Flow da so irgendwie so en passant durchtröpfeln lassen.

50:28 Aber wenn ich jetzt wirklich so ein Feature durchentwickeln will, wo halt die ganze Pipeline angefasst werden muss, wenn man dann so einen temporären, das gehört jetzt gerade mal zusammen und verhält sich als Vers 1, machen könnte und das dann wieder aufheben könnte. Das wäre ganz cool, temporäres Monorepo, baue mal einer.

50:44 Bau mal und dann sagst du Bescheid.

50:47 Naja, also im Prinzip muss es ja bloß irgendwie, oh Gott, jetzt hefte ich mir das selber an, aber im Prinzip müsste man ja bloß sagen, hier, das sind die Folders, da drin sind Package.json, daraus generierst du das entsprechende npm-Kommando und dann generierst du halt eben auch das Kommando, das das Ganze wieder zurücksetzt.

51:01 Das könnte ja eigentlich bloß ein Script sein. Nein, ich mach das heute nicht. Nein, ich muss stark sein.

51:07 Du könntest dir eigentlich mal das JDK anschauen, das GitLab Development Kit. Weil das habe ich bei mir im Onboarding gemacht. Dann habe ich mich auch gefragt, wie starte ich denn GitLab-Lokal? Das ist ja nicht so klein. Und dann hat man mir das JDK gegeben und dann installierst du das und dann läuft das. Und ich habe keine Ahnung, ehrlich gesagt, wie.

51:24 Sehr gut, das ist das Beste.

51:27 Das läuft einfach. Aber ist ja cool,

51:29 Oder? Dass das so gut geht.

51:30 Ja, das ist ein beeindruckender. Das schaffen die wenigsten.

51:33 Ja?

51:35 Ich weiß gar nicht, was für eine krasse Brainpower dahinter ist, aber es muss eine sein.

51:40 Ich kann mich an Software erinnern,

51:41 Dass es geheißen, bitte nur den Folder im Root-Director haben, ansonsten funktioniert unsere gesamte Bild-Chain nicht. Und dann checkst du mal eine Stunde aus und dann kompilierst du mal zwei Stunden und dann bitte nie wieder neu compilen, sondern den Super-Development-Button in deiner Favoritenliste anklicken, damit das separater Compile-Vorgang losgeht.

52:00 Also das ist die Welt, die ich gesehen habe, nicht vor dem ja cool, wenn ich dort einfach so ein Development Kit starte und das geht, saugeil.

52:07 Ja, also mein aktuelles Next.js-Projekt hat auch tatsächlich, da habe ich so eine Markdown-Datei, da steht drin, du führst diesen Befehl aus, diesen Befehl aus, diesen Befehl aus und diesen Befehl aus und danach kannst du auf die Seite gehen. Das ist halt schon arg barbarisch und theoretisch könnte man sowas ja auch in ein Skript gießen, damit man dann auch so eine Experience hat wie Vanessa. Man drückt auf den Knopf und dann geht's.

52:27 Das ist, glaube ich, Brainpower, ja, aber zum anderen muss sich halt auch jemand entscheiden, dass das überhaupt ein Ziel ist, das man hat und das man verfolgen will. Und wenn man das dann hat und einmal angefangen hat und einfach so die ersten 80% erledigt hat, ist der Rest ja bloß Maintenance. Wahrscheinlich.

52:41 Ich glaube, die Welt könnte sehr viel besser sein, wenn mehr Leute sich dazu entscheiden würden, es besser zu machen. Wenn ihnen die Möglichkeiten gegeben werden. Versus, das muss jetzt gestern schon fertig gewesen sein.

52:51 Ja, vor allem ist ja GitLab Open Source. Wir können ja nicht sagen, wir hoffen auf Community-Contributions. Und hier ist der Setup-Guide, wofür du auf jeden Fall erst mal ein MacBook M3 brauchst. Und dann brauchst du drei Directories und musst auf jeden Fall im richtigen installieren. Das stimmt. Das kann ich ja nicht machen.

53:07 Das stimmt natürlich.

53:10 Ich bin mal bei den Monorepos zu den Pain-Points runtergescrollt. Und wir haben jetzt nicht nur den Pain-Point-Complexity, nein, wir haben Excessive-Complexity und irgendwie mit all den anderen Rubriken, die wir uns vorher angeschaut haben, würde ich da jetzt irgendwie zustimmen. Also Webpack und Veed, die Komplexität klingt ja so klein versus Learner und ich kenne die anderen ehrlich gesagt gar nicht.

53:35 Jan Workspaces und danach hat es bei mir auch bald auf, was ich kenne.

53:41 Ich liebe es, dass auf Punkt 4 für die Monorepo-Tools Pain-Points Dependencies ist genau das eine Problem des Monorepos lösen sollen ist der viertgrößte Pain-Point, ist herrlich also irgendwie.

53:56 Ich finde viel besser 11 und 12, die direkt nebeneinander stehen Choice-Overload und Lack-of-Tools Gut,

54:06 Ich würde jetzt mal kurz auf die Bubble draufdrücken, was die Leute eigentlich meinen.

54:10 Nein, nein, nein, nein, die meinen genau das, das ist schön, das passt schon so in der Nachricht.

54:15 Ah, wunkelhaft. Ja, ich verstehe es auch gar nicht, es sind so viele verschiedene Nachrichten.

54:18 Ja.

54:20 Naja, und dann gibt es noch 36, ach, Entschuldigung, schon wieder, 63 Prozent andere Antworten, das heißt, ich glaube, jeder hat irgendwie Probleme mit Monorepo-Tools und sie sind einfach sehr groß.

54:37 Ich bin grundsätzlich sehr happy, dass es diese Pain-Points-Listen gibt in dieser Umfrage, weil die machen ein bisschen einen Reality-Check, finde ich. Man muss schon sehr frustriert sein, um sich den Aufwand anzutun, etwas in ein Textfeld zu schreiben. Wir reden ja eigentlich nur immer darüber, wie gut Dinge funktionieren.

55:00 Es ist gar nicht so schlecht, dass man einmal sieht, wenn Dinge schlechter funktionieren. Also ein riesen Fan davon.

55:05 Ja, und vor allem ist es ja, wenn du sagst, ich habe das Gefühl, ich müsste was Eigenes bauen, dann hast du ja quasi deine To-Do-Liste. Das ist ja auch schon was wert. So, meine Damen und Herren, wollen wir in die Other Tools reinlinsen?

55:23 Ja, und bei den Other Tools, Punkt Nummer 1, haben wir ja Teil 1 schon drüber gesprochen, weil hier kommt gleich mal Lodash. Würde ich mal sagen, wir verweisen zurück auf die 655, irgendwas, auf die State of JS Teil 1 zumindest, wo wir schon Lodash ausgiebig besprochen haben.

55:45 Was ich tatsächlich gemerkt habe letztens, das hatte ich glaube ich da gar nicht erwähnt. Ich habe auch mal so rumgefragt bei irgendwie so Leuten, die in meinen Workshop sitzen, warum habt ihr Lodash noch am Start? Die meisten verwenden da wirklich nur so ein, zwei Funktionen draus. So Sachen wie irgendwie Objektklonen und Zeug.

56:02 Das heißt, ich glaube wirklich, Lodash wird gar nicht so verwendet, sondern wirklich Partikel davon. Nur noch. Und auch das wäre ja eine To-Do-Liste für die Browser-Spezifikateure. Beziehungsweise sowas wie Objektklonen, Structuredklonen haben wir ja schon. Aber andere Sachen, müsste man mal gucken, was die da so drin haben.

56:19 Also die wenigsten verwenden viel von Lodash, würde ich behaupten.

56:23 Von meiner Erfahrung her kann ich es unterschreiben. Meistens so die Group By oder sowas Funktion oder wie sie heißt.

56:28 Auch die haben wir ja mittlerweile native. Also wer weiß.

56:34 Also IPD-Equal-Check wahrscheinlich noch.

56:39 Lodisch war ja gewisserweise die Roadmap für das TC39 in den letzten Jahren. Von dem her, ja, mittlerweile glaube ich auch, dass man gut ohne auskommt. Aber es ist immer noch so, finde ich, der erste Gedanke vieler, dass sie sagen, ja passt, das brauche ich jetzt. Und sie schauen gar nicht nach, was es in der Browser eigentlich gibt.

57:02 Aber hey, gut, wie gesagt, verweißen wir auf die andere Episode. Da haben wir schon genug drüber gesprochen.

57:08 Ich muss nur noch erwähnen, 7% underscore JS ist auch noch da.

57:13 Das hat er gesagt. So geil.

57:19 Ja. Gut, sind halt irgendwelche Libraries. Da ist jetzt nichts irgendwie drin, was mich überrascht so richtig.

57:25 Ich bin sehr froh, dass Axios sehr weit unten ist, weil das brauchst du wirklich nicht mehr. Das ist die Penit, die man wegkriegt. Super.

57:35 Wie ist denn der aktuelle Stand bei Moment? Da war doch mal so ein Hickhack irgendwie mit, kann man nicht mehr verwenden, kann man doch noch verwenden?

57:45 Also wenn du mich fragst, ist der aktuelle Stand von Moment, die Uhr läuft, Temporal ist fertig. Das muss jetzt nur noch geanfleckt werden. Und dann können die ganzen Libraries einpacken, weil wir dann vernünftiges Datumshandling im Browser haben. Und die haben bei Moment, glaube ich, gesagt, wir stellen jetzt die aktive Weiterentwicklung ein, sind jetzt im Maintenance-Mode.

58:04 Weil, naja, die sind halt auch noch aus einer Zeit von Fortree-Shaking und so, glaube ich. Das war, glaube ich, der Grund.

58:10 Ich glaube, das, was ich gerade meine, was ich gehört habe, war, dass Moment irgendwann auch beschlossen hat, mal modularer zu werden. Und dann gab es sehr viele Missverständnisse darüber. Aber vielleicht habe ich was Falsches mitbekommen.

58:23 Also ich denke, diese ganzen Datums- und Zeitdinger, die werden halt noch schneller den jQuery machen, als jQuery den jQuery macht. Einfach nur, weil die ja nicht so wie jQuery konstituierend sind für irgendeine Applikation, sondern du brauchst halt hier und da mal Datums- und Zeithändling, mal mehr, mal weniger.

58:40 Aber das sollte sich wirklich relativ easy gegen Temporal austauschen lassen, wenn man denn mal dazu kommt eines Tages. Was ja was anderes ist, als wenn du wirklich so eine riesige jQuery-Suppe zusammengerührt hast, um dein Frontend zu machen. Von daher denke ich, das geht auch bald vorbei, schätze ich mal.

58:55 Was ist Vue-Use? Habe ich auch noch nie gehört.

58:59 Was für ein Use?

59:00 Vue-Use, genau.

59:03 Das habe ich mal verwendet. Das ist eine Bibliothek. Also ich bin jetzt verwirrt, dass das irgendwie bei dieser Liste auch auftaucht. Aber das ist eine Bibliothek an relativ kleinen, coolen Plugins, die so die Vue-Core-Team-Leute auch geschrieben haben, weil sie die dann wiederum selber verwendet haben und dann quasi zur Verfügung gestellt haben.

59:27 Okay.

59:28 Da ist zum Beispiel so eine Bibliothek an gut zu verwendbaren Composables drin, Composables-React-Hooks quasi, wie Use-Dragable. Und dann hast du halt schon irgendwie eine Funktionalität drin für Drag-Drop-Funktionalitäten.

59:46 Okay, verstehe.

59:48 Also so ein View-Loadish. Nee, das ist ein bisschen unfair. Die sind nicht so primitiv. Es ist schon ein bisschen komplexer, was man sich da reinholt.

59:57 Okay, gut. Aber View-spezifische Plug-in-Sammlung.

1:00:01 Genau, aber eigentlich ganz cool. Das ist ganz nett, wenn man es braucht. Dient auch so ein bisschen für mich oft als Inspiration. Also dann ist es immer die Frage, mache ich jetzt tatsächlich, dass ich das verwende von denen oder lese ich mir deren die ganze Dokumentation durch, wie sie das so gebaut haben und einen Code durch und sage, ich brauche es ein bisschen anders, habe mich halt dadurch inspirieren lassen und baue es ein bisschen anders nach.

1:00:23 Verstehe. Ja, gut. Animationslibraries. Also meine Animationslibrary heißt CSS und die kommt hier drin nicht vor.

1:00:43 Ich bin zur Enterprise für moderne Animationen. Wobei, ich muss ganz ehrlich sagen, wir verwenden viel Charting. Also da geht es ja generell um Grafics und wir verwenden Highcharts. Das kommt tatsächlich auch in der Liste vor. Aber wir haben aber jetzt auch selber Visualisierungsprimitive geschrieben, glaube ich, auf der Basis von D3 direkt.

1:01:03 Das ist ja wirklich sehr niederschwellig. Nein, nicht niederschwellig, ist das falsche Wort. Low-Level? Genau.

1:01:14 Genau, ich wollte gerade sagen, Low-Level aber nicht mehr einzelne Pixel schieben. So halt eine Abstraktions-Library, auf die man dann draufsetzen kann. Hätte ich jetzt bei eurem Laden auch tatsächlich erwartet, dass so viel Visualisierungs-Fu, wie ihr mutmaßlich macht, dass es nicht schlecht ist, das ins Haus zu holen, weil keine Ahnung, die Hightshard-Maintainer werden gekauft, von einem Bus überfahren, sanktioniert, hast du nicht gesehen.

1:01:35 Das wäre schon recht katastrophal.

1:01:38 Ja.

1:01:39 Das ist ja eben auch nicht so ein Backend-Service, den man austauschen kann. Das ist ja was, was eure Kundschaft unmittelbar war. nimmt. Hätte ich auch vorgeschlagen, dass man das tut.

1:01:49 Ich habe gerade einen Kaffee bekommen.

1:01:51 Ja, super. Was ein Service. Was der Fliesenleger nicht alles für dich macht.

1:01:57 Das ist wohl nicht der Fliesenleger, das war meine Frau.

1:02:00 Hey, auch das kann man in Personalunion haben, wenn man es richtig macht.

1:02:09 Grandios.

1:02:10 Oh, Stefan, du bist doch hier der Experte für Backend Frameworks. Nächster Punkt hier. Express immer noch über 60 Prozent. Ja?

1:02:18 Ja, ich liebe Express. Es ist ein wunderschönes Framework. Also ich finde cool, dass es immer noch verwendet wird. Es ist rund, es funktioniert gut, es ist gut dokumentiert, es gibt viele Beispiele, viele Probleme, die in den letzten zehn Jahren aufgetaucht sind, sind gelöst. Es ist mir immer ganz wichtig, dass Leute tatsächlich daran arbeiten und die Probleme lösen. Nein, Express ist toll.

1:02:41 Fastify ist im Grund Express auf Stereoids, kannst du auch verwenden, super, dass das auch verwendet wird, aber ganz ehrlich, für mich ist Express immer noch das Go-To-Framework in Node, ich glaube, dass die Probleme, die wir mit anderen Frameworks lösen, sehr spezielle Probleme sind.

1:03:00 Was ich halt an Express sehr schön finde, ist, ich schreibe alle zwei Jahre mal eine neue Express-App und ich habe immer nur das Gefühl, dass ich mich erinnern muss und dass nicht wirklich sich fundamental was getan hat. Wahrscheinlich hat sich zwischendurch was getan, aber das kann halt so in den Erinnerungsprozess integriert werden, dass halt einfach das große Rewrite so scheinbar nie stattgefunden hat und dass die ganzen Konzepte immer noch die gleichen sind und das ist auch sehr viel wert, gerade in so einer JavaScript-Welt, wo ja sonst irgendwie nichts länger als fünf Minuten hält.

1:03:26 Ja, also die Erfahrung habe ich auch komplett. Wenn ich Express machen muss, denke ich mir, ah, ich habe das mal vor zehn Jahren hier, oh Gott, das wird alles mein Stand so klar veraltet sein. Ne, schaut gleich aus, kann ich weiterhin benutzen. Ich denke, Nitro, Nitro und H3H3 waren mal in meiner Bubble so.

1:03:44 Ich glaube, es kam aus der View-Bubble auch raus, war mal voll gehypt. Ich habe es mir auch angeschaut. Und es wirkte dann generell moderner, so JavaScript-mäßiger, Frontend-mäßiger. Punkt, ich habe da jetzt gar nichts Schlechtes oder Gutes dazu zu sagen. Das ist nur das einzig andere, was ich mir mal angeschaut habe.

1:04:01 Es sah auch interessant aus. So Redwood, habe ich gehört,

1:04:06 Cool.

1:04:07 Anscheinend, weiß ich nicht. Keystone, ja, hab ich mal verwendet. Und den ganzen Rest hab ich mir nicht mal angeschaut.

1:04:18 Ja, da sind, glaub ich, viele so drin, die so halb versuchen, irgendwie das Rails für JavaScript zu sein. Und das stellt sich dann doch als relativ schwierig raus, weswegen die dann meistens nicht so wirklich die kritische Masse erreichen. Was ja schade ist, so was wäre ja per se keine schlechte Idee. Aber Hammer halt nicht.

1:04:39 Ja.

1:04:41 Okay, dann gehen wir zum nächsten. JavaScript-Runtimes.

1:04:45 Ich verstehe dieses Ergebnis nicht.

1:04:47 Wieso nicht?

1:04:49 Warum Browser auf Platz 2 ist.

1:04:52 Weil das halt eine nicht repräsentative Umfrage ist. Und wenn das einfach nur mehr Backend-Leute mit mehr Followern untereinander geteilt haben, hast du halt mehr Node-Leute am Start.

1:05:02 Nein, ich glaube eher, dass viele Leute nicht checken, dass der Browser ein JavaScript-Runtime ist.

1:05:05 Nee, ich glaube eher, dass das so ist, wenn du irgendwas für den Browser machst, musst du dich auch mit Node.js rumschlagen, aber das ist nicht notwendigerweise umgekehrt genauso.

1:05:11 Ah, so, ja, okay, gut. Ja, ja, ja, ja, das könnte, das könnte stimmen.

1:05:20 Also so Sachen wie BAN haben relativ wenig Gefolge dafür, dass sie so viel Cola am Start haben.

1:05:26 Ja.

1:05:28 Ich bin immer

1:05:29 Nur beeindruckt von den 16% BAN-Nutzerinnen und Nutzern, weil... Also das Ding ist ein hype-driven Experiment. Also kein Mensch kann mir sagen, dass... Dass sie BAN verwenden und damit produktiven Code oder das Code in Production schreiben. Nein, so schlimm. Unmöglich.

1:05:54 Okay, das höre ich jetzt zum ersten Mal in der Deutlichkeit.

1:06:03 Nein, es bricht konstant mit Standards, die Kompatibilität lässt zu wünschen übrig, es ist nicht so schnell und so cool, wie es alle machen, es kommt nicht immer darauf an, welche Benchmark du verwendest. Und alle Sachen, die BAN löst, werden von anderen Runtimes besser und stabiler gelöst. Das heißt, wenn ich jetzt wirklich sage, ich möchte etwas schreiben, das nachher in Production kommt und in Production verwendet wird, dann nehme ich doch eher Technologie, die battle-tested ist.

1:06:31 Wo zum Beispiel, also tatsächlich ist das für mich auch, obwohl ich schon lang, wegkomme davon, ist das No-Chase, weil halt dort ein unzählige Software draußen stabil funktioniert. Denno ein großes zweites, aber bei Denno nehme ich sogar das Hosted-Service her von Denno selbst. Aber BUN, also BUN ist cool für Demos und ich glaube, dass alle Leute, die das verwenden, coole Demos damit machen.

1:06:58 Aber keiner lässt einen BUN-Server in Production laufen. Nicht, wo Geld dahinter ist. Nur für Sparscheid, hundertprozentig.

1:07:08 Das ist ein Statement, werte Zuhörerinnen und Zuhörer. Wenn eure Erfahrung eine andere ist, dann lasst es uns und speziell den Stefan mal wissen.

1:07:16 Sehr gern. Also meine Perspektive dazu ist, ich schreibe seit dreieinhalb Jahren, produzieren wir unsere eigene JavaScript-Randtime, die in Production läuft, die sehr stabil in Production läuft. Und die Entscheidungen, die wir treffen, um eine für Production optimierte JavaScript-Randtime zu schreiben, sind andere, als wir es BAN macht. Und ich würde keine einzige Entscheidung, die sie treffen, machen.

1:07:40 Die Entscheidungen, die sie treffen, sind, um Twitter-Traction zu bekommen, damit für die nächste Runde, für die nächste Visierrunde, genug Zahlen auf dem Tisch sind, dass die Investoren die nächste Runde freischalten. Alles was passiert. Würde ich mit sehr viel Vorsicht angehen.

1:08:01 Ja gut, es ist ja bei Next.js nicht so anders. Es ist halt ein Business-Manöver mit einem Artefakt, das man auch sich installieren kann, wenn man möchte.

1:08:11 Ja, Next.js ist im Enterprise angekommen. Da gibt es viele, viele, viele Firmen, die groß drauf sitzen. Mit allen Gotches, die wir uns in der letzten Folge gegeben haben.

1:08:25 Aber das heißt ja nur, dass die sozusagen in ihrem Business-Manöver besser arbeiten. Da ist ja das Software-Artefakt eher sekundärer Frage. Das muss ja nicht gut sein, um alle das zu bringen, dass sie es verwenden.

1:08:35 Ich glaube, dass NextJS schon ein bisschen Reife hat, tatsächlich. Trotz aller Kritikpunkte, die wir in der letzten Folge besprochen haben, ist dort eine gewisse Produktreife da. Wobei, Zufriedenheit fällt rapide. Also die Unzufriedenheit steigt rapide, aber die Zufriedenheit fällt rapide. Hat sicher was mit der Bewegung zu tun, die da gerade passiert.

1:09:02 Aber Bann ist ausschließlich ein Spaßprojekt. Da ist nichts drinnen, was irgendwie schreit, schreibt doch deinen Production selber damit. Nichts, gar nichts. Nichts, was andere Tools nicht besser machen und stabiler machen.

1:09:17 Also das muss auf jeden Fall unser Video-Snippet sein. KI, bitte aufpassen.

1:09:22 Gerne. Also wow. Tatsächlich ist es sogar so, dass Cloudflare Workers, die sehr, sehr wenig genutzt wird, eine um welten bessere und stabilere Roundtime ist. Die ist irrsinnig gut. Die hat einen ganz speziellen Use Case, nämlich Responses zu bearbeiten, bevor sie geschickt werden, wo du halt in Millisekunden eine Bearbeitung machen musst, weil ansonsten dauert die Response zu lange.

1:09:47 Das ist einmal ein tatsächlicher Use Case, das ist einmal eine tatsächliche Speed-Optimierung, das ist etwas, das BAN so nicht hinkriegt.

1:09:56 Ja gut, dafür ist es wahrscheinlich auch nicht gebaut.

1:09:59 Naja, also Speed und Performance ist einer der großen BAN-Eckpfeiler und.

1:10:06 Das kommt ja,

1:10:07 Ob welche Statistik du dir anschaust oder welche Benchmark du dir anschaust, aber es ist nicht schnell, es ist nur in gewissen Bereichen schnell.

1:10:13 Ja, aber wie gesagt, dass die besonders performant sind und irgendwie so Zeug machen, das liegt ja alles so im Messaging. Also, die haben ja auch irgendwie erzählt von wegen, da musst du dich nicht mehr um CommonJS und irgendwie ESM kümmern, weil wir Heuristiken haben. Und ich denke halt so, wenn ich die Spezifikationen lese, weiß ich genau, dass das nicht geht.

1:10:29 Das ist prinzipbedingt unmöglich, aber das ist halt dann im Messaging drin. Und ich meine, in 99 Prozent der Fälle wird es ja funktionieren.

1:10:36 Du kannst C-Fails laden.

1:10:38 In Bann?

1:10:39 Und ausführen.

1:10:41 Wüsste nicht, wie das was da schief gehen sollte.

1:10:43 Das klingt...

1:10:46 Okay, jetzt weiß ich, wie du zu dieser Idee Spaßprojekt kommst, weil für ein Spaßprojekt oder für so, das hänge ich am Nachmittag mal eben schnell zusammen, da will ich das haben, dringend sogar.

1:10:55 Es ist geil für einen Tweet, du kannst sagen, hey, cool, unser Random KC laden und dann sagst du so einen 10-Zeilen-Code her, wo du das tatsächlich machst und geil, super. Wenn ich ein Production-Problem angehe und ich brauche eine tiefe Dependencies im Jahr 2025, dann mache ich das ausschließlich über WebAsimple, weil ich will mir keine Security-Issues oder Sandbox-Probleme irgendwie eintreten.

1:11:22 Ja, und vor allem WebAssembly ist ja mittlerweile auch so gut abgehangen, dass der Schmerz sich im Rahmen hält im Vergleich zu, also C-Dateien importieren ist ja nicht was, was du brauchst.

1:11:32 Nein, das ist es. Also da dreht es einen ganz am unten Punkt. Falls es irgendeinen deutschsprachigen Bannentwickler oder Bannentwicklerin gibt, die tatsächlich auch an dem Produkt mitarbeiten, bitte kommen, ich will unbedingt verstehen, wie ihr tickt. Bitte kommt in den Podcast, ich möchte reden mit euch, ich möchte es kapieren, was da passiert, weil ich habe nur, also ich bin immer massiv aufgeregt, wenn ich an das Ding denke und wahrscheinlich ist das auch ein Ziel davon, vielleicht ist die Aufregung um diese Rundheim ein Ziel der Erfinder und Erfinderinnen, weil alles, was irgendwie Traction gibt, alles, was irgendwie nach einer Zahl gegossen werden kann für die nächste Runde ist super und auch nur,

1:12:14 wenn sich Leute aufregen drüber, aber wow, also, jede andere Randheim, die dort entsteht. Sogar Chakra Core. Chakra Core ist um einige stabiler, kannst du die Notwahl hängen, hast du die gleichen Dependencies dran, super, bitte. Nehme ich liebend gern, wenn ich nichts anderes habe, nehme ich das. Bevor ich sage, ich greife auf Bann zu, weil Bann ist einfach.

1:12:36 Du willst Software, würde ich schreiben, mit einem Produkt, das sich einfach von Tag 1 auf 2 so massiv ändert, wo so viele Dinge reinkommen, die du auch nicht kontrollieren kannst. Das Ding ist ja auch das, das macht ja Spaß, ich kapiere es, aber dann verwenden Leute das, um C-Dependencies reinzuladen und dann lädst du eine bahnoptimierte Dependency in dein Produkt rein und auf einmal hast du irgendwo eine C-Dependency, die du nicht kontrollieren kannst und auf einmal gibt es Zugriff auf deine Memory-Register und nein, nein.

1:13:05 Alles was wir in Not versuchen seit 15 Jahren weg zu bekommen, machen es einfach wieder auf, weil es Spaß macht. Cool, habt ihr euren Spaß, aber nicht in meinem Production-Kauf.

1:13:18 Ja, also, wenn Bannentwicklerinnen hier zuhören, oder noch viel spannender, fände ich ja was, wenn Investoren das jetzt gehört hätten, was die sagen.

1:13:29 Nein, also ich mache das irrsinnig gern. Ich bin sehr gern ein Consultant für Investoren. Ich kenne ein paar Investoren, die sind super, die machen richtig coole Sachen. Also ich schimpfe sehr viel über VCs, aber in Wirklichkeit bin ich da eher, also die VCs selber stören mich ja nicht. Ich finde ja, da sind wirklich coole Leute dabei.

1:13:46 Mir stören ja eher das Spiel im JavaScript-Bereich, das Leute mit VCs treiben. Das ist ja eigentlich eher das Problem, das ich habe. Bang wird euch unterm Arsch explodieren. Das wird jetzt nur für Series E und vielleicht Series B gut gehen, aber der Moment, wo Bang gezwungen wird, dass er Bezahlmodelle erfindet, irgendein Businessmodell, haben wir null Plan und null Idee, wie es das machen, außer dass die nächste Serverless-Plattform machen, die nicht ziehen wird, weil Serverless in Wirklichkeit ein Infrastrukturproblem ist und kein Randheimproblem.

1:14:20 Ja, das frage ich mich halt eben auch, wie es jetzt geht. Das gab es jetzt ja schon mehrfach, dass irgendwelche Dev-Tools sagen, hier, wir haben jetzt Funding eingeworben. Und wenn das Funding halt nicht davon kommt, dass man sich irgendwie von irgendeiner Software-Bude sponsoren lässt oder halt eben sagt, hier ist mein Spendensparschwein, wirf mal hin und wieder was ein.

1:14:39 Sehr spannend, wie man da irgendwie explosives Wachstum hinlegen möchte, ist mir auch nicht ganz klar. Aber ich bin ja auch kein Finanz-Jungleur, ich weiß das nicht.

1:14:47 Man sieht es ja bei Denno, Denno ist ja wirklich ein Randheim, wo ich finde, die ist exzellent gemacht, sehr, sehr nachhaltig gedacht und sehr gut gemacht. Die überlegen sich ja was dabei, straggeln total mit den Bezahlmodellen. Die haben, finde ich, auch ein sehr, sehr gutes Produkt. Wäre Denno, vor fünf Jahren da gewesen, wo es heute ist, hätte ich keine eigene JavaScript-Randheim geschrieben, da hätte ich das Produkt von Denno genommen.

1:15:15 Hundertprozentig. also da gibt es auch eine News-Kiste für, das verstehe ich, das kapiere ich da gibt es sicher Firmen, die das brauchen, aber also meine Outsider-Perspektive ist die dass die auch jetzt neue Ideen brauchen bis sie ein Bezahlmodell kriegen.

1:15:35 Was ist denn das Modell bei Dino?

1:15:38 Ein Hostet-Serverless das heißt, du kannst einen eigenen Serverless-Cluster betreiben der auf Dino baut mit sehr vielen coolen Security-Features wie Allow Listing und Isolated Invocations. Das heißt, du kannst sicher sein, dass du auf einer neuen Ranteil bist. Also Multitenancy und solche Sachen funktioniert alles irrsinnig gut.

1:15:59 Das ist ein richtig cooles Ding. Alles, was wir in den letzten fünf Jahren entwickelt haben, macht den jetzt auch. Und wahrscheinlich besser.

1:16:06 Ja, aber... Also ich habe ja keine Ahnung von so Serverless-Kram. Das wäre ja auch das nächste Thema, in das wir dann ja mal überleiten können. Aber ist das nicht so ein, also du hast es ja vorhin als Infrastrukturproblem beschrieben, ist das nicht sowas, wo am Ende einfach notwendigerweise der übrig bleibt, der der größte ist?

1:16:26 Weil der einfach Skalierungseffekte nutzen kann und damit der billigste ist. Und wenn man halt irgendwie so ein Common Feature Set, wie irgendwie so Allow Listing, das hört sich jetzt erstmal für mich, wie gesagt, ich kenne mich nicht aus, aber das hört sich jetzt für mich irgendwie an, wenn ich jetzt irgendwie AWS sage, ey, mach mal Allow Listing und die haben das nicht, dann brauchen die dafür ungefähr drei Sekunden.

1:16:46 Eher wahrscheinlich also das konvergiert doch alles notwendigerweise und dann ist es eine Frage der Skalierung und dann gewinnt der Größte also warum würde man sich in dem Teich aufhalten wollen als kleiner Fisch das erschließt sich mir nicht ganz Du kennst dich aus. Ich habe keine Ahnung.

1:17:07 Ich sehe gerade, Denno hat tatsächlich auch Kunden, muss ich ganz ehrlich sagen. Das ist schon ein gutes Zeichen. Wenn du irgendwelche Integrationen auf Slack schreibst, dann rennen die auf Denno. Das ist ja schon mal cool. Das sind Dinge, die denken, cool, du hast einen Fit gegeben. Da gibt es ein Produkt und es gibt einen Fit dazu.

1:17:24 Leute wollen einfach kleine JavaScript-Module haben, damit die Plattform erweitert werden kann oder was auch immer. Super. Perfekt. GitHub genauso. Also wahrscheinlich kannst du irgendwelche GitHub-Actions damit schreiben. Also, ja, nein, also, ja, keine Ahnung. Wir könnten ja Marvin einladen, wieder.

1:17:49 Den kann man immer einladen.

1:17:51 Ja, der ist ja bei den. Der soll uns ein bisschen erklären, was du jetzt vorhambem, ja?

1:17:56 Klar, den kann man immer einladen.

1:17:58 Ja, der schadet nie, aber der soll uns dann auch irgendwie erklären, wie sie glauben, jetzt irgendwie da so die besseren Cloud Functions zu machen, als irgendwie so Versailles zum Beispiel.

1:18:07 Sehr gerne. Also wie gesagt, ich bin ein riesen Denno-Fan. Ich finde, die machen extrem cooles Zeug und ich würde gerne mehr verstehen, was die vorhaben. Passt. Und wir kriegen ja Besuch von Void Zero, da möchte ich auch verstehen, was die machen. Also das ist nämlich auch so etwas, wo ich mir denke, ja, cool.

1:18:24 Also das Ding ist immer das. Ich freue mich irrsinnig, wenn, wenn Open-Source-Entwicklerinnen und Entwickler, Funding bekommen, damit sie das, was sie lieben, machen können. Und das sollen sie auch unbedingt tun. Also wenn die genug Geld haben, dass sie jetzt ein paar Jahre das tun können, was sie wollen, freue ich mich super.

1:18:45 Ich bin nur gespannt, irgendwann kommt nicht der Punkt, wo du nicht mehr nur das machst, was du machen willst, sondern auch das machst, was irgendwie Geld bringt. Und ich möchte verstehen, was das Bezahlmodell wird. Gut, dann höre ich schon auf mit meinen Rains.

1:19:00 Ja, ich würde auch sagen, wir können dann ja mit dem State of JavaScript aufhören, weil was jetzt kommt, ist ja nur noch so am Rande mit JavaScript befasst. Also JavaScript, Sprachen, die nicht JavaScript sind, die wir verwenden, interessiert eh keinen AI-Tools, da werden wir länger mal breite drüber reden.

1:19:15 Hosting Services, nimmst halt den Billigsten,

1:19:17 Der das macht, was du willst. Hostet man halt irgendwo.

1:19:19 Ja, ist wirklich wahr, ne?

1:19:21 Beziehungsweise wir hatten da auch noch die Folge mit Matthias Ott drüber, mit Indie-Web und Hosting etc., Gerade haben wir ja auch manche Sachen davon schon angesprochen.

1:19:28 Genau, stimmt. So, wir müssen jetzt auch nicht nochmal irgendwie das Fass der Volksfront von Judea versus jüdische TypeScript Volksfront aufmachen. AI, noch mehr AI, bla, bla, bla, bla, bla. Ich glaube, wir haben über den JavaScript-Teil, The State of JS, geredet. Nur die eine Frage ist noch, in der Liste der Podcasts, wo stehen wir diesmal?

1:19:50 Genau, das schaue ich auch gerade und wir sind auf Platz 20.

1:19:55 Ja, das finde ich ausgesprochen respektabel. Also noch vor dem, dass man auf einen Button drücken muss, um uns anzuzeigen. Das ist ja das eigentliche Ziel.

1:20:03 Nicht nur das, sondern die ersten 15 gab es wohl vorausgewählt zum Anhaken. Weil hier sehen wir, dass das 240 Leute haben auf die Frontend Happy Hour gedrückt. Und die ab Platz 16, die wurden manuell eingetippt. Das heißt, dass uns 16 Personen, obwohl wir noch nicht mal zur Auswahl standen, haben dennoch an uns gedacht und uns hier reingeschrieben.

1:20:28 Ich glaube, wir sind auch einer der wenigen nicht englischsprachigen Einträge dort.

1:20:36 Ich gucke gerade mal. Wahrscheinlich.

1:20:39 Ich glaube, dieser Mito-Dev ist, glaube ich, auf Portugiesisch.

1:20:44 Ja.

1:20:46 Der ist recht beliebt. Der Rest müsste eigentlich alles, sehr viele portugiesische Sachen.

1:20:57 Na gut, wundert jetzt auch nicht, weil es ja auch ein Sprachbereich, der so groß ist, dass es sich da lohnt, tatsächlich in der Sprache zu operieren. Das hast du ja nicht bei vielen.

1:21:08 Auf jeden Fall danke an alle, die uns dort eingetragen haben. Ich finde das immer grandios.

1:21:12 Ich finde das super. Da haben wir jetzt unmittelbar nichts von, aber es ist einfach irgendwie nett zu sehen, dass ich jetzt tatsächlich mit mehr Leuten rede, als nur mit zweien.

1:21:23 Ja, also ich finde schon, es ist schon eine Wertschätzung und eine Anerkennung, dass Leute das machen. Also es freut uns riesig. Also mir wird immer ganz warm ums Herz, auch wenn ich ganz, ganz, ganz wenig dabei bin beim Podcast, aber ich freue mich einfach, wenn ich sehe, dass das Projekt so eine Anerkennung findet.

1:21:37 Stefan, du bist nicht wenig dabei, du bist dann dabei, wenn es zählt.

1:21:42 Ja.

1:21:45 So, ich will sagen, was jetzt zählt, ist, einen Deckel drauf zu machen. Das war also unsere Sicht auf den State of JavaScript für das vergangene Jahr. Und dann schauen wir mal, wie hoch wir auf der Podcastleiter dann klettern, wenn es dieses Jahr zur Abstimmung kommt. Hörerinnen und Hörer, denkt an uns.

1:22:04 Denkt außerdem daran, uns fleißig auf Social Media zu verteilen, uns Sternchen zu geben in den jeweiligen Podcast-Plattformen, so ihr das noch nicht getan habt und bleibt uns weiter gewogen, denn wir haben auf jeden Fall für den Rest des Sommers noch einiges vor. Wir haben hochkalibrigste Gäste eingeladen zu den heißesten Themen, die man sich nur backen kann.

1:22:25 Und da bin ich ja wirklich sehr gespannt, wie das so ankommen wird. Es wird interessant, es wird kontrovers, es wird spannend. Okay, wunderbar. Dann danken wir fürs Zuhören. Ich danke Stefan, ich danke Vanessa fürs Dabeisein. Und dann hören wir uns bald wieder. Dankeschön, bis zum nächsten Mal. Tschüssi.

1:22:45 Bis bald. Ciao, ciao.