WEBVTT 00:00:00.017 --> 00:00:02.317 Ich würde nie auf die Idee kommen, mir irgendein Programm zu installieren, 00:00:02.397 --> 00:00:05.557 das ich nicht installieren muss, weil ich es genauso gut im Browser kriege. Ah, witzig. 00:00:06.397 --> 00:00:08.677 Andersrum, komplett andersrum. Ich würde es sofort installieren. 00:00:08.757 --> 00:00:10.997 Hauptsache, ich muss nicht wieder den Tab suchen, wo das drin liegt. 00:00:12.037 --> 00:00:14.757 Mir ist es eigentlich egal, ob man Monorebo oder Multirebo hat. 00:00:14.837 --> 00:00:17.937 Ich muss halt, egal was ich habe, muss ich halt irgendwas Special Dashal machen 00:00:17.937 --> 00:00:20.357 und habe ein bisschen mehr Arbeit in irgendeine Richtung. 00:00:20.477 --> 00:00:22.717 Dann sollte man sich halt entscheiden, was mache ich denn lieber? 00:00:22.857 --> 00:00:25.437 Ich mag dieses manuelle Untersuchen, das stört mich gar nicht. 00:00:25.497 --> 00:00:28.517 Das mache ich in 10 Minuten, dann mache ich halt das Repository, 00:00:28.517 --> 00:00:30.557 ich checke das aus, dann schreibe ich, oh, übrigens, ich habe schon mal ein 00:00:30.557 --> 00:00:33.857 Break & Change vorbereitet, ich war schon mal so frei, ihr könnt das ja merchen, 00:00:33.937 --> 00:00:35.117 wenn auch immer ihr upgraden wollt. 00:00:35.357 --> 00:00:39.177 Fertig ist cool, die Vanessa macht jetzt gerade vor den GitLab Sales Pitch. 00:00:40.777 --> 00:00:42.297 Aber es stimmt, du hast komplett recht. 00:00:45.597 --> 00:00:48.577 Diese Revision von Working Draft wird euch präsentiert von Mitwald, 00:00:48.817 --> 00:00:51.057 den Veranstaltern des Head in the Cloud Summits. 00:00:51.497 --> 00:00:54.557 Liebe Hörerinnen und Hörer, ihr kennt Mitwald ja mittlerweile als den Hoster 00:00:54.557 --> 00:00:58.737 von Nerds für Nerds. Aber Mitwald macht noch mehr, als nur Server zu bepüchern. 00:00:58.917 --> 00:01:04.617 So findet am 13. Juni 2015 auf dem Mitwald-Campus in Espelkamp der Head in the Cloud Summit statt. 00:01:04.937 --> 00:01:08.737 Auf dem geht's um Cloud und DevOps, es geht um Tech-Themen allgemein und ganz 00:01:08.737 --> 00:01:10.137 generell um kreative Vibes. 00:01:10.297 --> 00:01:20.157 Alle Infos findet ihr auf mitwald.de slash lp slash head strich in strich the strich cloud. 00:01:20.517 --> 00:01:24.017 Den Link zum Anklicken findet ihr auch in den Shownotes. Hinter diesem Link 00:01:24.017 --> 00:01:27.937 findet ihr die Ticketbuchung, den Newsletter, Videos des letzten Summits und 00:01:27.937 --> 00:01:29.357 den noch offenen Call for Papers. 00:01:29.617 --> 00:01:33.377 Wenn ihr Nerd seid, denen Kreativität, Tech, Cloud und DevOps am Herzen liegen, 00:01:33.697 --> 00:01:36.737 ist euch der Head in the Cloud Summit wie auf den Leib geschneidert. 00:01:36.997 --> 00:01:40.917 Alle Infos und Links findet ihr in den Shownotes zu dieser Revision. 00:01:41.197 --> 00:01:44.837 Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft. 00:01:48.651 --> 00:01:51.651 Hallo und herzlich willkommen zu Working Draft Revision 658. 00:01:51.891 --> 00:01:54.611 Heute am Start die Komponentenkönigin Vanessa. 00:01:55.151 --> 00:01:57.411 Servus. Und der Rust-Rächer Stefan. 00:01:59.391 --> 00:02:01.791 Guten Morgen, guten Abend, Moizet. 00:02:01.931 --> 00:02:05.651 Und meine Wenigkeit, der Peter. Es ist jetzt nicht ein Tag, nachdem wir die 00:02:05.651 --> 00:02:08.271 letzte Folge aufgenommen haben, sondern wie wir das immer so machen, 00:02:08.431 --> 00:02:10.351 eine Woche später am Montagabend. 00:02:13.111 --> 00:02:14.211 Zwei Wochen später. 00:02:14.431 --> 00:02:14.751 Genau, genau. 00:02:15.071 --> 00:02:15.971 Wir hatten zwischenzeitlich eine andere. Okay. 00:02:16.551 --> 00:02:20.191 So, so. Wir haben ja noch hier unseren Geheimpodcast, den wir dann ja auch noch 00:02:20.191 --> 00:02:22.431 aufnehmen müssen. Ganz, ganz secret. 00:02:23.271 --> 00:02:26.531 Was jetzt nicht so geheim ist, sind immer noch die Ergebnisse vom State of JS 00:02:26.531 --> 00:02:33.291 2024, den wir heute mal zumachen wollen, indem wir über die letzten paar Themen reden. 00:02:33.291 --> 00:02:38.831 Wir waren stehen geblieben bei Testing, haben uns über Jest aufgeregt im Wesentlichen 00:02:38.831 --> 00:02:42.831 und festgestellt, dass wir in unterschiedlichen Universen leben, was so Testing angeht. 00:02:43.551 --> 00:02:46.811 Und jetzt müssen wir halt sämtliche anderen Themen noch irgendwie in eine Folge quetschen. 00:02:47.911 --> 00:02:51.571 Weißt du jetzt nicht, wie interessant jetzt so Sachen wie React Native in eurer 00:02:51.571 --> 00:02:53.191 Realität so normalerweise sind? 00:02:53.811 --> 00:02:55.951 Also nicht existent. 00:02:56.491 --> 00:03:00.551 Ich habe es gerade schon vorher auch gemeint, hier bei Mobile und Desktop eigentlich 00:03:00.551 --> 00:03:06.531 habe ich gar nichts dazu zu sagen. außer ich habe gehört, dass Tauri cool ist vor einem Jahr. 00:03:07.751 --> 00:03:13.191 Und die einzige Frage, die ich aufbringen könnte, wäre überhaupt nicht eben 00:03:13.191 --> 00:03:17.911 toolspezifisch, sondern wie sinnvoll es generell eben ist, dass wir JavaScript 00:03:17.911 --> 00:03:20.891 benutzen, um Mobile- und Desktop-Apps zu schreiben. 00:03:21.371 --> 00:03:26.031 Und ich sehe halt einfach den Fall immer noch, dass du hast halt die JavaScript-EntwicklerInnen 00:03:26.031 --> 00:03:29.071 schon in deiner Firma sitzen und du brauchst halt jetzt eine Desktop-App. 00:03:29.071 --> 00:03:32.291 Also kannst du das doch mal eben in Elektron reinwerfen. 00:03:32.511 --> 00:03:36.311 Das klingt jetzt ein bisschen negativ. So hatte ich es mit früher auch behaftet, 00:03:36.371 --> 00:03:38.671 weil dann immer die Performance so schlecht war und irgendwie hat es alles nicht 00:03:38.671 --> 00:03:40.051 so richtig nativ gewirkt. 00:03:40.151 --> 00:03:44.871 Und du willst ja schon auf den Devices dein natives Gefühl haben, wie das heutzutage ist. 00:03:45.071 --> 00:03:48.731 Ich weiß es gar nicht. Ich weiß gar nicht, welche Apps ich da wie benutze, 00:03:48.771 --> 00:03:51.491 ob die Elektron-Apps sind oder ob das native Apps sind. 00:03:52.631 --> 00:03:55.611 Keine Ahnung. Ich weiß nicht, was Slack ist. Es wird wahrscheinlich kein Elektron 00:03:55.611 --> 00:03:56.731 sein. Vielleicht aber doch. 00:03:56.891 --> 00:03:57.591 Ich glaube schon, oder? 00:03:58.091 --> 00:03:59.371 Na, es sind Elektron-Apps, ja. 00:04:00.471 --> 00:04:03.031 Ja, läuft ja irgendwie auch, also kann es auch nicht so schlecht sein. 00:04:03.431 --> 00:04:06.031 Naja, vor allen Dingen brauchst du da ja speziell auf dem Desktop die exakt 00:04:06.031 --> 00:04:09.071 gleiche User-Experience wie im Browser. Und du brauchst den Browser, 00:04:09.271 --> 00:04:11.291 weil nicht jeder sich dieses Ding installieren mag oder kann. 00:04:12.991 --> 00:04:16.111 Ja, das finde ich immer ein bisschen, darüber wundere ich mich immer so ein 00:04:16.111 --> 00:04:23.031 bisschen, wenn man die Tools lieber im Browser verwendet, als die Pseudo-nativen Apps dann. 00:04:23.151 --> 00:04:25.731 Also ich würde niemals auf die Idee kommen, Slack im Browser zu verwenden, 00:04:25.731 --> 00:04:28.591 außer wie du gerade gemeint hast, man kann nicht, man darf nicht. 00:04:31.029 --> 00:04:33.469 Ich würde nie auf die Idee kommen, mir irgendein Programm zu installieren, 00:04:33.549 --> 00:04:36.189 das ich nicht installieren muss, weil ich es genauso gut im Browser kriege. 00:04:37.109 --> 00:04:39.569 Andersrum, komplett andersrum. Ich würde es sofort installieren, 00:04:39.649 --> 00:04:41.909 hauptsächlich muss ich wieder den Tab suchen, wo das drin liegt. 00:04:42.169 --> 00:04:46.149 Deswegen wäre ich fast generell ein größerer Fan von so Microsoft Teams und 00:04:46.149 --> 00:04:49.849 sowas, bevor ich Google Meet verwende, wo ich dann wieder das Browser-Tipp suchen muss. 00:04:50.389 --> 00:04:52.789 Das ist Wahnsinn. Ich lebe in einer komplett anderen Welt als du. 00:04:54.389 --> 00:04:58.549 Also erstens Microsoft Teams greife ich nicht einmal mit der Beißzange an. 00:04:58.549 --> 00:05:01.009 Das ist die schrecklichste Software, die je geschrieben worden ist. 00:05:01.849 --> 00:05:04.709 Und ich bin auch eher im Browser unterwegs. Also es kommt ganz darauf an, 00:05:04.889 --> 00:05:06.329 wie oft ich die Software verwende. 00:05:06.929 --> 00:05:09.929 Slack habe ich installiert, weil ich habe zehn Channels und ich bin da eigentlich, 00:05:11.229 --> 00:05:17.409 also das sind diese zehn Workspaces oder Teams oder wie sie sie dort nennen, meine Tabs. 00:05:17.509 --> 00:05:21.629 Und du brauchst nicht einen Tab im Browser und nachher nur einen Tab im Produkt, 00:05:21.749 --> 00:05:24.009 dass du das Richtige findest. 00:05:24.069 --> 00:05:27.749 Das ist okay, wenn ich das installiere. Also Sachen wie Visual Studio Code ja 00:05:27.749 --> 00:05:28.709 auch eine Elektron-App. 00:05:30.009 --> 00:05:33.469 Ich sage, dass ich das nicht im Browser laufen lasse, weil da fehlt mir halt 00:05:33.469 --> 00:05:35.389 ein bisschen der Zucker aufs Dateisystem. 00:05:35.769 --> 00:05:39.129 Aber ansonsten schaue ich halt, dass die anderen Sachen, die laufen alle irgendwie im Browser. 00:05:39.289 --> 00:05:42.509 Tatsächlich, unser Working-Draft-Channel, unser Working-Draft-Slack, 00:05:42.689 --> 00:05:46.769 den habe ich jetzt auch nur im Browser offen. Deswegen bin ich auch so langsam in meine Antwort. 00:05:48.649 --> 00:05:51.549 Ja, ich glaube, das ist tatsächlich so die Frage der Intensität der Nutzung. 00:05:51.549 --> 00:05:56.189 Also ich bin im Prinzip nie mehr als drei Slack-Workspaces drin. 00:05:56.749 --> 00:06:01.229 Und das passt irgendwie so in Tabs, minimiert, nebeneinander, 00:06:01.349 --> 00:06:03.789 weil ich dann weiß, der linke ist dieser, der mittlere ist jener, der rechte ist solcher. 00:06:05.909 --> 00:06:08.949 Aber bei 10 wird das wahrscheinlich nicht skalieren. Da wird es ja irgendwann 00:06:08.949 --> 00:06:09.829 den Überblick verlieren. 00:06:14.812 --> 00:06:17.932 Also ich verstehe diesen Elektron-Hass auch nicht, das ist halt dann entweder 00:06:17.932 --> 00:06:22.372 so und ob das UI jetzt beknackt ist, weil es, also mit beknackt meine ich nicht 00:06:22.372 --> 00:06:26.372 nativ ist, weil es Elektron ist oder weil es halt irgendein seltsames Toolkit 00:06:26.372 --> 00:06:29.712 verwendet, das ich gerade nicht installiert habe, ist mir ja im Endeffekt egal. 00:06:29.992 --> 00:06:32.792 Die Frage ist halt, brauche ich das Ding und kann ich mit dem arbeiten, 00:06:33.092 --> 00:06:37.532 so wie es ist, wenn ja, verwende ich es und wenn nicht, dann nicht. Das ist ja ein Werkzeug. 00:06:37.532 --> 00:06:48.612 Ich finde es recht spannend, weil gerade im Bereich Mobile Apps finde ich das 00:06:48.612 --> 00:06:49.472 immer sehr, sehr schwierig, 00:06:49.572 --> 00:06:54.252 mit Browser-Technologien sinnvoll Apps auf mobilen Devices zu schreiben. 00:06:54.252 --> 00:06:56.472 Gerade wenn man in die iOS-Gegend geht. 00:06:58.272 --> 00:07:05.112 Seit über zehn Jahren versuchen diese Cross-Plattform-Publishing-Tools, 00:07:05.452 --> 00:07:10.892 das App-Entwickeln auf unterschiedlichen Plattformen einfacher zu machen. 00:07:11.012 --> 00:07:13.812 Und ich glaube, dass sie nicht wirklich erfolgreich sind damit. 00:07:15.292 --> 00:07:19.372 Im Desktop ist komplett was anderes. Wenn ich Apps installiert habe, 00:07:19.452 --> 00:07:23.812 sind es entweder der Browser oder Elektron-Apps, die ich verwende. 00:07:23.812 --> 00:07:28.492 Also da dürfte mittlerweile schon so eine kritische Masse erreicht worden sein, 00:07:28.572 --> 00:07:30.272 dass wenn du eine Desktop-App machst, 00:07:30.872 --> 00:07:36.552 ist Elektron oder Tauri, das ist ja jetzt so eine rastbasierte Alternative zu Elektron, 00:07:36.612 --> 00:07:41.472 die ein bisschen einfacher ist oder ein bisschen leichter ist, 00:07:41.512 --> 00:07:46.812 was Speichermanagement angeht und nicht ganz so viel RAM benötigt wie die Elektron-Alternativen, 00:07:47.172 --> 00:07:48.612 durchaus eine Alternative geworden. 00:07:48.612 --> 00:07:54.172 Also ich glaube, dass Leute eher sagen, sie machen jetzt ein Desktop-App mit 00:07:54.172 --> 00:07:59.572 Web-Technologien, als sie sagen, sie machen ein Desktop-App mit nativen Technologien. 00:07:59.872 --> 00:08:01.032 Kommt natürlich auf die News gesagt, 00:08:01.232 --> 00:08:03.452 aber es ist auf jeden Fall eine sehr brauchbare Alternative geworden. 00:08:05.531 --> 00:08:09.071 Ja, da hast du, du hast einen guten Punkt gesagt, da kann man mal unterscheiden 00:08:09.071 --> 00:08:11.971 zwischen wirklich Desktop und Mobile noch, weil irgendwie finde ich es auch 00:08:11.971 --> 00:08:14.691 verständnisvoller, wenn ich eine App habe, 00:08:14.831 --> 00:08:19.411 die im Browser und dann die Elektron oder was auch immer App ziemlich gleich 00:08:19.411 --> 00:08:21.611 und identisch ist, das erwarte ich dann fast auch so. 00:08:22.171 --> 00:08:25.691 Also auf Mobile habe ich immer noch das Gefühl, da erwartet man schon noch irgendwie 00:08:25.691 --> 00:08:30.791 entweder die Android- oder iOS-Designs dann auch zusätzlich, 00:08:30.931 --> 00:08:33.531 dass die Loading-Icon so ausschauen, dass die Button so ausschauen, 00:08:33.611 --> 00:08:34.711 dass die Tabs so ausschauen. 00:08:37.511 --> 00:08:41.771 Wie das jetzt heutzutage übrigens ist, wie man da auf die Sensoren von den mobilen 00:08:41.771 --> 00:08:44.691 Geräten zugreifen kann. Ich glaube, das war früher immer kompliziert, 00:08:44.831 --> 00:08:49.171 mit wie man dann auf die Kamera und sowas zugreift. Ich habe leider wirklich keine Erfahrung. 00:08:49.371 --> 00:08:52.791 Also wenn auch da jetzt gerade jemand zuhört, der sich damit auskennt, 00:08:52.911 --> 00:08:55.351 schreibt uns dann gerne mal, wie da der Stand heutzutage ist. 00:08:55.911 --> 00:08:57.791 Oder wir laden dich dann auch gerne dazu ein. 00:08:58.531 --> 00:09:01.251 Interessieren wird es mich auf jeden Fall. Ich habe leider keine Info dazu. 00:09:01.591 --> 00:09:04.551 Außer, dass wenn ich jetzt hier bei dem State of JS nach unten scrolle, 00:09:04.971 --> 00:09:08.291 ich auch sehe, dass hier der Pain-Point Nummer 1 die Performance ist. 00:09:08.691 --> 00:09:13.631 Und dann der Klassiker, Elektron und React Native werden wahrscheinlich am meisten verwendet. 00:09:13.911 --> 00:09:17.311 Dementsprechend sind es auch die meisten Pain-Points, Electron und React Native dann. 00:09:21.411 --> 00:09:25.371 Tja, davon ist auszugehen. Ich würde mal sagen, ist halt ein Werkzeug wie jedes 00:09:25.371 --> 00:09:27.491 andere und dann benutzt man das halt eben oder halt nicht. 00:09:29.351 --> 00:09:30.751 Wobei Werkzeugen sind, die man 00:09:30.751 --> 00:09:33.951 entweder benutzt oder nicht. Wollen wir zum nächsten gehen? Build Tools? 00:09:35.351 --> 00:09:38.511 König der Build Tools ist immer noch Webpack. Das finde ich ein bisschen überraschend. 00:09:39.071 --> 00:09:40.491 Ja, es bricht mein Herz. 00:09:41.471 --> 00:09:44.551 Wirklich überraschend? Es ist nicht so dieser Jake-Very-Effekt. 00:09:44.551 --> 00:09:46.971 Es ist halt überall drin und bis du das mal weg hast. 00:09:47.491 --> 00:09:50.931 Ja, okay, die Frage ist aber, ob sozusagen diejenigen, bei denen das der Fall 00:09:50.931 --> 00:09:53.011 ist, also Webpack ist ja zum Beispiel auch der Unterbau von Next.js, 00:09:53.111 --> 00:09:53.831 wenn ich mich recht erinnere. 00:09:54.551 --> 00:09:58.571 Wenn ich jetzt hier sozusagen anhake, ich verwende das, ich würde jetzt, 00:09:58.611 --> 00:10:03.171 wenn ich eine Next.js-App baue, würde ich sagen, Webpack ist da irgendwie eine 00:10:03.171 --> 00:10:06.131 eingebaute Dependency und möglicherweise muss ich das auch mal direkt konfigurieren, 00:10:06.271 --> 00:10:09.471 aber ich würde mich jetzt nicht primär als ein Webpack-Nutzer wahrnehmen. 00:10:11.171 --> 00:10:13.491 Deswegen weiß ich nicht, ob das daherkommt, dass das überall eingebaut ist. 00:10:13.491 --> 00:10:16.131 Das ist ja dann öfter mal eher sekundär. 00:10:16.871 --> 00:10:20.211 Und wenn ich Probleme habe, dann liegt das ja an dem Überbau meistens, 00:10:20.211 --> 00:10:22.171 sagt jedenfalls meine sparsame Next.js-Erfahrung. 00:10:23.431 --> 00:10:27.071 Von daher muss es immer noch Leute geben, die sagen, ich brauche ein Build-Tool, 00:10:27.211 --> 00:10:28.711 ich gehe als Default-Lösung zu Webpack. 00:10:28.811 --> 00:10:32.071 Und das finde ich ja angesichts der Alternativen schon ein bisschen bemerkenswert. 00:10:32.991 --> 00:10:36.731 Naja, die Usage ist sehr hoch, aber wenn du auf die Positivity gerade drückst, 00:10:36.851 --> 00:10:39.571 dann geht der ganze Berg nach unten. 00:10:39.911 --> 00:10:43.131 Ganz steil. Also es war wirklich von Platz 1 auf Platz letzter Platz. 00:10:43.611 --> 00:10:43.771 Ja, 00:10:46.071 --> 00:10:46.451 okay, das stimmt. 00:10:49.426 --> 00:10:53.146 Also, du gibst einen validen Punkt auch nicht. 00:10:53.866 --> 00:10:57.326 Wie oft muss ich, wenn ich mich gerade in eines dieser vorgefertigten Framework 00:10:57.326 --> 00:11:00.226 setze, mit dem Build-Tool tatsächlich herumarbeiten? 00:11:01.926 --> 00:11:05.326 In all meinen Next.js-Projekten habe ich das nie gemacht. Da habe ich eher so 00:11:05.326 --> 00:11:06.666 ein Next-Config bearbeitet. 00:11:07.486 --> 00:11:10.626 Selbst wenn wir noch unseren Angular-Client gehabt haben, der ja auch auf Webpack 00:11:10.626 --> 00:11:16.006 aufbaut, habe ich nie mit Webpack selbst gearbeitet, sondern immer mit dem Framework rundherum. 00:11:16.006 --> 00:11:21.906 Und zu sagen, dass ich jetzt selbst ein Projekt mache, das ich komplett eigens 00:11:21.906 --> 00:11:28.046 kreiere, keine zehn Pferde könnten mich dazu zu Webpack bringen. 00:11:28.266 --> 00:11:32.926 Also wenn das nicht O ist, Legacy-Projekte von 2016 sind, wo die Leute das selbst 00:11:32.926 --> 00:11:34.766 geschrieben haben und immer noch hingreifen müssen. 00:11:35.406 --> 00:11:39.926 Oder vielleicht Create Reactive, glaube ich, exposed Webpack ziemlich stark. 00:11:40.086 --> 00:11:42.146 Also es muss irgendwas von dem sein, was die Leute verwenden, 00:11:42.246 --> 00:11:47.646 dass sie sagen, sie entwickeln täglich oder immer noch Webpack. 00:11:47.946 --> 00:11:51.466 Oder es ist der Enterprise-Effekt, dass das in den ganzen alten Applikationen mittlerweile drin ist. 00:11:52.226 --> 00:11:55.546 Und da hast du dann diese eine Person im Team, die genau das kann und genau 00:11:55.546 --> 00:11:59.786 das macht und immer auch machen muss, weil nichts funktioniert. 00:12:00.626 --> 00:12:03.146 Aber das Ding ist übelster Rotz meiner Meinung nach. 00:12:04.266 --> 00:12:09.466 Naja, komm. Ich meine, es ist eines der wenigen Werkzeuge, das alles kann. 00:12:10.226 --> 00:12:10.626 Ja. 00:12:11.066 --> 00:12:14.346 Und außerdem das erste seiner Art. Wie gut kann das schon sein? 00:12:16.626 --> 00:12:18.406 Okay, vielleicht tue ich ihm da Unrecht nicht. 00:12:19.926 --> 00:12:22.646 Also übelster Rotz würde ich das nicht nennen. Ich würde halt irgendwie sagen, 00:12:22.766 --> 00:12:26.126 so hier, Romo Erectus, hast du soweit gut gemacht, aber jetzt übernehmen wir hier. 00:12:26.986 --> 00:12:31.326 Ja, stimmt. Also ich glaube, ich tue dem Tool da Unrecht. Wobei, 00:12:31.446 --> 00:12:34.746 ich finde ja Webpack eigentlich nicht das Erste seiner Art. Das wäre ja Browser-Refy. 00:12:35.546 --> 00:12:38.686 Das Grundkonzept von Webpack, wie du Module lädst und so weiter und was das 00:12:38.686 --> 00:12:41.126 machen soll, ist genau das Gleiche wie bei Browser-Refy. 00:12:41.286 --> 00:12:43.306 Na gut, aber der Scope von Webpack ist ja ein viel weiterer. 00:12:43.306 --> 00:12:46.486 Das macht ja auch dein CSS, deine Bilder, alles so. Das ist ja ein Browser-Refy, 00:12:46.486 --> 00:12:47.686 nicht der Fokus gewesen. 00:12:48.726 --> 00:12:50.266 Ich weiß aber nicht, ob das richtig war. 00:12:50.446 --> 00:12:51.766 Auch schon. Ich glaube auch. 00:12:55.646 --> 00:12:59.346 Ich bin sehr skeptisch. Da ist in dieser Liste von Tools nämlich was drin, 00:12:59.346 --> 00:13:02.126 was ich halt sehr gerne verwende. 00:13:02.975 --> 00:13:05.415 Das ist das zweitunpopulärste, Parcel. 00:13:05.915 --> 00:13:07.095 Ja, Parcel ist speziell. 00:13:07.895 --> 00:13:12.115 Aber Moment, Stefan, Stefan, das ist doch das Gleiche. Dem sagst du ja buchstäblich, 00:13:12.115 --> 00:13:17.435 als Lademechanismus sagst du, da ist die HTML-Datei, da ist alles reingebunden 00:13:17.435 --> 00:13:18.735 mit HTML-Standardmitteln. 00:13:19.115 --> 00:13:25.075 Du machst halt dann eben Script Import meine TS-Datei und CSS Import meine SAS-Datei. 00:13:25.295 --> 00:13:28.855 Und der macht ja nichts weiter als automatisch dann zu erkennen, 00:13:28.995 --> 00:13:30.815 okay, dann brauche ich wohl TypeScript und den SAS-Compiler, 00:13:30.895 --> 00:13:31.675 installiert die von selber. 00:13:32.195 --> 00:13:35.915 Dir entgeht die Konfiguration, aber ansonsten ist es ja das gleiche wie Webpack. 00:13:36.215 --> 00:13:37.575 Gib mir dein Projekt, ich mach alles. 00:13:40.315 --> 00:13:44.115 Ich muss vielleicht meine Aussage revidieren. Webpack ist vielleicht ein gutes 00:13:44.115 --> 00:13:45.895 Tool, war vielleicht das erste und hat viele möglich. 00:13:46.415 --> 00:13:49.715 Was Webpack möglich hat und das ist eigentlich genau das, wo ich dagegen bin, 00:13:50.215 --> 00:13:55.055 und das ich kritisch finde, ist, dass wir JavaScript als die Single Source of 00:13:55.055 --> 00:13:57.115 Truth für die gesamte Applikation hergenommen haben. 00:13:57.195 --> 00:14:01.135 Es gibt Leute, die laden ihre Bilder in JavaScript, die laden CSS-Dateien in 00:14:01.135 --> 00:14:06.215 JavaScript, die laden jedes andere in JavaScript und das JavaScript ist diesen Hauptausgangspunkt. 00:14:07.275 --> 00:14:10.355 Und dadurch brauchst du diese ganzen unterschiedlichen Loader, 00:14:10.435 --> 00:14:14.195 die CSS laden, die PNGs laden, die dort dann die ganzen Imageoptimierungen machen 00:14:14.195 --> 00:14:16.755 und so weiter. Und ich finde, das ist der falsche Platz dafür. 00:14:17.015 --> 00:14:19.475 Ich finde, wir legen dort eine Komplexität auf die JavaScript, 00:14:19.655 --> 00:14:22.755 falls die dort nicht hingehört und die nicht kompatibel ist mit dem Rest, 00:14:22.835 --> 00:14:24.155 wie die ganze Maschinerie funktioniert. 00:14:24.355 --> 00:14:27.115 Und das ist eigentlich das Problem, das ich habe. Wenn ich in Parzl auf eine 00:14:27.115 --> 00:14:32.015 HTML-Datei gehe und das findet die Sourcen, die ich inkludiere und findet nachher 00:14:32.015 --> 00:14:35.595 heraus, was da eigentlich dahinter steckt, das ist fein für mich und je weniger 00:14:35.595 --> 00:14:37.135 ich konfigurieren muss, umso besser. 00:14:37.635 --> 00:14:41.635 Aber dass ich jetzt sage, mein Haupteinstiegspunkt ist die Main-JS-Datei und 00:14:41.635 --> 00:14:46.775 ich lade dort eine CSS-Datei genauso, wie ich das mit ECMAScript-Modulen machen 00:14:46.775 --> 00:14:49.015 würde. Ich glaube, dass dieser Weg falsch war. 00:14:49.455 --> 00:14:54.495 Ich glaube, dass uns dieser Weg mehr Probleme macht, weil wir effektiv eine 00:14:54.495 --> 00:14:57.415 Zweitsprache neben der tatsächlichen Sprache generieren. 00:14:57.495 --> 00:14:59.895 Gut, machen wir mit GSX von sich aus schon. 00:15:00.769 --> 00:15:04.369 Macht aber das Wegmigrieren davon ungleich schwieriger. 00:15:04.729 --> 00:15:08.649 Ja, das ist der Punkt, würde ich sagen. Also Webpack verleitet dich eher dazu, 00:15:09.649 --> 00:15:11.229 originelle Dialekte zu verwenden? 00:15:11.829 --> 00:15:15.849 Ja, im Webpack ist dann auf einmal alles ein Dialekt, weil du halt über diese 00:15:15.849 --> 00:15:19.189 Loader-Mechanik einfach alles im JavaScript machen kannst. 00:15:19.369 --> 00:15:24.889 Und das ist eher nicht das Problem vom Tool, sondern das Problem, 00:15:24.969 --> 00:15:26.209 wie Leute das Tool verwendet haben. 00:15:27.389 --> 00:15:31.609 Und ich merke das jetzt, wenn ich mit JavaScript-Entwicklerinnen und Entwicklern 00:15:31.609 --> 00:15:34.389 arbeite, die ein bisschen später angefangen haben wie ich damit. 00:15:35.469 --> 00:15:39.689 Wir haben ein React-basiertes Framework geschrieben und Leute wundern sich, 00:15:39.809 --> 00:15:41.749 warum sie keine CSS-Dateien da drin laden können. 00:15:41.949 --> 00:15:46.309 Nicht wissend, dass das ja eigentlich in JavaScript nicht geht. 00:15:47.409 --> 00:15:51.049 Gehen aber davon aus, dass das ein Standard-Feature ist von ECMAScript-Modulen. 00:15:51.269 --> 00:15:53.969 Das ist das nicht. Und da sehe ich eigentlich das Problem. 00:15:55.189 --> 00:15:58.609 Ja, ich meine, es existiert zu einem gewissen Grad auch in anderen Sachen, 00:15:58.729 --> 00:16:00.889 wie zum Beispiel Parcel. Die haben sich ja zum Beispiel auch diese, 00:16:01.569 --> 00:16:03.049 na hier, was war das denn? 00:16:03.509 --> 00:16:06.589 Diese Dinger, die zur Compile-Zeit ausgeführt werden, Makros, 00:16:07.249 --> 00:16:10.789 aus Bann gemobst und da auch eingebaut. Die habe ich noch nie zu funktionieren gebracht. 00:16:12.109 --> 00:16:12.949 Das muss ich googeln. 00:16:13.429 --> 00:16:16.089 Ja, hätte ich halt ganz gerne gehabt für so Web-Components, weil da wäre es 00:16:16.089 --> 00:16:19.129 ja schon praktisch, wenn du irgendwie sagen würdest, zur Compile-Zeit bitte 00:16:19.129 --> 00:16:24.149 den CSS-String aus der extra Datei inleinen und dann als Adopted Style-Sheet 00:16:24.149 --> 00:16:26.689 einhängen, damit du keine Duplizierung hast von dem Zeug. 00:16:27.329 --> 00:16:29.689 Aber andererseits habe ich dann auch gesagt, ich habe es jetzt nicht zum Funktionieren 00:16:29.689 --> 00:16:32.029 gebracht und eigentlich finde ich das auch nicht schlecht, weil sobald ich das halt mache... 00:16:33.259 --> 00:16:35.739 Bin ich halt mit meiner Software, die ich geschrieben habe, abhängig davon, 00:16:35.939 --> 00:16:38.559 dass ich ein Build-Tool habe, was halt diese Makros unterstützt. 00:16:38.899 --> 00:16:40.119 Und das ist ja kein Standard-Feature. 00:16:40.619 --> 00:16:43.659 Und der Grund, warum ich zunehmend mich weniger um Build-Tools schere, 00:16:43.919 --> 00:16:47.819 ist, dass ich halt einfach eine Aversion entwickelt habe gegen diese ganzen Dialekte. 00:16:48.459 --> 00:16:51.079 Ich sag halt, nehm den Standard-Weg und sonst keinen. Und dann ist es mir halt 00:16:51.079 --> 00:16:53.499 ehrlich gesagt egal, ob es Webpack, Parcel oder sonst was ist. 00:16:53.659 --> 00:16:55.259 Ganz genau. Weil dann ist es ja einfach. 00:16:55.999 --> 00:16:58.619 Es wird immer nur dann schwierig und die Tools werden nur zu einem Problem, 00:16:58.939 --> 00:17:02.099 wenn man halt versucht, Dinge zu machen, die nicht ohnehin Standard sind. 00:17:03.039 --> 00:17:06.499 Ganz genau. Auf einmal wird nämlich das ganze Thema Bundling wieder trivial. 00:17:06.779 --> 00:17:10.479 Dann kannst du relativ gut steuern, wo du dein Code-Splitting machst über diese Input-Funktion. 00:17:10.599 --> 00:17:13.759 Du kannst relativ genau steuern, was in deinem Bundle alles drinnen ist. 00:17:13.859 --> 00:17:15.499 Und es kommt halt nur das JavaScript-Ding rein. 00:17:15.919 --> 00:17:19.379 Und Leute, es ist nicht so schwierig, dass man eben bei CSS schreibt. 00:17:19.539 --> 00:17:21.359 Es ist echt nicht schwer. 00:17:21.619 --> 00:17:28.939 Und es gibt auch Tools, die auf Standards funktionieren, damit du das in JavaScript machen kannst. 00:17:29.079 --> 00:17:31.839 Also das ist auch ein gelöstes Problem. 00:17:32.879 --> 00:17:38.139 Man muss nicht alles über Import-Direktiven in seinen JavaScript-Source-Files machen. 00:17:38.319 --> 00:17:42.079 Ja, man braucht nicht mal notwendigerweise einen Bundler dieser Tage, würde ich sagen. 00:17:42.299 --> 00:17:46.759 Also seitdem ich Import-Maps habe, ist halt so, ich baue irgendwie ein NPM-Package 00:17:46.759 --> 00:17:48.239 und ich will eine Demo-Datei beilegen. 00:17:48.419 --> 00:17:52.979 Ist total trivial geworden, weil ich halt sagen kann, Import from NPM-Modulname. 00:17:53.299 --> 00:17:55.359 Und kann einfach sagen, ja, wenn du die halt ausprobieren willst, 00:17:55.799 --> 00:17:58.299 dann lad halt diese HTML-Datei irgendwie über Localhost. 00:17:58.899 --> 00:18:01.419 Man muss das Ding dafür nicht installiert haben. Es ist halt einfach so ein, 00:18:01.799 --> 00:18:02.879 es fühlt sich halt eben an. 00:18:03.359 --> 00:18:06.519 Und ganz ehrlich, für viele Use Cases sind auch so Sachen wie Bundling und Minifying 00:18:06.519 --> 00:18:08.259 ja nicht wirklich notwendig. 00:18:08.759 --> 00:18:12.399 Weil, ich meine, der Kram wird doch eh vom Web-Server gezippt ausgeliefert. 00:18:12.659 --> 00:18:15.759 Und Codesplitting hast du ja ohnehin dann auf Modulebene, so wie es wahrscheinlich 00:18:15.759 --> 00:18:16.819 grob irgendwie Sinn macht. 00:18:17.239 --> 00:18:20.379 Das ist ja eigentlich auch ein Aktefakt aus der Vergangenheit, 00:18:20.519 --> 00:18:22.239 als sowas halt eben zwingend notwendig war. 00:18:22.719 --> 00:18:25.539 Und mittlerweile geht ja so viel einfach gut genug von selbst, 00:18:25.619 --> 00:18:28.759 dass man sich große Teile von diesem ganzen Krempel echt sparen könnte. 00:18:29.640 --> 00:18:32.260 Ich finde es beeindruckend, weil in meinen ersten Webprojekten, 00:18:32.360 --> 00:18:37.860 für die ich tatsächlich bezahlt geworden bin, war Bundling immer ein Optimierungsschritt 00:18:37.860 --> 00:18:40.240 danach. Wir haben einfach auf Fälldateien gearbeitet. 00:18:40.600 --> 00:18:44.980 Wir haben unterschiedliche Modulsysteme genutzt, wie zum Beispiel dieses Require.js 00:18:44.980 --> 00:18:47.220 und so weiter, um unseren Code ein bisschen raufzusplitten zu können, 00:18:47.640 --> 00:18:50.720 haben aber tatsächlich mit den Originaldateien gearbeitet. 00:18:51.120 --> 00:18:56.240 Da war Bundling immer ein optionaler Optimierungsschritt, den wir heute für 00:18:56.240 --> 00:18:57.560 ein Production-Deploy gemacht haben. 00:18:58.640 --> 00:19:04.420 Und irgendwann ist es zum Requirement geworden und nicht erst mit den Dialekten 00:19:04.420 --> 00:19:08.340 wie JSX, also ich habe das Gefühl, das ist schon weit, weit früher passiert, 00:19:08.600 --> 00:19:10.700 dass man davon ausgegangen ist, dass, 00:19:11.880 --> 00:19:16.500 ein Bildprozess muss sowieso existieren und das ist eigentlich schon die erste 00:19:16.500 --> 00:19:18.080 Richtung, wo wir falsch abwogen sind. 00:19:18.200 --> 00:19:23.060 Ja, es ist halt Optimierungswahn, also der alte Spruch hier, 00:19:23.140 --> 00:19:26.460 premature optimization, bla bla bla, aber da hält sich ja keiner dran, 00:19:26.740 --> 00:19:30.260 weil einfach so gewisse Dinge als Best Practice vorausgesetzt werden. 00:19:30.300 --> 00:19:31.280 Man muss das halt so machen. 00:19:31.780 --> 00:19:33.600 Bevor man überhaupt überlegt, habe ich überhaupt ein Problem, 00:19:33.700 --> 00:19:34.760 dass es hier lösenswert ist. 00:19:38.300 --> 00:19:41.620 Wenn ich jetzt wieder an meine React-Katastrophe denke, an der ich da arbeite, 00:19:42.120 --> 00:19:46.180 da ist so viel Premature Optimization drin und so viel Use Callback und hast du nicht gesehen. 00:19:47.580 --> 00:19:50.720 Das macht es halt so dem Forensiker mir hier nicht einfacher zu verstehen, 00:19:50.780 --> 00:19:54.360 was da vor sich geht, wenn halt sowieso Unverständliches nochmal in Performance 00:19:54.360 --> 00:19:55.240 Optimierung gepackt wird. 00:19:55.720 --> 00:19:58.240 Wie wäre es, wenn man das einfach alles sein lassen würde. Wenn man das einfach 00:19:58.240 --> 00:20:02.420 so nutzen würde, wie es gedacht ist, so, und dann hat man auch kein Problem damit. 00:20:03.780 --> 00:20:06.100 So, aber trotzdem müssen wir jetzt, glaube ich, alle nochmal kurz nennen, 00:20:06.120 --> 00:20:09.920 hier aus diesen Build-Tools, was wir verwenden und warum. 00:20:10.080 --> 00:20:14.360 Ich habe ja schon Parcel gesagt, also No-Brainer-Lösung für die schnelle Mini-App zwischendurch. 00:20:14.580 --> 00:20:17.380 Da ist die HTML-Datei, mach mal. Das verwende ich gerne und wenn ich einfach 00:20:17.380 --> 00:20:19.940 JavaScript optimieren möchte, nehme ich ES-Bild. 00:20:20.180 --> 00:20:23.560 Und den Rest da habe ich, glaube ich, seit Ewigkeiten nicht benutzt. 00:20:25.274 --> 00:20:30.934 Ich nehme VEAT oder ich nehme die TypeScript CLI für so kleine Sachen. 00:20:32.154 --> 00:20:35.834 Und ich, mal davon abgesehen, was ich jetzt nehme, ich habe mir jetzt die ganze 00:20:35.834 --> 00:20:37.754 Zeit nochmal die Zahlen genau angeschaut. 00:20:38.114 --> 00:20:41.394 Und bei der USET, wo Webpack auch am meisten verwendet wird, 00:20:41.474 --> 00:20:42.594 das addiert sich ja nicht auf. 00:20:42.654 --> 00:20:46.434 Da ist ja nicht irgendwie 80% Webpack und 20% der ganze Rest, 00:20:46.674 --> 00:20:52.774 sondern wir haben hier halt dann irgendwie 86% Webpack, aber dann 78% VEAT. 00:20:53.454 --> 00:20:57.154 Und einerseits denke ich jetzt, Peter, zu dem, was du vorher gesagt hast, 00:20:57.254 --> 00:21:02.894 ich glaube, wenn jemand Next.js da verwendet, wird man schon Webpack anhaken, weil was sonst? 00:21:03.114 --> 00:21:05.154 Du willst hier die Frage vielleicht nicht leerlassen. 00:21:05.534 --> 00:21:10.094 Und dann könnte ich mir vorstellen, dass man pauschal einfach immer noch Webpack 00:21:10.094 --> 00:21:14.054 anhakt, weil jeder schon mal irgendwie was mit Webpack da gemacht hat. 00:21:14.154 --> 00:21:15.834 Und wann will man das hier auch abhaken? 00:21:16.074 --> 00:21:20.454 Aber wie gesagt, wenn ich hier habe, das sind jetzt 4% Unterschied zwischen 00:21:20.454 --> 00:21:23.134 Webpack und Veed. und wenn ich runterscrolle mit Used at Work, 00:21:23.374 --> 00:21:28.974 da habe ich 7733 Viet versus 7726 Webpack. 00:21:29.374 --> 00:21:32.154 Irgendwie habe ich das Gefühl, vielleicht hat man auch einfach von Webpack auf 00:21:32.154 --> 00:21:36.614 Viet umgestellt und dementsprechend hat man auch Webpack da einfach angefasst. 00:21:37.454 --> 00:21:40.914 Den ganzen anderen, alle anderen habe ich eigentlich nie wirklich verwendet. 00:21:41.014 --> 00:21:43.034 Also ES-Bild kenne ich, habe ich einmal benutzt. 00:21:43.154 --> 00:21:46.094 Roll-Up habe ich mir angeschaut, weil habe ich mir halt angeschaut. 00:21:46.174 --> 00:21:50.974 Turbo-Pack habe ich mir angeschaut, aber benutzt eigentlich jetzt immer nur Webpack und Viet. 00:21:52.374 --> 00:21:53.834 Oder TypeScript CLI. 00:21:56.774 --> 00:21:58.534 Na Stefan, und jetzt bist du dran. 00:22:00.954 --> 00:22:06.934 Also wir verwenden bei uns im Produkt ES-Bild, also Custom konfiguriert, 00:22:06.974 --> 00:22:10.154 wir haben da quasi unser eigenes Bild-Tool geschrieben, das taucht natürlich 00:22:10.154 --> 00:22:12.694 dort jetzt nicht auf, aber da ist ES-Bild die Basis. 00:22:13.434 --> 00:22:20.554 Wir sind nicht ganz so happy mit ES-Bild, weil potenziell mehr möglich ist mit 00:22:20.554 --> 00:22:24.354 deinen Bundling-Tools und DS-Bild steht gerade ein bisschen an. 00:22:24.514 --> 00:22:28.014 Also da hoffen wir sehr stark, dass das, was VIT liefert in Zukunft mit dem, 00:22:29.054 --> 00:22:32.614 RAS-basierten Unterbau, dass wir damit mehr machen können. 00:22:32.914 --> 00:22:37.274 Was wäre das so? Weil ich habe VIT noch nie benutzt. Ich habe keine Ahnung, was das Delta genau ist. 00:22:38.334 --> 00:22:40.874 Naja, VIT, also es ist ja witzig, dass die Sachen zusammengeworfen sind, 00:22:40.934 --> 00:22:44.794 weil VIT ist ja in meiner Vorstellung als erstes einmal ein Development-Server, 00:22:45.074 --> 00:22:48.194 ein General-Purpose-Development-Server, der halt nachher diesen Optimierungsschritt 00:22:48.194 --> 00:22:53.734 machen kann, dass er auch und verwendet, glaube ich, eh dann Rolldown als Unterbau, 00:22:53.834 --> 00:22:57.174 also jetzt aktuell ES-Bild als Unterbau, will aber auf Rolldown migrieren. 00:22:57.574 --> 00:23:02.994 Und Rolldown, da erwarten wir uns einiges, weil gerade diverse Optimierungsmöglichkeiten 00:23:02.994 --> 00:23:07.954 im Bereich Tree-Shaking und so weiter in ES-Bild eher schwierig sind und besser 00:23:07.954 --> 00:23:09.834 funktionieren mit anderen Tools. 00:23:10.274 --> 00:23:10.814 Ach guck, okay. 00:23:11.994 --> 00:23:15.494 Ja, aber das ist, also da sind wir in der, 00:23:17.398 --> 00:23:19.058 In Mikrooptimierungen drinnen. 00:23:19.378 --> 00:23:19.558 Ja. 00:23:20.378 --> 00:23:22.938 Also du musst den ES-Bild tatsächlich hier und da herum hacken. 00:23:23.358 --> 00:23:25.358 Genau, das erklärt, warum das bei mir noch nicht aufgetaucht ist, 00:23:25.478 --> 00:23:27.378 bei ES-Bild als Limitierung, weil ich das vor allen Dingen benutze, 00:23:27.378 --> 00:23:31.738 um halt irgendwie die Bundles von Libraries zu bauen. Und dann ist mir ja Tree-Shaking erstmal egal. 00:23:32.418 --> 00:23:35.918 Ja, genau. Und bei uns ist es halt so, wir haben halt teilweise geteilten Code 00:23:35.918 --> 00:23:39.698 zwischen Frontend und Backend. Und du willst halt keinen Frontend-Code im Backend haben. 00:23:40.018 --> 00:23:43.458 Und das passiert mit ES-Bild öfter, weil halt ES-Bild sehr konservativ ist, 00:23:43.538 --> 00:23:47.058 was das Tree-Shaking angeht. und halt auch keine Anstalten zeigt, 00:23:47.078 --> 00:23:48.618 das irgendwie zu verändern in Zukunft. 00:23:48.798 --> 00:23:52.218 Das ist Feature komplett. Die wollen da nicht wirklich was machen. 00:23:53.838 --> 00:23:58.378 Persönlich verwende ich halt dann einfach die TSC CLI und SWC tatsächlich. 00:23:58.578 --> 00:24:02.758 SWC ist cool, wenn du einfach nur Type Erasure machen willst und JavaScript rauskriegen willst. 00:24:04.938 --> 00:24:08.238 Das wohl wahr. Okay, ich will noch ein Tool erwähnen, das da nicht aufgeführt 00:24:08.238 --> 00:24:09.478 ist, was ich aber ganz lustig finde. 00:24:10.098 --> 00:24:13.278 Habe ich möglicherweise auch schon mal erwähnt. Es gibt wirklich diverse Tools, 00:24:13.498 --> 00:24:17.118 um DTS-Files von eurem TypeScript-Projekt auch zu bundeln. 00:24:17.558 --> 00:24:21.058 Also normalerweise macht ja der TypeScript-Compiler irgendwie, 00:24:21.258 --> 00:24:24.878 keine Ahnung, hier sind sieben TypeScript-Dateien, macht da sieben JavaScript-Dateien 00:24:24.878 --> 00:24:26.718 draus und sieben DTS-Dateien. 00:24:26.898 --> 00:24:30.278 Und die JavaScript-Dateien werden dann ja öfter mal noch durch einen Bundling-Schritt 00:24:30.278 --> 00:24:31.898 noch zusammengefügt, in eine 00:24:31.898 --> 00:24:34.718 große Datei, sie alle zu knechten und die DTS-Dateien normalerweise nicht. 00:24:34.838 --> 00:24:37.678 Und so Kram wie der DTS-Bundler, der macht das tatsächlich. 00:24:38.498 --> 00:24:41.518 Was ganz lustig ist, wenn man mal so das Requirement hat, wie irgendwie 00:24:43.738 --> 00:24:47.218 obfuskieren, was da genau die Modulstruktur ist oder ich will das Projekt irgendwem 00:24:47.218 --> 00:24:50.718 in die Hand geben können mit den Worten, hier sind zwei Dateien, werde glücklich damit. 00:24:51.178 --> 00:24:53.718 Das ist ganz nett. Da gibt es auch eine breite Auswahl, die auch ähnlich wie 00:24:53.718 --> 00:24:55.438 die Buildtools alle sehr unterschiedliche Trade-offs machen. 00:24:56.038 --> 00:24:59.098 Und das kann man dann auch mal gebrauchen, wenn man das braucht, 00:24:59.278 --> 00:25:02.038 was wahrscheinlich fast nie ist. Aber ich will nur erwähnen, sowas existiert auch. 00:25:02.698 --> 00:25:05.958 Dann war das damit dann der letzte Punkt zu den Buildtools. 00:25:06.158 --> 00:25:06.878 Würde ich sagen, oder? 00:25:07.478 --> 00:25:10.778 Ja, wenn man Lauf rette. Das ist der Wahnsinn. 00:25:10.778 --> 00:25:14.798 Wir haben das jetzt alle im Hinterkopf, dass das die letzte ist. 00:25:15.798 --> 00:25:18.218 Naja, und nicht vergessen, wir hatten ja eine ganze Woche Pause, 00:25:18.218 --> 00:25:19.338 um uns wieder zu erholen. 00:25:24.067 --> 00:25:27.547 Und wir sind zwar jetzt bei dem letzten Punkt von den Libraries, 00:25:27.667 --> 00:25:30.907 aber es kommen ja irgendwie noch andere Punkte danach, obwohl danach jetzt nur 00:25:30.907 --> 00:25:35.407 noch die Other Tools, Usage, Resources kommen, wo wir normalerweise schneller drüber springen. 00:25:37.147 --> 00:25:40.847 Aber jetzt wird es spannend, wie lange wir bei den Monorepos hängenbleiben. 00:25:41.667 --> 00:25:45.747 Ich kann jetzt natürlich wieder die Grundsatzfrage aufmachen von Monorepo versus 00:25:45.747 --> 00:25:49.507 Multirepo. Ich bin ja immer so ein bisschen für die einfache Variante. 00:25:49.907 --> 00:25:52.987 Ich finde Monorepos gar nicht so schlecht, Aber ich würde es auch nicht verkomplizieren. 00:25:53.407 --> 00:25:57.427 Ich finde auch Multi-Repos ganz gut. Man muss halt richtig konfigurieren, gell? 00:25:57.607 --> 00:26:00.747 Ich wüsste ja ganz gerne mal, wie ich das überhaupt entscheide. 00:26:02.307 --> 00:26:04.687 Weil also irgendwie, ob ich so was haben will. Weil ich habe irgendwie hier 00:26:04.687 --> 00:26:07.167 so meinen kleinen Zoo an Libraries und die hängen irgendwie zusammen. 00:26:07.707 --> 00:26:12.787 Und manchmal habe ich halt dieses klassische Szenario, dass irgendwas upstream, ein Update braucht. 00:26:12.887 --> 00:26:16.347 Und dann muss ich das halt eben erst so durch sämtliche Dependents durchziehen 00:26:16.347 --> 00:26:17.367 für halt so meinen kleinen Zoo. 00:26:17.627 --> 00:26:20.047 Wo ich normalerweise sagen würde, ja, wunderbar, hätte ich jetzt Monorepo, 00:26:20.067 --> 00:26:23.027 wäre das Problem jetzt in dem Maße nicht existent. 00:26:23.687 --> 00:26:26.627 Andererseits hat mein ganzes Set an Dingen, die da existieren, 00:26:27.807 --> 00:26:31.087 nicht inhärent was miteinander zu tun, sondern das ist halt meine persönliche 00:26:31.087 --> 00:26:32.067 vertikale Integration. 00:26:32.627 --> 00:26:35.187 Da ist mein Toolkit A, da ist mein Toolkit B, dann verwende ich da irgendwie 00:26:35.187 --> 00:26:39.727 Library C und in Projekt D verwende ich das. Aber das hat ja erstmal inhärent keinen Zusammenhang. 00:26:41.207 --> 00:26:44.667 Ist das jetzt was für ein Monorepo oder nicht? Weil es mir Ärger macht, 00:26:44.767 --> 00:26:46.847 aber es gehört irgendwie nicht zusammen. Was mache ich denn da? 00:26:48.387 --> 00:26:50.927 Ich wünschte, ich könnte einfach drauf antworten. 00:26:51.007 --> 00:26:53.207 Wenn nicht, dann antwortet kompliziert, nehme ich mir auch gerne. 00:26:55.330 --> 00:26:58.970 Ja, die schwierige Antwort ist wahrscheinlich, wie man arbeiten möchte. 00:26:59.410 --> 00:27:02.730 Denn es wird ja dein Repository nicht interessieren in dem Sinne, 00:27:02.810 --> 00:27:05.130 ob das jetzt wirklich zusammengehört oder nicht. 00:27:05.510 --> 00:27:10.650 Das interessiert auch meinen Bild, also ich meine jetzt so ein Picture, so Fotos. 00:27:10.730 --> 00:27:15.050 Es interessiert auch meinen Fotoordner nicht, ob ich da meine Hochzeit und sonst 00:27:15.050 --> 00:27:16.330 was zusammengeschmissen habe. 00:27:16.950 --> 00:27:20.070 Wenn ich die lieber zusammen anschaue, dann schaue ich die in einem Folder an. 00:27:20.150 --> 00:27:22.610 Und wenn ich sie lieber in Subdirectories mache, dann mache ich sie lieber in 00:27:22.610 --> 00:27:24.150 Subdirectories und suche dann die durch. 00:27:24.730 --> 00:27:28.310 Ich wollte nur den einen Punkt noch sagen, die Situation, wenn ich lieber zu 00:27:28.310 --> 00:27:34.530 einem Monorepo raten würde, wäre die, wenn man sonst sehr viel Hickhack machen 00:27:34.530 --> 00:27:38.150 muss, um die Dependencies zusammen zu testen. 00:27:38.310 --> 00:27:44.570 Also, wenn ich ein Repository habe über eine UI-Library, dann sollte ich die 00:27:44.570 --> 00:27:48.070 irgendwie, die UI-Library ja einfach so entwickeln können, indem ich da meine 00:27:48.070 --> 00:27:49.370 Button und meine Boxen mache. 00:27:50.090 --> 00:27:55.690 Wenn ich jetzt aber so entwickeln muss, dass ich gar nicht unbedingt den Button 00:27:55.690 --> 00:27:59.090 jetzt implementieren muss, sondern eigentlich einen kompletten Flow und paar 00:27:59.090 --> 00:28:04.430 Seiten und da in diesem Programmierschritt muss ich eben auch noch den Button dafür schreiben, 00:28:04.690 --> 00:28:09.470 dann habe ich das schon erlebt, dass man dann mit NPM-Links oder wie das heißt 00:28:09.470 --> 00:28:13.430 oder Sim-Links irgendwie anfange, auf die Dateien dazu zu greifen. 00:28:13.430 --> 00:28:17.290 Das funktioniert aber eben auch nicht immer glorreich oder muss eingestellt 00:28:17.290 --> 00:28:18.530 werden und dann geht es wieder kaputt, 00:28:18.730 --> 00:28:22.950 dann wird halt auch einfach mal das HTML rüberkopiert oder sowas und dann wird 00:28:22.950 --> 00:28:28.690 halt die Button-Komponente doch wieder in dem eigentlichen Main-Repo implementiert 00:28:28.690 --> 00:28:34.950 und muss dann irgendwann wieder in das UI-Bibliotheken-Repository umgezogen werden. 00:28:34.950 --> 00:28:39.670 Und wenn das einfach mental von dem Workflow her zu Problemen führt, 00:28:39.750 --> 00:28:43.290 weil man einfach von den Projekten her nicht so entwickelt, dass man sagt, 00:28:43.390 --> 00:28:45.830 ich möchte diesen Button bauen, da, ich habe mein Ticket für meinen Button, 00:28:45.950 --> 00:28:48.490 da, da, da, da, da, Button gebaut, okay, jetzt kann ich den Flow bauen. 00:28:49.170 --> 00:28:51.810 Wenn das einfach nicht zusammenpasst, dann würde ich es vielleicht so entscheiden 00:28:51.810 --> 00:28:55.330 zu sagen, da ist jetzt ein Monorepo besser und in dem Fall, wenn man anders 00:28:55.330 --> 00:28:57.350 entwickeln möchte, ist vielleicht ein Multirepo besser. 00:28:59.808 --> 00:29:04.848 Ja, aber ich meine, bei mir ist es ja noch so, dass die sozusagen Schritte in 00:29:04.848 --> 00:29:08.208 so einer Pipeline wirklich keinerlei inhaltlichen Zusammenhang haben. 00:29:08.328 --> 00:29:11.688 Es ist halt nur so, dass alle Dinge, an denen ich schraube, sich halt in einen 00:29:11.688 --> 00:29:14.328 Graphen sozusagen einpflegen. 00:29:14.968 --> 00:29:18.408 Weißt du, ich könnte jetzt theoretisch das Monorepo, das reicht das für Peper aufmachen. 00:29:18.628 --> 00:29:22.508 Und das wäre halt noch so eine semantisch sinnvolle Grenze. Aber ansonsten hängt 00:29:22.508 --> 00:29:26.088 der Kram da drin irgendwie nicht zusammen, weswegen ich da so ein bisschen einfach 00:29:26.088 --> 00:29:29.388 so eine semantische Aversion verspüre, das zu machen. 00:29:29.648 --> 00:29:32.288 Das Leben würde halt sehr viel leichter werden, weil also ich habe halt irgendwie 00:29:32.288 --> 00:29:35.468 so ein Ding, das macht was. Und dann gibt es dieses Ding, was das macht. 00:29:35.788 --> 00:29:41.248 Das hat dann, keine Ahnung, was das dieses Ding in Markdown noch so verarbeitet. 00:29:41.288 --> 00:29:44.908 Das ist dann so ein Markdown-Parser-Plugin. und dann will ich dieses Markdown-Parser-Plugin 00:29:44.908 --> 00:29:50.048 in der Präsentationssoftware verwenden, damit man da via Markdown das ursprüngliche Ding drin hat. 00:29:50.708 --> 00:29:54.968 Und natürlich sollte das so sein, dass das einfach einander einfach so verwendet 00:29:54.968 --> 00:29:57.028 und einbaut, aber wir wissen, wie das in der Realität ist. 00:29:57.308 --> 00:30:01.968 Ich habe einen Use Case und um halt sozusagen Upstream auch alles bereitzustellen, 00:30:02.048 --> 00:30:06.628 um den Use Case zu bedienen, muss ich ja sozusagen in jedem dieser Dinge auf 00:30:06.628 --> 00:30:08.948 die ganzen Dinge stoßen, die nicht funktionieren, 00:30:09.268 --> 00:30:10.888 damit ich die dann wieder Upstream 00:30:10.888 --> 00:30:13.588 sagen kann, ey, da muss jetzt hier der Markdown-Parser angepasst werden. 00:30:13.908 --> 00:30:16.748 Yo, dazu brauche ich aber diese extra Option in dem Wurzelding. 00:30:17.668 --> 00:30:20.228 Und das ist halt das, was mir im Moment halt einfach extrem viel Zeit traut, 00:30:20.308 --> 00:30:22.908 weil dann mache ich halt genau diesen Krempel hin und her linken und dann bin 00:30:22.908 --> 00:30:24.928 ich am Laptop und dann radle ich ins Büro. 00:30:25.028 --> 00:30:26.588 Ist ein anderer Computer, habe ich das da auch schon gelinkt? 00:30:26.708 --> 00:30:28.408 Nee, aber das merke ich erst nach zehn Minuten. 00:30:28.728 --> 00:30:32.328 Und das ist halt einfach super, super lästig. Aber es hängt halt an sich nicht zusammen. 00:30:35.148 --> 00:30:39.648 So, das ist so mein Ding. Es ist halt einfach nur mein persönlicher Werkzeugkoffer. 00:30:40.368 --> 00:30:43.388 Und ich habe extrem die Schmerzen, die Monorepos lösen würden, 00:30:43.568 --> 00:30:47.468 aber ich kann doch nicht dann einfach sagen, mein Werkzeugkoffer ist einfach 00:30:47.468 --> 00:30:51.308 ein so ein gewaltiges Repository oder Projekt oder so, gefühlt. 00:30:51.548 --> 00:30:53.508 Das hat ja alles nichts mehr dazu zu tun. Das ist halt einfach nur Kram. 00:30:53.568 --> 00:30:56.448 Ja, der Nachteil davon ist natürlich so ein bisschen von der Code-History, 00:30:56.548 --> 00:31:01.128 weil du hast ja dann eine Commit-History für deine zehn verschiedenen Tools da drin. 00:31:01.428 --> 00:31:01.908 Ja, gut. 00:31:03.448 --> 00:31:07.348 Ich versuche jetzt gerade mal den Nachteil davon zu finden, dass das alles so eine Monorepo liegt. 00:31:08.128 --> 00:31:10.348 Das gehört halt nicht zusammen. Ich finde das eigentlich ganz cool. 00:31:10.368 --> 00:31:13.788 Ja, es gehört nicht zusammen. Aber das ist ja gerade nur so ein mentales Problem. 00:31:14.188 --> 00:31:18.368 Oder ist es ein Problem, wenn du die Systeme startest? Ist da irgendwas langsam? 00:31:18.848 --> 00:31:22.088 Nö, aber zum Beispiel so Sachen wie Teile davon will ich halt gerne in GitHub 00:31:22.088 --> 00:31:24.868 so als Open-Source-Ding rumliegen haben und andere Sachen sollen privat bleiben. 00:31:25.728 --> 00:31:26.228 Ja, gut. 00:31:28.268 --> 00:31:31.748 Aber durch meine spezifische Realitätslinse betrachtet ist das schon alles eins. 00:31:35.151 --> 00:31:39.931 Und deswegen, alle zwei Wochen denke ich so, Monorepo, lass mal lesen, was dieses Tool so tut. 00:31:40.071 --> 00:31:42.951 Und dann merke ich halt relativ schnell, das passt auf mich nicht so ganz, 00:31:43.071 --> 00:31:44.871 dann vergesse ich wieder für zwei Wochen und dann wieder von vorne. 00:31:45.431 --> 00:31:47.731 Ich wollte auch gerade sagen, ich habe deinen Fall eigentlich noch nie gehört. 00:31:48.451 --> 00:31:52.211 Ich kenne eigentlich schon wirklich nur den Fall, dass halt eben alles zusammen gehört. 00:31:52.531 --> 00:31:55.711 Nur, dass wenn man das zusammen in einem Repository liegen hat, 00:31:56.131 --> 00:31:59.791 zum Beispiel die Build-Time oder von deinem Development-Server, 00:31:59.871 --> 00:32:03.271 das ist einfach viel zu lange, Dauer zu starten und du möchtest halt schon eigentlich 00:32:03.271 --> 00:32:05.031 nur deinen Teilbereich davon starten. 00:32:05.031 --> 00:32:08.111 Und nicht die komplette Amazon-Webseite, so nach dem Motto. 00:32:08.911 --> 00:32:12.111 Und dann musst du vielleicht anfangen, dir zu überlegen, ob du jetzt Multi-Repo 00:32:12.111 --> 00:32:15.251 machst oder ob du verschiedene Mono-Repo-Tools ausprobierst, 00:32:15.351 --> 00:32:18.631 wie sie hier genannt werden, wie Rush, Turbo, Repo, Yarn, Workspaces, etc. 00:32:19.051 --> 00:32:20.191 Ja, ich habe auch schon drüber nachgedacht. 00:32:20.211 --> 00:32:21.951 Dein Use Case ist eigentlich total neu. Das ist ja spannend. 00:32:22.331 --> 00:32:24.471 Ich habe auch gedacht, man könnte vielleicht mehrere Mono-Repos haben. 00:32:25.111 --> 00:32:29.031 Aber dann habe ich sozusagen ja auch noch einen Zerfall in sich drin. 00:32:30.331 --> 00:32:32.611 Ja, Multi-Mono-Repo, warum nicht? Kannst du ja haben irgendwie so. 00:32:32.611 --> 00:32:35.911 Monorepo öffentlich, Monorepo privat zum Beispiel. 00:32:37.171 --> 00:32:40.491 Wäre jetzt nicht die beknackteste Idee, aber ist trotzdem beknackt. 00:32:41.891 --> 00:32:44.531 Ich habe auch ein bisschen eine Meinung zu dem Monorepo-Ding. 00:32:45.271 --> 00:32:46.251 Ja, hau raus. 00:32:46.931 --> 00:32:49.571 Hau raus, ich lehne mich mal zurück. 00:32:51.791 --> 00:32:56.751 Ich glaube, es ist technische Lösung für ein Organisationsthema. 00:32:57.791 --> 00:32:58.471 Ja gut. 00:32:59.171 --> 00:33:04.051 Das ist mein Take daran. Also was wollen wir denn mit Monorepos lösen? 00:33:04.371 --> 00:33:11.991 Wir wollen versuchen, dass mehrere Teams miteinander an dem gleichen Stück Software arbeiten können. 00:33:13.271 --> 00:33:19.751 Und das ist der große Selling Point von vielen dieser Dingen hier. 00:33:19.751 --> 00:33:26.791 Ich meine, Sachen wie Package-Manager-bezogene Workspaces, die haben meiner 00:33:26.791 --> 00:33:27.651 Meinung nach einen Sinn, dass 00:33:27.651 --> 00:33:32.451 man irgendwie Dependencies innerhalb einer Software sauber managen kann. 00:33:32.611 --> 00:33:34.671 Also Cross-Dependencies von der eigenen geschriebenen Software, 00:33:34.731 --> 00:33:36.911 das funktioniert in anderen Programmiersprachen auch ganz gut. 00:33:37.631 --> 00:33:42.571 Ich glaube, in .NET diese Solutions, es gibt Cargo-Workspaces in Rust und so weiter. 00:33:43.031 --> 00:33:48.391 Und um die eigene Software ein bisschen einfacher zu strukturieren und Cross-Referenzen 00:33:48.391 --> 00:33:49.591 einfacher zu machen, ist das super. 00:33:49.751 --> 00:33:58.151 Dinge, die da rausfallen, wie Turbo Repo oder NX, die haben ja den großen Anspruch, 00:33:59.271 --> 00:34:10.711 inkrementelle Updates von großen Softwareprojekten ermöglichen zu können. 00:34:10.711 --> 00:34:16.151 Das heißt, du kannst ja ein Submodul in deinem NX-Projekt entwickeln, 00:34:16.351 --> 00:34:20.671 bauen, shippen und das funktioniert nachher super gut mit allen anderen Modulen, 00:34:20.751 --> 00:34:22.871 die du auch verwendest. Und. 00:34:24.169 --> 00:34:29.229 Das ist für mich ein Conway. Das ist für mich ganz klar einfach nur ein technisches 00:34:29.229 --> 00:34:34.489 Tool, um irgendwie zu schauen, dass viele, viele Leute in einer gewissen Organisationsstruktur 00:34:34.489 --> 00:34:35.389 miteinander arbeiten können. 00:34:35.529 --> 00:34:38.649 Und wenn du diese Organisationsstruktur nicht hast, brauchst du es auch nicht. 00:34:39.149 --> 00:34:41.509 Aber jetzt hat Vanessa doch gerade noch andere Probleme erwähnt, 00:34:41.589 --> 00:34:45.969 die das lösen kann, wie zum Beispiel, dass ich die ganze Amazon-Webseite hochfahren 00:34:45.969 --> 00:34:48.689 muss, um was zu testen, was ja vielleicht nicht der Fall wäre, 00:34:48.749 --> 00:34:52.609 wenn das irgendwie entsprechend modularisiert wäre. Habe ich das richtig verstanden? 00:34:52.609 --> 00:34:56.169 Muss man auch nicht. Das ist eigentlich auch, auch das ist eigentlich unabhängig 00:34:56.169 --> 00:34:59.909 davon, ob es in einer Monorepo liegt, das einfach nur ein Monorepo ist oder 00:34:59.909 --> 00:35:03.669 ein Monorepo liegt, das ein Turporepo ist oder ein Multirepo liegt. 00:35:03.949 --> 00:35:07.569 Du kannst ja auch mit, ich weiß es von Webpack, deswegen sage ich jetzt Webpack, 00:35:07.789 --> 00:35:11.429 du kannst ja auch in Webpack konfigurieren, dass du, wenn du NPM Start oder 00:35:11.429 --> 00:35:16.669 sonst was schreibst, dass du eine Reihe an Values mitgeben möchtest, 00:35:16.849 --> 00:35:20.049 welche Bereiche du davon jetzt eigentlich hofern möchtest und welche du einfach 00:35:20.049 --> 00:35:22.589 aus dem Cache laden möchtest oder welche du gar nicht laden möchtest. 00:35:22.609 --> 00:35:24.209 Möchtest, weil du jetzt gar nicht drauf zugreifst. 00:35:24.769 --> 00:35:27.469 Dann geht halt vielleicht auch mal wieder ein bisschen was kaputt, 00:35:27.589 --> 00:35:31.549 wie A, dann ist das CSS nicht richtig geladen oder irgendwas ist dann nicht 00:35:31.549 --> 00:35:37.129 mit Hot Module Replacement gemacht, aber dann stirbt man halt den Tod ein bisschen, 00:35:37.289 --> 00:35:41.389 muss dann halt vielleicht mal ganz altertümlich Command-R auf der Seite drücken oder F5, 00:35:41.949 --> 00:35:45.709 damit die Seite neu lädt und das neue CSS jetzt da ist, muss mich damit aber 00:35:45.709 --> 00:35:49.509 eben nicht mit einem Tool dafür auseinandersetzen, dass mir das irgendwie auf 00:35:49.509 --> 00:35:50.969 magische Weise gelöst hätte. 00:35:51.649 --> 00:35:55.249 Ich glaube auch, das sind Benefits, die mit einem Monorepo mitkommen, 00:35:55.849 --> 00:35:57.429 dass du dann auch solche Dinge machen kannst. 00:35:58.549 --> 00:36:05.569 Aber warum es Monorepos grundsätzlich gibt, ist halt, wie gesagt, viele Köche, viel Brei. 00:36:06.869 --> 00:36:09.089 Ja, und dann genau dieses zusätzliche, nicht nur viele Köche, 00:36:09.229 --> 00:36:13.709 viel Brei, sondern ich finde, es kommt eine gewisse Komplexität dazu, 00:36:14.009 --> 00:36:18.789 wenn du als nur eine Köchin bei mehreren Küchen was machen musst. 00:36:18.789 --> 00:36:23.569 Was bei mir sehr, seit vielen Jahren eben der Fall ist, immer mit dieser UI-Bibliothekenarbeit, 00:36:23.689 --> 00:36:26.349 dass ich da irgendwie in drei Repos so durchhüpfen muss. 00:36:26.969 --> 00:36:31.629 Und bei GitLab bin ich ja auch im Designsystem. Was wir aufgezogen haben mit 00:36:31.629 --> 00:36:36.009 manueller, nicht automatisierter Arbeit oder so halb automatisierter dann, 00:36:36.209 --> 00:36:38.009 ist, dass wir eine Liste haben an, 00:36:38.589 --> 00:36:43.129 wenn wir was in diesem Repository ändern, in welchen anderen Repositories mussten 00:36:43.129 --> 00:36:46.169 wir das überprüfen, ob das da Änderungen ergibt. 00:36:46.169 --> 00:36:49.709 Natürlich schreiben wir alle Conventional Commit Messages und wir schreiben 00:36:49.709 --> 00:36:53.229 da rein, Obacht, das hätte jetzt vielleicht diesen Breaking Change. 00:36:53.549 --> 00:36:57.169 Trotzdem gehen wir noch zusätzlich den proaktiven Schritt zu sagen, 00:36:57.369 --> 00:37:00.389 wir haben jetzt diese Komponente verändert auf eine Breaking Change Art und 00:37:00.389 --> 00:37:02.729 Weise und leider kann ein Breaking Change 00:37:03.716 --> 00:37:06.136 Sehr, sehr klein auch einfach sein, ist trotzdem ein Breaking Change, 00:37:06.196 --> 00:37:08.956 wenn ich die Property umbenenne, die vielleicht niemand benutzt, 00:37:09.136 --> 00:37:12.436 ist aber egal, ich hab irgendwas von der API geändert von IO, 00:37:13.316 --> 00:37:16.476 dann muss ich durch fünf andere Repositories mal kurz durchgucken, 00:37:16.856 --> 00:37:19.396 ob da denn jemand diese Property verwendet hat. 00:37:19.696 --> 00:37:23.556 Was ich nicht durchgucken kann, ist, ob gerade ein offener Merge-Request zum 00:37:23.556 --> 00:37:27.356 Code-Review vorliegt, wo jetzt jemand plötzlich eine Property verwendet, 00:37:27.436 --> 00:37:28.816 die noch nie jemand davor verwendet 00:37:28.816 --> 00:37:30.896 hatte und ich deswegen einfach diesen Breaking Change machen kann. 00:37:31.476 --> 00:37:34.336 Und deswegen brauchst du im Endeffekt halt einfach sehr, sehr gutes Testing 00:37:34.336 --> 00:37:37.636 oder vielleicht auch nur ein rudimentäres Testing, das dir dann meldet, 00:37:37.756 --> 00:37:40.676 huch, da verwendest du plötzlich eine Property, die gibt's doch jetzt irgendwie gar nicht. 00:37:41.656 --> 00:37:45.616 Deswegen kann's halt ein bisschen schwieriger sein, weil ein Multi-Repo-Ansatz, 00:37:46.536 --> 00:37:51.056 wenn ich da über mehrere Repositories das ausprobieren muss. 00:37:51.236 --> 00:37:53.736 Das ist aber nicht unmöglich. Ich muss ja nur dran denken. 00:37:53.936 --> 00:37:57.516 Und dran denken tue ich dadurch, dass ich beim Code Review ein Template habe, 00:37:57.816 --> 00:38:01.916 wo Checkboxen stehen, wo steht, hast du ein Break-and-Change gemacht, 00:38:02.196 --> 00:38:06.316 in dem Bereich hast du dann diese sieben Repositories mal kurz durchgecheckt. 00:38:06.436 --> 00:38:08.576 Dieser kurz durchgecheckt, das sind ja zehn Minuten. 00:38:09.856 --> 00:38:14.556 Das ist ja in keinem Vergleich zu ich setzte da jetzt ein kompliziertes Monorepo Setup auf. 00:38:15.976 --> 00:38:18.756 Mir ist eigentlich egal, ob man Monorepo oder Multirepo hat. 00:38:18.856 --> 00:38:21.936 Ich muss halt egal, was ich hab, muss ich halt irgendwas special-dashle machen 00:38:21.936 --> 00:38:24.376 und hab ein bisschen mehr Arbeit in irgendeine Richtung. 00:38:24.496 --> 00:38:26.716 Dann sollte man sich halt entscheiden, was mach ich denn lieber. 00:38:26.856 --> 00:38:29.456 Ich mag dieses manuelle Untersuchen, das stört mich gar nicht. 00:38:29.516 --> 00:38:31.916 Das mache ich in 10 Minuten, dann schreibe ich halt, dann mache ich halt das 00:38:31.916 --> 00:38:34.496 Repository, check das aus, dann schreibe ich, oh, übrigens, ich habe schon mal 00:38:34.496 --> 00:38:36.536 ein Break and Change vorbereitet, ich war schon mal so frei, 00:38:36.956 --> 00:38:39.136 ihr könnt das ja merchen, wenn auch immer ihr upgraden wollt. 00:38:39.536 --> 00:38:40.616 Finde das cool, die Vanessa 00:38:41.096 --> 00:38:45.296 Macht jetzt gerade voll den GitLab Sales Pitch, weil du kannst jetzt einfach 00:38:45.296 --> 00:38:48.376 ein Template verwenden, dann kannst du ein Häkchen machen und dann gehst du 00:38:48.376 --> 00:38:51.176 in das andere Repo rein, das geht alles super cool mit GitLab. 00:38:52.396 --> 00:38:52.716 Ja. 00:38:53.056 --> 00:38:55.056 Aber es stimmt, du hast komplett recht, es ist, 00:38:55.893 --> 00:38:58.793 Es ist oft an die Lösungen so einfach. 00:39:00.213 --> 00:39:03.853 Hier nicht entschalten oder vielleicht sich hier und da selbst an gewisse Dinge 00:39:03.853 --> 00:39:05.773 erinnern, hilft schon sehr. 00:39:07.613 --> 00:39:09.193 Es hilft auch ungemein. 00:39:09.253 --> 00:39:13.873 Wenn man dann kein Blaming in der Firma betreibt. Da kann mal was schief gehen. 00:39:13.953 --> 00:39:17.513 Wie gesagt, ich kann einen Breaking Change machen, von dem ich 100% sicher bin, 00:39:17.873 --> 00:39:20.653 dass der nicht wirklich was breaking kann, weil bisher niemand diese Property 00:39:20.653 --> 00:39:23.773 verwendet hat, weil die noch nicht mal dokumentiert war. Aber sie war halt irgendwie 00:39:23.773 --> 00:39:26.453 rein technisch, hat die halt bestanden. 00:39:26.593 --> 00:39:27.973 Und dann kann es immer noch doch 00:39:27.973 --> 00:39:30.573 sein, dass das doch jemand in einem Merch-Request dann aufgemacht hat. 00:39:30.793 --> 00:39:34.233 Und dann irgendwie nach drei Tagen werde ich getaggt und dann kriege ich auch 00:39:34.233 --> 00:39:35.453 mal ein kleines Herzrasen. 00:39:35.493 --> 00:39:37.733 So, Vanessa, du hast doch was geändert. Ich so, oh Gott, oh Gott, 00:39:37.793 --> 00:39:38.873 was habe ich gewohnt gemacht? 00:39:39.253 --> 00:39:41.313 Und dann gehe ich halt da rein. Ach so, ja, und dann sage ich, 00:39:41.353 --> 00:39:42.153 das war der Breaking Change. 00:39:42.313 --> 00:39:44.913 Und es ist halt schon alles sehr viel einfacher, wenn es dann dokumentiert ist, 00:39:44.973 --> 00:39:47.493 wenn ich dann einen Link habe zu meinem Breaking Change, das ist der bla bla bla. 00:39:48.093 --> 00:39:51.073 Und dann sagt die Person, ach cool, danke, dann weiß ich Bescheid. 00:39:51.073 --> 00:39:52.833 Dann benutze ich jetzt die andere Property. 00:39:53.053 --> 00:39:55.993 Wenn ich jetzt in Teams arbeite, wo das dann wirklich heißt, 00:39:56.433 --> 00:40:00.193 entschuldigen Sie hier C-Level, die Vanessa, die hat da, ja, 00:40:00.313 --> 00:40:02.093 deswegen habe ich hier wieder mehr Arbeit, 00:40:02.413 --> 00:40:05.193 dann ist das vielleicht unangenehm und dann braucht man vielleicht technische 00:40:05.193 --> 00:40:08.073 Lösungen, wie Stefan, du es schon so häufig heute auch gesagt hast, 00:40:08.113 --> 00:40:11.713 dann braucht man vielleicht leider technische Lösungen für Organisationslösungen. 00:40:11.973 --> 00:40:15.073 Ich hätte halt immer so ein bisschen mehr vielleicht eher so die organisatorische 00:40:15.073 --> 00:40:17.433 Lösung, bevor ich mir die technische da irgendwie holen muss. 00:40:17.433 --> 00:40:21.933 Ich glaube, dass das ja auch ein bisschen eine Möglichkeit es ist, dass sie Firmen, 00:40:23.152 --> 00:40:28.452 Und selbst einreden, an einer Lösung zu arbeiten für irgendwelche Kommunikationsprobleme, 00:40:28.492 --> 00:40:31.152 die so in der Firmenstruktur herrschen, weil tatsächlich ist es bei einer gewissen 00:40:31.152 --> 00:40:37.672 Größe auch schwierig, eine Firmenstruktur zu ändern oder eine Organisationsstruktur zu ändern. 00:40:38.152 --> 00:40:45.352 Also von dem her, dieses Wechselspiel zwischen Softwarearchitektur und Firmenorganisation, 00:40:45.592 --> 00:40:50.612 das ist ja schwierig und das ist ja sehr, sehr delikat in der Umsetzung. 00:40:50.712 --> 00:40:53.292 Von dem her, verstehe ich das, dass Teams dann sagen, hey cool, 00:40:53.332 --> 00:40:56.092 da gibt es eine Lösung, das löst zumindest einmal 90% unserer Probleme. 00:40:56.512 --> 00:40:59.732 Wie immer kaufst du halt damit irgendwelche anderen Probleme oder Meinungen 00:40:59.732 --> 00:41:04.532 ein, mit denen musst du halt rechnen und von dem her ist das halt auch legitim. 00:41:04.532 --> 00:41:08.292 Wir haben viel Monorepo-Tools ausprobiert. 00:41:08.432 --> 00:41:11.992 Wir haben auch NX in einigen unserer Projekte drinnen. 00:41:12.912 --> 00:41:18.012 Das ist ja immer so dieses vorherrschende Monorepo-Tool. Ich bin sehr skeptisch, 00:41:18.072 --> 00:41:21.732 was das Ding angeht, weil die Probleme, die du dir einkaufst, 00:41:21.932 --> 00:41:25.132 sind teilweise sehr, sehr groß oder die Schwierigkeiten, die du dir einkaufst, 00:41:25.232 --> 00:41:27.392 sind sehr, sehr groß oder zumindest zeitfressend. 00:41:27.392 --> 00:41:31.472 Wir haben gesehen, dass wenn zwei oder mehrere Teams versuchen, 00:41:31.692 --> 00:41:34.832 Software zu konsolidieren über ein Monorepo, das auf Nix-Basis ist, 00:41:35.352 --> 00:41:40.712 kannst du mindestens eine Person pro Jahr abstellen dafür, um das Monorepo am 00:41:40.712 --> 00:41:43.472 Leben zu erhalten. Das ist heftig. 00:41:44.112 --> 00:41:49.572 Die Lösung dafür ist, wenn du nicht eine Person abstellen möchtest dafür, 00:41:49.952 --> 00:41:52.032 mindestens eine Person abstellen möchtest dafür, 00:41:52.432 --> 00:41:56.472 ist, dass du den Bezahldienst von NX verwendest, die halt viele Dinge in der 00:41:56.472 --> 00:42:01.252 Cloud bei denen lösen, wo wir wieder bei dem gleichen Punkt sind wie bei meinem 00:42:01.252 --> 00:42:05.772 Vasell-Rent vor einer oder zwei Episoden. Naja, das ist halt aber das Bezahlmodell. 00:42:05.832 --> 00:42:08.112 Sie geben dir ein cooles Tool, das funktioniert in vielen Fällen. 00:42:08.892 --> 00:42:12.692 Wenn du aber gewisse Investments nicht tätigen willst, musst du halt dann das 00:42:12.692 --> 00:42:14.752 Ding bezahlen und irgendwie wollen sie auch, 00:42:15.896 --> 00:42:19.816 ihr eigenes Produkt finanzieren wird. Und ja, 00:42:20.516 --> 00:42:25.676 wir haben tatsächlich in dem, das ist jetzt ein bisschen ironisch, 00:42:26.056 --> 00:42:28.376 wir haben in dem letzten Projekt, in dem wir drinnen waren, haben wir versucht, 00:42:28.516 --> 00:42:32.096 diese Monorepo-Diskussion über Softwarearchitektur zu lösen. 00:42:32.276 --> 00:42:35.956 Da haben wir tatsächlich versucht, eine Architektur zu definieren und nachher 00:42:35.956 --> 00:42:37.616 die Organisation danach zu schneiden. 00:42:39.116 --> 00:42:41.536 Wir schreiben, glaube ich habe eh schon mal erzählt davon, wir schreiben lauter 00:42:41.536 --> 00:42:44.396 kleine Apps und diese Apps hängen wir in so eine App-Shell rein. 00:42:44.396 --> 00:42:51.436 Die App-Shell ist iFrame-basiert, aus dem Grund, dass wir uns nicht auf eine 00:42:51.436 --> 00:42:52.636 Technologie fixieren wollen. 00:42:53.796 --> 00:42:57.156 Diese Lademechanismen, wie wir diese Apps laden, wie der Lifecycle dieser App 00:42:57.156 --> 00:42:59.376 ist, wie Aktualisierungen stattfinden, 00:42:59.836 --> 00:43:02.596 ist alles in plain JavaScript geschrieben, da ist kein Framework dahinter, 00:43:02.696 --> 00:43:05.676 das ist unser langlebiger Teil und du kannst noch React, Angular, 00:43:05.856 --> 00:43:08.956 Fuse, Welt, was auch immer verwenden, dass du dich in dieses Framework reinhängst 00:43:08.956 --> 00:43:12.356 und die UI schreibst, die du willst mit Design-Tokens aus einem Design-System, 00:43:12.476 --> 00:43:14.176 damit alles irgendwie halbwegs gleich ausschaut. 00:43:14.796 --> 00:43:17.616 Meistens von unserer Sachen ist React passiert, aber ein Großteil davon auch 00:43:17.616 --> 00:43:19.836 noch Angular passiert, den wir halt einfach neu angemalt haben. 00:43:20.476 --> 00:43:23.876 Funktioniert irrsinnig gut und hat bis zu einem gewissen Grad auch funktioniert. 00:43:24.376 --> 00:43:28.756 Jetzt kommen halt Teams drauf, ja, aber irgendwie haben wir doch jetzt Dinge, die wir teilen wollen. 00:43:28.836 --> 00:43:30.956 Wir wollen nicht immer alles neu schreiben zwischen den einzelnen Apps, 00:43:31.096 --> 00:43:35.596 auch, dass wir Konsistenz behalten und dass die Apps alle irgendwie aus dem 00:43:35.596 --> 00:43:37.796 gleichen Guss wirken. Na, jetzt machen sie wieder ein Monorepo. 00:43:38.956 --> 00:43:44.356 Jetzt sind wir wieder dort angelangt Und ich weiß noch nicht, wie wir das lösen. 00:43:44.436 --> 00:43:47.616 Also ich bin sehr dagegen, weil ich weiß, was das für Aufwand ist. 00:43:47.996 --> 00:43:50.076 Gerade wenn es darum geht, dass wir ein Monorepo haben, das von, 00:43:50.576 --> 00:43:53.536 also wir haben ja da mehrere Monorepos, es schließen sich ja immer so zwei, 00:43:53.636 --> 00:43:55.616 drei Teams zusammen und machen das dann. 00:43:55.736 --> 00:43:58.876 Das heißt, du hast dann in jedem dieser Dreierteams-Konstellationen hast du 00:43:58.876 --> 00:44:01.456 ein, zwei Leute, die sich nur um Bild und Repo kümmern. 00:44:02.516 --> 00:44:05.336 Das finde ich das falsche Investment. Deswegen habe ich jetzt noch keine Lösung, 00:44:05.376 --> 00:44:06.296 wie man das eigentlich angeht. 00:44:06.696 --> 00:44:11.236 Warte mal, warte mal. Das war jetzt so, dass ihr habt eine Architektur definiert, 00:44:11.236 --> 00:44:16.716 dann nach eurer Organisation definiert und das lief so lange bis eine Anforderung rein kam. 00:44:16.716 --> 00:44:17.296 Das lief jetzt vier Jahre gut. 00:44:17.576 --> 00:44:19.096 Genau, dann kam diese Anforderung rein. 00:44:21.016 --> 00:44:27.436 Dann sind wir, na was ist passiert? Wir sind überrascht worden von der Anzahl 00:44:27.436 --> 00:44:29.936 an Teams, die nachher wirklich tatsächlich mit unserer Architektur arbeiten. 00:44:30.096 --> 00:44:32.756 Das heißt, das was wir erreichen wollten mit dieser Architektur, 00:44:32.836 --> 00:44:38.176 dass Teams unabhängig zu unserer Plattform kontributen können und Apps schreiben 00:44:38.176 --> 00:44:42.756 können, Komplett isoliert, komplett ohne Rücksicht auf irgendwelche anderen Teams, 00:44:43.176 --> 00:44:46.176 indem wir ein Designsystem zur Verfügung stellen, diese App-Shield zur Verfügung 00:44:46.176 --> 00:44:51.056 stellen und sagen, ihr könnt dort mit den Tools, die wir euch geben, 00:44:51.616 --> 00:44:53.396 zu 100% alles erreichen, was ihr wollt. 00:44:53.536 --> 00:44:57.496 Das hat so gut funktioniert, dass wir von den prognostizierten Teams zehnmal 00:44:57.496 --> 00:44:59.796 mehr Teams jetzt haben, als wir eigentlich gedacht haben. 00:44:59.976 --> 00:45:04.436 Und die versuchen jetzt untereinander in diesen Teilorganisationen wieder Code 00:45:04.436 --> 00:45:08.996 zu teilen. Das heißt, unser Ansatz war so erfolgreich, 00:45:10.297 --> 00:45:15.657 dass wir schneller gewachsen sind als erwartet haben und jetzt Probleme im Detail 00:45:15.657 --> 00:45:16.977 auftauchen, an denen wir heute noch nicht gedacht haben. 00:45:18.077 --> 00:45:22.757 Ja, aber dann müsste man ja doch theoretisch die Architektur und die damit zusammengehängende 00:45:22.757 --> 00:45:26.517 Organisationsstruktur an die neue Skalierung anpassen. 00:45:27.217 --> 00:45:27.697 Ja, genau. 00:45:27.857 --> 00:45:31.017 Oder? Und das ist jetzt nicht passiert, wenn ich das richtig verstanden habe. 00:45:31.157 --> 00:45:33.477 Das ist noch nicht passiert, genau. Das ist gerade mein großes Problem. 00:45:33.817 --> 00:45:35.237 Ja, dann knirscht es natürlich. Das macht Sinn. 00:45:35.677 --> 00:45:35.817 Ja. 00:45:36.277 --> 00:45:39.417 Weil an sich schien es ja zu funktionieren. Man muss halt nur, 00:45:39.537 --> 00:45:43.317 wer sagt, muss auch die sagen und dann halt eben auch die Organisationsstruktur 00:45:43.317 --> 00:45:44.457 maintainen, so wie die Software. 00:45:45.457 --> 00:45:47.777 Damit ich es einmal an einem konkreten Beispiel festhorte. Wir haben ja gesagt, 00:45:47.937 --> 00:45:51.157 wir stellen ein Designsystem zur Verfügung, das hat unterschiedliche Ebenen. 00:45:51.217 --> 00:45:54.657 Da geht es darum, dass wir nicht nur einzelne Kontrolls oder Komponenten schreiben, 00:45:54.817 --> 00:45:57.817 sondern auch jetzt zum Beispiel ein Document Viewer, der schon Backend-Anbindung 00:45:57.817 --> 00:46:00.577 hat, wo du jetzt sagen kannst, ich lade ein Dokument in meiner App. 00:46:01.897 --> 00:46:06.117 Die Reihenfolge, wie das mit der Backend-API kommuniziert, ist gegeben. 00:46:06.117 --> 00:46:09.137 Gewisse Workflows zum Teilen dieses Dokumentes sind schon gegeben, 00:46:09.217 --> 00:46:15.477 du sagst einfach nur, das ist mein Document Viewer, da hast du deinen Dokumenttyp 00:46:15.477 --> 00:46:19.397 mit deiner App-ID, damit du das auch filtern kannst und dann funktioniert das. 00:46:19.757 --> 00:46:24.997 Also so weit gehen wir im Design-System, dass wir sogar solche High-Level-Components bereitstellen. 00:46:25.257 --> 00:46:28.437 Und das funktioniert auch gut, wenn du das auf einer gewissen Abstraktionsebene 00:46:28.437 --> 00:46:31.837 behältst. Aber dann gibt es zum Beispiel das Team Application Observability. 00:46:31.997 --> 00:46:34.857 Das sind drei, vier Teams, die arbeiten alle an dem Problem, 00:46:34.857 --> 00:46:42.357 wie kann ich meine Application gut observen, monitoren, Informationen rauskriegen. 00:46:42.417 --> 00:46:46.757 Da sind sehr, sehr viele Patterns drinnen, die gleich sind, egal ob du jetzt 00:46:46.757 --> 00:46:51.737 in Real-User-Monitoring bist oder ob du jetzt im Backend gewisse Call-Graphs 00:46:51.737 --> 00:46:55.657 anschaust, da sind sehr, sehr viele visuelle Dinge, die ähnlich sind und Abläufe, die ähnlich sind. 00:46:56.397 --> 00:47:00.217 Es ist irrsinnig schwierig, dieses Spezialwissen in das Design-System zu bringen 00:47:00.217 --> 00:47:01.697 und für alle zur Verfügung zu stellen. 00:47:02.617 --> 00:47:06.277 Was Leute jetzt machen, ist, dass sie quasi so eine Nebenschiene zum Designsystem 00:47:06.277 --> 00:47:11.817 machen, wo sie diese Komponenten teilen für diese vier Apps, die sie kreieren. 00:47:13.317 --> 00:47:16.677 Und es kann gut gehen, es kann auch vielleicht die richtige Lösung jetzt sein 00:47:16.677 --> 00:47:19.517 dafür, weil wir jetzt auf einmal die Knödel, die quasi dranhängen, 00:47:19.597 --> 00:47:21.537 an unserer Architektur größer sehen müssen. 00:47:22.857 --> 00:47:26.637 Ich bin mir aber nicht sicher, ob das das Richtige ist. Und ich lasse das Problem 00:47:26.637 --> 00:47:28.537 jetzt sehr offen. Ich bin halt einfach skeptisch. 00:47:29.217 --> 00:47:31.677 Aber nachdem ich ja eh schon seit zwei Jahren nur mehr Last mache, 00:47:33.857 --> 00:47:37.517 bin ich ja eigentlich nur der alte Mann, der von der Seite reinschaut und kritisch 00:47:37.517 --> 00:47:38.637 ist. Das ist die beste Rolle. 00:47:40.677 --> 00:47:43.997 Ich wollte noch dazu erwähnen, mit den Multi-Repos ganz andere, 00:47:44.097 --> 00:47:47.297 aber quasi die gleichen Probleme dann geben, die im Endeffekt irgendwie Geld 00:47:47.297 --> 00:47:52.517 kosten oder dass man die Teamstruktur, Organisationsstruktur ein bisschen umstellen muss. 00:47:53.437 --> 00:47:56.477 Wenn zurzeit, das ist natürlich jetzt nicht der Standardfall, 00:47:56.477 --> 00:48:00.457 Aber zurzeit haben wir eben einfach im Design-System bei GitLab relativ viele 00:48:00.457 --> 00:48:04.597 Breaking Changes, weil wir davon, wir stellen da halt was um, anderes Thema. 00:48:05.788 --> 00:48:11.648 Und jetzt arbeiten hier glücklicherweise nicht so viele Personen an diesem Repository. 00:48:11.848 --> 00:48:15.088 Denn wenn jetzt Person 1 einen Breaking Change macht, Person 2 einen Breaking 00:48:15.088 --> 00:48:19.008 Change macht, Person 3 einen Breaking Change macht, dann fängst du an zu diskutieren, 00:48:19.248 --> 00:48:25.288 sollte man diese Breaking Changes zusammenfügen, weil dann hast du nur einen Major-Version-Bump. 00:48:25.488 --> 00:48:29.548 Dann überlegst du dir, was ist denn das Problem an drei Major-Version-Bumps. 00:48:29.688 --> 00:48:32.368 Dann fängst du an zu diskutieren, ist das eigentlich ein Problem, 00:48:32.508 --> 00:48:37.008 wenn wir irgendwann auf Version 100.0.0 laufen oder ist irgendwie 100 so eine magische Grenze. 00:48:37.188 --> 00:48:39.248 Also das sind ja so Diskussionen, die braucht man irgendwann nicht. 00:48:39.308 --> 00:48:40.408 Aber irgendwie fängt dann sowas an. 00:48:40.968 --> 00:48:44.628 Und dann haben wir zum Beispiel einen Breaking Change drin und sagen, 00:48:44.748 --> 00:48:47.608 okay, jetzt möchten wir aber erst in den ganzen Main Repos, die wir haben, 00:48:47.768 --> 00:48:51.248 auf diese Version upgraden, bevor wir wieder einen Breaking Change haben. 00:48:51.388 --> 00:48:56.128 Ansonsten muss ja irgendwie so ein Main Repository sonst mal von Nummer 50 auf 00:48:56.128 --> 00:48:58.148 55 updaten. Und ist das eigentlich ein Problem? 00:48:58.468 --> 00:49:03.188 So, also das sind keine technischen Probleme, aber dann muss man vielleicht 00:49:03.188 --> 00:49:05.408 dann drüber diskutieren, wie man das handhabt. 00:49:05.528 --> 00:49:10.908 Und es ist halt relativ einfach, Hand zu haben, wenn du nur eine gewisse Menge 00:49:10.908 --> 00:49:13.428 an Personen hast, die überhaupt Breaking Changes machen können, 00:49:14.108 --> 00:49:21.108 Sodass du das einfach kurz mal in sonst wo, Issue, Slack, sonst wo mal kurz 00:49:21.108 --> 00:49:23.088 schreiben kannst, wie du es jetzt eigentlich handhaben möchtest. 00:49:23.088 --> 00:49:27.708 Hast du stattdessen eine Struktur, wo du sagst, alle deine Frontend-Developer 00:49:27.708 --> 00:49:31.568 können jederzeit, können sie bei GitLab auch, aber es passiert halt in der Regel 00:49:31.568 --> 00:49:35.788 nicht so häufig, aber ist deine Struktur eher so, dass alle Frontend-Developer 00:49:35.788 --> 00:49:37.188 werden dazu aufgefordert, 00:49:37.628 --> 00:49:42.168 das auch in dem Design-System, Pattern-Library zu machen, und dann hast du da 00:49:42.168 --> 00:49:45.448 50 Frontend-Developer sitzen, die plötzlich alle Breaking Chances machen, 00:49:45.528 --> 00:49:48.228 dann ist es vielleicht nicht der richtige Weg in dem Fall, und dann hast du 00:49:48.228 --> 00:49:49.808 es lieber wieder im Monorepo zusammen. 00:49:49.808 --> 00:49:52.968 Hm. Ich denke mir auch gerade, 00:49:53.328 --> 00:49:57.528 was, glaube ich, mein seltsames Problem lösen könnte, wäre so eine Art temporäres 00:49:57.528 --> 00:50:01.188 Monorepo, dass ich irgendwie so auf den Knopf drücken kann und sagen kann, 00:50:01.308 --> 00:50:05.488 ich habe jetzt hier diese sieben NPM-Packages und ab Knopfdruck machen die alle 00:50:05.488 --> 00:50:06.768 untereinander dieses NPM-Link, 00:50:07.508 --> 00:50:10.768 dass ich die sozusagen als einen Block betrachten kann und dass ich hinterher 00:50:10.768 --> 00:50:13.888 auch auf den Knopf drücken kann, um das temporäre Monorepo wieder aufzuheben. 00:50:13.888 --> 00:50:17.488 Und dann habe ich wieder meine ganzen Einzelpackages für, ich muss halt irgendwie 00:50:17.488 --> 00:50:21.908 super Downstream mal was updaten oder super Upstream einen Bug fixen, 00:50:21.968 --> 00:50:25.108 der halt jetzt nicht mission-critical ist und dann kann ich das halt wieder 00:50:25.108 --> 00:50:27.948 so in meinem normalen Flow da so irgendwie so en passant durchtröpfeln lassen. 00:50:28.208 --> 00:50:30.568 Aber wenn ich jetzt wirklich so ein Feature durchentwickeln will, 00:50:30.648 --> 00:50:34.328 wo halt die ganze Pipeline angefasst werden muss, wenn man dann so einen temporären, 00:50:34.488 --> 00:50:37.088 das gehört jetzt gerade mal zusammen und verhält sich als Vers 1, 00:50:37.608 --> 00:50:39.068 machen könnte und das dann wieder aufheben könnte. 00:50:40.388 --> 00:50:42.928 Das wäre ganz cool, temporäres Monorepo, baue mal einer. 00:50:44.968 --> 00:50:46.468 Bau mal und dann sagst du Bescheid. 00:50:47.308 --> 00:50:50.188 Naja, also im Prinzip muss es ja bloß irgendwie, oh Gott, jetzt hefte ich mir 00:50:50.188 --> 00:50:52.048 das selber an, aber im Prinzip müsste man ja bloß sagen, hier, 00:50:52.108 --> 00:50:56.008 das sind die Folders, da drin sind Package.json, daraus generierst du das entsprechende 00:50:56.008 --> 00:50:58.728 npm-Kommando und dann generierst du halt eben auch das Kommando, 00:50:58.788 --> 00:51:00.428 das das Ganze wieder zurücksetzt. 00:51:01.188 --> 00:51:03.828 Das könnte ja eigentlich bloß ein Script sein. Nein, ich mach das heute nicht. 00:51:04.228 --> 00:51:05.048 Nein, ich muss stark sein. 00:51:07.570 --> 00:51:11.410 Du könntest dir eigentlich mal das JDK anschauen, das GitLab Development Kit. 00:51:12.110 --> 00:51:15.210 Weil das habe ich bei mir im Onboarding gemacht. Dann habe ich mich auch gefragt, 00:51:15.330 --> 00:51:17.630 wie starte ich denn GitLab-Lokal? Das ist ja nicht so klein. 00:51:18.170 --> 00:51:21.330 Und dann hat man mir das JDK gegeben und dann installierst du das und dann läuft 00:51:21.330 --> 00:51:23.570 das. Und ich habe keine Ahnung, ehrlich gesagt, wie. 00:51:24.610 --> 00:51:26.190 Sehr gut, das ist das Beste. 00:51:27.570 --> 00:51:28.950 Das läuft einfach. Aber ist ja cool, 00:51:29.090 --> 00:51:30.510 Oder? Dass das so gut geht. 00:51:30.830 --> 00:51:33.050 Ja, das ist ein beeindruckender. Das schaffen die wenigsten. 00:51:33.990 --> 00:51:34.130 Ja? 00:51:35.510 --> 00:51:39.790 Ich weiß gar nicht, was für eine krasse Brainpower dahinter ist, aber es muss eine sein. 00:51:40.030 --> 00:51:41.550 Ich kann mich an Software erinnern, 00:51:41.710 --> 00:51:45.370 Dass es geheißen, bitte nur den Folder im Root-Director haben, 00:51:45.510 --> 00:51:47.830 ansonsten funktioniert unsere gesamte Bild-Chain nicht. 00:51:48.750 --> 00:51:51.370 Und dann checkst du mal eine Stunde aus und dann kompilierst du mal zwei Stunden 00:51:51.370 --> 00:51:56.530 und dann bitte nie wieder neu compilen, sondern den Super-Development-Button 00:51:56.530 --> 00:52:00.630 in deiner Favoritenliste anklicken, damit das separater Compile-Vorgang losgeht. 00:52:00.730 --> 00:52:03.270 Also das ist die Welt, die ich gesehen habe, nicht vor dem ja cool, 00:52:03.670 --> 00:52:06.950 wenn ich dort einfach so ein Development Kit starte und das geht, saugeil. 00:52:07.150 --> 00:52:09.370 Ja, also mein aktuelles Next.js-Projekt hat auch tatsächlich, 00:52:09.590 --> 00:52:12.570 da habe ich so eine Markdown-Datei, da steht drin, du führst diesen Befehl aus, 00:52:12.630 --> 00:52:15.970 diesen Befehl aus, diesen Befehl aus und diesen Befehl aus und danach kannst du auf die Seite gehen. 00:52:17.850 --> 00:52:19.630 Das ist halt schon arg barbarisch und 00:52:21.710 --> 00:52:24.550 theoretisch könnte man sowas ja auch in ein Skript gießen, damit man dann auch 00:52:24.550 --> 00:52:27.110 so eine Experience hat wie Vanessa. Man drückt auf den Knopf und dann geht's. 00:52:27.750 --> 00:52:30.830 Das ist, glaube ich, Brainpower, ja, aber zum anderen muss sich halt auch jemand 00:52:30.830 --> 00:52:34.210 entscheiden, dass das überhaupt ein Ziel ist, das man hat und das man verfolgen will. 00:52:34.610 --> 00:52:37.110 Und wenn man das dann hat und einmal angefangen hat und einfach so die ersten 00:52:37.110 --> 00:52:39.930 80% erledigt hat, ist der Rest ja bloß Maintenance. Wahrscheinlich. 00:52:41.110 --> 00:52:43.290 Ich glaube, die Welt könnte sehr viel besser sein, wenn mehr Leute sich dazu 00:52:43.290 --> 00:52:44.510 entscheiden würden, es besser zu machen. 00:52:46.631 --> 00:52:49.871 Wenn ihnen die Möglichkeiten gegeben werden. Versus, das muss jetzt gestern 00:52:49.871 --> 00:52:50.711 schon fertig gewesen sein. 00:52:51.751 --> 00:52:54.511 Ja, vor allem ist ja GitLab Open Source. Wir können ja nicht sagen, 00:52:54.551 --> 00:52:57.011 wir hoffen auf Community-Contributions. 00:52:57.411 --> 00:53:03.291 Und hier ist der Setup-Guide, wofür du auf jeden Fall erst mal ein MacBook M3 brauchst. 00:53:03.351 --> 00:53:05.891 Und dann brauchst du drei Directories und musst auf jeden Fall im richtigen 00:53:05.891 --> 00:53:07.611 installieren. Das stimmt. Das kann ich ja nicht machen. 00:53:07.831 --> 00:53:08.771 Das stimmt natürlich. 00:53:10.171 --> 00:53:13.811 Ich bin mal bei den Monorepos zu den Pain-Points runtergescrollt. 00:53:13.811 --> 00:53:18.031 Und wir haben jetzt nicht nur den Pain-Point-Complexity, 00:53:18.151 --> 00:53:23.531 nein, wir haben Excessive-Complexity und irgendwie mit all den anderen Rubriken, 00:53:23.631 --> 00:53:26.811 die wir uns vorher angeschaut haben, würde ich da jetzt irgendwie zustimmen. 00:53:27.471 --> 00:53:34.091 Also Webpack und Veed, die Komplexität klingt ja so klein versus Learner und 00:53:34.091 --> 00:53:35.511 ich kenne die anderen ehrlich gesagt gar nicht. 00:53:35.711 --> 00:53:38.471 Jan Workspaces und danach hat es bei mir auch bald auf, was ich kenne. 00:53:41.111 --> 00:53:47.251 Ich liebe es, dass auf Punkt 4 für die Monorepo-Tools Pain-Points Dependencies 00:53:47.251 --> 00:53:54.271 ist genau das eine Problem des Monorepos lösen sollen ist der viertgrößte Pain-Point, 00:53:54.591 --> 00:53:56.171 ist herrlich also irgendwie. 00:53:56.171 --> 00:54:01.391 Ich finde viel besser 11 und 12, die direkt nebeneinander stehen Choice-Overload und Lack-of-Tools 00:54:05.391 --> 00:54:05.991 Gut, 00:54:06.151 --> 00:54:09.831 Ich würde jetzt mal kurz auf die Bubble draufdrücken, was die Leute eigentlich meinen. 00:54:10.491 --> 00:54:12.411 Nein, nein, nein, nein, die meinen genau das, das ist schön, 00:54:12.471 --> 00:54:13.931 das passt schon so in der Nachricht. 00:54:15.291 --> 00:54:18.271 Ah, wunkelhaft. Ja, ich verstehe es auch gar nicht, es sind so viele verschiedene Nachrichten. 00:54:18.631 --> 00:54:18.751 Ja. 00:54:20.711 --> 00:54:24.591 Naja, und dann gibt es noch 36, ach, Entschuldigung, schon wieder, 00:54:25.671 --> 00:54:30.631 63 Prozent andere Antworten, das heißt, ich glaube, jeder hat irgendwie Probleme 00:54:30.631 --> 00:54:34.671 mit Monorepo-Tools und sie sind einfach sehr groß. 00:54:37.233 --> 00:54:42.433 Ich bin grundsätzlich sehr happy, dass es diese Pain-Points-Listen gibt in dieser 00:54:42.433 --> 00:54:46.833 Umfrage, weil die machen ein bisschen einen Reality-Check, finde ich. 00:54:48.853 --> 00:54:53.333 Man muss schon sehr frustriert sein, um sich den Aufwand anzutun, 00:54:53.453 --> 00:54:54.753 etwas in ein Textfeld zu schreiben. 00:54:57.493 --> 00:55:00.813 Wir reden ja eigentlich nur immer darüber, wie gut Dinge funktionieren. 00:55:00.933 --> 00:55:04.613 Es ist gar nicht so schlecht, dass man einmal sieht, wenn Dinge schlechter funktionieren. 00:55:04.813 --> 00:55:05.953 Also ein riesen Fan davon. 00:55:05.953 --> 00:55:09.313 Ja, und vor allem ist es ja, wenn du sagst, ich habe das Gefühl, 00:55:09.393 --> 00:55:12.493 ich müsste was Eigenes bauen, dann hast du ja quasi deine To-Do-Liste. 00:55:14.093 --> 00:55:16.113 Das ist ja auch schon was wert. 00:55:20.573 --> 00:55:23.833 So, meine Damen und Herren, wollen wir in die Other Tools reinlinsen? 00:55:23.833 --> 00:55:29.673 Ja, und bei den Other Tools, Punkt Nummer 1, haben wir ja Teil 1 schon drüber 00:55:29.673 --> 00:55:32.233 gesprochen, weil hier kommt gleich mal Lodash. 00:55:32.473 --> 00:55:37.893 Würde ich mal sagen, wir verweisen zurück auf die 655, irgendwas, 00:55:38.433 --> 00:55:45.213 auf die State of JS Teil 1 zumindest, wo wir schon Lodash ausgiebig besprochen haben. 00:55:45.533 --> 00:55:47.953 Was ich tatsächlich gemerkt habe letztens, das hatte ich glaube ich da gar nicht 00:55:47.953 --> 00:55:51.133 erwähnt. Ich habe auch mal so rumgefragt bei irgendwie so Leuten, 00:55:51.193 --> 00:55:53.253 die in meinen Workshop sitzen, warum habt ihr Lodash noch am Start? 00:55:53.873 --> 00:55:57.033 Die meisten verwenden da wirklich nur so ein, zwei Funktionen draus. 00:55:58.133 --> 00:56:00.293 So Sachen wie irgendwie Objektklonen und Zeug. 00:56:02.513 --> 00:56:05.013 Das heißt, ich glaube wirklich, Lodash wird gar nicht so verwendet, 00:56:05.073 --> 00:56:06.433 sondern wirklich Partikel davon. 00:56:07.093 --> 00:56:11.673 Nur noch. Und auch das wäre ja eine To-Do-Liste für die Browser-Spezifikateure. 00:56:12.553 --> 00:56:14.933 Beziehungsweise sowas wie Objektklonen, Structuredklonen haben wir ja schon. 00:56:15.133 --> 00:56:19.633 Aber andere Sachen, müsste man mal gucken, was die da so drin haben. 00:56:19.713 --> 00:56:22.153 Also die wenigsten verwenden viel von Lodash, würde ich behaupten. 00:56:23.833 --> 00:56:26.613 Von meiner Erfahrung her kann ich es unterschreiben. Meistens so die Group By 00:56:26.613 --> 00:56:28.133 oder sowas Funktion oder wie sie heißt. 00:56:28.773 --> 00:56:32.833 Auch die haben wir ja mittlerweile native. Also wer weiß. 00:56:34.749 --> 00:56:37.289 Also IPD-Equal-Check wahrscheinlich noch. 00:56:39.369 --> 00:56:47.449 Lodisch war ja gewisserweise die Roadmap für das TC39 in den letzten Jahren. 00:56:47.729 --> 00:56:51.729 Von dem her, ja, mittlerweile glaube ich auch, dass man gut ohne auskommt. 00:56:51.789 --> 00:56:52.629 Aber es ist immer noch so, 00:56:55.049 --> 00:56:58.789 finde ich, der erste Gedanke vieler, dass sie sagen, ja passt, 00:56:58.869 --> 00:57:02.349 das brauche ich jetzt. Und sie schauen gar nicht nach, was es in der Browser eigentlich gibt. 00:57:02.889 --> 00:57:05.409 Aber hey, gut, wie gesagt, verweißen wir auf die andere Episode. 00:57:05.629 --> 00:57:08.709 Da haben wir schon genug drüber gesprochen. 00:57:08.969 --> 00:57:12.269 Ich muss nur noch erwähnen, 7% underscore JS ist auch noch da. 00:57:13.309 --> 00:57:14.209 Das hat er gesagt. 00:57:17.549 --> 00:57:18.169 So geil. 00:57:19.229 --> 00:57:23.589 Ja. Gut, sind halt irgendwelche Libraries. Da ist jetzt nichts irgendwie drin, 00:57:23.649 --> 00:57:24.709 was mich überrascht so richtig. 00:57:25.629 --> 00:57:29.329 Ich bin sehr froh, dass Axios sehr weit unten ist, weil das brauchst du wirklich 00:57:29.329 --> 00:57:32.529 nicht mehr. Das ist die Penit, die man wegkriegt. Super. 00:57:35.249 --> 00:57:40.009 Wie ist denn der aktuelle Stand bei Moment? Da war doch mal so ein Hickhack 00:57:40.009 --> 00:57:43.949 irgendwie mit, kann man nicht mehr verwenden, kann man doch noch verwenden? 00:57:45.109 --> 00:57:47.249 Also wenn du mich fragst, ist der aktuelle Stand von Moment, 00:57:47.809 --> 00:57:49.549 die Uhr läuft, Temporal ist fertig. 00:57:49.849 --> 00:57:53.249 Das muss jetzt nur noch geanfleckt werden. Und dann können die ganzen Libraries 00:57:53.249 --> 00:57:55.609 einpacken, weil wir dann vernünftiges Datumshandling im Browser haben. 00:57:57.029 --> 00:58:00.589 Und die haben bei Moment, glaube ich, gesagt, wir stellen jetzt die aktive Weiterentwicklung 00:58:00.589 --> 00:58:01.969 ein, sind jetzt im Maintenance-Mode. 00:58:04.769 --> 00:58:07.789 Weil, naja, die sind halt auch noch aus einer Zeit von Fortree-Shaking und so, 00:58:07.949 --> 00:58:09.269 glaube ich. Das war, glaube ich, der Grund. 00:58:10.269 --> 00:58:12.329 Ich glaube, das, was ich gerade meine, was ich gehört habe, war, 00:58:12.469 --> 00:58:14.829 dass Moment irgendwann auch beschlossen hat, mal modularer zu werden. 00:58:15.829 --> 00:58:18.629 Und dann gab es sehr viele Missverständnisse darüber. Aber vielleicht habe ich 00:58:18.629 --> 00:58:19.509 was Falsches mitbekommen. 00:58:23.460 --> 00:58:28.780 Also ich denke, diese ganzen Datums- und Zeitdinger, die werden halt noch schneller 00:58:28.780 --> 00:58:30.920 den jQuery machen, als jQuery den jQuery macht. 00:58:31.500 --> 00:58:35.900 Einfach nur, weil die ja nicht so wie jQuery konstituierend sind für irgendeine 00:58:35.900 --> 00:58:36.980 Applikation, sondern du brauchst 00:58:36.980 --> 00:58:39.920 halt hier und da mal Datums- und Zeithändling, mal mehr, mal weniger. 00:58:40.320 --> 00:58:43.320 Aber das sollte sich wirklich relativ easy gegen Temporal austauschen lassen, 00:58:43.800 --> 00:58:45.380 wenn man denn mal dazu kommt eines Tages. 00:58:45.660 --> 00:58:48.940 Was ja was anderes ist, als wenn du wirklich so eine riesige jQuery-Suppe zusammengerührt 00:58:48.940 --> 00:58:50.500 hast, um dein Frontend zu machen. 00:58:51.480 --> 00:58:54.960 Von daher denke ich, das geht auch bald vorbei, schätze ich mal. 00:58:55.900 --> 00:58:58.220 Was ist Vue-Use? Habe ich auch noch nie gehört. 00:58:59.800 --> 00:59:00.620 Was für ein Use? 00:59:00.820 --> 00:59:01.920 Vue-Use, genau. 00:59:03.280 --> 00:59:09.420 Das habe ich mal verwendet. Das ist eine Bibliothek. 00:59:09.580 --> 00:59:12.060 Also ich bin jetzt verwirrt, dass das irgendwie bei dieser Liste auch auftaucht. 00:59:12.480 --> 00:59:17.800 Aber das ist eine Bibliothek an relativ kleinen, coolen Plugins, 00:59:17.800 --> 00:59:21.600 die so die Vue-Core-Team-Leute auch geschrieben haben, weil sie die dann wiederum 00:59:21.600 --> 00:59:26.440 selber verwendet haben und dann quasi zur Verfügung gestellt haben. 00:59:27.380 --> 00:59:27.980 Okay. 00:59:28.540 --> 00:59:36.220 Da ist zum Beispiel so eine Bibliothek an gut zu verwendbaren Composables drin, 00:59:36.360 --> 00:59:40.260 Composables-React-Hooks quasi, wie Use-Dragable. 00:59:40.400 --> 00:59:44.900 Und dann hast du halt schon irgendwie eine Funktionalität drin für Drag-Drop-Funktionalitäten. 00:59:46.060 --> 00:59:47.160 Okay, verstehe. 00:59:48.300 --> 00:59:52.280 Also so ein View-Loadish. Nee, das ist ein bisschen unfair. 00:59:52.760 --> 00:59:55.660 Die sind nicht so primitiv. Es ist schon ein bisschen komplexer, 00:59:55.740 --> 00:59:56.780 was man sich da reinholt. 00:59:57.760 --> 01:00:00.940 Okay, gut. Aber View-spezifische Plug-in-Sammlung. 01:00:01.960 --> 01:00:04.160 Genau, aber eigentlich ganz cool. Das ist ganz nett, wenn man es braucht. 01:00:04.940 --> 01:00:07.520 Dient auch so ein bisschen für mich oft als Inspiration. 01:00:07.740 --> 01:00:10.500 Also dann ist es immer die Frage, mache ich jetzt tatsächlich, 01:00:10.640 --> 01:00:13.960 dass ich das verwende von denen oder lese ich mir deren die ganze Dokumentation 01:00:13.960 --> 01:00:17.760 durch, wie sie das so gebaut haben und einen Code durch und sage, 01:00:17.840 --> 01:00:20.420 ich brauche es ein bisschen anders, habe mich halt dadurch inspirieren lassen 01:00:20.420 --> 01:00:21.740 und baue es ein bisschen anders nach. 01:00:23.700 --> 01:00:24.060 Verstehe. 01:00:28.808 --> 01:00:31.228 Ja, gut. Animationslibraries. 01:00:35.208 --> 01:00:38.188 Also meine Animationslibrary heißt CSS und die kommt hier drin nicht vor. 01:00:43.348 --> 01:00:48.268 Ich bin zur Enterprise für moderne Animationen. Wobei, ich muss ganz ehrlich 01:00:48.268 --> 01:00:50.408 sagen, wir verwenden viel Charting. 01:00:50.548 --> 01:00:54.928 Also da geht es ja generell um Grafics und wir verwenden Highcharts. 01:00:55.028 --> 01:00:58.208 Das kommt tatsächlich auch in der Liste vor. Aber wir haben aber jetzt auch 01:00:58.208 --> 01:01:03.508 selber Visualisierungsprimitive geschrieben, glaube ich, auf der Basis von D3 direkt. 01:01:03.748 --> 01:01:11.068 Das ist ja wirklich sehr niederschwellig. Nein, nicht niederschwellig, 01:01:11.168 --> 01:01:13.948 ist das falsche Wort. Low-Level? Genau. 01:01:14.548 --> 01:01:17.928 Genau, ich wollte gerade sagen, Low-Level aber nicht mehr einzelne Pixel schieben. 01:01:18.248 --> 01:01:21.048 So halt eine Abstraktions-Library, auf die man dann draufsetzen kann. 01:01:21.888 --> 01:01:26.008 Hätte ich jetzt bei eurem Laden auch tatsächlich erwartet, dass so viel Visualisierungs-Fu, 01:01:26.068 --> 01:01:29.428 wie ihr mutmaßlich macht, dass es nicht schlecht ist, das ins Haus zu holen, 01:01:29.528 --> 01:01:32.968 weil keine Ahnung, die Hightshard-Maintainer werden gekauft, 01:01:33.108 --> 01:01:35.308 von einem Bus überfahren, sanktioniert, hast du nicht gesehen. 01:01:35.888 --> 01:01:37.828 Das wäre schon recht katastrophal. 01:01:38.948 --> 01:01:39.068 Ja. 01:01:39.508 --> 01:01:41.668 Das ist ja eben auch nicht so ein Backend-Service, den man austauschen kann. 01:01:41.748 --> 01:01:44.108 Das ist ja was, was eure Kundschaft unmittelbar war. nimmt. 01:01:46.388 --> 01:01:48.148 Hätte ich auch vorgeschlagen, dass man das tut. 01:01:49.728 --> 01:01:50.968 Ich habe gerade einen Kaffee bekommen. 01:01:51.448 --> 01:01:56.108 Ja, super. Was ein Service. Was der Fliesenleger nicht alles für dich macht. 01:01:57.028 --> 01:01:58.668 Das ist wohl nicht der Fliesenleger, das war meine Frau. 01:02:00.168 --> 01:02:02.488 Hey, auch das kann man in Personalunion haben, wenn man es richtig macht. 01:02:09.448 --> 01:02:09.768 Grandios. 01:02:10.108 --> 01:02:12.388 Oh, Stefan, du bist doch hier der Experte für Backend Frameworks. 01:02:13.488 --> 01:02:17.808 Nächster Punkt hier. Express immer noch über 60 Prozent. Ja? 01:02:18.488 --> 01:02:22.488 Ja, ich liebe Express. Es ist ein wunderschönes Framework. Also ich finde cool, 01:02:22.568 --> 01:02:23.768 dass es immer noch verwendet wird. 01:02:25.208 --> 01:02:31.228 Es ist rund, es funktioniert gut, es ist gut dokumentiert, es gibt viele Beispiele, 01:02:31.568 --> 01:02:35.088 viele Probleme, die in den letzten zehn Jahren aufgetaucht sind, sind gelöst. 01:02:35.188 --> 01:02:38.048 Es ist mir immer ganz wichtig, dass Leute tatsächlich daran arbeiten und die 01:02:38.048 --> 01:02:40.268 Probleme lösen. Nein, Express ist toll. 01:02:41.328 --> 01:02:44.868 Fastify ist im Grund Express auf Stereoids, kannst du auch verwenden, 01:02:45.168 --> 01:02:51.388 super, dass das auch verwendet wird, aber ganz ehrlich, für mich ist Express 01:02:51.388 --> 01:02:54.508 immer noch das Go-To-Framework in Node, ich glaube, dass die Probleme, 01:02:54.648 --> 01:02:56.128 die wir mit anderen Frameworks lösen, 01:02:57.480 --> 01:02:58.740 sehr spezielle Probleme sind. 01:03:00.020 --> 01:03:03.200 Was ich halt an Express sehr schön finde, ist, ich schreibe alle zwei Jahre 01:03:03.200 --> 01:03:06.700 mal eine neue Express-App und ich habe immer nur das Gefühl, 01:03:06.740 --> 01:03:11.100 dass ich mich erinnern muss und dass nicht wirklich sich fundamental was getan hat. 01:03:11.200 --> 01:03:13.940 Wahrscheinlich hat sich zwischendurch was getan, aber das kann halt so in den 01:03:13.940 --> 01:03:18.020 Erinnerungsprozess integriert werden, dass halt einfach das große Rewrite so 01:03:18.020 --> 01:03:20.300 scheinbar nie stattgefunden hat und dass die ganzen Konzepte immer noch die 01:03:20.300 --> 01:03:23.300 gleichen sind und das ist auch sehr viel wert, gerade in so einer JavaScript-Welt, 01:03:23.380 --> 01:03:25.080 wo ja sonst irgendwie nichts länger als fünf Minuten hält. 01:03:26.000 --> 01:03:30.580 Ja, also die Erfahrung habe ich auch komplett. Wenn ich Express machen muss, 01:03:30.660 --> 01:03:32.780 denke ich mir, ah, ich habe das mal vor zehn Jahren hier, oh Gott, 01:03:32.880 --> 01:03:34.900 das wird alles mein Stand so klar veraltet sein. 01:03:35.380 --> 01:03:37.440 Ne, schaut gleich aus, kann ich weiterhin benutzen. 01:03:38.200 --> 01:03:44.160 Ich denke, Nitro, Nitro und H3H3 waren mal in meiner Bubble so. 01:03:44.260 --> 01:03:47.720 Ich glaube, es kam aus der View-Bubble auch raus, war mal voll gehypt. 01:03:48.100 --> 01:03:49.120 Ich habe es mir auch angeschaut. 01:03:49.640 --> 01:03:55.200 Und es wirkte dann generell moderner, so JavaScript-mäßiger, Frontend-mäßiger. 01:03:56.760 --> 01:03:59.320 Punkt, ich habe da jetzt gar nichts Schlechtes oder Gutes dazu zu sagen. 01:03:59.400 --> 01:04:01.740 Das ist nur das einzig andere, was ich mir mal angeschaut habe. 01:04:01.940 --> 01:04:03.300 Es sah auch interessant aus. 01:04:03.580 --> 01:04:05.760 So Redwood, habe ich gehört, 01:04:06.520 --> 01:04:07.040 Cool. 01:04:07.460 --> 01:04:11.520 Anscheinend, weiß ich nicht. Keystone, ja, hab ich mal verwendet. 01:04:11.740 --> 01:04:15.560 Und den ganzen Rest hab ich mir nicht mal angeschaut. 01:04:18.820 --> 01:04:21.420 Ja, da sind, glaub ich, viele so drin, die so halb versuchen, 01:04:21.680 --> 01:04:23.780 irgendwie das Rails für JavaScript zu sein. 01:04:25.100 --> 01:04:28.340 Und das stellt sich dann doch als relativ schwierig raus, weswegen die dann 01:04:28.340 --> 01:04:30.200 meistens nicht so wirklich die kritische Masse erreichen. 01:04:32.960 --> 01:04:38.060 Was ja schade ist, so was wäre ja per se keine schlechte Idee. Aber Hammer halt nicht. 01:04:39.960 --> 01:04:40.440 Ja. 01:04:41.400 --> 01:04:44.380 Okay, dann gehen wir zum nächsten. JavaScript-Runtimes. 01:04:45.480 --> 01:04:47.120 Ich verstehe dieses Ergebnis nicht. 01:04:47.680 --> 01:04:48.220 Wieso nicht? 01:04:49.300 --> 01:04:51.380 Warum Browser auf Platz 2 ist. 01:04:52.700 --> 01:04:55.800 Weil das halt eine nicht repräsentative Umfrage ist. Und wenn das einfach nur 01:04:55.800 --> 01:04:59.800 mehr Backend-Leute mit mehr Followern untereinander geteilt haben, 01:04:59.880 --> 01:05:01.580 hast du halt mehr Node-Leute am Start. 01:05:02.000 --> 01:05:04.400 Nein, ich glaube eher, dass viele Leute nicht checken, dass der Browser ein 01:05:04.400 --> 01:05:05.280 JavaScript-Runtime ist. 01:05:05.280 --> 01:05:07.560 Nee, ich glaube eher, dass das so ist, wenn du irgendwas für den Browser machst, 01:05:07.660 --> 01:05:11.160 musst du dich auch mit Node.js rumschlagen, aber das ist nicht notwendigerweise umgekehrt genauso. 01:05:11.740 --> 01:05:17.940 Ah, so, ja, okay, gut. Ja, ja, ja, ja, das könnte, das könnte stimmen. 01:05:20.520 --> 01:05:25.720 Also so Sachen wie BAN haben relativ wenig Gefolge dafür, dass sie so viel Cola am Start haben. 01:05:26.900 --> 01:05:27.260 Ja. 01:05:28.120 --> 01:05:29.220 Ich bin immer 01:05:29.220 --> 01:05:34.520 Nur beeindruckt von den 16% BAN-Nutzerinnen und Nutzern, weil... 01:05:37.120 --> 01:05:41.280 Also das Ding ist ein hype-driven Experiment. 01:05:42.000 --> 01:05:45.880 Also kein Mensch kann mir sagen, dass... 01:05:48.100 --> 01:05:51.700 Dass sie BAN verwenden und damit produktiven Code oder das Code in Production 01:05:51.700 --> 01:05:53.960 schreiben. Nein, so schlimm. Unmöglich. 01:05:54.560 --> 01:05:59.120 Okay, das höre ich jetzt zum ersten Mal in der Deutlichkeit. 01:06:03.080 --> 01:06:07.400 Nein, es bricht konstant mit Standards, die Kompatibilität lässt zu wünschen 01:06:07.400 --> 01:06:10.920 übrig, es ist nicht so schnell und so cool, wie es alle machen, 01:06:11.100 --> 01:06:13.080 es kommt nicht immer darauf an, welche Benchmark du verwendest. 01:06:13.880 --> 01:06:20.060 Und alle Sachen, die BAN löst, werden von anderen Runtimes besser und stabiler gelöst. 01:06:20.160 --> 01:06:22.780 Das heißt, wenn ich jetzt wirklich sage, ich möchte etwas schreiben, 01:06:22.880 --> 01:06:25.620 das nachher in Production kommt und in Production verwendet wird, 01:06:26.360 --> 01:06:31.180 dann nehme ich doch eher Technologie, die battle-tested ist. 01:06:31.640 --> 01:06:35.640 Wo zum Beispiel, also tatsächlich ist das für mich auch, obwohl ich schon lang, 01:06:37.300 --> 01:06:45.520 wegkomme davon, ist das No-Chase, weil halt dort ein unzählige Software draußen stabil funktioniert. 01:06:46.780 --> 01:06:51.200 Denno ein großes zweites, aber bei Denno nehme ich sogar das Hosted-Service her von Denno selbst. 01:06:52.020 --> 01:06:56.380 Aber BUN, also BUN ist cool für Demos und ich glaube, dass alle Leute, 01:06:56.400 --> 01:06:58.300 die das verwenden, coole Demos damit machen. 01:06:58.980 --> 01:07:02.600 Aber keiner lässt einen BUN-Server in Production laufen. Nicht, 01:07:02.680 --> 01:07:05.600 wo Geld dahinter ist. Nur für Sparscheid, hundertprozentig. 01:07:08.300 --> 01:07:12.840 Das ist ein Statement, werte Zuhörerinnen und Zuhörer. Wenn eure Erfahrung eine 01:07:12.840 --> 01:07:15.220 andere ist, dann lasst es uns und speziell den Stefan mal wissen. 01:07:16.280 --> 01:07:23.020 Sehr gern. Also meine Perspektive dazu ist, ich schreibe seit dreieinhalb Jahren, 01:07:23.240 --> 01:07:26.460 produzieren wir unsere eigene JavaScript-Randtime, die in Production läuft, 01:07:26.740 --> 01:07:28.120 die sehr stabil in Production läuft. 01:07:28.340 --> 01:07:34.680 Und die Entscheidungen, die wir treffen, um eine für Production optimierte JavaScript-Randtime 01:07:34.680 --> 01:07:39.220 zu schreiben, sind andere, als wir es BAN macht. Und ich würde keine einzige 01:07:39.220 --> 01:07:40.540 Entscheidung, die sie treffen, machen. 01:07:40.780 --> 01:07:44.140 Die Entscheidungen, die sie treffen, sind, um Twitter-Traction zu bekommen, 01:07:44.260 --> 01:07:48.440 damit für die nächste Runde, für die nächste Visierrunde, genug Zahlen auf dem 01:07:48.440 --> 01:07:51.320 Tisch sind, dass die Investoren die nächste Runde freischalten. 01:07:52.580 --> 01:07:53.400 Alles was passiert. 01:07:55.374 --> 01:07:59.234 Würde ich mit sehr viel Vorsicht angehen. 01:08:01.114 --> 01:08:04.294 Ja gut, es ist ja bei Next.js nicht so anders. 01:08:04.614 --> 01:08:10.314 Es ist halt ein Business-Manöver mit einem Artefakt, das man auch sich installieren kann, wenn man möchte. 01:08:11.134 --> 01:08:16.554 Ja, Next.js ist im Enterprise angekommen. Da gibt es viele, viele, 01:08:16.554 --> 01:08:18.614 viele Firmen, die groß drauf sitzen. 01:08:20.514 --> 01:08:24.714 Mit allen Gotches, die wir uns in der letzten Folge gegeben haben. 01:08:25.374 --> 01:08:29.154 Aber das heißt ja nur, dass die sozusagen in ihrem Business-Manöver besser arbeiten. 01:08:29.274 --> 01:08:31.214 Da ist ja das Software-Artefakt eher sekundärer Frage. 01:08:31.734 --> 01:08:34.554 Das muss ja nicht gut sein, um alle das zu bringen, dass sie es verwenden. 01:08:35.474 --> 01:08:41.554 Ich glaube, dass NextJS schon ein bisschen Reife hat, tatsächlich. 01:08:43.074 --> 01:08:46.834 Trotz aller Kritikpunkte, die wir in der letzten Folge besprochen haben, 01:08:47.574 --> 01:08:49.754 ist dort eine gewisse Produktreife da. 01:08:52.294 --> 01:08:55.614 Wobei, Zufriedenheit fällt rapide. Also die Unzufriedenheit steigt rapide, 01:08:55.734 --> 01:08:57.374 aber die Zufriedenheit fällt rapide. 01:08:58.094 --> 01:09:02.234 Hat sicher was mit der Bewegung zu tun, die da gerade passiert. 01:09:02.954 --> 01:09:06.414 Aber Bann ist ausschließlich ein Spaßprojekt. 01:09:06.754 --> 01:09:10.574 Da ist nichts drinnen, was irgendwie schreit, schreibt doch deinen Production 01:09:10.574 --> 01:09:12.194 selber damit. Nichts, gar nichts. 01:09:12.674 --> 01:09:15.594 Nichts, was andere Tools nicht besser machen und stabiler machen. 01:09:17.736 --> 01:09:21.356 Also das muss auf jeden Fall unser Video-Snippet sein. KI, bitte aufpassen. 01:09:22.136 --> 01:09:26.516 Gerne. Also wow. Tatsächlich ist es sogar so, dass Cloudflare Workers, 01:09:26.556 --> 01:09:30.616 die sehr, sehr wenig genutzt wird, eine um welten bessere und stabilere Roundtime 01:09:30.616 --> 01:09:32.396 ist. Die ist irrsinnig gut. 01:09:32.656 --> 01:09:38.896 Die hat einen ganz speziellen Use Case, nämlich Responses zu bearbeiten, 01:09:39.076 --> 01:09:44.656 bevor sie geschickt werden, wo du halt in Millisekunden eine Bearbeitung machen 01:09:44.656 --> 01:09:47.416 musst, weil ansonsten dauert die Response zu lange. 01:09:47.996 --> 01:09:51.076 Das ist einmal ein tatsächlicher Use Case, das ist einmal eine tatsächliche 01:09:51.076 --> 01:09:55.116 Speed-Optimierung, das ist etwas, das BAN so nicht hinkriegt. 01:09:56.236 --> 01:09:57.856 Ja gut, dafür ist es wahrscheinlich auch nicht gebaut. 01:09:59.076 --> 01:10:04.896 Naja, also Speed und Performance ist einer der großen BAN-Eckpfeiler und. 01:10:06.436 --> 01:10:07.356 Das kommt ja, 01:10:07.556 --> 01:10:10.076 Ob welche Statistik du dir anschaust oder welche Benchmark du dir anschaust, 01:10:10.156 --> 01:10:12.636 aber es ist nicht schnell, es ist nur in gewissen Bereichen schnell. 01:10:13.436 --> 01:10:17.296 Ja, aber wie gesagt, dass die besonders performant sind und irgendwie so Zeug 01:10:17.296 --> 01:10:18.616 machen, das liegt ja alles so im Messaging. 01:10:18.836 --> 01:10:21.176 Also, die haben ja auch irgendwie erzählt von wegen, da musst du dich nicht 01:10:21.176 --> 01:10:25.056 mehr um CommonJS und irgendwie ESM kümmern, weil wir Heuristiken haben. 01:10:25.856 --> 01:10:29.256 Und ich denke halt so, wenn ich die Spezifikationen lese, weiß ich genau, dass das nicht geht. 01:10:29.516 --> 01:10:32.996 Das ist prinzipbedingt unmöglich, aber das ist halt dann im Messaging drin. 01:10:33.136 --> 01:10:35.536 Und ich meine, in 99 Prozent der Fälle wird es ja funktionieren. 01:10:36.276 --> 01:10:37.776 Du kannst C-Fails laden. 01:10:38.736 --> 01:10:39.236 In Bann? 01:10:39.496 --> 01:10:40.216 Und ausführen. 01:10:41.296 --> 01:10:42.876 Wüsste nicht, wie das was da schief gehen sollte. 01:10:43.956 --> 01:10:44.596 Das klingt... 01:10:46.796 --> 01:10:49.656 Okay, jetzt weiß ich, wie du zu dieser Idee Spaßprojekt kommst, 01:10:49.656 --> 01:10:52.636 weil für ein Spaßprojekt oder für so, das hänge ich am Nachmittag mal eben schnell 01:10:52.636 --> 01:10:54.976 zusammen, da will ich das haben, dringend sogar. 01:10:55.316 --> 01:10:59.816 Es ist geil für einen Tweet, du kannst sagen, hey, cool, unser Random KC laden 01:10:59.816 --> 01:11:03.616 und dann sagst du so einen 10-Zeilen-Code her, wo du das tatsächlich machst und geil, super. 01:11:05.076 --> 01:11:11.236 Wenn ich ein Production-Problem angehe und ich brauche eine tiefe Dependencies im Jahr 2025, 01:11:12.136 --> 01:11:17.416 dann mache ich das ausschließlich über WebAsimple, weil ich will mir keine Security-Issues 01:11:17.416 --> 01:11:20.516 oder Sandbox-Probleme irgendwie eintreten. 01:11:22.480 --> 01:11:24.880 Ja, und vor allem WebAssembly ist ja mittlerweile auch so gut abgehangen, 01:11:24.960 --> 01:11:30.340 dass der Schmerz sich im Rahmen hält im Vergleich zu, also C-Dateien importieren 01:11:30.340 --> 01:11:31.780 ist ja nicht was, was du brauchst. 01:11:32.620 --> 01:11:37.060 Nein, das ist es. Also da dreht es einen ganz am unten Punkt. 01:11:37.280 --> 01:11:41.020 Falls es irgendeinen deutschsprachigen Bannentwickler oder Bannentwicklerin 01:11:41.020 --> 01:11:44.000 gibt, die tatsächlich auch an dem Produkt mitarbeiten, bitte kommen, 01:11:44.180 --> 01:11:46.320 ich will unbedingt verstehen, wie ihr tickt. 01:11:46.320 --> 01:11:49.280 Bitte kommt in den Podcast, ich möchte reden mit euch, ich möchte es kapieren, 01:11:49.400 --> 01:11:51.680 was da passiert, weil ich habe nur, 01:11:53.260 --> 01:11:58.220 also ich bin immer massiv aufgeregt, wenn ich an das Ding denke und wahrscheinlich 01:11:58.220 --> 01:12:01.800 ist das auch ein Ziel davon, vielleicht ist die Aufregung um diese Rundheim 01:12:01.800 --> 01:12:04.680 ein Ziel der Erfinder und Erfinderinnen, 01:12:05.320 --> 01:12:10.800 weil alles, was irgendwie Traction gibt, alles, was irgendwie nach einer Zahl 01:12:10.800 --> 01:12:14.220 gegossen werden kann für die nächste Runde ist super und auch nur, 01:12:14.280 --> 01:12:17.340 wenn sich Leute aufregen drüber, aber wow, also, 01:12:18.900 --> 01:12:20.680 jede andere Randheim, die dort entsteht. 01:12:21.280 --> 01:12:26.300 Sogar Chakra Core. Chakra Core ist um einige stabiler, kannst du die Notwahl 01:12:26.300 --> 01:12:28.420 hängen, hast du die gleichen Dependencies dran, super, bitte. 01:12:29.200 --> 01:12:31.800 Nehme ich liebend gern, wenn ich nichts anderes habe, nehme ich das. 01:12:32.360 --> 01:12:35.060 Bevor ich sage, ich greife auf Bann zu, weil Bann ist einfach. 01:12:36.740 --> 01:12:41.100 Du willst Software, würde ich schreiben, mit einem Produkt, das sich einfach 01:12:41.100 --> 01:12:44.700 von Tag 1 auf 2 so massiv ändert, wo so viele Dinge reinkommen, 01:12:44.780 --> 01:12:45.940 die du auch nicht kontrollieren kannst. 01:12:46.260 --> 01:12:49.540 Das Ding ist ja auch das, das macht ja Spaß, ich kapiere es, 01:12:49.800 --> 01:12:53.520 aber dann verwenden Leute das, um C-Dependencies reinzuladen und dann lädst 01:12:53.520 --> 01:12:56.280 du eine bahnoptimierte Dependency in dein Produkt rein und auf einmal hast du 01:12:56.280 --> 01:12:59.320 irgendwo eine C-Dependency, die du nicht kontrollieren kannst und auf einmal 01:12:59.320 --> 01:13:03.200 gibt es Zugriff auf deine Memory-Register und nein, nein. 01:13:05.220 --> 01:13:08.700 Alles was wir in Not versuchen seit 15 Jahren weg zu bekommen, 01:13:09.660 --> 01:13:11.980 machen es einfach wieder auf, weil es Spaß macht. 01:13:12.260 --> 01:13:14.720 Cool, habt ihr euren Spaß, aber nicht in meinem Production-Kauf. 01:13:18.040 --> 01:13:22.860 Ja, also, wenn Bannentwicklerinnen hier zuhören, oder noch viel spannender, 01:13:22.860 --> 01:13:27.640 fände ich ja was, wenn Investoren das jetzt gehört hätten, was die sagen. 01:13:29.020 --> 01:13:34.580 Nein, also ich mache das irrsinnig gern. Ich bin sehr gern ein Consultant für Investoren. 01:13:36.000 --> 01:13:38.980 Ich kenne ein paar Investoren, die sind super, die machen richtig coole Sachen. 01:13:39.140 --> 01:13:42.680 Also ich schimpfe sehr viel über VCs, aber in Wirklichkeit bin ich da eher, 01:13:43.320 --> 01:13:46.300 also die VCs selber stören mich ja nicht. Ich finde ja, da sind wirklich coole Leute dabei. 01:13:46.580 --> 01:13:51.160 Mir stören ja eher das Spiel im JavaScript-Bereich, das Leute mit VCs treiben. 01:13:51.260 --> 01:13:52.860 Das ist ja eigentlich eher das Problem, das ich habe. 01:13:55.620 --> 01:14:00.140 Bang wird euch unterm Arsch explodieren. Das wird jetzt nur für Series E und 01:14:00.140 --> 01:14:02.840 vielleicht Series B gut gehen, aber der Moment, wo Bang gezwungen wird, 01:14:02.920 --> 01:14:04.120 dass er Bezahlmodelle erfindet, 01:14:04.620 --> 01:14:08.380 irgendein Businessmodell, haben wir null Plan und null Idee, 01:14:08.520 --> 01:14:10.720 wie es das machen, außer dass die nächste Serverless-Plattform machen, 01:14:10.820 --> 01:14:15.520 die nicht ziehen wird, weil Serverless in Wirklichkeit ein Infrastrukturproblem 01:14:15.520 --> 01:14:16.540 ist und kein Randheimproblem. 01:14:20.027 --> 01:14:22.847 Ja, das frage ich mich halt eben auch, wie es jetzt geht. Das gab es jetzt ja 01:14:22.847 --> 01:14:26.847 schon mehrfach, dass irgendwelche Dev-Tools sagen, hier, wir haben jetzt Funding eingeworben. 01:14:27.147 --> 01:14:32.087 Und wenn das Funding halt nicht davon kommt, dass man sich irgendwie von irgendeiner 01:14:32.087 --> 01:14:36.487 Software-Bude sponsoren lässt oder halt eben sagt, hier ist mein Spendensparschwein, 01:14:36.567 --> 01:14:37.567 wirf mal hin und wieder was ein. 01:14:39.807 --> 01:14:43.847 Sehr spannend, wie man da irgendwie explosives Wachstum hinlegen möchte, 01:14:43.847 --> 01:14:47.687 ist mir auch nicht ganz klar. Aber ich bin ja auch kein Finanz-Jungleur, ich weiß das nicht. 01:14:47.687 --> 01:14:49.927 Man sieht es ja bei Denno, Denno ist ja wirklich ein Randheim, 01:14:50.027 --> 01:14:54.927 wo ich finde, die ist exzellent gemacht, sehr, sehr nachhaltig gedacht und sehr gut gemacht. 01:14:55.267 --> 01:14:59.227 Die überlegen sich ja was dabei, straggeln total mit den Bezahlmodellen. 01:14:59.907 --> 01:15:04.207 Die haben, finde ich, auch ein sehr, sehr gutes Produkt. Wäre Denno, 01:15:07.347 --> 01:15:12.367 vor fünf Jahren da gewesen, wo es heute ist, hätte ich keine eigene JavaScript-Randheim 01:15:12.367 --> 01:15:14.127 geschrieben, da hätte ich das Produkt von Denno genommen. 01:15:15.767 --> 01:15:19.467 Hundertprozentig. also da gibt es auch eine News-Kiste für, das verstehe ich, 01:15:19.507 --> 01:15:21.467 das kapiere ich da gibt es sicher Firmen, die das brauchen, 01:15:23.507 --> 01:15:31.587 aber also meine Outsider-Perspektive ist die dass die auch jetzt neue Ideen 01:15:31.587 --> 01:15:34.167 brauchen bis sie ein Bezahlmodell kriegen. 01:15:35.687 --> 01:15:37.207 Was ist denn das Modell bei Dino? 01:15:38.747 --> 01:15:41.627 Ein Hostet-Serverless das heißt, du kannst einen eigenen Serverless-Cluster 01:15:41.627 --> 01:15:45.667 betreiben der auf Dino baut mit sehr vielen coolen Security-Features wie Allow 01:15:45.667 --> 01:15:51.567 Listing und Isolated Invocations. 01:15:51.707 --> 01:15:56.687 Das heißt, du kannst sicher sein, dass du auf einer neuen Ranteil bist. 01:15:56.907 --> 01:15:59.407 Also Multitenancy und solche Sachen funktioniert alles irrsinnig gut. 01:15:59.907 --> 01:16:02.467 Das ist ein richtig cooles Ding. Alles, was wir in den letzten fünf Jahren entwickelt 01:16:02.467 --> 01:16:06.507 haben, macht den jetzt auch. Und wahrscheinlich besser. 01:16:06.827 --> 01:16:12.027 Ja, aber... Also ich habe ja keine Ahnung von so Serverless-Kram. 01:16:12.107 --> 01:16:14.207 Das wäre ja auch das nächste Thema, in das wir dann ja mal überleiten können. 01:16:15.127 --> 01:16:18.747 Aber ist das nicht so ein, also du hast es ja vorhin als Infrastrukturproblem 01:16:18.747 --> 01:16:23.827 beschrieben, ist das nicht sowas, wo am Ende einfach notwendigerweise der übrig 01:16:23.827 --> 01:16:25.607 bleibt, der der größte ist? 01:16:26.487 --> 01:16:30.987 Weil der einfach Skalierungseffekte nutzen kann und damit der billigste ist. 01:16:31.227 --> 01:16:34.147 Und wenn man halt irgendwie so ein Common Feature Set, wie irgendwie so Allow 01:16:34.147 --> 01:16:37.147 Listing, das hört sich jetzt erstmal für mich, wie gesagt, ich kenne mich nicht 01:16:37.147 --> 01:16:39.847 aus, aber das hört sich jetzt für mich irgendwie an, wenn ich jetzt irgendwie 01:16:39.847 --> 01:16:42.427 AWS sage, ey, mach mal Allow Listing und die haben das nicht, 01:16:42.807 --> 01:16:44.227 dann brauchen die dafür ungefähr drei Sekunden. 01:16:46.527 --> 01:16:50.067 Eher wahrscheinlich also das konvergiert doch alles notwendigerweise und dann 01:16:50.067 --> 01:16:53.107 ist es eine Frage der Skalierung und dann gewinnt der Größte also warum würde 01:16:53.107 --> 01:16:58.467 man sich in dem Teich aufhalten wollen als kleiner Fisch das erschließt sich mir nicht ganz 01:17:03.297 --> 01:17:04.917 Du kennst dich aus. Ich habe keine Ahnung. 01:17:07.137 --> 01:17:11.917 Ich sehe gerade, Denno hat tatsächlich auch Kunden, muss ich ganz ehrlich sagen. 01:17:12.017 --> 01:17:13.577 Das ist schon ein gutes Zeichen. 01:17:14.577 --> 01:17:17.397 Wenn du irgendwelche Integrationen auf Slack schreibst, dann rennen die auf 01:17:17.397 --> 01:17:18.577 Denno. Das ist ja schon mal cool. 01:17:18.997 --> 01:17:21.717 Das sind Dinge, die denken, cool, du hast einen Fit gegeben. 01:17:21.917 --> 01:17:23.997 Da gibt es ein Produkt und es gibt einen Fit dazu. 01:17:24.097 --> 01:17:28.497 Leute wollen einfach kleine JavaScript-Module haben, damit die Plattform erweitert 01:17:28.497 --> 01:17:29.717 werden kann oder was auch immer. Super. 01:17:31.137 --> 01:17:34.677 Perfekt. GitHub genauso. Also wahrscheinlich kannst du irgendwelche GitHub-Actions damit schreiben. 01:17:35.337 --> 01:17:40.277 Also, ja, nein, also, 01:17:42.937 --> 01:17:47.857 ja, keine Ahnung. Wir könnten ja Marvin einladen, wieder. 01:17:49.337 --> 01:17:50.637 Den kann man immer einladen. 01:17:51.097 --> 01:17:54.917 Ja, der ist ja bei den. Der soll uns ein bisschen erklären, was du jetzt vorhambem, ja? 01:17:56.157 --> 01:17:57.377 Klar, den kann man immer einladen. 01:17:58.017 --> 01:18:00.077 Ja, der schadet nie, aber der soll uns dann auch irgendwie erklären, 01:18:00.097 --> 01:18:03.917 wie sie glauben, jetzt irgendwie da so die besseren Cloud Functions zu machen, 01:18:04.117 --> 01:18:06.757 als irgendwie so Versailles zum Beispiel. 01:18:07.597 --> 01:18:09.677 Sehr gerne. Also wie gesagt, ich bin ein riesen Denno-Fan. Ich finde, 01:18:09.757 --> 01:18:11.917 die machen extrem cooles Zeug und ich würde gerne mehr verstehen, 01:18:12.017 --> 01:18:14.777 was die vorhaben. Passt. 01:18:16.417 --> 01:18:20.017 Und wir kriegen ja Besuch von Void Zero, da möchte ich auch verstehen, was die machen. 01:18:21.457 --> 01:18:23.797 Also das ist nämlich auch so etwas, wo ich mir denke, ja, cool. 01:18:24.557 --> 01:18:29.177 Also das Ding ist immer das. Ich freue mich irrsinnig, wenn, 01:18:31.277 --> 01:18:33.537 wenn Open-Source-Entwicklerinnen und Entwickler, 01:18:36.197 --> 01:18:38.737 Funding bekommen, damit sie das, was sie lieben, machen können. 01:18:40.197 --> 01:18:41.477 Und das sollen sie auch unbedingt tun. 01:18:41.657 --> 01:18:43.957 Also wenn die genug Geld haben, dass sie jetzt ein paar Jahre das tun können, 01:18:44.017 --> 01:18:45.397 was sie wollen, freue ich mich super. 01:18:45.617 --> 01:18:47.977 Ich bin nur gespannt, irgendwann kommt nicht der Punkt, wo du nicht mehr nur 01:18:47.977 --> 01:18:51.697 das machst, was du machen willst, sondern auch das machst, was irgendwie Geld bringt. 01:18:51.797 --> 01:18:54.517 Und ich möchte verstehen, was das Bezahlmodell wird. 01:18:57.578 --> 01:18:59.758 Gut, dann höre ich schon auf mit meinen Rains. 01:19:00.098 --> 01:19:03.198 Ja, ich würde auch sagen, wir können dann ja mit dem State of JavaScript aufhören, 01:19:03.258 --> 01:19:06.758 weil was jetzt kommt, ist ja nur noch so am Rande mit JavaScript befasst. 01:19:07.038 --> 01:19:09.438 Also JavaScript, Sprachen, die nicht JavaScript sind, die wir verwenden, 01:19:10.458 --> 01:19:13.618 interessiert eh keinen AI-Tools, da werden wir länger mal breite drüber reden. 01:19:15.158 --> 01:19:17.358 Hosting Services, nimmst halt den Billigsten, 01:19:17.438 --> 01:19:18.478 Der das macht, was du willst. Hostet man halt irgendwo. 01:19:19.238 --> 01:19:20.178 Ja, ist wirklich wahr, ne? 01:19:21.518 --> 01:19:23.698 Beziehungsweise wir hatten da auch noch die Folge mit Matthias Ott drüber, 01:19:23.818 --> 01:19:28.298 mit Indie-Web und Hosting etc., Gerade haben wir ja auch manche Sachen davon schon angesprochen. 01:19:28.778 --> 01:19:31.918 Genau, stimmt. So, wir müssen jetzt auch nicht nochmal irgendwie das Fass der 01:19:31.918 --> 01:19:35.918 Volksfront von Judea versus jüdische TypeScript Volksfront aufmachen. 01:19:37.838 --> 01:19:42.698 AI, noch mehr AI, bla, bla, bla, bla, bla. Ich glaube, wir haben über den JavaScript-Teil, 01:19:42.778 --> 01:19:44.318 The State of JS, geredet. 01:19:44.678 --> 01:19:48.638 Nur die eine Frage ist noch, in der Liste der Podcasts, wo stehen wir diesmal? 01:19:50.458 --> 01:19:53.658 Genau, das schaue ich auch gerade und wir sind auf Platz 20. 01:19:55.398 --> 01:19:59.598 Ja, das finde ich ausgesprochen respektabel. Also noch vor dem, 01:19:59.958 --> 01:20:03.398 dass man auf einen Button drücken muss, um uns anzuzeigen. Das ist ja das eigentliche Ziel. 01:20:03.618 --> 01:20:09.658 Nicht nur das, sondern die ersten 15 gab es wohl vorausgewählt zum Anhaken. 01:20:10.698 --> 01:20:14.658 Weil hier sehen wir, dass das 240 Leute haben auf die Frontend Happy Hour gedrückt. 01:20:14.898 --> 01:20:18.538 Und die ab Platz 16, die wurden manuell eingetippt. 01:20:18.638 --> 01:20:21.638 Das heißt, dass uns 16 Personen, obwohl wir noch nicht mal zur Auswahl standen, 01:20:21.638 --> 01:20:23.818 haben dennoch an uns gedacht und uns hier reingeschrieben. 01:20:28.118 --> 01:20:33.998 Ich glaube, wir sind auch einer der wenigen nicht englischsprachigen Einträge dort. 01:20:36.418 --> 01:20:38.918 Ich gucke gerade mal. Wahrscheinlich. 01:20:39.278 --> 01:20:43.038 Ich glaube, dieser Mito-Dev ist, glaube ich, auf Portugiesisch. 01:20:44.138 --> 01:20:44.638 Ja. 01:20:46.098 --> 01:20:50.998 Der ist recht beliebt. Der Rest müsste eigentlich alles, 01:20:54.298 --> 01:20:55.758 sehr viele portugiesische Sachen. 01:20:57.838 --> 01:21:02.038 Na gut, wundert jetzt auch nicht, weil es ja auch ein Sprachbereich, 01:21:02.098 --> 01:21:06.078 der so groß ist, dass es sich da lohnt, tatsächlich in der Sprache zu operieren. 01:21:06.158 --> 01:21:07.058 Das hast du ja nicht bei vielen. 01:21:08.498 --> 01:21:11.378 Auf jeden Fall danke an alle, die uns dort eingetragen haben. 01:21:11.458 --> 01:21:12.398 Ich finde das immer grandios. 01:21:12.678 --> 01:21:15.998 Ich finde das super. Da haben wir jetzt unmittelbar nichts von, 01:21:16.078 --> 01:21:18.918 aber es ist einfach irgendwie nett zu sehen, dass ich jetzt tatsächlich mit 01:21:18.918 --> 01:21:20.158 mehr Leuten rede, als nur mit zweien. 01:21:23.638 --> 01:21:27.078 Ja, also ich finde schon, es ist schon eine Wertschätzung und eine Anerkennung, 01:21:27.458 --> 01:21:30.598 dass Leute das machen. Also es freut uns riesig. 01:21:30.998 --> 01:21:33.538 Also mir wird immer ganz warm ums Herz, auch wenn ich ganz, ganz, 01:21:33.538 --> 01:21:35.618 ganz wenig dabei bin beim Podcast, aber ich freue mich einfach, 01:21:35.718 --> 01:21:37.438 wenn ich sehe, dass das Projekt so eine Anerkennung findet. 01:21:37.898 --> 01:21:40.958 Stefan, du bist nicht wenig dabei, du bist dann dabei, wenn es zählt. 01:21:42.278 --> 01:21:42.598 Ja. 01:21:45.969 --> 01:21:48.629 So, ich will sagen, was jetzt zählt, ist, einen Deckel drauf zu machen. 01:21:48.889 --> 01:21:54.749 Das war also unsere Sicht auf den State of JavaScript für das vergangene Jahr. 01:21:55.349 --> 01:21:58.929 Und dann schauen wir mal, wie hoch wir auf der Podcastleiter dann klettern, 01:21:59.109 --> 01:22:02.629 wenn es dieses Jahr zur Abstimmung kommt. Hörerinnen und Hörer, denkt an uns. 01:22:04.029 --> 01:22:07.489 Denkt außerdem daran, uns fleißig auf Social Media zu verteilen, 01:22:07.689 --> 01:22:11.109 uns Sternchen zu geben in den jeweiligen Podcast-Plattformen, 01:22:11.169 --> 01:22:14.629 so ihr das noch nicht getan habt und bleibt uns weiter gewogen, 01:22:14.989 --> 01:22:19.789 denn wir haben auf jeden Fall für den Rest des Sommers noch einiges vor. 01:22:19.789 --> 01:22:23.569 Wir haben hochkalibrigste Gäste eingeladen zu den heißesten Themen, 01:22:23.749 --> 01:22:25.009 die man sich nur backen kann. 01:22:25.629 --> 01:22:29.409 Und da bin ich ja wirklich sehr gespannt, wie das so ankommen wird. 01:22:29.829 --> 01:22:32.489 Es wird interessant, es wird kontrovers, es wird spannend. 01:22:33.529 --> 01:22:36.909 Okay, wunderbar. Dann danken wir fürs Zuhören. Ich danke Stefan, 01:22:37.009 --> 01:22:39.069 ich danke Vanessa fürs Dabeisein. 01:22:40.529 --> 01:22:44.809 Und dann hören wir uns bald wieder. Dankeschön, bis zum nächsten Mal. Tschüssi. 01:22:45.749 --> 01:22:46.489 Bis bald. Ciao, ciao. 01:22:47.120 --> 01:23:15.652