Transcript
[0:00] Wie fängt man da an, überhaupt auf die Suche zu gehen, wo man ansetzen kann, um bestehende Tools im Stack schneller zu machen? Aber dann musste die halt ein bisschen weiter überlegen, okay, was macht denn das Tool eigentlich?
Was erwarte ich, was es dann macht und matcht das mit dem, was ich hier sehe?
Für die immer jüngeren Zuhörer hier, das werde ich alles nicht verkennen, aber wir hatten kein Modulsystem.
Es gab nichts. Revision 564.
[0:24] Music.
[0:54] Diese Revision von Working Draft wird euch präsentiert von Factorial.
Liebe Hörerinnen, liebe Hörer, findet ihr nicht, dass ihr etwas Besseres verdient habt, so jobtechnisch?
Findet ihr nicht, dass ihr mehr drauf habt, als den ganzen Tag in der stillen Kammer Code zu tippen?
Dass Teams auch wichtiger sind als Tools?
Dann solltet ihr euch dringend überlegen, bei Factorial als Frontend-People-Lead anzuheuern.
Dort könnt ihr nämlich bei der Betreuung des 10-köpfigen Frontend-Teams mal eure Talente in Sachen Recruiting und Teamführung zum Einsatz bringen.
Bei Factorial Kundenprojekte arbeitet mit Management und Recruiting zusammen und unterstützt eure Kolleginnen und Kollegen in ihrer fachlichen und persönlichen Weiterentwicklung.
Ja, vielleicht habt ihr wirklich etwas Besseres verdient. Sowas wie einen Job mit Flexibilität und Familienfreundlichkeit.
Oder wie ein vierstelliges Fortbildungsbudget. Jedes Jahr.
Was ja nur ein paar von den Benefits sind, die es bei Factorial so gibt.
Doch ich denke schon, dass ihr mit etwas Besserem etwas anfangen könnt.
Und deswegen solltet ihr euch sofort bei factorial.io.slashjobs bewerben.
Nochmal zum Mitschreiben! Factorial.io slash jobs für euren neuen Job als Frontend-People-Lead.
Wir danken Factorial für die Unterstützung von dieser Revision von Working Draft.
[2:02] Wir sind heute zu dritt. Da hätten wir aus dem Team einmal den Hans.
Revision 565:Quo vadis Frontend-Tooling?
[2:10] Hallo. Ich bin der Shep und wir haben wieder einen Gast und zwar den Marvin Hagemeister. Hallo Marvin.
Hallo zusammen. Schön wieder da zu sein.
Ja, wir freuen uns auch sehr. Du warst schon zweimal bei uns zu Gast.
Stimmt. Ich glaube einmal zu, lass mal überlegen, also zu Code Golfing, glaube ich.
Könnte das sein?
Genau. Und ich glaube, das zweite Mal war über ein Testing Framework, was ich mir da durchgeschrieben hatte. Stimmt, so war es.
Erzähl mal einmal kurz, bring uns mal auf Stand, wer du bist.
Ja, gerne, mach ich. Also ich bin, wie gesagt, Marvin. Man mag mich vielleicht kennen, weil ich ziemlich viel im Open Source-Bereich tätig bin.
Hauptsächlich bei Preact, also das ist ein Framework, was ziemlich React-ähnlich ist, aber halt in 3 KB.
Und das hat sich dann daraus so ein bisschen entwickelt, dass ich mich auch immer mehr so um das ganze Ecosystem JavaScript interessiere, um Toolings und sonst was.
Und heute werden wir auch ganz viel über Tooling in JavaScript reden.
Von daher, bleibt dran.
Tipptopp. Kurzer Einschub, was ist aus dem Testing-Framework geworden?
Weil ich glaube, mittlerweile können die anderen ja auch so die coolen Tricks, die ihr so da auf Lager hattet?
[3:29] Ja, bei dem Testing Framework, das war damals geschrieben, wo Playwright noch nicht so wirklich, es gab es noch nicht so wirklich.
Also es war so ganz in den Anfangsschuhen.
Und mittlerweile würde ich sagen, Playwright ist deutlich voraus.
Von daher war das so praktisch so ein Produkt, was die Lücke gefüllt hat, wo Puppeteer nicht mehr weiterentwickelt worden ist.
Mittlerweile wird es ein bisschen weiterentwickelt und Playwright noch nicht so weit war, dass man es wirklich benutzen konnte.
Also von daher, es war damals mega geil, hat auch mega Spaß gemacht, dran zu arbeiten. Aber wenn jetzt hier Leser fragen, was soll ich nutzen, dann nutzt Playwright.
Okay, alles klar. Du bist schon ein ganz, ganz lange Teil des Projektteams und ihr macht da echt krasse Sachen, um Performance rauszuholen und auch Javascript möglichst klein zu ja zu zu daddeln also und verlasse euch da eben nicht nur auf irgendwelche automatisierten tools sondern ihr ihr knetet das sozusagen ihr massiert das per hand klein oder im zweifel so dass dann später die tools das optimal klein komprimieren können.
Und wie du schon gesagt hast, steckst du da mittlerweile schon ganz schön tief so im JavaScript-Tooling-Maschinenraum und machst da ein paar coole Geschichten wieder auf Lager, die du heute mitgebracht hast.
[4:55] Ja, definitiv. Es ist auch nicht einfach, dass ich so in die Tiefe gegangen bin, dass wir immer mehr den Practice-Kiss hatten, sondern irgendwann stellt sich auch die Frage, hey, wenn ich jetzt dieses Tool verbessere, hat das einen riesen Impact auf das gesamte Ecosystem, weil so viele JavaScript-Entwickler darauf aufbauen.
Und das war dann so ein bisschen so der Sprung, so wie ich dann nur für den Eigennutz noch so ein bisschen eine Mehrwert für die ganze Industrie denken kann.
Vielleicht starten wir mal mit der Feststellung, dass sich gerade so in diesem ganzen Tooling-Universum einiges tut, weil viele der bestehenden Tools im Prinzip nochmal neu, nochmal neu gedacht werden, aber in einer anderen Programmiersprache als JavaScript.
Also zum Beispiel Webpack, Am Nachfolger von Webpack wird gerade gearbeitet, der dann TurboPack heißt.
Das ist auch die gleichen Leute, die daran arbeiten. Aber was die eben jetzt machen, ist, dass sie sagen, JavaScript ist zu langsam, weil die Projekte möglicherweise zu groß geworden sind.
Weil wir Entwickler ja auch immer irgendwie alle Ressourcen ausschöpfen, die wir so bekommen.
Und deswegen machen wir das eben nicht mehr in JavaScript, sondern in was Schnellerem.
Und das ist halt momentan vorwiegend Rust.
[6:25] Und da gibt's ja recht viele Projekte, die so diesem Schema derzeit folgen.
Teilweise sind die noch in der Entwicklung, und teilweise gibt es die ja dann auch schon, ne?
Ja, da tötet sich echt viel. Das war so spannend zu sehen, weil ich sehe es jetzt auch selber in meinen eigenen Projekten.
Leute, die es nicht wissen, aktuell bin ich bei Shopify angestellt. Das ist so für mich so die größte Firma, wo ich bisher gearbeitet habe. Und die Projekte sind auch dort viel größer. Und je größer die Projekte sind, desto länger dauert es zu bauen, desto länger dauert es, die zu testen.
Und dann sieht man auch so, weil manche sagen, okay, vielleicht reichen wieder auch irgendwie so Limits der bestehenden Tools. Und da kann ich auch echt gut verstehen, dass viele sagen, vielleicht ist Rust die Lösung. Vielleicht ist auch ES Build, was in Go geschrieben ist, was aus den, äh, dass es auch mega schnell ist.
Vielleicht ist das die Lösung. Und die haben auch so bewiesen, dass diese Tools mega schnell sind.
Und so Probleme trifft man halt echt, wenn die Projekte größer sind.
Und das ist eigentlich ganz spannend, weil darum wird es auch heute ganz viel gehen.
Wie viel macht die Größe von Projekten aus? Wie viel trägt die Programmiersprache dazu bei?
Also so spannende Sachen halt. Das ist so, das, womit ich mich am meisten beschäftige aktuell.
Mhm. Wie bist du denn also dahin gekommen? Du hast ja schon angedeutet du bist jetzt bei shopify und die projekte sind groß das heißt du kodes dinge und dann drehst du wahrscheinlich erstmal däumchen wenn.
[7:54] Wenn die verschiedenen Tools darüber laufen und Dinge kompilieren oder dein Code gelintet wird oder gepretified wird, so in die Richtung geht's dann wahrscheinlich.
Also dass dir sozusagen in diesem Umfeld die, in Anführungszeichen, relative Langsamkeit des Tooling-Ökosystems so ein bisschen auf die Füße fällt.
Ja, ganz genau. Also wie ich das ganze angefangen habe mit den ganzen Toolings, das ist wie gesagt, Shopee feiert echt große Projekte und irgendwann ist man selber so ein bisschen genervt, vor allem dauert das ja so lange.
Also ich bin halt von Projekten gewöhnt, zum Beispiel wir können 1000 Tests innerhalb einer Sekunde testen, auch gegen Voll, gegen DOM, gegen Proza und alles.
Und jeder der vielleicht JS benutzt als Testframework, weiß, dass die Tester deutlich länger brauchen, gerade wenn man jetzt mit JS DOM arbeitet.
Und dann bei der Menge an Tests und Massen Tests, die wir haben, dauert das schon mal echt verdammt lange.
Und ich bin halt so ein Typ, wenn ich halt irgendwie arbeite, ich muss ganz offen gestehen, wenn ich mich jetzt irgendwie so interessiere und an einem Test arbeite und der Test braucht dann irgendwie 10 oder 20 Sekunden, bis er dann durch ist, dann, bin ich oft abgelenkt oder ich verliere meinen Gedankenfluss so ein bisschen, so meinen Flow, weil ich dann irgendwie denke, ah, das dauert so lange und dann bin ich wieder abgelenkt.
Und irgendwann habe ich mir gedacht, ja, okay, ist ja eigentlich blöd, ich kenne das schneller, Ich weiß, dass es schneller geht aus eigener Erfahrung.
Warum ist das hier nicht so schnell?
[9:21] Und dann hab ich halt so ein bisschen mir angewohnt, halt immer wenn ich auf irgendwas warten musste.
[9:25] Schaue ich mir einfach nach, was passiert denn da.
Dann ist vielleicht irgendwas offensichtlich, das ist natürlich immer so die Hoffnung von wegen, es gibt so den einen Trick und wenn ich diesen in eine Stelle finde, dann wird alles besser.
Ist aber leider oft nicht so und oft ist das so ein Zusammenhang aus so ganz vielen kleineren Dingen, die sich dann alle dann summieren und je mehr Tests du hast, und bei Shopify haben wir mega viele Tests, desto mehr summiert sich das natürlich auf und desto mehr können auch kleinere Sachen riesen Auswirkungen haben und sollte eigentlich das ganze dann angefangen dass ich dann immer tiefer gebohrt habe in die Tools und angefangen hat es echt mit Jest, ist dann auch so ein bisschen weiter herausgelaufen halt nachher in ESLint, weil wir alle nutzen irgendwie ESLint zum Prüfen unserer Tools und dann, wenn man immer tiefer bohrt in die Tools, dann lernt man ganz viel über JavaScript auch, also einfach auch wie funktioniert JavaScript, welche Patterns sind so ein bisschen langsamer, Welche Problematiken haben auch so viele Tools in unserem Umfeld, die wir alle benutzen?
Haben die vielleicht die gleichen Probleme? Welche Fehler machen die?
Und das sind ja auch, wir sind ja alle nur Menschen. Es ist von verschiedenen Menschen geschrieben, auch zu verschiedenen Stadien in ihrer Karriere.
Vielleicht am Anfang wussten die noch nicht so viel, haben aber schon Code beigetragen.
[10:34] Heute würden die es vielleicht anders machen. Und gerade Open Source ist ja auch ein bisschen bekannt dafür, dass es eigentlich immer einen Mangel gibt an Entwicklern, die da was contributen.
Von daher ist es jetzt nicht immer so das Perfekte.
Aber es ist das, was wir alles benutzen halt und das, was wir haben.
Das ist eigentlich das Spannende, wo ich dann gedacht habe, okay, kann ich da irgendwie einen Teil dazu beitragen in irgendeiner Form.
[10:56] Aber also dein Weg war dann also nicht, also ich finde häufig ist es so, wenn ein Bildprozess langsam ist, dann gehen die Leute hin und versuchen irgendwie das nächste gehypte Pool dann stattdessen in ihren Stack reinzuflexen.
Und also die suchen ihr Heil sozusagen im nächsten Tool. Und die versuchen gar nicht, das, was sie haben, sich genau anzuschauen und vielleicht das schneller zu bekommen.
Aber das hast du ja... Du bist ja diesen Weg eingeschlagen, richtig?
[11:34] Das sprichst du zu einem sehr guten Punkt an. Also bei kleinen Projekten oder wenn ich jetzt privat was mache, würde ich einfach sagen, probier doch mal einfach das andere Tool aus.
Ich sag mal so kurz ein NPM-Install, ein paar Commands umschreiben, zack hast du was Neues ausprobieren.
Bei so größeren Projekten ist es auch immer so die Frage, schaffst du es, was weiß ich, 300 Entwickler, die am gleichen Projekt arbeiten, oder was weiß ich, wie viele hunderte, schaffst du es, die alle umzulernen.
Weil jedes Tool, was du jetzt neu reinbringst, da sind vielleicht neue Commands, funktionieren manche so nicht wie das alte, und je länger und älter die Projekte auch sind, desto typischerweise, desto mehr nutzen die auch so diese ganzen sehr Niche-Features von irgendeinem Framework oder so, weil irgendwie, so bei Jest ist es dieses Module-Mocking, wo man noch ganz gezielt Sachen umschreiben kann, was viele Test-Frameworks nicht machen, und dann auch mit dem Snapshot-Testing, wo noch eigene Formate hier und alles das Mögliche drüber läuft, und auch, also ich würde bei uns, bei dem Jest-Framework fast sagen, Shopify, wir benutzen so ziemlich jedes Feature, was Jest nur zu bieten hat. Um das Tool auszuwechseln zu können, brauchen wir irgendwas, was so die gleiche Anzahl an Features hat. Und das ist typischerweise nicht der Fall, weil das schon so Nischenfeatures sind, die einfach nur in größeren Projekten gebraucht werden. Ich meine, man kennt das ja manchmal, wenn man, also irgendwann haben wir in unserem Projekt, glaube ich auch, ich überlege gerade, was war das nochmal? Also, Also ich glaube, es war ...
[12:54] Eventuell war's ES-Lint. Ich glaube, wir wollten das updaten auf die neueste Version.
Und allein da merkt man ja schon, also das ist dann ja ...
Dann fällt hier was um und da fällt was um. Und man muss irgendwie da noch nachziehen und muss seinen ganzen Code umformatieren, weil irgendwelche Defaults anders sind.
Oder man muss die umkonfigurieren.
Und manchmal rennt einem dann doch die Zeit davon, das alles einzufangen.
Und dann geht man eben wieder auf das zurück, was man vorher hatte und verschiebt das Projekt ESLint Upgrade dann irgendwie auf ein anderes Mal, ne?
[13:30] Das kenne ich nur zu gut. Ich merke es auch oft immer, wenn du, wie du sagst, du updatest was und auf einmal zerfällt alles.
Dann bist du wieder am debuggen, was ist denn los, was ist nicht geändert.
Du wolltest nur mal eben schnell.
Ja, nur mal eben. Ja. Und schon sind es ein paar Tage.
Vielleicht für mich nochmal aus einer anderen Seite kommt, also ich bin so jemand, ich versuche mich mit, vom Tooling so gut es geht fernzuhalten.
Und ich freue mich immer, wenn einfach alles sozusagen irgendwie funktioniert.
Deswegen ich bekomme jetzt im Moment natürlich mit, dass sehr sehr viel so in diesem Themenbereich, wir haben ja eben schon TurboPack beispielsweise angesprochen und ähnliches, dass da viel passiert.
Aber für mich ist es halt im Idealfall, ich nutze halt meinen Next.js und dann läuft das halt irgendwie so.
Was sind denn so die Neuerungen, warum man sich überhaupt mit diesem, ich sag mal, moderneren Tooling überhaupt beschäftigen sollte?
Also ist es immer nur die Performance oder gibt es da noch andere Gründe?
[14:33] Da sprichst du ein sehr gutes Thema und das ist auch so das Sternzeichen, was Next richtig gut macht.
Die bieten dir eigentlich so einfach alles.
Und das du dir einfach dich nicht um kümmern musst, du hast dein Kopf frei, kannst dich um dein Projekt kümmern, das machen die richtig gut.
Aber auch Next natürlich investiert sehr viel in Tooling, was halt viel auf GitHub immer passiert.
Also der Grund, warum ich mich gerne auch so mit anderen Toolings beschäftige, ist einfach, ich finde wir haben noch nicht so das perfekte Tool gefunden.
Also es kann immer, einen Teil ist natürlich Performance, je schneller, je kürzer der Feedbackloop ist, desto angenehmer ist es zu arbeiten, weil du immer, du tippst was, du speicherst und siehst direkt deine Änderung.
Und auch bei größeren Next-Projekten dauert das schon mal eine ganze Weile, bis da irgendwas passiert und hast noch Server-Side-Rendering und alles mögliche drin.
Und dann kann das schon mal dauern. Und das ist eigentlich so der ewige Such nach, können wir das schneller machen?
Aber nicht nur schneller, sondern auch so, wie jetzt immer mehr die Metaframeworks, wie Next oder auch bei Nuxt, bei Vue und anderen Frameworks, so diese ganze Developer Experience als Ganzes zu betrachten.
Da gehört ja nicht auch nur das Bauen hinzu, sondern es ist dann auch das Testen, das Linting, das Formatieren.
Und das ist mittlerweile vielmehr so, was passiert eigentlich in der ganzen Umgebung des Entwicklers?
Das ist mittlerweile sehr cool, kann man sehr viele Features machen, aber für mich persönlich ist es ehrlich gesagt hauptsächlich immer nur der Feedback Loop.
Also fast die Performance. Ich will eine Änderung machen, ich will die Änderung sofort sehen oder ich will, dass die Änderung sofort getestet ist.
Ist. Und das dauert mir einfach zu lange aktuell.
[16:03] Ja, und das Problem haben ja apparently viele Menschen, ne? Also ich erinnere mich natürlich auch noch an Webpack-Zeiten, als man alles selber programmiert oder konfiguriert hat und dann gemerkt hat, okay, mit meinen 15 Plugins ist es halt doch irgendwie saulangsam und auch so ein Production-Build dauert mir viel zu lang.
Das soll doch alles irgendwie bitte schneller gehen. Und daraufhin gab es ja auch diese Bewegung, wir haben das vorhin angesprochen, dass man halt gesagt hat, okay, diese Tools in JavaScript zu schreiben ist vielleicht nicht die idealste Art und Weise, weil es gibt Programmiersprachen, die machen das besser. Was ist da so das Ergebnis dieser Hypothese gewesen?
[16:50] Das ist eigentlich eine sehr gute Hypothese, weil JavaScript ist natürlich eine Sprache, die mit Garbage Collection funktioniert.
Und so Programmiersparen wie Rust, die sind viel näher an der Maschine dran und so.
Und die sind schon schneller. Also es ist ein super spannendes Thema, weil ich finde, es gibt noch nicht so die Lösung dafür oder das, wo man sagen könnte, das ist jetzt die Entscheidung.
Man sieht natürlich jetzt immer mehr gehen Leute auf Rust oder mit Go, mit ESP, das und diese anderen Programmiersparen.
SIG ist teilweise, taucht auch mal hier und da auf.
Aber wir sind noch so in dieser komischen Phase, wo diese Rust-Tools gerade erst noch aufpoppen und sie sich erst mal noch so ein bisschen bewähren müssen.
Und ich finde das ein ganz spannendes Thema, weil diese Programmiersparen sicher, damit kann man schneller machen, aber es ist teilweise auch für das JavaScript-Ökosystem ein bisschen schwierig, weil wir nicht mehr unsere, also ein JavaScript-Entwickler, der interessiert sich viel mehr für die ganzen JavaScript-Sachen, und will viel mehr, das ist gut, das ist jetzt mal meine These.
[17:49] Wenn du jetzt viel mehr primär ein Rust-Entwickler bist, zum Beispiel, dann interessiert sich vielleicht JavaScript nicht so, und das heißt, also dieses Dogfooding, so der eigenen Tools und der eigenen Features, und ich sehe es auch bei vielen, zum Beispiel, RSLint war zum Beispiel auch ein ziemlich cooles Projekt, wo die praktisch ein ESLint in Rust geschrieben haben, aber es wird jetzt nicht mehr weiterentwickelt, weil irgendwann hat der Entwickler halt die Lust verloren.
Und das ist so ein Ding, wo ich denke, ich find's mega geil, dass da die ganzen Ansätze da gibt und die anderen Tools in anderen Programmiersprachen.
Aber es ist halt die Frage, bewähren die sich auf Langzeit?
Das ist was, wo ich einfach noch nicht weiß, wo ich sagen kann, okay, der wägt jetzt, schreibt alle Tools in Rust um oder so.
Von daher weiß ich noch nicht, ob man so wirklich so einen Schlussstrich ziehen kann unter die Frage.
[18:35] Man kennt das ja auch von von Sass, dass ja ursprünglich, was war das in Ruby geschrieben war genau und dann gab es ja den C-Port, aber der war dann ja auch erstmal, der war dann ja nie quasi hatte nie Feature-Parity, Zu dem Original und dann kam ja noch der Rodney um die Ecke und hat dann noch einen Wasm oder einen Asm Port dann noch gemacht, der wiederum in so Coding IDEs im Browser dann benutzt wurde, die das dann auch wieder sozusagen hinterhergehend ist.
Und ich stelle mir vor, dass es bei diesen Tools momentan schon so ist, dass sie wahrscheinlich noch dabei sind. Also sie sind zwar per se schneller, sind jetzt noch dabei, erst mal so Catch-up zu spielen, mit dem, was halt über Jahre schon fertig entwickelt wurde.
Und also bevor sie dann die Möglichkeit haben, die aber nicht zwingend gegeben ist, dass sie sozusagen dann in die Führung gehen, was so Features angeht, und dann auf einmal das andersrum läuft.
Aber ich glaube, so momentan ist es eher noch so Catch-up-Game, oder?
[19:46] Ja, so sehe ich es auch noch ein bisschen. Also viel Potenzial überall, aber es muss sich halt noch bewähren.
Das war so einer der Gründe, warum ich mir gedacht habe, okay, ich könnte jetzt sagen, ich warte, bis die halt alle in Anführungszeichen fertig sind für mein Projekt oder wo ich sie benutzen will.
Oder ich gucke einfach mal, was die aktuellen Tools machen. Kann ich da irgendwelche Verbesserungen machen, die mir schon heute praktisch die Arbeit erleichtern oder irgendwas schneller machen?
So dass ich jetzt nicht drauf warten muss, bis irgendwelche anderen Leute ein Projekt fertig machen oder in einer ganz anderen Projektsprache, weil wenn du von null anfängst, dauert natürlich auch ein bisschen länger, als wenn du schon an irgendwas bestämmeln arbeitest.
Ist natürlich, passt jetzt nicht so ganz auf jedes Projekt, auf manche Projekte ist es durchaus cool, wenn man das neu schreibt, aber an sich ist eigentlich, denke ich, so erstmal gut zu schauen, was hat man denn da und kann man irgendwie ein paar Sachen machen, um es einfach schon jetzt schneller zu machen. So hat eigentlich alles dann angefangen.
[20:40] Du hast ja auch eingangs gesagt, dass, dass eben wenn man das schafft und da Dinge findet, dass man natürlich, dass da ganz viele Leute von profitieren können.
Also ich nicht, weil ich kann ja mein ES-Lint anscheinend nicht updaten, aber so grundsätzlich profitieren von den Verbesserungen, wenn du denn welche findest und auch irgendwie einfließen lassen kannst in das Tool, profitieren halt einfach auch viel, viel, viel mehr Leute, als eben die paar, die sich trauen, auf zum Beispiel nach Raspottiertes Tool dann in ihren Stack reinzubauen.
[21:20] Und wie machst du das denn? Also wie würde also wie ist so deine Vorgehensweise?
Also wie fängt man da an, also überhaupt auf die Suche zu gehen, wo man ansetzen kann, um bestehende Tools im Stack schneller zu machen?
Wie hast du es gemacht? Das ist eine sehr gute Frage und die bekomme ich oft gestellt. Der Trick ist eigentlich der, dass jetzt so diese ganzen JavaScript-Tools wie ESLint, Prettier oder was auch immer, die sind einfach wie ein normales JavaScript-Datei geschrieben. Die importieren dann vielleicht ein paar andere Dateien, aber dadurch, dass die eine normale JavaScript-Datei sind, kann man auch die ganzen Profiling-Tools von dem Browserumfeld nehmen. Und am einfachsten, was ich eigentlich am liebsten mache, es gibt bei Node ein Argument, das heißt das ist »strichstrich CPU-Prof« und das generiert dir halt eine CPU-Profile-Datei, so eine JSON-Datei, und die wiederum kannst du dann in verschiedene Visualisierungstools hochladen.
Für mich ist Speedscope das beliebteste, weil es von der Oberfläche ziemlich cool ist.
Dann kriegst du eigentlich praktisch das gleiche, so ganz viele bunte Balken, wie auch wenn du auf den Performance-Tab klickst und einmal da was recordest.
Nur bei Speedscope ist noch so ein bisschen der Vorteil, dass die noch so ein bisschen...
[22:35] Da das rumschieben kannst und andere Visualisierungen auswählen kannst, die es einfach sehr einfach machen, damit sie erkennen, okay, hier ist vielleicht, also, was ich halt super mag an Speedscope ist, dass die haben so ein left-heavy-view, das heißt im Prinzip, wenn du jetzt in JavaScript so verschiedene Funktionsaufrufe hast, die ineinander geschaltet sind, addiert der die alle auf, die irgendwie gleich sind, also die ganzen Zeiten.
Und das sind viele Tools halt immer, wo die gleichen Funktionen immer neu aufgerufen werden, und die werden dann alle zusammengefügt, Das macht dir ganz viel leichter zu sehen, ah, okay, die Funktion ist vielleicht, da passiert ziemlich viel, die sollte ich mir mal anschauen.
Als wenn das einfach nur ganz viele einzelne Sachen sind.
Das ist auch so bei meinen Problemen, diesen Chrome DevTools, wenn man in Chrome direkt so was macht, dass einfach nur so ein Salat an vielen bunten Balken hat und manchmal ganz schwer ist zu sehen, okay, wohin soll ich jetzt gucken, das sind einfach zu viele Daten.
Das Speedscope-App, das hatte ich bei dir dann gelesen, das kann ich gar nicht, hab's dann ausprobiert, ausprobiert, fand ich auch ganz gut.
Genau, das ist dann so eine Art so ein Flame Chart mäßig. Ich benutze dann noch gerne dieses, den Profiler, glaube ich, heißt der in den DevTools. Der macht dann ja keine so...
[23:50] Ich glaube, der macht dann oder macht er auch die flame charts aber du kannst ja auch so eine quasi so eine tabellarische übersicht dir dann ausgeben lassen.
Wo der dann die also quasi sortiert danach welche funktionen halt am am längsten.
Zeit verbraucht haben und ich glaube da gruppiert die funktion auch zusammen also es fand ich auch ganz ganz gut.
[24:14] Ja, funktioniert auch mega gut. Also wer damit zufrieden ist, ist auch fast einfacher. Da muss man nicht den Umweg gehen über eine Datei und die Datei dann wieder in ein anderes Tool laden.
Ja, dann hat man so seine seine verschiedenen Funktionen, die die sozusagen am erfolgversprechendsten zu sein scheinen zumindest, wenn man halt sieht, wie viel Zeit die verbraten.
Und wenn man dann irgendwas darin optimiert bekommt, dann summiert sich das dann auf.
[24:44] Ja, das ist auch nicht so, also normalerweise als erstes, was man immer da guckt, ist so, habe ich da irgendeinen langen Balken?
Das deutet immer darauf hin, dass eine Funktion irgendwie ziemlich lange braucht.
Aber manchmal, oder was ich auch oft gesehen habe, ist okay, da ist jetzt nicht so die zwei, drei Stellen oder so, wo jetzt so lange Funktionen sind, sondern es sieht alles so auf den ersten Blick erstmal okay aus, ne?
Aber dann musst du dir halt ein bisschen weiter überlegen, okay, was macht denn das Tool eigentlich? Was ist der Sinn von dem Tool?
Was erwarte ich, was es dann macht und match das mit dem, was ich hier sehe.
Also sind vielleicht ganze Funktionsaufrufe gar nicht notwendig oder manchmal, man kann es schon so ein bisschen an den Funktionsnamen so ein bisschen erkennen, was versucht das gerade zu machen. Und dann habe ich halt auch viele Stellen entdeckt, wo ich denke, okay, wir machen hier Arbeit, aber eigentlich brauche ich das jetzt gar nicht. Also eigentlich ist es, ich habe jetzt in dem Tool gesagt, ich will zum Beispiel Weil beim ESLint zum Beispiel, ich will jetzt Linten, dass die Importe sortiert sind, dass ich erst die habe, die nicht mehr im Punkt anfangen, also die npm-Pakete, danach will ich die haben, die relativ sind oder so, und danach vielleicht die CSS-Dateien.
[25:53] Und ich merke dann zum Beispiel, Moment mal, ich habe hier ganz viele Aufrufe irgendwie.
Und es sieht so aus, als ob immer wieder die gleichen Module resolved werden.
Oder irgendwie ist da was zu komplexes gemacht, um zu erkennen, wie die Sortierung machen soll.
Also irgendwie so eine ziemlich aufwendige Sortierfunktion. Wo man dann irgendwie denkt, okay, ist jetzt nicht so ein langer Balken.
Aber weil es halt in so verschiedenen Sachen passiert, ist das irgendwie so ein ganzer Baum, kann man schon fast sagen.
So in diesem flamecraft ansicht wo man denkt da muss doch eigentlich gar nicht da sein oder kann oder kann ich den auch irgendwie weg kriegen das war ich auch die spannende aufgabe du hattest ja auch also in einem deiner deiner blogpost dazu hattest du geschrieben also auch genau dieses module resolving also dieses quasi die art wie not dann versucht so ein paket ausfindig zu machen, Also das ist so relativ überkompliziert.
Und da hast du, glaube ich, eben auch festgestellt in dem Tool, das du da untersucht hattest, dass das sehr, sehr viel Module Resolving macht.
Teilweise eben doppelt und dreifach, das die gleichen irgendwie, meine ich mich zu erinnern.
Und dann eben, wie Node vorgeht auf der Festplatte, ist halt dann irgendwie auch...
[27:15] Sagen wir mal, fragwürdig. Was aber daran liegt, dass ja zum Beispiel du keine JS-Sendung, glaube ich, benutzen musst, und dann muss Node irgendwie selber gucken, ist das jetzt irgendwie eine JavaScript-Datei, oder was ist es dann?
Ich glaube, so in die Richtung ging das, oder?
Ja, ganz genau. Das ist auch so eine Sache, viele sagen immer, JavaScript verändert sich zu viel, bleibt nicht stehen.
Aber ich denke, das ist genau ein Punkt, wo ich sage, es ist gut, dass sich was verändert.
Das Hauptproblem, was da Note ist damals, also damals gab es ja, kennen wir, wie wir früher angefangen haben mit jQuery und sonst was noch.
Für die immer jüngeren Zuhörer hier, das werdet ihr alles nicht mehr kennen, aber wir hatten kein Modulsystem, es gab nichts.
Wir haben einfach nur einen Script Tag eingebunden und wenn wir ein zweiteres Modul haben, haben wir noch einen Script Tag eingebunden und das war dann unser Modulsystem.
Dann kamen so die ersten Tools auf, ich glaub damals war das CryoJazz oder so, was dann so versucht haben, so ein bisschen so was abzudrehen, dann wow, wir wurden schon mit Ajax, haben wir uns ein anderes Modul reingeholt und so, das war schon ganz cool.
Aber es gab halt noch nichts wirkliches. Und als dann Node aufkam, war dann halt die Frage, ja, wir müssen jetzt irgendwie Module abbilden.
Und die haben sich halt damals für Comment.js entschieden, also das ist das Node-Module-System praktisch.
Und das hat halt ein paar Sachen, was so im ersten Moment eigentlich ganz cool klingt, so von wegen, ich muss jetzt nur, wenn ich jetzt relativ was importieren will, kann ich einfach nur die Dateinamen machen, nur die Detaillen und filmt das Ding schon automatisch.
[28:41] Das hört sich erstmal ganz cool an, sieht auch im Code ein bisschen nicer aus, wenn man ein bisschen weniger tippen muss.
Aber da hast du natürlich das Problem, okay, die JavaScript-Engine, die muss ja trotzdem wissen, welche exakte Datei auf dem Dateisystem ist das denn jetzt.
[28:57] Und wenn das jetzt so unspezifisch ist, ohne Dateien, dann kann man natürlich am Anfang einfach nur, okay, ich hau einfach einen Punkt JS heran und dann weiß ich direkt, wo das ist.
Natürlich gedacht, wäre doch auch cool, wenn wir so JSON-Dateien laden können. Jetzt müssen wir checken, ist es JavaScript, wenn nicht, okay, ist es vielleicht JSON und erst wenn das nicht ist, dann schmeißen wir den Fehler. Und dann mittlerweile haben natürlich das ESM-Module-System praktisch die Fortführung und dann ist es natürlich jetzt, jetzt gibt es nicht nur JavaScript, jetzt gibt es ja auch noch TypeScript oben drauf. Das heißt, wir haben jetzt ganz viele Dateien, doch wir haben Punkt.js, wir haben Punkt.js, Punkt.js, Punkt.js, Punkt.jsx, Punkt.jsx und so weiter.
Das sind irgendwie so zehn Stück mittlerweile und im Worst-Case-Szenario, jetzt passiert es nicht immer, aber im Worst-Case-Szenario kann man echt zehn Dateien durchchecken und in der Regel werden immer so zwei, drei mal durchgecheckt. Von wegen ist es das? Ne, okay, ist es das? Ne, okay, ist es das? Ne. Und das Problem, warum das halt so ein bisschen ins Gewicht fällt, ist einfach, dass wir haben zwei SSDs und mittlerweile ziemlich schnelle Festplatten, aber es ist halt immer noch ein ticken langsamer. Also man verliert halt jedes mal so ein bisschen Performance. Das ist auch der Grund, wenn man jetzt im Browser ESM Modules benutzt, warum man immer eine Dateihindung angeben muss. Weil dadurch weiß man ganz exakt, ich muss nicht rumsuchen, irgendwie was könnte das sein, sondern ich weiß mit einem Aufruf direkt, es ist das und fertig und das spart halt ziemlich viel Zeit.
[30:22] Hast du dann okay das ist ja ist ja quasi ein fremdes tool das heißt du kannst ja da im grunde genommen, testweise so ein bisschen das das verändern aber am ende so beim nächsten, npm update oder so ist das ja alles wieder über jordan weil das ja dann wieder irgendwie von npm installiert wird das tool in der neuesten version aber.
[30:47] Hat es dann war dann der trick in dem fall zum beispiel überall einfach JS dran zu packen an die Require-Angaben.
War das so eine Sache, die viel gebracht hat?
Sie hätte was gebracht, aber das ist mal ein bisschen die Schwierigkeit.
Weil wenn du das jetzt machst, ein Projekt mit vielen Entwicklern, musst du alle Entwickler umschulen so ein bisschen.
Ich hab gesagt, okay, das ist vielleicht ein bisschen viel. Aber was ich halt da entdeckt hab, ist, Das war ein Teil, das macht durchaus ein bisschen Zeit aus, aber es war irgendwie nicht so viel, dass ich es angefühlt habe, okay, ich ändere jetzt mein ganzes Projekt.
Ich ändere jetzt alle Importfahnen und füge da .js hinten dran.
Sondern was ich stattdessen entdeckt habe, dass diese Logik in dem Linting Tool, um zu prüfen, ist es jetzt die Dateinung oder die Dateinung, immer jedes Mal, wenn es halt nicht die Dateinung war und die Datei nicht existierte, ein Fehlerobjekt erzeugt hat und das geschmissen hat.
Und die Funktion da drüber war praktisch so eine Funktion, ist das eine Datei?
Und die hat nun Boolean zurückgeworfen.
[31:51] Boolean return, das heißt, wir gucken immer, ist auf der Festplatte, gibt es die Datei?
Ne, gibt nicht, es wird ein Fehler geschmissen, der wird sofort im try-catch-Block gefangen und wurde dann einfach return false zurückgegeben.
Und das Hauptproblem, warum diese Funktion so langsam war, war echt dieses Erstellen der Fehler, weil ich habe halt in vielen, Ninting-Vorgängen in verschiedenen Projekten dann gesehen, okay, das wird irgendwie so knapp 35.000 mal bis teilweise 50.000 mal aufgerufen und dann der ganze Overhead, allein diese Fehlerobjekte zu erstellen, die werden in meinem C-Kontext erstellt, es wird ein Stacktrace dran geheftet und so weiter und dann wird das in JavaScript umgeschoben, das kostet verdammt viel Zeit.
[32:30] Und nur wenn ich das halt schon wegmachen kann, da gibt es so ein Argument, die haben glaube ich eine Start-Funktion benutzt und bei Node gibt es diese, throw if no irgendwas, so ein Boolean Flag, was man mitgeben kann, von wegen erstellen wir ein Errorobjekt oder nicht.
Und das habe ich halt hinzugefügt und schwupps war es auf einmal schnell genug, dass es eben, wenn man sich dann das Profile angeschaut hat, die ganzen Flame Graphs, dann hat es gar nicht mehr so ins Gewicht getreten, wie es funktioniert, da waren dann andere Stellen wichtiger.
Von da habe ich es jetzt nicht mehr so verfolgt, bringe ich jetzt noch alle Dateinamen, ändere ich die noch unbedingt.
Ich würde definitiv auch was machen, aber da muss man mal Kosten-Nutzen abwägen, weil ich glaub, das wär zu viel, zu invasiv für die ganzen anderen Entwickler gewesen.
Ja, aber cool. Und jetzt hast du ja quasi so einen großen, eine große Low-Hanging-Fruit dann identifiziert.
Und hast sie dann bei dir lokal eben geändert.
Und dann bist du wahrscheinlich auf die Macher von ESLint zugegangen mit einem Pull-Request.
Und hast dann gehofft, dass die das sozusagen dein Fix, dein Performance Fix integrieren in die Codebase.
[33:42] Ja, das ist so der Idealansatz. Vieles wurde auch akzeptiert, manches auch nicht.
Ist halt Open Source, also manchmal tritt man auch den Männchen auf den falschen Fuß.
Aber was man immer machen kann, es gibt so ein Patch-Package-Projekt, was eigentlich mega cool ist, wo man das dann immer, also im NPM, wenn man was installiert, dann gibt es immer so Post-Install-Scripts.
Und in diesen Post-Install-Scripts kann man mit diesem Patch-Package-Tool einfach noch Patches in Node-Modules praktisch drüber beraten.
Und das haben wir dann anfangs gemacht, sodass wir direkt alle Performance-Verbesserungen direkt jetzt nutzen können, ohne auf die Maintainer von Open-Source-Projekten warten zu müssen, bis sie das merken, bis sie ein neues Release machen. Und das dauert ja auch alles immer.
Und das ist auch so eine gute Möglichkeit, das einfach lokal und auch über viele Projekte hinweg einfach mal auszuprobieren.
Ja, cool. Ja, hab ich auch schon von gehört, noch nicht benutzt, aber genau, Genau pack ich auch mal in die Show-Nos-Fierces.
Patch-packaged.
Ja. Ist definitiv in den Links drin. Tun wir da ein? Mhm.
[34:49] Machen wir.
All right, genau was hast du, was hast du denn noch für so, für so faux pas, hast du noch so ähnliche schlimme Verbrechen gefunden oder sagen wir mal Ausrutscher, das sind ja keine absichtlichen Dinge.
[35:12] Ja, das ist immer ganz wichtig. Ich finde immer so, wenn viel über Performance geredet wird, dann sieht man auch leider online immer, dass so Sachen schlecht geredet werden.
Ich denke nicht, dass es böswillig ist oder so, sondern manchmal ist es auch einfach, zu der Zeit wusste man das noch nicht im JavaScript-Umfeld oder das Know-how war in der JavaScript-Szene noch nicht da und im Nachhinein ist es immer einfacher so zu wissen, ah, okay, hat jemand doch das und das gemacht.
Das ist mir ganz wichtig, dass man sagt, okay, das ist nicht schlimm, es passiert halt auch immer, dass man auch was übersieht. Ist völlig normal.
[35:42] Hat ja auch nicht jeder so eine Codebase wie du jetzt da bei Shopify sozusagen zum Gegenwerfen, wo man überhaupt dann solche Probleme mal feststellt.
Das stimmt auch. Also je größer das Projekt ist, desto eher steckt auch was am Tisch, wenn man irgendwo was nicht so gut klappt.
Definitiv, also ich, ja, das war auch so ein bisschen so der Anfang, was mich bewegt, okay, ich mache jetzt diese Blog-Serie, ich habe auch lange überlegt, aber es war so ein bisschen, ich wollte auch ein bisschen besser im Englisch werden, also ich würde schon behaupten, mein Englisch ist schon ganz okay, aber wenn man jetzt den ganzen Tag nur mit englisch sprechenden Leuten umgeht, merkt man schon, ja, okay, es ist vielleicht gut genug hier so, aber es ist halt irgendwie noch nicht da, wo ich es eigentlich gerne hätte.
Dann hab ich halt gedacht, okay, komm, kann man irgendwie per Blogpost einfach so das Schreiben üben oder auch irgendwie so.
Es ist immer einfach zu verstehen, zu lesen, eine andere Sprache, aber so ein bisschen schwieriger, selber zu sprechen.
Und dann hab ich gedacht, okay, worüber schreibst du? Und dann vielleicht ist auch so diese ganze Performance-Thematik, vielleicht ist das auch was Interessantes einfach.
Weil ich will nicht einfach nur einen Blogpost schreiben, um einen Blogpost zu schreiben, sondern ich will auch dann was sagen.
Also ich will nicht einfach nur irgendwie daher Stuss drehen, sondern man muss auch schon irgendeinen Sinn haben.
[36:55] Ja und dann hab ich gedacht, vielleicht ist doch cool einfach mal über die ganzen JavaScript-Sachen, was da im Hintergrund passiert, einfach zu reden und dann nämlich einfach mal so, weil viele wissen auch gar nicht mehr, also was passiert denn mit den Tools, was machen die eigentlich?
Oder, na kommen wir auch zu der Kernfrage, wo auch eben noch gesprochen haben, dass jetzt alle auf Rust aufspringen oder anderen Sprachen.
Einfach, war mir so ein bisschen das Interesse gepackt, wie viel macht jetzt so die Programmiersprache eigentlich aus?
Also ist die Programmiersprache das Hauptproblem? Warum sind unsere Tools so langsam?
Wenn was Neues in Rust geschrieben ist, warum das so viel schneller ist? Ist das jetzt wirklich nur Rust?
Oder ist es auch einfach, weil die halt schon schreiben mit diesem ganzen Wissen und diesen ganzen Learnings aus den JavaScript-Tools und das jetzt praktisch nochmal zusammenpacken, ohne Tech-Debt in Anführungszeichen, und einfach so wirklich von neu auf ideal schreiben im optimalsten Fall.
Da hab ich auch so ein bisschen was Interessantes. Okay, komm.
[37:49] Wie kannst du jetzt einfach wie schnell kriegst du javascript wie schnell kriegst du die tools einfach und wie nah kommst du an restaurant Es war halt nicht einfach so gepackt ich wollte es wissen, Ja, da ich sage okay, bin ich halt noch mehr in diese ganzen professor gegangen dieser ständige flow manchmal ein profile ich gucke ich Mach die erlaubt bringt die was nee vielleicht die andere änderung vielleicht kann ich das hier sparen, Was ist wenn ich die funktionen wissen umschreibe und so Und darüber lernt man immer mehr, wie eigentlich JavaScript funktioniert, was viel Zeit kostet.
Und viele denken immer, JavaScript zu optimieren ist echt schwierig, weil man so viel JavaScript-spezifische Sachen wissen muss und so weiter.
Und ich habe mich gemerkt, nee, stimmt eigentlich gar nicht.
Die meisten Optimierungen, die ich dann so gemacht habe, oder die ich gefunden habe, oder worüber ich auch geblockt habe, das sind alles Optimierungen, die würde man in jeder Programmiersprache machen.
[38:37] So ein Hauptansatz immer, ich versuche irgendwie zu vermeiden, zu viel Memory zu reservieren, in JavaScript-Sprache wie das zu viele Objekte zu erstellen, zu viele Arrays zu erstellen, die ich gar nicht brauche.
Ich habe zum Beispiel eine Funktion gefunden, die hat über so eine Datenstruktur einfach ein Element gesucht, ein bestimmtes, also eine ähnliche Datenstruktur wie HTML, also so eine Baumstruktur, und dann ich will ein bestimmtes Element finden.
Und die haben bei jedes Mal, wenn die ein Element gecheckt haben, haben die immer ein neues Array erstellt, dann ein neues Array reingespreadet und dann drüber gefiltert und das dann returned.
Das ist natürlich ganz wild, weil das heißt dann, je mehr Elemente ich habe, also pro jedes Element, wo ich einmal checke, ist es das, was ich haben will, wird immer Memory reserviert.
[39:19] Je größer dieser ganze Suchhaufen ist, wo ich dann suche, desto mehr Arrays erstelle ich dann natürlich.
Und als ich die dann alle weggeschrieben habe, dann habe ich gesagt, nee, ich habe nur ein Array, das Ergebnis Array, wo ich einfach alles reinstopfe.
Das hat mega viel ausgebracht und das ist eine Optimierung, das ist jetzt nicht, wo man sagt, das ist jetzt super JavaScript typisch, sondern das ist einfach was, die wird man in jeder Programmiersprache machen.
Und der Vorteil halt so von den Leuten, die Rust entwickeln, ist halt, die beschäftigen sich mit so Themen viel mehr, als wir JavaScript entwickeln.
Die sind viel mehr gucken, die ich profiliere immer, ich gucke, wie viel Memory verbraucht das, wie viel CPU.
Das macht man jetzt im JavaScript-Umfeld eigentlich typischerweise nicht, sondern man schreibt irgendwas, funktioniert, lange ist die Animation nicht ruckelt im Browser, so ist eigentlich alles cool. Das ist so in Anführungszeichen meine Erfahrung mit dem JavaScript-Umfeld und von da ist, denke ich, einfach nur mehr so ein Wissen-Transfer, was so eine Wissenslücke vielleicht auch einfach im JavaScript-Umfeld und ich habe mir halt gedacht, ich habe mir so ein bisschen Wissen angeeignet, indem ich halt immer das gemacht habe, gesagt, okay, darüber schreiben eigentlich noch gar nicht viele. Also viele schreiben über die neuesten TypeScript-Features, die neuesten JavaScript-Features, die neuesten CSS-Features und alles sowas. Ich habe halt gesagt, okay.
[40:30] Okay, wenn ich was blogge, ich will auch irgendwie so ein bisschen meine Ecke finden oder irgendwie was beitragen können zu einer Szene. Und ich hab gedacht, okay, vielleicht ist genau das die Nische, worüber ich bloggen kann. Und so hat dann alles angefangen. Das ist dann einfach in der Hoffnung, dass auch einfach mehr Leute darüber Bescheid wissen über so Dinge.
Weil ich hab auch gemerkt, zu dem ersten Blogpost hab ich noch alles berichtet, wo ich selber Prototyp-Quests gemacht hab, die alle auch gemerged worden sind. Ist natürlich auch ziemlich viel Arbeit.
Und ich habe halt gemerkt, das skaliert halt auch nicht, weil ich kann nicht, eine Person kann nicht in Anführungszeichen das gesamte Jahr über das Krypto-Ökosystem schneller machen.
Das geht vorne und hinten, nicht? Aber das wird viel effektiver, wenn immer mehr Leute Bescheid wissen und dann schon selber danach gucken.
Das heißt, also eine Hoffnung war praktisch einfach, dass man so Wissen verbreitet und dann die Leute selber dann vielleicht sagen, oh, ich habe das hier gelesen im Blogpost-Beitrag, trifft das vielleicht auch auf mein Projekt zu, wenn ich mir einfach mal meinen Code angucke.
Das war so die große Hoffnung eigentlich dahinter, weswegen ich das Ganze dann auch angefangen habe.
[41:27] Hast du denn da neben den technischen Themen auch noch andere, ja so Actions gefunden, die man so mitnehmen kann? Also ich weiß nicht, man stellt fest sein Projekt ist langsam und findet aber nicht raus woran es liegt.
Woran, an wen wendet man sich so nach dem Motto?
Das ist eine sehr gute Frage. Hängt natürlich immer aufs Projekt an, oder was genau langsam ist.
Wenn jetzt bei dir zum Beispiel sagst, als Next-Entwickler, Next ist langsam, dann ganz klar schiebt man in Richtung Vercel, macht das Ding schneller, da hat man hier mal einen direkten Ansprechpartner.
Bei anderen Sachen ist es halt oft ein bisschen schwieriger, weil es gibt nicht so diese eine Anlaufstelle. Also der erste Versuch ist immer, ich mache ein Issue bei dem Projekt und sage, hey, irgendwie ist das langsam.
Habt ihr vielleicht eine Idee, wo das liegen könnte? Aber es ist natürlich immer so ein Schuss in den Wald hinein.
Man weiß nicht, ob da irgendwas zurückkommt oder ob da überhaupt eine Antwort kommt.
Also es ist ein echt schwieriges Problem.
[42:26] Ich weiß da echt auch nicht so eine ganze Lösung, oder an wen man sich wenden kann.
Ja, also ich glaube, was man ja früher in der Vergangenheit auch viel gesehen hat, ist halt auf Stack Overflow sieht man halt irgendeine Frage aufpoppen zu einem ähnlichen Thema.
Ich weiß, dass es mir häufig so gegangen ist, dass die Frage halt dann irgendwo schon mal aufgepoppt war.
Oder es gibt schon irgendein Issue und meistens ist ja dann das das Problem, dieses Issue zu fixen.
Und ich glaube, da, wenn man halt reduzierte Testcases bereitstellen kann, oder auch nur manchmal Kleinigkeiten hinzufügen kann, bei so, gerade Open Source Issues oder so, kann das ja schon total hilfreich sein, um das komplette Projekt dann voranzubringen.
Gerade auch, weil man wahrscheinlich selbst auch gar nicht immer die Zeit hat, sich mit diesen Themen zu befassen. Man weiß nur, okay, irgendwas läuft nicht.
[43:24] Jetzt schaffe ich es aber nicht, das zu fixen und so. Und dann kann man vielleicht aber wenigstens die Infos, die man hat, so wenige es sind, halt auch trotzdem teilen.
[43:34] Ja, definitiv. Das merke ich auch immer im Projektumfeld. Das Wichtigste ist eigentlich immer, dass man den Fehler selber auf seiner Maschine sehen kann.
Und wenn man jetzt selber sagt, ich habe hier einen Fehler, ich habe nicht die Zeit, das zu fixen, was auch vollkommen okay ist.
Oder vielleicht ist das nicht mal eine Thematik. Wenn man aber irgendwie schafft, wie du schon sagst, das irgendwie runterzurichten, sei es, keine Ahnung, ein kleines Git-Projekt, was man halt hochladen kann auf GitHub, in kleine Code-Sandbox oder Stack-Bits oder was auch immer für Tools gibt, irgendwie, dass man sagen kann, ich hab hier ein kleines Codeschnipster gefunden oder einen kleinen Projektaufwand und dann, wenn der Entwickler von diesem Projekt das bei sich ausführt, dann sieht er den gleichen Fehler, den ich gefunden habe oder das gleiche Problem.
Weil das ist immer das einfachste, wie man es dann fixen kann.
Das schwierigste ist halt immer, wenn es halt nicht da ist, dann weiß man, okay, es gibt ein Problem, aber ich kann jetzt nur Vermutungen anstellen, weil ich habe das Problem nicht selber gesehen.
Ich kann es auch nicht analysieren, weil ich weiß nicht, wie man dieses Problem aufruft.
Also von wie du sagst, so kleine reproduzierbare Dinge sind Gold wert immer.
[44:37] Und erzähl mal was war deine ausgangslage wie lange musstest du immer warten wenn du dinge gemacht hast und wo bist du dann später gelandet das würde mich mal interessieren also bist du konnte konnte dein flow aufrechterhalten werden nach deinen verbessern beim programmieren.
Ja, ist eine gute Frage. Ich würde mal sagen, ich bin bei vielen Sachen ein ganzes Stück weiter gekommen.
Ich bin immer noch nicht da, wo ich eigentlich sein möchte.
[45:06] Ein gutes Beispiel sind halt die Jazz-Tests. Also Jazz hat mega viel gebracht, finde ich, der Jahreskriptumfeld.
Einfach so das ganze Entwickler-Workflow, den ganzen Test-Watcher hat das nochmal echt einen Meilenstein in die Szene vorangebracht.
Aber wir merken auch irgendwie, das sind Grenzen.
[45:23] Wenn ich jetzt zum Beispiel Tests bei mir laufen lasse, alle lokal, dann kann das schon mal eine halbe Stunde dauern, wo ich denke, okay, das ist jetzt ein bisschen viel.
Und gerade wenn du jetzt so Änderungen machen möchtest, die so ein bisschen größer sind, als jetzt nur so ein kleines Feature, wo du genau weißt, ich muss nur die 10 Tests testen und dann ist okay.
Sondern wo du mehr so was ein bisschen größer ist und wo du mehr alle Tests laufen lassen musst, ist ein bisschen das zu langsam.
Klar kann man auf der CI das schaden und dann ist, keine Ahnung, dass jeder, dass er auch noch parallelisieren ins Gottlose und sonst was.
Sonst was, aber ich will es ja eigentlich lokal schnell machen, damit ich halt schnell damit entwickeln kann.
Und bei Jest ist es halt so, das sind halt oft so 20 Minuten, ich bin Prototyp dran, dass ich, also vielleicht muss ich ein bisschen zurückgehen, innerhalb für das Projektprojekt haben wir halt ein Test-Setup, das ist noch sehr alt, das basiert auf Karma, also würde ich nicht mehr empfehlen, ehrlich gesagt, heutzutage. Aber was wir da halt gemacht haben, ist, Wir haben die ganzen Tests genommen, haben die einmal durch ES-Build gejagt, dass wir einen riesen Bundle haben und laden das einfach so wie es ist im Browser.
[46:26] Das heißt, wir feuern die ganzen Tests gegen die echte DOM API vom Browser, die gibt keine bessere optimierte DOM, also HTML Umgebung als der Browser, weil die ist so gut optimiert.
Und auch dadurch, dass wir die Tests halt bundeln, hat man auch viel unnötigen kurzschritt weggeschmissen und wir können 1000 testen eine sekunde durch ballern das ist mega gut ich habe gedacht können wir das bei gest nicht auch machen so und da habe ich halt gesehen habe ich mal gest geprofiled ist ein bisschen schwäger weil die halt ganz viele child process ist nehmen also es gibt nicht nur einen hauptprozess sondern ganz viele kleinere weil ich halt parallelisieren wollen und da habe ich halt gesehen man denkt man so keine angst dass die Testfunktion zu langsam oder so. Nee, gar nicht. Irgendwie 98 Prozent der Testzeit wird nur damit verbracht, die ganzen Module zu lernen. Also jetzt nur nicht mal so zu transpilieren oder umzuschreiben von TypeScript nach JavaScript und dieses ganze Gedämpftes. Nee, einfach wirklich nur das Modul zu lernen. Das heißt, du siehst immer ein Gest. Du hast zum Beispiel einen in der Testdatei und dann zeigt dir jemand so, die Testdatei hat gedauert irgendwie zwölf Sekunden.
[47:32] Und dann siehst du die einzelnen Tests da drin, irgendwie 30 Millisekunden, 100 Millisekunden, sonst ok wenn ich die jetzt alle addiere dann komme ich auf 320 millisekunden der ganze test hat aber irgendwie zwölf ganze sekunden gedauert irgendwas ist der faul also irgendwas kann ja nicht stimmen und das war dann wirklich echt einfach nur weil diese ganzen module geladen werden und das sind irgendwie 40.000 dateien wenn du jetzt die ganzen npm dependencies und das geht ja immer npm ist ja immer so ein loch praktisch und das dauert halt echt lange und dann habe ich gesagt, okay, du brauchst irgendwas um diesen Module Graph, also das eine Modul importiert man das andere und ich weiß genau, für diesen Test brauche ich die meisten Dateien einfach gar nicht.
[48:15] Kann man das irgendwie wegschmeißen, den ganzen Code, den ich nicht brauche.
Da hab ich mir gedacht, okay, was ist, wenn wir das Setup aus Preact nehmen, wo wir praktisch alles durch ihr ES-Bild jagen, weil das Beste, was ein Bundler machen kann, ist zu erkennen, ob Code genutzt wird oder nicht.
Da sind die Meister drin.
Dann hab ich gedacht, was ist, wenn ich das jetzt einfach vor Jazz knalle.
Und das hab ich dann gemacht und hab dann gesehen, okay, mit dieser Änderung hab ich die Testdatei, die jetzt so 12 Sekunden gedauert hat, Hat jetzt, ich glaub, 400 Millisekunden oder so gedauert.
Also ein bisschen Overhead immer noch, weil man noch extra ES-Build feuert.
Okay, das war dann mit dem ES-Build-Run noch quasi mit reingerechnet schon.
Ja, ES-Build ...
Da kann man ja nicht meckern. Also von 12 Sekunden auf 400 Millisekunden, das hab ich schon, ja, das find ich ganz gut, das ist akzeptabel.
Und jetzt ist halt so ein Prototyp erst mal von jetzt, Und jetzt ist natürlich die Frage, bei uns nutzen halt ganz viel halt diese ganzen exotischen Jest-Features.
Und die müssen dann auch unterstützt werden. Aber das ist so eine Sache, wo ich denke, das ist es wert.
Also es hört sich erstmal komplex an, aber einfach, du kennst es ja selber, wenn du 12 Sekunden bei jeder Erinnerung warten musst, weißt du, es klappt das oder klappt das nicht, dann ist man schon zu lange.
Ich finde, ich sag immer so, alles unter einer Sekunde, oder von mir ist auch zwei Sekunden, ist eigentlich okay.
Aber sobald es dann irgendwie ein bisschen länger dauert, dann ist man schon, mh, schon ein bisschen schwieriger.
Da kann man schon echt viel Lebenszeit sparen.
[49:42] Ja also und du hast ja auch gesagt dass diese 12 sekunden das sind ja sind das ist das dann sind das dann schon alle test oder das ja auch nur ein teil eurer test also das war jetzt für eine einzelne testanteil.
Ja das heißt also wenn man dieses dieses wenn man quasi so ein muster findet das und das dann eben auf alle test anwenden kann das natürlich auch super und dann.
Testet man vielleicht auch einfach generell mehr auch wieder also weil weil es dann eben auch schneller geht und dann muss man sich dann beschränkt man sich vielleicht auch weniger.
[50:20] Ja da sprichst du ein gutes thema das ist aber im performance immer ganz schwierig.
Es geht mal jetzt in unserer Industrie, jetzt wird auch letztens leider viele in USA oder auch viele große Firmen Leute entlassen worden, da ist immer so die ganzen Gerede von wir müssen effizienter werden, wir müssen schneller werden, wir müssen leaner werden, was auch immer.
Und ich finde auch, wenn wir das so auf unsere Tools übertragen, ist ja auch, wir müssen schneller werden, wir müssen effizienter werden und alles.
Ein ganz wichtiger Bestandteil dafür ist auch, dass man viel oder auch schnell experimentieren kann.
Kann. So was passiert, wenn ich die Änderung mache, wie wirkt sich das aus. Das heißt, dann sind wir wieder bei diesem Feedback-Loop. Je schneller der ist, wenn jetzt die Tests zum Beispiel ganz schnell sind oder auch zum Beispiel das ganze Projekt super schnell durchgetestet ist, dann habe ich viel weniger Hürde oder auch Hemmungen einfach zu sagen, keine Ahnung, ich mach jetzt auch eine größere Änderung. Ich gucke mal einfach, ist die sinnvoll. Und wenn du dagegen hast, okay, ich habe jetzt eine Test, die dauert ewig durchzulaufen, dann sagst du, ja, nee, eigentlich, dann dauert das wieder so lange und sonst fange ich besser nicht an das heißt ich sage mal so das ist gehört so ein bisschen zusammen du willst sehr schnelles code schreiben und sonst was und dann brauchst du auch so ein bisschen tools die dich doch wo es auch spaß macht schnell kurz zu schreiben weil du einfach so viel ausprobieren kannst. Das ist halt für mich immer, das gehört zu beides zusammen.
[51:36] Ja nachvollziehbarerweise auf jeden fall genau was mir übrigens auch ein bisschen so gerade in den sinn gekommen ist es gibt ja so dieses.
Also das ist indirekt damit zu tun aber man sagt ja auch mit schnelleren verkehrsmitteln also mit schnelleren zügen und solchen dingen, da könnten leute ja schneller einfach zur arbeit kommen oder sowas und alle verbringen weniger zeit beim auf der straße und auf der schiene und so und aber tatsächlich ist es so dass die leute immer gleich viel zeit.
Mit reisen verbringen und dann einfach nur ihren radius erhöhen können und so ein bisschen finde ich ist das bei diesen.
Tools ja auch. Also es gibt so einen Sweet Spot, den man irgendwie ausschöpft, der, wenn er irgendwie länger dauert, dann ist es halt doof.
Und wenn es viel schneller geht, dann belässt man es nicht dabei, sondern dann packt man halt einfach noch Dinge oben drauf, die man noch so macht, Macht oder mit dem man sich sein leben besser macht oder man schreibt einfach immer mehr code und kommt eigentlich idealerweise immer bei diesem.
Bei diesem sweet spot wieder raus.
[52:57] Genau und das da willst du ja auch wieder hin sozusagen von der von der von von oben willst du da wieder runter und die die meisten arbeiten sich ja eher so von unten auf diesen sweet spot hin.
[53:11] Ja das ist definitiv ein argument. ist natürlich je schneller die Sachen sind, desto mehr Möglichkeiten eröffnen sich auch.
Das sieht man auch, ich finde die ES-Build ist so ein Paradebeispiel dafür.
Was hat erstmal gezeigt, okay, es geht wirklich schnell, ja was gibt kurze Bundle, vorher hat das keiner so wirklich geglaubt und dann kommt irgendjemand her, macht das einfach.
[53:32] Und zeigt allen, nee Moment mal, das geht wirklich schnell, wenn man es nur richtig aufzieht.
Und das wiederum hat jetzt uns zum Beispiel auch ermöglicht, das da auf diese Tests anzuwenden, weil das hat wieder uns die Tür geöffnet, weil es einfach so schnell ist, also diese Bundling-Zeit von der Est-Bild, wie das dauert, um alle Dateien in eine zu flanschen, das kann man fast vernachlässigen, weil es einfach so schnell ist und dass man es gar nicht mehr berücksichtigen muss und das öffnet wieder die Türen halt uns, die Tests schnell zu machen und so sehe ich es halt auch, was ist mit dem nächsten Tool, was wir schnell machen. Wenn wir das, ich weiß jetzt kein gutes Beispiel, aber nehmen wir mal auf einmal Linting ist super schnell, das heißt ja, wenn das so super schnell dann kann man es auch viel besser zum Beispiel in online IDEs integrieren, weil es schnell genug ist.
Ihr kennt vielleicht alle bei größeren Projekten, man tippt irgendwas und dann dauert es 10 Sekunden, bis dann die roten Striche weggehen und dann die roten Striche wieder in die neue Stelle eingesetzt werden und so.
Wenn das halt sofort instant wäre, das würde ja auch wieder neue Sachen ermöglichen.
Das würde es auch wieder vielleicht leichter machen für neue JavaScript Entwickler, die sich noch nicht so vertrauen mit den ganzen Tools.
Also ich habe es halt oft bemerkt, wenn ich damit Jugendlern entwickelt habe, dass die echt verwirrt waren durch langsame Tools, Tools, weil die sagen, warum ist das hier rot angezeigt? Ich habe das doch gerade korrigiert.
Und das ist einfach, das Tool hat noch hinterhergehangen. Das war noch nicht so schnell.
Das hat noch ein bisschen gebraucht, um die neuen Änderungen zu verarbeiten.
Und das eröffnet dann auch wieder neue Türen.
[54:53] Man kann es noch nicht so ganz voraus schauen was das für neue türen eröffnet man kann vielleicht ein paar vermutungen anstellen aber das ist eigentlich auch so das spannende also man weiß nie was andere leute damit machen und das sei ja das coole, komm immer super tolle ideen bei rum.
Aber das deutet ja auch darauf hin, dass das möglicherweise auf ein Mix hinausläuft, also aus so einer Prise neuer, bahnbrechender Tools, aber eben auch ganz, also gepaart mit ganz viel bewährter Tools, und die einfach sozusagen Hand in Hand zu einem besseren Developer Experience dann führen.
[55:35] Ja, was die bestehenden Tools halt echt unschlagbar haben, vielleicht sind es nur Tools, ist meistens eine echt große Test-Suite.
Die haben schon alle möglichen Edge-Cases gefunden oder sonst was oder auch eine gute Übersicht über das, was die Developer, wie die halt die Tools benutzen und wie die die benutzen wollen.
Und das geht meistens auch so ein bisschen verloren, wenn was neu geschrieben wird.
Also so dieses Wissen, was denn diese Test-Suite oder die alten Tools schon drin ist, weil da so viele Entwickler mit schon gearbeitet haben, ist dann oft nicht mehr da. Aber ist natürlich auch eine Chance, weil die haben viel Erfahrung gesammelt, vielleicht merkt man, okay, so wie wir dieses Tool gemacht haben, das macht eigentlich heutzutage keinen Sinn mehr.
Kein Sinn ist vielleicht hart zu sagen, aber ich erinnere mich auch, wie du schon eben sagtest, damals in die SAS-Geschichte, wo es erst durch Ruby ging, dann durch C, jetzt mittlerweile sind die, glaube ich, bei Dart gelandet.
Mit Ruby hat man echt gemerkt, zu C, das war ein Riesensprung von der Geschwindigkeit.
Das hat schon viel gebracht, aber dadurch, dass sie halt auch so viele Tests hatten, ich vermute mal, dass die Entwickler bei der C-Variante sehr viel von den Tests in der Ruby-Variante profitieren konnten.
Da hat schon jemand herausgefunden, diese ganzen Edge Cases, die muss ich alle bedienen, damit ich dieses Tool ersetzen kann.
Das ist halt echt wertvoll.
[56:53] Ja, du hast ja gesagt, dein ursprünglicher Ansatz war, dass du gesagt hast, ich finde Stellen im Code, die ich verbessern kann.
Und ich versuche auch entsprechend, diese Verbesserung bei den Projekten irgendwie ein-, also dass die quasi, ich versuche, die an die Macher ranzutragen und dass die das auch dann merchen.
Und dann hast du ja gesagt, du hast festgestellt, Das skaliert einfach nicht, wenn du das alleine machst.
Und darum war dann deine die Strategie 2.0 eben den Leuten so dieses Wissen drauf zu schaffen mit den deinen weiteren Blogposts.
Und hast du denn da Feedback bekommen von Leuten?
Also hat das funktioniert? Ist dein Plan aufgegangen?
Und welche Projekte haben davon profitiert?
[57:55] Ja, ähm ... Ich war mir am Anfang echt unsicher, weil es war so ein Versuch, einfach mal, ich hausse jetzt mal einfach in die Welt hinaus.
Mir war auch echt gar nicht so wichtig, ob die Leute reagieren, sondern ich wollte für mich einfach sagen, ich hab jetzt mal irgendwas rausgebracht.
Ich war auch so ein bisschen stolz auf diese Artikel, weil ich das Gefühl hatte, dass es so was noch nicht gab.
Sind. Ich habe dann gemerkt, dass es halt relativ gut eingeschlagen ist auch, also wurde auch teils, auf Hacker News geteilt und auch auf Reddit und verschiedene auf Twitter auch mehrmals rumgeteilt.
Ich habe hier irgendwie so ein bisschen so einen Nerv getroffen. Dann gab es dann einige, die dann auch gesehen haben, okay ich habe jetzt den Blogpost gesehen, zum Beispiel AESLint war eine große Diskussion, die Akteure einfach gesagt haben, da gibt es so eine große Diskussion bei den sollen wir in rastreiben Ist ja ein guter Ansatz, weil das ist eine schnelle Programmiersprache, verspricht sehr viel Performance, macht das Sinn.
Und ich habe ja zu der Zeit auch so einen Blogpost gemacht und dann hast du dann auch die Entwickler von YesLint auf mich zugegangen und gesagt, hey, mega cool.
Das hat dann auch so ein bisschen was losgetrieben, wir haben ein bisschen dann gechattet halt ein bisschen so, hey, was mit dem, was mit dem.
Die wiederum haben sich jetzt mit den ganzen anderen, also ich habe auch bei YesLint zum Beispiel gerade geschrieben, das sind die populären Tools, die oft zusammen mit YesLint benutzt werden.
Und das hat nochmal so ein bisschen irgendwie einfach so ein bisschen Freude gebracht, den Entwicklern.
Die gesagt haben, komm wir gehen uns mal an einen Tisch und fragen uns einfach, was brauchen wir eigentlich voneinander?
[59:24] Also was, z.B. die Typescript-Variante, was braucht ihr, damit ihr gut mit dem ESLint Core arbeiten könnt?
Oder dieses Babel-Plugin oder so. Und auf einmal haben die Leute miteinander gesprochen, was sie halt vorher nur so ein bisschen gemacht haben, aber nicht so wirklich.
So, die haben jetzt mal wirklich gesprochen, was brauchen wir?
Und ich sehe das immer mehr, das ist jetzt ein Beispiel, aber ich sehe es auch in vielen anderen Projekten, wo Leute einfach.
[59:47] Das waren schon die richtigen Leute da, aber die haben irgendwie noch nicht miteinander gesprochen.
Und auf einmal reden die miteinander. Und auf den Weg sind auch nach dem Artikel über Modular Resolution gerade im Enode, sind dann einfach ein paar Leute aus dem Node-Team oder aus dem Chrome-Team auf mich zugegangen und haben, hey cool, wie ist denn das mit dem und dem und was sagst du dazu?
Dann bin ich einfach an ein Meeting von denen gejoint, wo wir einfach über Modular Resolution in Node gesprochen haben, weil dann, wovon ich eben erzählt habe, dass immer so viele Fehler geschmissen werden, dass dann einfach abgefangen wird.
Genau den gleichen Fehler machst du innerhalb der Note auch.
[1:00:22] Dann hab ich halt gesehen, oh stimmt, das können wir verbessern.
Und so irgendwie tun sich dann so ganz viele Sachen auf, wo dann Leute schreiben, oh, also irgendwie, ich kenn die Leute teilweise gar nicht, aber die kommen dann auf mich zu.
Und ich freu mich mega einfach mehr Ausdauer zu haben, einfach mit den Leuten drüber zu quatschen und irgendwie zu sehen, dass das auch Leute irgendwie so ein bisschen packt und auch sagen, geil, ich will da auch mitmachen.
Ich seh auch, dass ich meine Tools schneller machen kann.
Und das ist eigentlich das Schönste, wenn man zu sehen, dass die Blogposts, die ich so geschrieben hab, irgendwie dann auch Leute Freude so ein bisschen bringen.
Oder auch Begeisterung, sich ein bisschen weiterzuentwickeln, was Neues zu probieren. Und das ist eigentlich das schönste Feedback, finde ich, was man nur bekommen kann.
[1:01:05] Ja, das ist auch ein tolles Thema. Also ich finde, das passt aber auch zu dir, so wie du ja auch schon im Projekt irgendwie lange mitmischt das ist ja auch so so ein bisschen so dass ihr einfach was bestehendes genommen habt und gesagt habt das implementieren wir jetzt aber nochmal in ganz anders und performanter und kleiner das das geht doch alles besser und so ein bisschen die Kerbe hast du ja auch geschlagen und du hast wahrscheinlich da einfach irgendwie Für manche, die quasi so im Limbo waren, aus was machen wir jetzt?
Geben wir jetzt unser JavaScript-Projekt auf und machen Rust?
Oder gehen wir irgendwie nochmal an die Codebase ran und verbessern die?
Du hast denen da irgendwie einen neuen Weg aufgezeigt, würde ich sagen.
[1:02:00] Und ja, es ist einfach so, in so interner, da so rumzunerden, ist einfach immer, immer super spannend und cool.
Also deswegen auch so ... Also ich hab das auch sehr gerne gelesen.
Fand ich total gut.
Ja, das freut mich zu hören. Also ich fand mich halt echt unsicher, ist das jetzt zu krass nerdig und so? Nee, gar nicht. Das ist total ...
Also, so alle Arten von Artikeln sind cool, aber man braucht halt dann ab und zu ...
Muss will man auch so ganz tief rein in in das genörde und ja das ist irgendwie auch sehr befriedigend und auch ein stück weit so hey cool ich habe jetzt geheimwissen so danke marvin so.
Ja, man sieht ja eigentlich gerade, dass das nicht Geheimwissen ist.
Nee, nee, eigentlich nicht.
Nee, also genau, aber es ist vielleicht, also offenbar beschäftigt man sich damit nicht so viel oder man kleistert eben vielleicht immer nur mehr Schichten obendrauf, anstatt nochmal so die unterste Schicht nochmal so zu untersuchen und zu gucken, was kann man da gut machen oder besser machen.
Bis zum nächsten Mal.
[1:03:18] Ja das sehe ich halt auch für und ich wollte auch so ein bisschen mit dem blog post auch irgendwie zeigen das macht also mir persönlich macht das super viel spaß auch einfach so ein bisschen direktiv spielen so ein bisschen so die murder mystery was finde ich jetzt hier was, was könnte daran schuld sein dass es so ein bisschen so lange dauerte und das macht auch spaß also klar macht es nicht jedem spaß kann ich vollkommen verstehen aber mir macht spaß und ich wollte die freude auch irgendwie so ein bisschen teilen auch irgendwie zeigen dass es, Das was cool ist, weil man hat danach ja auch so ein Ergebnis und auch so ein Eigennutzen, gerade wenn man jetzt Entwicklertools verbessert, die man selber tagtäglich anbaut und benutzt und die auf einmal schneller sind oder irgendwie flüssiger sind, das irgendwie, das mag sich vielleicht jetzt ein bisschen dämlich anhören, aber mich macht das glücklich, ich denke mir so, ey, das ist mal geil, das ist so ein Erfolgserlebnis, immer so ein freudiges Gefühl einfach, ich denke, juhu, ich hab irgendwas schneller gemacht und dann fühle ich mich auch manchmal, wenn ich irgendeine große Optimierung gefunden habe, dann fühle ich das Kommando irgendwie mehrmals aus, ich denke, boah, geil, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja cool, das ist ja Weil das jetzt so schnell ...
Da wisch ich mich dabei immer selber schon ein bisschen peinlich.
Ich freu mich halt einfach, dass man so was gefunden hat.
Und dass dann klappt einfach, dass der Plan dann so praktisch, den man sich vorher ausgehackt hat, das könnte das sein, das könnte das sein.
Und auf einmal geht der auf. Das ist halt megacool.
Ja, super. Kann ich nachvollziehen.
[1:04:35] Und jetzt das Einzige, was jetzt noch fehlt, ist, dass du irgendeine KI jetzt noch anlernst, die deinen Job dann macht.
Also so einen quasi GitHub Copilot artigen Assistenten, den man auf so Code-Basis loslassen kann.
Das wäre natürlich schon mega krass, aber ich glaube, da sind wir noch echt weit von entfernt.
Das ist auch Chat-GPT in so einem Fall ist mega geil.
Aber ich habe so ein bisschen das Gefühl, die denken halt nicht wirklich nach, sondern die ziehen halt einfach so aus so einem riesen Wissensding und machen so ein Pattern-Matching, auf was könnte so ähnlich sein, da reinpassen, da kommt auch auf Cowder-Welch raus.
Und ich glaube, das Schwierige bei Performance ist auch, man muss eigentlich so ein bisschen so von wegen, was will der Code, den ich vor mir habe, was will der machen, was ist das Ziel von dem Code?
Und passt das was in wirklichkeit macht auch dazu was er machen will über auf sind es so ein bisschen so zwei welten aus gelangt über ganz viele umwege zu dem ziel man könnte eigentlich den direkten weg nehmen.
Das ist ja voll zu dem wissen so ein tieferes verständnis von dem was eigentlich passiert von da bin ich ich glaube nicht dass das so schnell mit der ki und so passiert aber wir lassen uns überraschen einfach mal.
Na ja, jetzt sind ja deine Blogposts da draußen und auch einige und du wirst vielleicht noch ein paar schreiben und wie wir alle wissen wird das ja alles dann wieder in die nächsten Chat-GPT-Trainingsdaten einfließen.
[1:06:03] Und mal sehen. Das wäre natürlich schade, aber ja, könnte passieren. Ja, super.
Aber das ist doch also erstmal ein guter Ausblick auch. Und aber das war auch sehr spannend und interessant.
Und genau wer das noch nicht gemacht hat, dem empfehlen wir mal durch die Links zu stöbern, die wir in die Show Notes packen werden.
Wo natürlich auch diese Blogposts drin sind, wo auch hier euer Ansatz ist, Einsatz ist mit den 1000 Tests in einer Sekunde im Projekt. Das werden wir verlinken.
Genau noch ihr Speed Scope und Patch Package.
[1:06:49] Ja toll dass du da warst mal wieder macht macht immer spaß. Bitte weitermachen und genau du schaust oder wir hauen dich einfach nochmal an bei deinem bei deinem nächsten.
Krassen ding dass du raushaust.
Ja, vielen Dank, dass ich da sein durfte. Also hat mir wieder Spaß, abzuhängen. Ich hoffe, dass ich wieder was Spannendes habe. Ich glaube, diesmal war das Thema schon ganz, ganz ungewöhnlich. Und mal schauen, vielleicht findet ihr nächstes Mal auch wieder was Cooles.
Bleibt gespannt. Auf jeden Fall. Bei dir mache ich mir da keine Sorgen. Ich hoffe es. No pressure.
Ach, viele Grüße nach, äh, hier, Harn.
Viele Grüße nach Köln an den Hans. Danke an die Hörerinnen und Hörer fürs fleißige Mithorchen.
Wenn ihr Fragen habt, findet ihr Marvin auf Twitter. Und machst du dann auch, ne? Oder?
[1:07:53] Ja, machst du dann auch, ja. Genau, verlinken wir auch.
Und ihr könnt aber auch an commentsatworkingdraft.de schreiben.
Oder ihr schaut in unserem Community-Snack vorbei, den ihr unter draft.community findet.
Oh, da bin ich noch gar nicht drin, da muss ich direkt mal joinen.
Ja, genau. Also der eignet sich dann für komplexere Austausche besser als Twitter oder E-Mail.
Also kommt da gerne rein. Da sind auch diverse andere Hörerinnen und Hörer und ehemalige Gäste drin. Und dann, genau, hören wir uns Woche wieder, wo wir auch wieder einen Gast haben, dessen Name mir natürlich gerade entfallen ist, aber der auch schöne Sachen zu berichten hat.
Bis dahin macht's gut, tschüss bis dahin tschüssi tschüssi. Ciao!
[1:08:48] Music.
[1:09:16] Untertitel im Auftrag des ZDF für funk, 2017.