Working Draft

Schon wieder eine neue Buzzword-KI? Nicht ganz. In dieser Folge sprechen wir mit Robin Böhm über Agentic AI – ein Konzept, das gerade massiv Fahrt aufnimmt. Statt auf einen Prompt zu warten, werden KI-Agenten selbst aktiv: Sie analysieren Aufgaben, planen Schritte und setzen diese eigenständig um. Was bedeutet das für Entwickler:innen, Tools – und letztlich für uns als Nutzer:innen? Unser Sponsor Die KI-Revolution ist da – bist du bereit, sie aktiv zu gestalten? Workshops.DE macht dich fit für die Praxis: In intensiven Schulungen lernst du, Künstliche Intelligenz nicht nur zu verstehen, sondern gezielt in Projekten einzusetzen. Ob vor Ort, remote oder als individuelle Firmenschulung – bring dein Team auf das nächste Level! Informier dich jetzt über die aktuellen Kurse und sichere dir deinen Platz auf workshops.de/ki. Mit dem Rabatt-Code WORKINGDRAFT sparst du außerdem 10 % auf alle Schulungen! Schaunotizen [00:01:36] Agentic AI Robin gibt einen praxisnahen Überblick: Was macht eine KI „agentisch“? Wie wird festgelegt, was ein Agent darf – und was nicht? Wir steigen ein mit einem technischen Abriss der Konzepte, die aktuell unter dem Schlagwort Agentic AI diskutiert werden: Fähigkeiten, Kontrollinstanzen, Kontextverwaltung und mehr. Dabei geht es auch um Frameworks wie LangChain, den Umgang mit JSON-Kommandostrukturen, und um frühe Ansätze für Protokolle, mit denen Agenten sich gegenseitig über ihre Fähigkeiten austauschen können. Robin vergleicht den aktuellen Stand mit „Super Nintendo-Level“ – was aber nicht heißt, dass das Ganze ungefährlich wäre. Denn die nächste Iteration ist vielleicht nicht weit entfernt. Wir diskutieren, wie Agentic AI bereits heute in Projekten auftaucht, wo es echte Automatisierungsvorteile gibt – und wo wir dringend Grenzen ziehen müssen. Besonders spannend wird es, wenn Robin beschreibt, wie sich unsere Erwartungen an „Tools“ verändern: Weg vom klassischen Button-Klick, hin zur Zieldefinition – und der Agent übernimmt. Am Ende steht die Frage: Wie behalten wir als Entwickler:innen die Kontrolle – und wie gestalten wir diese Systeme so, dass sie nicht nur mächtig, sondern auch nachvollziehbar und verantwortungsvoll sind? Keine Schaunotizen LangChain Ein populäres Framework für agentenbasierte KI-Anwendungen – bringt Tools, Speicher und Entscheidungslogik zusammen. ReAct Prompting Ein Konzept, das Denk- und Aktionsschritte kombiniert – oft Basis für agentisches Verhalten bei LLMs.

Jens Jacobsen, Autor und Digitalexperte, gibt spannende Einblicke in die Webentwicklung mit Künstlicher Intelligenz. Er erklärt, warum es wichtig ist, bei Webseiten zuerst über das Geschäftsmodell nachzudenken und nicht nur auf Geschwindigkeit zu setzen. Jens beleuchtet die Herausforderungen und Chancen von KI-Tools sowie die Bedeutung qualitativ hochwertiger Inhalte. Zudem diskutiert er, wie Barrierefreiheit und soziale Medien die Erstellung und Wahrnehmung von Websites beeinflussen. Ein unterhaltsamer Austausch über die Zukunft des digitalen Designs!

Matthias Scharwies, aktiver Maintainer von SelfHTML und Mitgestalter der Community, erzählt von 30 Jahren der Plattform, die vielen Webentwicklern als Grundlage diente. Er diskutiert die Herausforderungen der Webstandardisierung und die Wichtigkeit von Community-Engagement. Nostalgie und der Wandel in der Nutzung von Dokumentationen kommen zur Sprache, während er auch die Relevanz von Barrierefreiheit und Bildung im Web betont. Das bevorstehende SelfHTML-Treffen 2025 in Mannheim verspricht spannende Begegnungen und neue Impulse für die Community.

