News 12/25 –

TypeScript Compiler Rewrite // Vue Vapor Mode // Vite Plus // GitHub Actions Supply Chain Attack // Lynx // Siri Delay // AI Coding

19.03.2025

// Podcast
// News 12/25

Shownotes

Wir dürfen (endlich!) mal wieder Sebi in unserer Runde begrüßen – und er hat eine ganze Ladung Themen mit dabei! Wir erfahren von Sebi, was sich hinter dem TypeScript-Compiler-Rewrite in Go verbirgt und mehr über den aktuellen Stand zu Vue 3.6 und den sehnlichst erwarteten Vapor Mode.

Gespannt warten wir auf die News rund um Vite Plus und die angekündigte Dokumentation zu Vite von techdocumentaries.com.

Weil unser Security-Dave aktuell im Urlaub ist, gibt es von Jan die Zusammenfassung zur neuesten Supply-Chain-Attacke in GitHub Actions via tj-actions und – ganz frisch von Wiz aufgedeckt – reviewdog.

Außerdem hat ByteDance, die Firma hinter TikTok, mit Lynx eine eigene Alternative zu React Native veröffentlicht – natürlich darf das in unserer Diskussion nicht fehlen!

Zum Abschluss versorgt uns Dennis noch mit ein paar kleinen News aus dem AI-Bereich, in dem wir zwar etwas länger auf die neue Version von Siri werden warten müssen, aber dafür schon jetzt an unseren Software Development Skills feilen können, um zukünftig noch besser mit AI kollaborieren zu können.

Download

/transkript/programmierbar/news-12-25-typescript-compiler-rewrite-vue-vapor-mode-vite-plus-github-actions-supply-chain-attack-lynx-siri-delay-ai-coding