PHP ist eine dieser Sprachen, die man leicht unterschätzt – und die trotzdem nicht weggeht. Im Gegenteil: Sie hat sich über Jahrzehnte hinweg weiterentwickelt und ist heute das Fundament unzähliger produktiver Anwendungen. Grund genug für uns, einen genaueren Blick auf den Status quo und die Entwicklung dahinter zu werfen. Unser Sponsor Am 13. Juni 2025 lädt mittwald zum Head in the Cloud Summit ein – ein Tag voller Inspiration und Austausch auf dem mittwald Campus. Hier treffen sich Webworker, Developer und Digitalagenturen, um voneinander zu lernen. Freu dich auf spannende Talks und Sessions zu Cloud & DevOps, Technology und Culture & Creativity. Von den Herausforderungen der digitalen Arbeitswelt bis hin zu den Trends von morgen – hier bekommst du Einblicke von den klügsten Köpfen der Branche. Die Tickets sind begrenzt, also schnell buchen auf mittwald.de/hitc. Für diese Revision haben wir uns einen der zentralen Köpfe der PHP-Welt eingeladen: Sebastian Bergmann, Erfinder von PHPUnit, langjähriger Open-Source-Maintainer und pragmatischer Beobachter des Ökosystems (Web / LinkedIn / Mastodon). Gemeinsam mit Schepp und Hans spricht er über Technologie, Verantwortung und das Leben als jemand, der seit Jahrzehnten mit und an PHP arbeitet. Schaunotizen [00:01:03] PHP im Jahr 2025 Wir starten mit Sebastians Weg in die PHP-Welt: Wie kam es zur Entstehung von PHPUnit? Was war der Stand der Dinge damals – und warum hat sich Sebastian überhaupt entschlossen, ein eigenes Test-Framework zu bauen? Wir sprechen über die Anfangsjahre von PHP, über JUnit als Vorbild und den wilden Westen früher PHP-Projekte. Danach werfen wir einen Blick auf das Jetzt: Wie steht es um das Vertrauen in PHP als Sprache? Welche Rolle spielen moderne Tools wie Composer, Frameworks wie Symfony oder Laravel – und was macht eigentlich die PHP Foundation genau? Sebastian schildert, wie sich das Ökosystem professionalisiert hat, aber an vielen Stellen trotzdem auf Freiwilligenarbeit beruht. Natürlich reden wir auch über Tests: Was bedeutet gutes Testing im Jahr 2025? Wie sieht das Zusammenspiel mit Tools wie PHPStan oder Psalm aus? Und wie geht man mit Legacy-Code um, der eigentlich nie für Tests gedacht war? Sebastian teilt Einblicke aus seiner Beratungsarbeit mit Teams und erklärt, wie man pragmatisch Qualität sichert. Ein wichtiger Teil des Gesprächs dreht sich um Open Source im Dauerbetrieb: Was bedeutet es, ein Projekt wie PHPUnit über Jahrzehnte hinweg zu pflegen? Wie hält man durch? Welche Erwartungen kommen von außen – und was kann die Community beitragen, damit das Ganze nicht auf Einzelpersonen lastet? Zum Schluss schauen wir nach vorn: Welche Entwicklungen im PHP-Core lohnen sich im Auge zu behalten? Was fehlt der Sprache noch? Und was wünscht sich Sebastian von der nächsten Generation an Entwickler:innen, die vielleicht bald ihre ersten Pull Requests schreiben? Links PHPUnit Das führende Test-Framework für PHP – entwickelt und gepflegt von Sebastian Bergmann seit über 25 Jahren. PHP Foundation Die Stiftung hinter der aktiven Weiterentwicklung der Sprache. Hier arbeiten festangestellte Entwickler:innen am PHP-Core. Composer Das Dependency-Management-Tool der Wahl für PHP – unerlässlich für moderne Projektstrukturen. Symfony Ein weitverbreitetes PHP-Framework mit Fokus auf Wiederverwendbarkeit, Konventionen und Skalierbarkeit. Laravel Ein modernes Full-Stack-Framework für PHP mit einem großen Ökosystem und starker Community. PHPStan Ein statischer Code-Analyzer, der potenzielle Fehler in PHP-Projekten schon zur Entwicklungszeit erkennt. Psalm Ein weiteres beliebtes Tool zur statischen Analyse von PHP-Code – mit Fokus auf Type Safety.

In dieser Folge ist Melanie Patrick zu Gast, eine erfahrene Senior Backend Engineer bei Trivago mit einem Hintergrund in der internationalen Sekretariatsarbeit. Sie teilt wertvolle Lifehacks für Webentwickler, die von effektiven Meetings bis hin zu cleveren Ablagesystemen reichen. Melanie diskutiert, wie man in stressigen Situationen organisiert bleibt und Zeitmanagement verbessert. Außerdem spricht sie über die Bedeutung guter Kommunikation im Team und wie individuelle Vorbereitungen den Arbeitsalltag erleichtern können.

Peter, Stefan und Vanessa nehmen sich auch in dieser Woche wieder die Ergebnisse des State of JS 2024 vor. In Teil 1 haben wir uns auf die neuen JavaScript-Features gestürzt, in Teil 2 ging’s um Pain Points in JavaScript und den Browser-APIs, dazu die Leseliste und die Libs. Teil 3 war dann ganz den Meta-Frameworks und dem Testing gewidmet. Jetzt im letzten Teil schauen wir noch auf die Themen „Mobile & Desktop“, „Build Tools“, „Monorepo Tools“ und „Sonstige Tools“. Unser Sponsor Am 13. Juni 2025 lädt mittwald zum Head in the Cloud Summit ein – ein Tag voller Inspiration und Austausch auf dem mittwald Campus. Hier treffen sich Webworker, Developer und Digitalagenturen, um voneinander zu lernen. Freu dich auf spannende Talks und Sessions zu Cloud & DevOps, Technology und Culture & Creativity. Von den Herausforderungen der digitalen Arbeitswelt bis hin zu den Trends von morgen – hier bekommst du Einblicke von den klügsten Köpfen der Branche. Die Tickets sind begrenzt, also schnell buchen auf mittwald.de/hitc. Schaunotizen [00:02:49] Mobile & Desktop App oder Webseite? Bei uns gehen die Meinungen auseinander: Vanessa nutzt gern installierbare Desktop-Apps, während Stefan lieber einfach einen Tab offen lässt. Einig sind wir uns: Egal ob App oder Web – das Verhalten sollte konsistent bleiben. Besonders spannend wird’s beim Blick auf Electron vs. Tauri. Tauri basiert auf Rust und hat in den letzten Jahren deutlich an Aufmerksamkeit gewonnen – nicht zuletzt, weil es deutlich schlanker daherkommt. [00:09:29] Build Tools Webpack ist zwar noch immer weit verbreitet, aber wir sind uns nicht sicher, ob das heute noch gerechtfertigt ist. Stefan kritisiert den „JavaScript-first“-Ansatz und die vielen Loader. Peter ist entspannter unterwegs: Hauptsache, es funktioniert. Unsere Build-Tool-Favoriten: tsc, esbuild und Vite. Wir sprechen auch über dts-Bundler für Typdefinitionen und den (möglichen) Verzicht auf Bundler mit Import Maps. [00:25:37] Monorepo Tools Monorepos – Fluch oder Segen? Vanessa beschreibt typische Stolpersteine bei Multirepos, etwa mit npm link oder Symlinks. Wir finden: Monorepos sind weniger eine technische Entscheidung als eine organisatorische. Peter erzählt von seinem persönlichen „Sirpepe-Universum“-Monorepo – der zeigt, dass das Konzept auch für Einzelpersonen nützlich sein kann. [00:55:26] Sonstige Tools Wir diskutieren Tools wie Lodash und Axios – früher unverzichtbar, heute eher „meh“. Mit der neuen Temporal API könnten auch Libraries wie Moment.js bald Geschichte sein. Vanessa empfiehlt VueUse, Stefan feiert weiterhin Express, und wir nehmen Bun kritisch unter die Lupe. Fazit: Viel Hype, aber oft wenig Substanz. Deno und Cloudflare Workers schneiden da besser ab – vor allem in echten Projekten. Ähnliche Revisionen Revision 656: State of JS 2024, Teil 3/4 Revision 655: State of JS 2024, Teil 2/4 Revision 653: State of JS 2024, Teil 1/4 Revision 652: Automatisiertes Testing mit Playwright Revision 633: State of CSS 2024, Teil 1/3 Revision 634: State of CSS 2024, Teil 2/3 Revision 635: State of CSS 2024, Teil 3/3