Dennis: Hallo und herzlich willkommen zu 1 neuen programmier.baren News Folge 12 2025. Ich bin Dennis und ganz nah neben mir sitzt
Sebi: Der Sevi, hallo.
Dennis: Den wir endlich mal wieder hier haben Huuuuh. Da wir urlaubsbedingt ein bisschen Ausfälle haben. Deswegen Du sagst erst mal Du bist Ersatz heute, aber
Sebi: Ersatz vom Ersatz, aber schön wieder hier zu sein.
Dennis: Schön, dass Du da bist Sevi. Und zugeschaltet ist uns auch
Jan: Ja, Jan, ganz frisch aus dem Urlaub gekommen vor ungefähr 2 Stunden oder so. Frisch aus dem Urlaub? Frisch erholt würde
Dennis: man gerne sagen, aber es ist 'n bisschen Augenringer, bist Du über Nacht geflogen?
Jan: Also tatsächlich sind wir, hatten wir 'n Über Nachtflug, ja. Aber ich muss, also ich hab heute Morgen gespielt, dachte ich, ich seh eigentlich noch relativ erholt aus, aber danke Dennis. Danke.
Dennis: Sehr gut. Das ist das ist die Kamerabeleuchtung.
Jan: Ja, ja, ja, ich mach hier guck mal, ich hab hier son tolles, hipster Lichtkur. Jetzt ist alles.
Dennis: Oh, jetzt sieht er Viel
Jan: viel besser.
Dennis: Ja. Sehr gut. Sehr gut. Wir reden heute über type Script und Go. Oh, das hat irgendwas miteinander zu tun neuerdings. Dann gibt es einen neuen Versuch, wieder ein neues Framework zu starten mit links und es gibt ein Update von View. Dann gab es so, da Dave nicht da ist, muss Jan das heute übernehmen, son Security Incident, also das heißt Security Day wird heute ersetzt mit Jan. Und ich hab noch 'n bisschen kurzes Update zu Siri und einen Artikel über AI, den wir son bisschen andiskutieren können und ja, als Gedankenfutter für euch für die nächsten Tage und Wochen. Sibi, magst Du vielleicht einsteigen mit type Skript und Go? Wie passt das zusammen? Was hat das miteinander zu tun?
Sebi: Okay, dann ja. Und zwar diese Woche, war glaub ich diese Woche, haben die Leute von Microsoft, die sich ja für typecript verantwortlich zeichnen, announced, dass sie den typecript Compiler komplett von vorne nach hinten in Go neu schreiben und dadurch die Performance den Faktor 10 steigern möchten. Und das ist eine, ja, eine coole Neuigkeit. Wir freuen uns alle sehr. Das hat dann Auswirkungen, also jetzt nicht nur darauf, dass da halt mein Projekt irgendwie schneller getypeechegt werden kann, sondern eben auch die ganze das Tooling in der IDI und so weiter wird dadurch super viel schneller. Freuen wir uns alle drauf. Interessant war der, dass sie sich für Go entschieden haben und nicht für Rust. Und sie haben ja auch selber gesagt so, dass den das größte, der größte Nachteil, dass sie keinen Rust verwendet haben, ist, dass sie lauter Fragen beantworten müssen, warum keinen Rust?
Jan: Das war eigentlich so, dass er das ja
Sebi: der größte Pain Point in der Sache, aber ansonsten hat sich go einfach als bequemere bequemere Transpilationssprache so für, also der aktuelle Compiler ist in Javaskripte geschrieben und den nach Go zu portieren ist viel einfacher, weil eben auch Garbage Collection und so weiter Und der Performance Gain, den man gewinnen würde durch Rust, wär jetzt nicht so substanziell gegenüber von Go. Die hauptsächliche Performancesteigerung wird durch die Parallelisierung in Go erzielt. Und ja, und das ist irgendwie ganz cool. Die der neue type Skript Go Compiler kann man sich übrigens auch schon über aufm Mac installieren. Es funktioniert auch schon einiges, aber es hat noch nicht ganz Feature Complete. Auf der Roadmap steht, dass wir bis Ende diesen Jahres das Ding fertig haben wollen. Ah. Okay. Und ich glaub son early early Preview im Sommer oder so. Aber nichtsdestotrotz, man kann's jetzt auch schon, also wie gesagt, beim Über Bruce Mhm. 'n bisschen anspielen. Ist cool, oder? Ja,
Dennis: ist cool.
Sebi: Ich hab Was
Dennis: gibt, wie viele Edge Cases gibt es so, wenn man das macht? Oder das ist relativ klar. Also ich stell mir jetzt grade vor, wenn ich 'n Compiler, Mhm. Mit dem ich keine Ahnung hab, wenn ich den umschreiben will.
Sebi: Ich glaub, das ist ganz cool, dass die das halt nicht neu schreiben komplett, sondern dass sie, also sie haben auch son Gegenüberstellung gemacht vom Javascript und dem Go Code Und da können die das, glaub ich, relativ gut so rüber nehmen. Okay.
Jan: Und das ist ja auch relativ einfach testbar, ne? Also Du wirfst halt Quelltext hin, kompilierst das und führst ihn danach aus und kannst halt supergut evaluieren, ob er all deine Cases berücksichtigt oder nicht.
Dennis: Genau und dann ist halt nur die Frage, hast Du alle Cases?
Jan: Gut, aber das also das Problem hätten Sie ja jetzt auch schon.
Dennis: Ja. Ja. Ja klar, wenn Du, ich mein, deswegen also wenn wenn was sie gesagt hat, wenn Du's irgendwie versuchst, 1 zu 1 praktisch deinen Code einfach upzudaten und da sind ja dann alle Use Cases drin, die aktuell abgedeckt werden, dann ist es relativ einfach versus Du gehst irgendwie neu aus son Ding und sagst, oh, wir wollen jetzt 'n neuen Computer und das soll rauskommen. Ja. Das macht's natürlich schwieriger. Aber ja, okay, cool. Genau.
Sebi: Und dadurch, dass Sie die eben Go genommen haben, schreiben Sie auch, dass Sie eben diese ambitionierte Deadline Deadline, also dass Sie es halt dieses Jahr fertig bekommen, weil wenn Sie's jetzt von von ganz von vorne in Rust hätten schreiben wollen, dann wär's halt 'n Mhm. Unterfangen von mehreren Jahren gewesen wahrscheinlich. Okay. Klar. Und in dem Zuge
Dennis: Mhm.
Sebi: Möchte ich mitteilen, dass die Leute von View, die Leute, also halt die das Chor Ja. Core Maintainer von View, Ja. Even View et cetera, Wussten auch von diesem bereits seit letztem Jahr. Der ist jetzt zwar erst announced worden, aber das ist natürlich schon 'n bisschen länger in der Mache. Und er hat son bisschen über die Roadmap von View in der Keynote der Viewjar Amsterdam erzählt und ein wenig über View 3 Punkt 6 gesprochen. Wir sind ja aktuell bei View 3 Punkt 5, also dieser Juni dieses Frontend Framework, wo Reaktivität et cetera mit drin ist und so weiter. Und Sie haben einmal mehr, also Sie haben in der Vergangenheit das öfter gemacht, einmal mehr das komplette Reactivity System noch mal aufn Kopf gestellt und neu geschrieben, was allerdings nicht in Userfacing API Änderungen mündet, sondern man kann's nach wie vor bedienen, das wird einfach schneller in der View 3 6. Da bedienen sie sich, oh Gott, Alien Signals. Ja, so heißt das Projekt. Die sind dann eingebaut und er hat ein wenig erzählt über den Vapormode, den wir ja jetzt irgendwie schon Jahre mittlerweile warten. Der soll als experimentell in 'nem View 3 6 mitkommen.
Jan: Kannst Du einmal erklären, was das ist für alle, die nicht jeden Tag View benutzen und darauf warten?
Sebi: Sehr gerne. Also Vapormode, aktuell ist es so, wenn ich eine View Komponente verwende, dann wird diese Reaktivität und das Rendering alles über die View Run time gesteuert und Vapormode ist, dass meine Viewkomponenten in mehr imperatives JavaScript kompiliert werden, so wie Svelt. Mhm. Und Solid. Und soll dann in, je nach Anwendungsfall eben zur besseren Performance führen, weil man ja, das fällt halt dieses w w wenote Diffing dann weg. Ja. Die Benchmarks sind natürlich, wenn er sie präsentierte, Evan View hervorragend. Also aber ich fand's ganz gewiss, er hat gesagt, so nach, also seit View rausgekommen ist oder in den letzten Jahren redet man eben nicht mehr da rüber, dass View irgendwie besonders schnell sei, sondern halt nur schnell genug. Und mit der Änderung in Vapormode ist es eben performancetechnisch auch wieder vorne dabei. Wird vorne dabei sein.
Jan: Und soll das dann der Default Case sein oder muss man das so optional wollen?
Sebi: Das ist superspannend, weil man kann das Mix and Match, also Du kannst bestimmte Komponenten im Vapormode betreiben und den Rest nicht. Das heißt also, Du kannst eine bestehende App sukzessive auf Vapormode umbauen, falls Du das brauchst. Muss aber nicht. Können ja auch nur so performance kritische Komponenten irgendwie anders sein. Kannst aber auch, wenn Du 'n neues Viewprojekt startest, son View create Vapor oder irgendwie sowas aufrufen, also dass die ganze View Run time dann nicht mehr in deinem Projekt gebandelt ist, weil für Vapormode brauchst Du ja die Run Time nicht mehr. Mhm. Das heißt, das wird dann alles 'n bisschen kleiner.
Dennis: An der Stelle können wir 'n bisschen Werbung machen für den Talk, den Garlet hält auf der NTAGS, weil es da ja Reaktivität geht, das mal grundsätzlich 'n bisschen zu erklären und zu erläutern und vielleicht, weiß ich nicht, macht's da am Ende einen Ausflug Signals, zu gucken, was da denn unter der Haube noch die Optimierungen sind, wenn man einmal die Basisimplementierung davor verstanden hat.
Jan: Wenn wir es hier fest genug behaupten, macht das vielleicht einfach.
Dennis: Hast Du 'n Datum im Kopf, RTL Jazz?
Jan: Nein, Du hast mich kalt erwischt. Mai.
Dennis: Okay, irgendwann im Mai. Ja, das hätte ich auch wissen, soweit. Aber Sekunden. Also genau, im Mai Dritter
Jan: Dritter bis achter Mai. Siebter bis achter, sehr gut. Sehr gut. Highspeed Googeling.
Dennis: Highspeed Googel. Boah. Ist schneller als ChatGPT.
Sebi: Letzte Sache, die ich spannend finde, also auch keine super News, aber wird kommen, weil Evanview hat von, also er ist ja auch im Viet Projekt mit drin. Viet ist ja dieser Bundler, so was im Viewuniversum angefangen hat, sich dann aber Framework Agnostisch geöffnet und jetzt von mehr oder weniger jedem Framework verwendet wird als Unterbau außer Next. Und er hat gesagt, dass es, was in der Mache das Ende des Jahres kommen wird, das nennt sich Veed plus.
Dennis: Oh, ein Abo.
Sebi: Klingt wie 'n Abo, ja. Stimmt. Und das ist es aber nicht, sondern das soll sein, das Cargo für Javaskripte Entwickler. Oh. Und zwar Cargo ist ja dieser Dependency Manager, Bild Manager, alles alles irgendwie bei Rust unter der, also alle möglichen Befehle werden dadrunter vereint, unter anderem auch Linting und Formating. Und so was haben sie sich irgendwie vorgenommen, auch für Java Script und Hypescript zur Verfügung zu stellen und das finde ich eigentlich 'n superspannende Sache, weil das ist ja schon relativ fragmentiert aktuell und 'n viel Konfigurationsaufwand. Und Deno hat das ja eigentlich auch ganz schön gemacht, dass das auch Deno, also bei Deno gibt's ja auch schon Formating und Lintig und so, out of the box. Und ja, und wenn die da jetzt einmal richtig draufhauen, glaub ich, spannend. Also man weiß ja jetzt noch nicht, was das ist, aber was haben sie sich vorgenommen Ende des Jahres? Auf jeden Fall gute Dinge. Okay. Und da fällt mir grade ein, es kommt eine Dokumentation raus über.
Dennis: Auf welchem Kanal?
Sebi: Jan. Können wir vielleicht dann auch mal hier so wieder gucken? Ich weiß nicht. Aber es ist
Jan: auch diese Honeypod Serie oder was?
Sebi: Das weiß ich nicht. Hab nur gesehen, es gibt eine Dokumentation mit Eventview interviewt und so weiter.
Dennis: Das kann der Jan schneller googeln im Hintergrund.
Jan: Tatsächlich hab ich das grade versucht und finde nichts.
Dennis: Okay, ich Google weiter, während Du, Jan, uns ein Update gibst zu, oder? Sibi auch so fertig.
Sebi: Links kann ich
Dennis: Das können wir's so gleich.
Sebi: Mach ich gleich. Ja.
Dennis: Bevor Johannes 'n kleines Update aus der CICD Security Pipeline gibt.
Jan: Ja. Ich mach ja die Woche den Dave und red 'n bisschen über Security, weil der Dave nicht da ist. Und zwar ist mir das Thema am siebzehnten, also jetzt am Wochenende über den Weg gelaufen, aber hat sich wohl schon Mitte letzter Woche ereignet. Und zwar gab es einen Supply Chain Angriff und das sind ja so Angriffsvektoren, über die wir hier schon 'n paarmal gesprochen haben, weil das immer weiter so auf dem Vormarsch ist. Und zwar ging es da das Paket TG Action oder ist eine eine eine Reihe von Paketen und insbesondere auch sind das GitHub Actions. GitHub Actions sind ja diese kleinen modularen Bausteine, die ihr nehmen könnt, eure CICD Workflows auf GitHub quasi aus wiederverwertbaren Modulen zusammenzubauen. Und was da jemand gemacht hat, das hat eben dieses Paket genommen, was im Prinzip 'n relativ kleinen Scope hat, euch zu sagen, hey, für den Commit, wo gerade diese Pipeline läuft, welche Dateien haben's denn eigentlich geändert? Das braucht man, Linding zum Beispiel betreiben zu können auf den Dateien oder wenn man 'n Test Coverage beurteilen will oder so was, das ist immer ganz hilfreich zu verstehen, was hat sich dann irgendwie grade, welches Change hat's denn hier in diesem Commit irgendwie drin? Und weil GitHub das nicht out of the box bietet, gibt's da eben eine eine Action für. So, was hat da also jemand gemacht? Dieses Paket ist quasi infiltriert worden und da wurde ein bisschen Code eingeschleust, der im Prinzip die Laufzeitumgebung nach Umgebungsvariablen durchforstet und das dann einfach in den Bild lock reindammt. So und noch noch 'n bisschen Base 64 encoded, weil normalerweise GitHub ja automatisch Umgebungsvariablen, die geprinted werden, ins Log so maskiert, damit eben genau das nicht passiert, dass das nicht im Log liegt. Wenn man den ganzen Logoutput allerdings Base 64 encoded, dann fällt dem Maske das nicht mehr auf und dann landet das so im Log und jeder Angreifer kann sich dann das Log anschauen und eben eine reverse encoden und dann eure Umgebungsvariablen anschauen. Und da kann ja alles Mögliche drinstecken, da können AWS Secrets drinstecken, Tokens für andere Services, API Keys, Signaturschlüssel, alles, was man eben so braucht. Und genau das ist halt dann auch so passiert. Dadurch, dass das in Anführungszeichen nur in das Lock reingelegt wird, ist es natürlich erst mal am allerkritischsten für die Repositories, die Open Source sind, weil bei Open Source Repositories natürlich auch die Bild Logs offen sind. Das heißt, wenn jetzt ein Paket wie, weiß nicht, Sebi hatte grade Weed angesprochen, ja, wenn jetzt Weed in seiner Pipeline t j actions irgendwo benutzt, könnte man jetzt öffentlich einsehen, was für environment secrets da irgendwie alle grade mit gebraucht werden in diesem Bild Step. So. Das ist natürlich super-, super ungünstig und wirft die Frage auf, wie konnte es dazu kommen? Und was da offensichtlich passiert ist, ist, dass ein Botuser aus dem t g actions User Maintainer Kreis, wer auch immer, sein sein Token geleakt hat und dementsprechend diese ganzen Änderungen an dem Repository im Namen dieses Bots gemacht worden sind und dementsprechend auch erst mal nicht aufgefallen sind, weil der Bot macht jeden Tag superviel dadran, ja. Und das kontrolliert ja auch in der Regel niemand, weil alle trauen ja so diesen automatischen Bots, so. Und was auch gemacht wurde, ist, dass nicht einfach nur eine neue Version released wurde mit diesem eingeschleusten Schadcode drin, sondern einfach alle Versionstext oder die meisten Versionstext umge worden sind auf nicht eben ihren korrekten Release, sondern im Prinzip ein Angreifer einen oder mehrere neue Releases erstellt hat und alle Versionstext dann darauf gepointet hat. So, das heißt egal welche Version ihr verwendet habt von t j actions, 1 Punkt 1, 2 Punkt 3, was auch immer, die haben alle auf eben eine neue schädliche Version gezeigt, weil das ja so ein Fluch und Segen bei GitHub ist, dass man Versionen und Tags im Prinzip immer wieder neu vergeben kann und sie nicht nicht sozusagen sind. Also ich kann Versionen, die ich in der Vergangenheit released hab, unter demselben Namen mit derselben Nummer neu releasen, ohne dass es da draußen jemand merkt, ne. Und das hat dann natürlich auch gleich GitHub mit auf den Plan gerufen, die natürlich gesagt haben, ja, dass dieser dieser Angriffsvektor über die Supply Chain, das sollte ja eigentlich so gar nicht passieren, weil wenn ihr es wirklich sicher machen wollt, solltet ihr eure GitHub Actions nicht auf Versionen pinnen, also nicht sagen, ich verwende hier t j action 1 Punkt 1 oder 2 Punkt 0 oder was auch immer, sondern ihr solltet auf einen kompletten verweisen, so. Und im Prinzip sagen, welcher welchen Commit, welche Version von diesem Paket im Prinzip verwendet werden sollte. Und da lehne ich mich mal superweit ausm Fenster und sag, das macht ja niemand. Also Ja. Ihr könnt jetzt ja mal gerne hier die Hand heben oder uns schreiben, wenn ihr so was macht, aber ich kenn niemanden, der so paranoid ist, dass er seine kompletten Dependencies auf Festnagel. Ja, ich kenn Leute, die nehmen dedizierte Versionen und machen halt kein Sternchen oder geben nicht mal Miner- oder Patchversion frei oder so was. Das versteh ich noch, ja? Aber auf den zugrunde liegenden Commitash was festzupinnen, das ist, glaube ich, jenseits jeglichem Pragmatismus und jegliche Realität da draußen so. Ich glaub, das war einfach nur sone Ad hocreaktion von GitHub, die natürlich technisch korrekt ist, aber wie gesagt, glaub ich, sehr weit ab von dem normalen Entwickleralltag da draußen, ja. Und der Fairness halber muss man natürlich sagen, dass der die Schuld hier nicht bei bei GitHub oder in der falschen Anwendung von von Actions ist oder in unsicherer Verwendung von Semantik Versioning, die Schuld ist eindeutig in dem Fall bei dem Autor von TJ Actions. Denn dieser Bot User, der war halt überhaupt nicht abgesichert. Der hatte ein Access Token verwendet, der halt einen zu weiten Scoup hatte. Das heißt, dieser Bot durfte viel mehr, als er eigentlich gebraucht hätte. Die Bot Credentials waren nicht multifaktor gesichert, das wurde mittlerweile alles natürlich geändert. Aber da wurde einfach ganz basale Security Hygiene nicht beachtet an der Stelle, ja. Jetzt könnte man das eigentlich darauf beruhen lassen und sagen, okay, damit hat sich die Geschichte erledigt, die Fehler wurden behoben, neue saubere Versionen wurden released, das Einfallstor in den Bot User wurde geschlossen. Wenn nicht immer noch die Frage im Raum gestanden hätte, wie dieser Token von dem Bot eigentlich geleakt war, ja? Weil nur weil der Token unsicher war oder falsch konferiert war, heißt ja noch lange nicht, dass da jeder einfach so drankommen kann, ja, weil Token sind ja schon per se 'n bisschen sicher. Und heute Morgen wurde ganz druckfrisch dazu eine eine Follow up Analyse sozusagen veröffentlicht von Wizz. Kennt man vielleicht, ist sone Bude, die ich glaub vor Kurzem auch von Google gekauft wurde. Die kümmern sich so Security. Google Cloud hat der die jetzt, glaub ich, übernommen. Irgendwann letzte vorletzte Woche ist das, glaub ich, bekannt gegeben worden. Und die haben sich das auch noch mal 'n bisschen genauer angeguckt. Die waren auch mit bei den Ersten, die über TJ Actions berichtet hatten. Und die haben weiterhin rausgefunden, dass es einen vorangegangenen Angriff gab, und zwar eine eine selbe Supply Chain Attacke gegen eine auch gegen eine GitHub Action und zwar gegen die GitHub Action von Review Dogg. Review Dogg ist son Tool, was im Prinzip automatische Code Review machen kann. Und da ist eben was sehr Ähnliches passiert. Da wurde auch Code eingeschleust, der im Prinzip dazu da ist, Environment Secrets zu leaken. Und interessanterweise benutzt TJ Actions in seinem eigenen Bildprozess Review Dog. So und so wurde quasi durch eine einen Supply Chain Angriff der nächste Supply Chain Angriff ausgelöst. Und das hat dann die Leute son bisschen schutzig gemacht, weil man dann natürlich sagen kann, dieser Angriff, den wir grade beschrieben haben, der secrets in einen Log liegt, das ist ja nur, also ist ungünstig, betrifft aber maßgeblich Open Source Pakete, weil für alle Enterprise Kunden die Logs genauso wie der Quelltext ja erst mal nicht öffentlich ist. So, wenn man sich aber anguckt, wie dieser Angriff gegen Review Doc gelaufen ist, sieht man, dass da nur eine Version von betroffen war und auch die nur in einem sehr kurzen Zeitfenster. So. Und das lässt wiederum son bisschen den Verdacht im Raum stehen, dass es vielleicht gar nicht darum ging, irgendwie groß angelegt, Open Source Pakete zu treffen, sondern dass da jemand schon unterwegs war, der sehr vorsichtig eigentlich versucht hat, seine Spuren wieder zu verwischen und es vielleicht eher sonen Eskalationsangriff ging, ja? Also wo jemand versucht hat, vielleicht in 1 Firma an Geheimnisse zu kommen, an Environment secrets, auf die er eigentlich keinen Zugriff hatte, wohl aber vielleicht auf den Quelltext und die Logs von den Workflows. Und im Prinzip alles andere, was danach gekommen ist, sodass von vielen Open Source Paketen die Secrets geleakt sind, dass das vielleicht im Prinzip nur Kollateralschaden war von einem Angriff, der sehr viel gezielter im Hintergrund abgelaufen ist. Das ist eigentlich superinteressant, so.
Dennis: Aber doch von der gleichen Identität oder nicht?
Jan: Das weiß man natürlich nicht.
Dennis: Okay, das weiß man nicht, weil die Okay.
Jan: Weil der Angriff auf DJ Actions ja unter dem Bot Usernamen quasi gelaufen ist, ja? Und dementsprechend nicht nachvollziehbar war, wer das gemacht hat und der Angriff gegen Review Dog, auch son bisschen haarersträubend. Es gibt einen Automatismus, wie man bei Review Dog, bei der Review Dog GitHub Action zum werden kann. Weil da im Prinzip keine Prüfung stattfindet, sondern sobald Du dich quasi mit dem repository beschäftigst und da Pur recest und darüber alles machst, greift son Automatismus, der dich irgendwann irgendwie zu 'nem Maintainer macht. Das entscheidet niemand selbst, so. Deshalb hat Review Dog auch schon über 100 Maintainer, so, weil sobald Du halt son bisschen was mitmachst, kommst Du halt automatisch die Rechte dazu, so. Und das ist vielleicht auch eine fragwürdige Security Praxis, aber die erlaubt sie halt auch mit 'nem Wegwerf Account, der halt 'n bisschen Good Faith Actions vorher macht, ja, da irgendwann in diesen Kreis aufgenommen zu werden und dementsprechend schwierig ist dann die die Nachverfolgung, ne. Also wenn wir uns an vergangene Angriffe erinnern, wo da jemand monatelang irgendwie erst ernsthaft an 'nem Projekt mitgearbeitet hat, dann irgendwie Maintainer geworden ist und dann halt irgendwie Schabernack da mittreibt, das ist was ganz anderes. So, hier war das deutlich, deutlich einfacher.
Dennis: Ja, ich frag mich nur, also war son bisschen das Ziel, ich mein, wenn Du jetzt da dieses Umbiegen aller aller Tags oder Versionen auf einen Commit, das ist ja auch schon was relativ Offensichtliches, ne, was was man dann leicht sieht. Ist jetzt nicht so, ich mache versteckt was im Hintergrund.
Jan: Na, aber ist es
Dennis: ist ist es wirklich lange. Ich ich hab zumindest Screenshots gesehen, dass halt in der GitHub Oberfläche ist jeder jeder Commit die gleiche ID untereinander, also wenn, da kannst Du relativ schnell eigentlich reingucken und
Jan: Aber da guckt da keine rein?
Dennis: Nee, wow, weiß ich nicht. Einmal in den Verlauf der Versionen ist jetzt nicht so selten, dass man da mal reingeht oder?
Jan: Na ja, aber also wie gesagt Also zumindest das glaube
Sebi: ich nicht.
Jan: Was Du erreichen willst. So, wenn wenn's Ja, ja, genau. So das 1 Firma einmal unterzujubeln oder einem Ja. Einem Repository, dann reicht's dir ja, wenn das 2 Stunden erfolgreich online ist und einmal 'n Bild getriggert hat und fertig. Den Rest brauchst Du ja dann nicht mehr.
Dennis: Das stimmt. Das stimmt. Gut, was soll sollen wir noch was lernende? Also irgendwas anderes machen oder machen die anderen was anders?
Jan: Also es gab noch 'n paar andere Hinweise auch seitens, die wirklich auch sinnvoll waren. Also wie gesagt, das auf den auf den Commitash festnageln, weiß ich nicht, wie wie sinnvoll das wirklich ist. Natürlich hätte das das verhindert, das muss man schon sagen, aber das macht ja halt den Upgrade Pfad und den täglichen Umgang damit super superschwierig. Ja. Was Sie zum Beispiel noch sagen, ist, man kann in der GitHub Adminoberfläche festlegen, welche GitHub Actions dein Projekt benutzen darf, damit nicht jeder und jeder Developer, der quasi weitere Actions unterjubeln kann. Kann da sone Allowlist anlegen. Das klingt supersinnvoll, ja. Und dann natürlich, man muss es sagen, auch wenn's draußen wahrscheinlich keiner macht, eigentlich bist Du halt schon auch in der Pflicht, so dir deine Dependency irgendwie regelmäßig mal anzugucken und zu gucken, was da passiert. Ja, lass mir mal so im Raum stehen, ne.
Dennis: Mhm. Okay, dann danke dir Jan für die Einblicke. Sibi, Du hast noch 'n Kleinigkeit zu links mitgebracht. Was ist links?
Sebi: Links ist wirklich, also das ist 'n wie React native in neu von ByteDance. ByteDance ist die Firma, die auch TikTok betreibt, so, ja. Und ja, das nutzen Sie in TikTok und zu den firmeninternen Apps schon eine Zeit lang und das haben Sie jetzt open source. Sagst Du, kann man mal kann man 'n bisschen rumspielen mit. Und ich fand's euch ganz spannend, dass Sie auch eine eigene JavaScript Run Time da mitschippen. Ja. Und das war's eigentlich. Ansonsten haben sie hier heute den Fokus auf Performance, startet recht schnell und wahrscheinlich kann man, ja, muss man wahrscheinlich erst mal 'n bisschen anfühlen, hab ich jetzt nicht gemacht. Aber cool, dass das für oder es eine Alternative zu Reagnative gibt. Also weil sie sagen halt, die Webentwicklung und so, das möchten sie schon beibehalten. Ihre Meinung ist aber auch, dass unsere Digital Natives, also die nachwachsende Generation vollkommen abgeschreckt ist, wenn die User Experience nicht Native ist. Mhm. Also wenn ich irgendwo auf einen Like Button drücke und eine 100 Millisekunden Latenz habe, dann sind die direkt weg. Ja. Ist natürlich auch 'n Hot Take, aber kann gut sein. Oder dass man, ja, also die sagen halt so, ja, Native ist wahrscheinlich die beste User Experience und Web ist aber so der kleinste gemeinsame Nenner für Cross Plattformen Development und verheiraten wir das doch mal. Ja, Open Source und kann man antesten jetzt.
Dennis: Schon spannend irgendwie zu sehen, ne, dass so jede jede große Plattform oder dann direkt zu sonem Techunternehmen wird. Ich frag mich halt, also wenn jetzt irgendwie, Du hast eine Plattform, die skaliert riesig groß. Was für eine Plattform? TikTok.
Sebi: Ach so.
Dennis: Facebook, Meta irgendwie halt sowas. Du bist aber immer eine große Firma, die irgendwie das großes Ding hat und dann kommst Du einfach, weil Du so viele Devs dann hast oder dann kommst Du auf die Idee so, wir müssen das jetzt selbst und besser machen. Also wie wär das bei uns? Wir machen jetzt 'n Riesenspiel, wo Milliardennutzer sind und dann zeigen wir, ah, jetzt schreiben wir mal irgendwie das Web neu. In
Sebi: so 'nem ersten Fronthand Framework. Genau. Dann ist
Jan: jetzt so nicht diese ganzen Spielengines entstanden, so und so, weil halt jemand 'n großes Spiel gebaut hat und gemerkt hat, so, ich muss meine eigene Umgebung dafür bauen?
Dennis: Ja. Ja, wahrscheinlich, wenn die Ressourcen da hat, ist ja schön. Also wenn's Weiterentwicklung ist. Ich war auch kein negativer Kommentar, aber nur 'n, ich fand nur, ist eine interessante Beobachtung.
Jan: Und ab 'ner kritischen Größe lohnt sich's halt einfach eher, ne? Irgendwann wird's für dich halt einfacher, dein eigenes Ding zu bauen als die Änderungen, die Du halt unbedingt in oder Angular oder wo auch immer haben willst, anstatt darauf zu warten, dass das kommt, noch so dein eigenes Ding.
Dennis: Ja. Mhm. Gut, wir können nachreichen, Tech Documentaries dot com ist die Seite, die einige Dokumentationen schon gemacht hat über alles Mögliche. UJS, React JS, No JS, Tabescriptswelt, Larawell, Elixier und einfach mehr haben Sie auf Ihrer Webseite und Sie haben eben auch dort eine jetzt über UJS
Jan: Über Weed?
Dennis: Über Weedsuri Punkt com, das genau, die Veröffentlichung war. Das ist jetzt in Produktion gegangen, das heißt, da haben Sie schon einiges für gemacht und bald kann man sich darüber dann was angucken. Aber vielleicht auch einige der anderen, ja irgendwie ganz interessant. Von daher, das mal als Link hier gedroppt. Gut, ich hab 2 kleine Tim aus dem AI Bereich. Das Erste ist einfach, Apple hat jetzt sehr offiziell gesagt, so, sorry, das, was wir mit Siri so alles vorgestellt haben letztes Jahr, das wird nix und zwar nicht dieses Jahr, sondern wenn dann nächstes Jahr irgendwann. Also das haben sie, nachdem sie ja das immer mehr bisschen nach hinten geschoben haben und dann vielleicht mit 18 Punkt 4 und keine Ahnung was, mussten sie sich jetzt eingestehen, dass das, was sie sich da als Produkt vorgestellt haben und in der Qualität, wie sie es vielleicht haben, jetzt erst mal nichts wird und das erst im nächsten Jahr so hättest. Und gab da auch relativ viel Zoff intern. Aber man kann natürlich auch irgendwie argumentieren, okay, besser irgendwie jetzt die den Hohn über das Verschieben, als dass Du 'n Produkt rausbringst, was halt einfach nicht funktioniert. Und ich glaub, über eine Zahl war auch irgendwie drin, dass so in 60 bis 80 Prozent der Fällen funktioniert's gut und das ist halt nicht der Anspruch, den Apple irgendwie eine Funktionalität Funktionalität hat. Deswegen, let's see. Mal gucken, was Alexa Plaas dann bald abliefert, wie die Qualität dort ist so als persönlicher Assistent. Und wir müssen uns als iOS und User, Mac User noch ein bisschen gedulden.
Sebi: Kommt dumm.
Jan: Weiß man, woran Was
Dennis: schüttelst Du den, was schüttelst Du den Kopf, Jan?
Jan: Also, mich wundert's immer, wie man so als reichste Firma der Welt halt so Probleme haben kann, wenn links und rechts halt irgendwie Leute dich in sonem Feld überholen und Du's halt einfach nicht schaffst, dann nachzuziehen. Mhm.
Dennis: Ja. Sind dann vielleicht schon irgendwie eigene Ansichten oder eigene Strukturen, wie man versucht, das dann ans Leben zu bekommen und und hofft, dass es ist. Oder Sie warten vielleicht, keine Ahnung, es könnte auch sein, Sie denken so, okay, Sie haben den nächsten riesengroßen Wurf und dann wär's noch mal, es ist 'n ganz anderes Level und nicht nur das, was wir versprochen haben und warten dann noch mal so aus Produktsicht. Könnte auch eine Strategie sein. Mal gucken. Ja, und als Sie den Apple Feed noch ganz kurz ans Rand uns jetzt, wir können uns alle freuen, iOS 19 soll der größte UI und Interface Retrides seit iOS, was hast Du gesagt? 7 oder so. 7 oder so.
Jan: 7 oder so. 7 oder so.
Dennis: Wie seit 1 Dekade. Soll richtig alles neu machen. Von daher gespannt, was die WPCC im Juni, wann ist die Juni, Juli uns bringt. Und vielleicht mal wieder ein Grund, die Beta zu installieren, Sevie?
Sebi: Yeah, yui. Ja, vielleicht auch.
Dennis: Obwohl das wird wahrscheinlich so eine Beta, die erst mal gar nicht funktioniert, wenn sie alles neu gemacht haben. Anyway, dann wollte ich gerne noch, verlinken wir einen Artikel. So im Dev Bereich ist ja immer son bisschen oder einfach, ich glaub eine eine Fragestellung, die man im Moment auch noch nicht beantworten kann, aber die man sich einfach 'n bisschen Gedanken machen kann. Was bedeutet AI für uns aktuell und was bedeutet AI natürlich auch für irgendwie die Rolle des Softwareentwickelnden in der Zukunft? Und da hab ich 'n Artikel von Eddie Osomani gelesen, der, ich glaub's in in sehr kurz sich so zusammenfassen lässt, dass die Meinung ist so, okay, 70 Prozent kann man vielleicht jetzt oder in naher Zukunft ganz gut mit a a abdecken in dem Softwareentwicklungszyklus, aber 30 Prozent sind die schwierigen Dinge und die ist a I im Moment noch nicht in der Lage. Und da gibt's verschiedenste Bereiche, in die das letztendlich geht, aber vor allen Dingen geht es so die Skills, die man halt Senior Development irgendwie zuschreibt. Das heißt, dass man gerade einen Fokus auf Architektur, auf Skalierung, auf Modularisierung et cetera, also alle diese Themen, irgendwie einen System größer werden zu lassen und zu halten, dass das halt alles Dinge sind, die AI nicht besonders gut kann. Und umso wichtiger ist, einfach in den Bereichen seine Skills dann eben auszubauen und sich darauf zu fokussieren, diese Dinge zukünftig zu machen. Und ja, da gibt's sehr, sehr viele, ganz interessante finde ich, Einblicke, was was dort so die Ansichten sind. Und das ist auch 'n großer Bereich so, okay, wenn man jetzt gerade Junior ist oder als Junior anfängt, wie soll man sich da auf die Zukunft vorbereiten? Was sind die was sind die besten, ja, Wegeansätze? Welche Dinge muss man verstehen? Welche Dinge sind okay, wenn sie einem von AI vorgelegt werden? Von daher und für unterschiedliche Skill Level, glaube ich, einfach mal 'n interessanter Take zu dem Ganzen. Trotzdem natürlich ein Fragezeichen, weil keiner weiß, wie es sich wie schnell weiterentwickelt und was AI dann zusätzlich noch übernehmen kann. Das kann mal unterschiedliche Meinungen haben. Ich bin da ja immer 'n bisschen eher, weiß nicht, was das richtige Wort progressiver oder optimistischer, was auch da die Zukunft angeht. Aber ich weiß, dass meine beiden Kollegen, die mit mir sitzen, da eher anderer Ansicht sind. Und keiner von uns kann es beweisen oder sagen, sondern wir können einfach nur eine wilde Wette in die Zukunft machen, aber einfach trotzdem sich mit dem Status quo auseinanderzusetzen und zu gucken, so was ist da im Moment und mit sehr hoher Wahrscheinlichkeit so, wie verändert das unsere Arbeit aktuell? Kann man sich den Artikel mal gut geben?
Jan: Das hast Du schön gesagt.
Dennis: Gut und aber auch da, ich find unterschiedliche Meinungen super interessant. Von daher, wenn ihr da draußen auch dazu Meinungen habt, schreibt sie uns gerne an Podcast at programmier.bar, mit auch gerne Feedback zu der Folge und dem Jubel, dass Sebi wieder dabei war, könnt ihr uns auch gerne schreiben, wenn euch das gefreut hat. Sonst vielen, vielen Dank fürs Zuhören. Jan hat noch eine wichtige programmier.bar interna
Jan: Nachricht. Genau, wenn ihr euch mit Dennis noch mehr über AI unterhalten wollt, dann solltet ihr vielleicht am vierundzwanzigsten April zu unserem Meetup kommen, wo wir The Thinking Game als Film bei uns in der Sabine schauen werden und danach ein bisschen über AI diskutieren, philosophieren, elaborieren werden können bei viel Popcorn und guten Drinks. Sehr schön.
Dennis: Da freu ich mich drauf. Wunderbar. Vielen Dank fürs Zuhören. Bis nächste Woche in den I news. Macht's gut.
Sebi: Tschau tschau. Tschau tschau. Tschüs.