In dieser Revision sprechen wir mit Marius Kleidl (Web / LinkedIn / Mastodon / GitHub), Webentwickler bei Transloadit und Mitwirkender am Open-Source-Projekt TUS, über das Thema Resumable Uploads – also Datei-Uploads, die fortgesetzt werden können, wenn zwischendurch mal die Verbindung abraucht oder das Tab versehentlich geschlossen wird. Schaunotizen [00:01:13] Resumable Uploads Wir starten mit der Frage, warum klassische Upload-Methoden im Web oft unzuverlässig sind – vor allem bei großen Dateien wie Videos. Gerade bei instabilen Verbindungen oder auf Mobilgeräten ist Frust vorprogrammiert: Einmal abbrechen heißt meistens von vorne anfangen. Mit Resumable Uploads gehört das der Vergangenheit an. Stattdessen kann der Upload pausieren, später fortgesetzt werden – ganz ohne Datenverlust. Im Zentrum der Folge steht TUS, ein Open-Source-Protokoll für Resumable Uploads, das Marius mitentwickelt. Wir reden über die Entstehung des Projekts, die technischen Grundlagen und wie man TUS in eigene Anwendungen integriert – sei es in Node.js, Go oder mit vorhandenen Client-Libraries. Besonders spannend: Die Spezifikation wird derzeit mit der IETF abgestimmt, mit dem Ziel, Resumable Uploads langfristig als offiziellen HTTP-Standard zu etablieren. Marius gibt uns außerdem einen Einblick in die Community-Arbeit hinter TUS, den Beitrag anderer Open-Source-Projekte und wie Entwickler:innen durch eigene Implementierungen zur Verbesserung beitragen können. Wir streifen Themen wie Caching, Storage-Backends und was eigentlich alles im Hintergrund passieren muss, damit so ein Upload wirklich „resumable“ ist. Natürlich kommen auch die praktischen Fragen nicht zu kurz: Was muss man beachten, wenn man Resumable Uploads in ein bestehendes Projekt integriert? Wie sieht die Kommunikation zwischen Client und Server aus? Und wie viel Aufwand steckt wirklich dahinter? Links TUS-Projekt Die offizielle Webseite des TUS-Projekts, welches Resumable Uploads ermöglicht. Transloadit Der Dienstleister für File-Processing, der Resumable Uploads unterstützt und individuelle Lösungen anbietet. Uppy Ein Open-Source-Projekt, das eine flexible API für den Datei-Upload aus verschiedenen Quellen bereitstellt.

Peter, Stefan und Vanessa besprechen auch diese Woche wieder die Ergebnisse des State of JS 2024. In Teil 1 stürzten sich die Hosts vor allem auf die neuen JavaScript Features, in Teil 2 besprachen sie die Pain Points von JavaScript und Browser APIs,  die Leseliste und die Bibliotheken. In diesem vorletzten Teil schaffen die Hosts ganze zwei weitere Seiten der Umfrage: Meta-Frameworks und Testing. Schaunotizen [00:01:17] Meta-Frameworks Die Hosts wenden sich zunächst der Frage zu, was Meta Frameworks denn eigentlich sind. Bekannte Namen sind Nuxt, Next.js, Remix, SvelteKit, etc. Doch was genau was so ein Meta Framework aus? Ist es eine „All in One“ Lösung? Muss es zwangsweise auf einem anderen Framework basieren? Das bringt uns auch zu einer Endlos-Diskussion: Ist React ein Framework oder eine Library (deutsch: Bibliothek)? Wobei, React hat diese Frage nun selbst beantwortet: Es ist eine Library. Nun gut, die Hosts einigen sich darauf, dass man eine gewisse Erwartungshaltung an Meta-Frameworks hat: Sie kommen mit einem Router, Zustandsverwaltung (State Management), SSR und SSG und weiteren bereits eingebauten Features. Meta-Frameworks kommen mit diesen vielen nützlichen Features, keine Frage. Dennoch stellt man auch eine neue Abhängigkeit her. Das Benutzen dieser Meta-Frameworks kann es schwieriger machen, Bugs zu finden und zu fixen. Wie so oft, wenn man nicht mehr die Kontrolle über den kompletten Code hat. Sie können auch mit Sicherheitslücken kommen, wie es kürzlich der Fall bei Next.js war. Wie auch in den beiden vorherigen Teilen sind sich die Hosts wieder in einem Punkt sicher: Es kommt auf die Entwickler:innen an, nicht auf das Meta-Framework. Kleine Bibliotheken wie Eleventy sind dennoch immer eine gute Wahl. Das liegt bei Eleventy daran, dass man HTML und CSS losgelöst von dem Tool schreibt. Das ermöglicht eine leichte Migration in der Zukunft. [00:43:32] Testing Bei dem Thema Testing leben die Hosts in verschiedenen Welten. Während Vanessa sich schon seit Jahren mi Tests in der Welt von Frontend Frameworks beschäftigt, hat der in der Rust-Welt lebende Stefan kaum Berührungspunkte mit Framework-Component Testing und kann die ganze Problematik daher gar nicht so genau nachvollziehen. Vanessa klärt also zunächst einmal über die ganze Tragödie von Unit Tests über Component Tests zu End to End Tests oder doch auch Visual Regression Tests und Snapshot Tests auf. Die Umfrage verrät, dass aktuell viel Jest eingesetzt wird, jedoch niemand mehr so richtig glücklich mit diesem Tool ist. Vitest ist stark auf dem Vormasch, genauso wie Playwright. In Revision 652 sprach kürzlich erst Stefan Judis über automatisiertes Testing mit Playwright. Ähnliche Revisionen Revision 655: State of JS 2024, Teil 2/4 Revision 653: State of JS 2024, Teil 1/4 Revision 652: Automatisiertes Testing mit Playwright Revision 633: State of CSS 2024, Teil 1/3 Revision 634: State of CSS 2024, Teil 2/3 Revision 635: State of CSS 2024, Teil 3/3

Peter, Stefan und Vanessa besprechen weiterhin die Ergebnisse des State of JS 2024, so wie in der Vergangenheit auch bereits der State of CSS (Revision 633-635) besprochen wurden. In Teil 1 stürzten sich die Hosts vor allem auf die neuen JavaScript Features. Nun geht es weiter mit den Schmerzpunkten von JavaScript und Browser APIs,  der Leseliste und den Bibliotheken. Schaunotizen [00:01:35] JavaScript Pain Points Die JavaScript Pain Points Angaben in der Umfrage kamen durch eine Freitext Eingabe in der Umfrage zustande, Wie Peter, Stefan und Vanessa finden, eine wichtige Zusatzinformation, um die Ergebnisse etwas besser interpretieren zu können. Denn diese sind bei näherem Betrachten der eigentlichen Antworten gar nicht mehr so konkret wie die Liste an Kurzantworten erst erscheinen lässt. Ein viel besprochenes Thema ist EcmaScript Module & Common JS. Das ES Module ist ein standardisiertes JavaScript-Modulsystem, das in ECMAScript 2015 (ES6) eingeführt wurde. Es wird in modernen Browsern und Node.js unterstützt. Das CJS Modulsystem wird hauptsächlich in Node.js verwendet. Es wurde entwickelt, bevor JavaScript ein offizielles Modulsystem hatte. Vor allem die Migration von CJS auf ESM wird als komplex und kompliziert genannt. Ebenfalls benannt wird das Fehlen von Typen. Hierbei kommen Peter und Stefan zu dem Schluss, dass man TypeScript „einfach“ dazu installieren, oder notfalls per IDE Extension hinzufügen kann. Sie sind also anderer Meinung als die Umfrage Ergebnisse. Der nächste Schmerzpunkt, der genannt wird, ist der, der fehlenden Standardbibliothek. Hier argumentiert Stefan, dass das eigentlich kein Problem von der Sprache JavaScript, sondern der Runtime sei. Er streut nebenbei das Wissen herein, dass es ein Standard Committee gibt, dass sich nun um serverseitige Runtimes kümmern wird: das TC55. Stefan erzählt weiterhin, Rust hätte noch viel weniger Standards, da wäre alles frei konfigurierbar. Der letzten besprochenen Schmerzpunkt ist die asynchrone Programmierung. Da hätte Stefan gerne viele mehr Prozente gesehen. Denn gerade seit es async/await gibt, gibt es viele Verständnislücken über die asynchrone Programmierung. Er weist auf den hilfreichen Blogartikel „What color is your function“ von Bob Nystrom hin. [00:30:35] Browser API Pain Points und Readlist Die Liste der Schmerzpunkte über Browser APIs ist doch sehr erheiternd zu lesen: Safari und Firefox. Und eigentlich auch Chrome. Peter, Stefan und Vanessa arbeiten sich durch die Liste und finden heraus: Das Hautproblem sei wohl, dass Chrome einige APIs freischaltet, die die anderen Browser noch nicht unterstützen. Dadurch gibt es Indifferenzen zwischen den Browsern. Doch ob es wirklich die Lösung ist, dass Chrome sich besser absprechen könnte? In Teil 1 besprachen die Hosts das JavaScript Feature error.cause. Umso schöner nun zu sehen, dass viele der Ausfüllenden der Umfrage sich auch dieses Feature auf die Leseliste gesetzt haben. [00:44:04] Bibliotheken Über die Bibliotheken gibt es massig viele Daten anzuschauen. Doch für wen sind diese nun eigentlich interessant? Vermutlich eher, wenn man Inhalte für Blogartikel und Vorträge sammelt. Dennoch wüten sich Peter, Stefan und Vanessa durch die Daten. Webpack ist das meistebenuzte Tool, jedoch nicht das Beliebteste. React und Vite stehen beide hoch im Kurs. Zum konkreten Thema der JavaScript Frameworks besprechen die Hosts, dass man wohl irgendwie eine Entscheidung treffen muss – und richtig falsch ist keine, aber wohl oft trifft man wohl auch nicht die Richtige, wie man an den Schmerzpunkten wieder sieht. Denn hier werden Frameworks auch oft als zu komplex beschrieben. Die Hosts finden, dass Entwickler und Entwicklerinnen generell flexibel sein müssen in ihrem Beruf. Und jederzeit zwischen Frameworks wechseln können sollten. Links State of JS – Outreach Ähnliche Revisionen Revision 653: State of JS 2024, Teil 1/4 Revision 633: State of CSS 2024, Teil 1/3 Revision 634: State of CSS 2024, Teil 2/3 Revision 635: State of CSS 2024, Teil 3/3

Wusstet ihr, dass man mit der richtigen TypeScript-Config plötzlich wieder Lust auf JavaScript bekommt? Kein Witz – wir haben’s ausprobiert! Schaunotizen [00:01:08] TypeScript 5.8 Wir steigen ein mit einem TypeScript-Feature, das Stefan so begeistert hat, dass er direkt eine ganze Revision darüber machen wollte: die „Erasable Syntax Only“-Option. Wir diskutieren, warum diese Einstellung TypeScript endlich wieder zu einem erfreulichen Tool macht – besonders in Verbindung mit einer besseren Developer Experience und weniger magischem Code. Danach nehmen wir TypeScript in Node-Projekten auseinander, sprechen über das Für und Wider von Linting vs. Type-Checking zur Laufzeit und streifen dabei auch Themen wie Build-Systeme, tsc vs. esbuild und warum man manchmal doch wieder Bock auf „einfaches JavaScript“ bekommt. Zum Ende hin geht’s noch kurz um die Realität in Teams, in denen nicht alle TypeScript gleich intensiv nutzen – und um die Frage, ob TypeScript bald nur noch Linter mit Typen sein sollte.