Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft
der etablierteste Podcast für Webentwickler im deutschsprachigen Raum.
Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler
anbietet, schreibt uns unter sponsoring@workingdraft.de.
In dieser Folge sprechen wir mit Andreas Kottre (CEO & Technical Lead bei typedigital) & Tim Olbrich (Geschäftsführer und Inhaber der Bitory GmbH) von der Hackerkiste Augsburg, einem einzigartigen Event, das seit 2017 regelmäßig die Web- und Tech-Community zusammenbringt. Wir tauchen ein in das besondere Setting: eine ehemalige Siemens-Halle, die zum kleinen Festival-Dorf mit Plaza, weitläufigem Gelände, großen Stages und verwinkelten Bereichen wurde. Außerdem ergründen wir den barcampartigen Rahmen mit 10-Min-Talks, Call for Papers, First-Time-Speakers-Betreuung – und am Ende erwartet euch eine grandiose Verlosung!
Schaunotizen
[00:00:58] Hackerkiste Augsburg
Inhaltlich bietet die Hackerkiste ein volles Programm: Rund dreißig Speaker:innen und ein Dutzend Barcamp-Sessions locken jedes Jahr etwa dreihundert Teilnehmende nach Augsburg. Das Format ist bietet mehrere Stages, inklusive ausführlichen Vorträgen auf den großen Stages und Lightning Talks. Es gibt dabei Sage und Schreibe ganze vier Tracks zu besuchen! Lightning Talks dauern nur (bis zu) zehn Minuten, eingebettet in halbstündige Sessions, die zum Austausch einladen und Barcamp-Charakter haben. Angesprochen sind Entwickler:innen, UX-Interessierte, Community-Macher:innen und alle, die Lust auf neue Impulse haben.Besonders spannend ist der Umgang mit neuen Speaker:innen. Über den Call for Papers können sich erfahrene Vortragende genauso wie Newcomer melden. Wer zum ersten Mal auf die Bühne geht, wird von Stage Hosts betreut und bekommt Unterstützung bei Vorbereitung, Ablauf und Stressmanagement. So wird der Einstieg leicht gemacht, ohne dass die Qualität leidet.
Neben der eigentlichen Konferenz prägt die Hackerkiste auch das Community-Leben in Augsburg. Unter anderem veranstalten die Organisator:innen das Meetup Web and Wine, das nicht nur technische Themen, sondern auch Metaebenen wie den Umgang mit Stress aufgreift. Damit wird deutlich, dass es bei der Hackerkiste nicht allein um Technologie, sondern auch um Austausch und Gemeinschaft geht.
Und weil wir es bis zum Schluss spannend machen wollen: Am Ende dieser Revision wartet noch eine Verlosung auf euch. Mehr verraten wir hier nicht. Außer, dass es sich lohnt, dranzubleiben.
Vanessa und Stefan haben Alexander Lichter zu Gast, seines Zeichens Vue.js Community Größe und Dev Rel bei void(o).Um das von Vue.js und Vite Erfinder Evan You gegründete Startup für „Next Generation Tooling“ geht es auch in der heutigen Revision.
Schaunotizen
[00:01:00] VoidZero
Wir erfahren welche Projekte void(0) unterstützt, betreut, oder sogar ganz verantwortet. Wir reden über Open Source Governance, den meme-tauglichen „Rewrite in Rust“ und hinterfragen dabei unter anderem kritisch welchen Einfluss ein VC gefördertes Startup auf kritischen JavaScript Infrastruktur haben darf. Vergleiche mit einem bekannten Serverless Hosting Unternehmen aus San Francisco und deren berühmt-berüchtigte Unterwanderung der React.js Szene bleiben da natürlich nicht aus, der Vollständigkeit halber sei aber erwähnt, dass wir die Folge vor dem nicht weniger überraschenden Kauf von NuxtLabs aufgezeichnet haben.
Links
oxc. Ein JavaScript Transpiler und Minifier, in Rust geschrieben.
In dieser Revision sprechen Vanessa und Schepp mit Jannik Lehmann (LinkedIn), Senior Frontend Developer bei GitLab, darüber, wie man Chat-Applikationen mit gängigen LLM-APIs erstellt. Dabei geht er auf verschiedenste Stolpersteine ein, spricht über Streaming und warum der Kontext so wichtig ist.
Schaunotizen
[00:01:42] Chat-Applikationen mit gängigen LLM-APIs
LLM-APIs unterscheiden sich in zwei zentralen Punkten von klassischen APIs: Erstens sind die Antworten nicht deterministisch – das bedeutet, dass ein identischer Prompt bei jedem Request ein anderes Ergebnis liefern kann. Zweitens kommen die Antworten gestreamt an – oft in Form von Text-Chunks, die schrittweise per Server Sent Events (SSE) an den Client geliefert werden.
Ein typischer Request beginnt mit einem einfachen Prompt als Plaintext. Die Antwort wird dann dynamisch in Markdown-Form gestreamt. Doch genau dieses gestreamte Markdown bringt etliche Stolperfallen mit: Von XSS- und Prompt-Injection-Risiken über unvollständige Mermaid-Diagramme bis hin zu halbfertigen Flowcharts und weiteren seltsamen Markdown-Konstrukten, die ein LLM ausgeben kann.
Hier lohnt ein Exkurs in das Thema streambare vs. nicht streambare Dateiformate: HTML ist beispielsweise streambar, da der Browser Bit für Bit lesen und direkt rendern kann. Deshalb gibt es auch Metriken wie „First Meaningful Paint“ und Gründe dafür, warum ein Script-Tag lieber am Ende statt am Anfang einer HTML-Datei stehen sollte. Markdown hingegen ist nicht streambar – es braucht oft Kontext über mehrere Zeilen hinweg, bevor eine Darstellung sinnvoll möglich ist. Genau deshalb ist Markdown als Streaming-Format nicht ganz trivial zu handhaben.
Ein weiteres zentrales Thema ist der Kontext – oder vielmehr: wie wir mit ihm umgehen. Denn LLMs sind per se stateless. Das bedeutet: Jeder einzelne Request muss alles enthalten, was das Modell wissen soll – den Prompt, die bisherige Konversation, den System Prompt und ggf. auch hochgeladene Dateien. Aus Erfahrung wissen wir: Alle nutzen am Ende dieselben Modelle, aber wie der Kontext behandelt wird, entscheidet darüber, ob der AI-Assistent genial oder nutzlos wirkt.
Apropos Kontext: LLMs haben ein beschränktes Kontextfenster – je nach Modell unterschiedlich groß, aber immer begrenzt. Was tun, wenn dieses Limit erreicht ist? Strategien wie Sliding Windows (ältere Nachrichten rauswerfen), automatische Zusammenfassungen oder manuelle Priorisierung helfen weiter. Wichtig ist: Mehr Kontext kostet nicht nur mehr Tokens, sondern macht die Anwendung auch langsamer und teurer.
Unser Fazit: Die Komplexität solcher Systeme ist hoch – aber genau deshalb ist es so wichtig, mit kleinsten Prototypen zu starten. Sie helfen, zentrale Probleme frühzeitig sichtbar zu machen. Wer Lust bekommen hat, sich einmal ein wenig inspirieren zu lassen, dem sei der GitLab Duo Chat ans Herz gelegt. Es befindet sich als Open-Source-Projekt im GitLab Repository – man freut sich über jeden Merge Request.
Nach mehreren Folgen im KI-Block zu Tools und Technik sprechen wir diesmal mit Markus Oberlehner über eine grundlegendere Frage: Kann eine KI Entwickler:innen ersetzen? Markus war schon zweimal bei uns zu Gast – in Revision 473 zu Vue 3 und Revision 535 über Testing mit Cypress und Vitest. Diesmal geht’s um das Spannungsfeld zwischen KI-Hype, echtem Mehrwert im Alltag und langfristigen Auswirkungen auf die Branche.
Schaunotizen
[00:01:33] Kann eine KI Entwickler:innen ersetzen?
Markus erzählt, wie er anfangs begeistert war – besonders mit dem Sprung von ChatGPT 3 zu [ChatGPT 4](https://openai.com/gpt-4). Für einen Moment schien es, als müsste bald niemand mehr selbst coden. Doch dann kam die Ernüchterung. Neue [agentic Modelle](https://www.talkdesk.com/de-de/blog/agentic-ai/) und Tools wie [Gemini 2.5](https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/), [Claude 4](https://www.anthropic.com/news/claude-4) oder [DeepSeek R1](https://deepseek-r1.com/de/) machen Hoffnung – aber die Realität bleibt durchwachsen.
Die zentrale Frage ist: Ersetzt KI den ganzen Job – oder „nur“ das Coden? Wir sind uns einig: Entwickler:innen machen weit mehr als nur Code zu schreiben. Kommunikation, Konzeption, QA-Abstimmung – all das bleibt. Dass KI etwa 20 % der Arbeit übernehmen kann, klingt für Markus realistisch. Beim schnellen Prototyping hilft KI bereits enorm.
Aktuell arbeitet Markus wieder mit [GitHub Copilot](https://github.com/features/copilot), nachdem er [Cursor](https://www.cursor.so/) eine Weile ausprobiert hatte. Autovervollständigung ist für ihn mittlerweile Alltag. Aber: Macht das wirklich produktiver? Ob KI-Nutzung ein echter Wettbewerbsvorteil ist, bleibt unklar.
Spannend wird es bei der Frage: Was passiert, wenn KI Junior-Entwickler:innen ersetzt? Denn wo keine Juniors nachrücken, fehlen später auch Seniors. KI könnte also nicht nur Arbeitskraft, sondern auch Ausbildungspfade gefährden.
Ein sinnvolles Einsatzgebiet sieht Markus bei Aufgaben, die sonst eher lästig sind – etwa Refactorings oder Library-Upgrades. Doch genau da hapert’s noch. Seine Erfahrungen bei der Migration von [Nuxt 2 auf 3](https://nuxt.com/docs/migration/overview) waren eher ernüchternd. Auch bei komplexen Kombinationen – etwa [React 19](https://react.dev/blog/2024/12/05/react-19) mit [Next.js 15](https://nextjs.org/blog/next-15) oder [Remix](https://remix.run/) – liefern KI-Tools oft Mischmasch aus alten und neuen Patterns.
Unterschiede gibt’s auch zwischen den Frameworks: [React](https://react.dev/) wird gut unterstützt, [Vue](https://vuejs.org/) weniger, bei [Svelte](https://svelte.dev/) wird’s noch dünner. Der Grund: KI kann nur gut, was sie oft genug gesehen hat.
Markus‘ Fazit ist realistisch: Für schnelle MVPs ist KI ein gutes Tool. Für langfristige Architektur oder Legacy-Code eher nicht. Zwischen Hype und Ernüchterung bleibt KI ein mächtiges Werkzeug – aber nur, wenn man es gezielt und reflektiert einsetzt.
In unserem KI-Block geht’s diesmal wieder um den Einsatz von Künstlicher Intelligenz in der Webentwicklung – von Codegenerierung über Tool-Integrationen bis hin zu lokalen Modellen und neuen Standards, die die Zusammenarbeit zwischen Mensch und Maschine verändern könnten. Dazu haben wir Max Marschall eingeladen (Consultant bei ThinkTecture, LinkedIn), der mit Vanessa und Schepp über seine Erfahrungen spricht. Wir diskutieren Tooling, werfen einen kritischen Blick auf technische und ethische Grundlagen – und Max bringt’s auf den Punkt: Wir arbeiten immer mehr mit „Sprache als Interface“.
Schaunotizen
[00:06:15] LLMs
Wir sprechen über die Basis fast aller heutigen KI-Anwendungen: LLMs. Schepp erinnert sich an seine ersten Gehversuche mit der Tabnine-Erweiterung für JetBrains, Max bringt die aktuelle Entwicklung ein – von klassischem Machine Learning bis zu ChatGPT. Dabei bleibt klar: Die Vorschläge sollte man nicht blind übernehmen. Und auch das Thema Urheberrecht beim Training von Modellen lassen wir nicht außen vor.
[00:13:15] Komplexität der Aufgaben
Je komplexer die Aufgabe, desto schwieriger tut sich KI. Das stellen Max und Vanessa schnell fest. Bei einfachen Problemen funktioniert’s oft erstaunlich gut – bei größeren Projekten sinkt der Nutzen oder es schleichen sich Fehler ein.
[00:21:42] Agentic Code Editors
Wir werfen einen Blick auf Editoren, die mehr können als einfache Prompts: sogenannte Agentic Code Editors. Max hat verschiedenste Tools ausprobiert – von NeoVim über VS Code bis JetBrains. Tools wie Windsurf oder Cursor liefern echte Kontextunterstützung. Vanessa bleibt lieber bei ChatGPT, weil dort klar ist: Kontext gibt’s keinen. Wir reden auch über @commands zur gezielten Aufgabensteuerung und Use Cases wie Variablennamen oder Talktitel finden.
[00:30:47] Coding Rules
Wir sprechen über CodingRules.ai und ähnliche Tools, mit denen wir einmal definieren können, welche Stilregeln gelten – z. B. ob fat arrow functions oder ECMAScript-Imports verwendet werden sollen. Max nutzt solche Tools projektbezogen – und schaltet z. B. in einen „Architekturmodus“ oder „Doku-Modus“ um.
[00:34:45] Memory Bank
Langfristiger Kontext ist das Stichwort: Mit Tools wie Cursor Memory Bank oder Cline.bot lassen sich Informationen dauerhaft speichern – z. B. welche Tools im Projekt verwendet werden. Cline legt dafür Markdown-Dateien an, wie in den Cline Docs beschrieben.
[00:39:56] Lokale LLMs
Datenschutz ist ein großes Thema – gerade im Unternehmenskontext. Wir sprechen über lokale LLMs mit Ollama oder ChatGPT via Azure. So lassen sich Modelle datenschutzkonform nutzen – ohne dass Inhalte ins Training einfließen.
[00:45:18] MCP (Model Context Protocol)
Max bringt MCP ins Spiel – das Model Context Protocol von Anthropic. Eine neue Schnittstelle, mit der sich LLMs standardisiert mit externen Tools wie Datenbanken oder Backends verbinden lassen.
[00:51:02] Generatoren
Wir reden über Tools wie V0, Lovable, Bolt.new und Builder.io. Sie liefern per Prompt komplette Frontends – oft als React-Komponenten. Das spart Zeit, ist aber in der Praxis oft auf generische Anwendungen begrenzt. Kevin hat in Revision 665 ähnliche Erfahrungen gemacht.
[01:00:31] Chrome Dev Tools
Auch die Chrome DevTools bekommen KI-Funktionen. Max berichtet, dass man dort künftig Fragen zum Code stellen oder Styles ändern kann – spannend, auch wenn er selbst das lieber direkt in der IDE macht. Firefox testet laut Support-Artikel eigene KI-Features.
Auch rund um GitHub, Jira & Co. zieht KI ein. Automatische Pull Request Reviews, Ticket-Zusammenfassungen, Textoptimierungen – das verändert unsere Workflows und spart Zeit.
Weiter in unserem KI-Block geht es mit Kevin Chromik (Webseite, LinkedIn), Content Creator (YouTube). Kevin berichtet Hans und Vanessa seine Erfahrungen darüber, wie er mit KI Tools 3x schneller Apps programmieren kann.
Schaunotizen
[00:01:30] Wie ich mit KI 3x schneller Apps programmiere
3x schneller entwickeln! Ja, das ist eine YouTube-Clickbait Headline! Es wird schnell klar: Die KI übernimmt zwar nicht alles, aber sie kann an vielen Stellen den Entwicklungsprozess deutlich beschleunigen – manchmal sogar um das Dreifache. Kevin berichtet über eine App, die er zusammen mit einem anderem YouTuber in Flutter mit Hilfe von KI-Tools gebaut hat. Der Anwendungsfall ist hierbei, dass sie nur zu zweit an dieser App schreiben, und beide zuvor nicht mit Flutter gearbeitet haben. Sie müssen bei dieser App auch keinen strikten Design Richtlinien folgen, sondern können der KI mehr Freiheiten geben.
Ein großes Thema ist die Frage nach dem Kontext: Tools wie ChatGPT liefern oft brauchbare Antworten, kennen aber die eigene Codebase nicht. Das macht ihre Vorschläge schnell unbrauchbar oder zumindest nicht optimal integrierbar. Ganz anders sieht es bei Tools wie Cursor oder Windsurf aus, die direkt in die IDE eingebunden werden – z. B. in VS Code – und Zugriff auf das gesamte Projekt haben. Damit können sie nicht nur präziser helfen, sondern auch bessere Architekturvorschläge machen oder konkrete Codeabschnitte erklären.
Besonders spannend ist Kevins Ansatz, KI nicht unbedingt zum „schnelleren Programmieren“ im klassischen Sinne zu nutzen, sondern vielmehr für alles drumherum. Beim Prototyping etwa hilft KI, Ideen schnell zu visualisieren – auch wenn der produzierte Code am Ende verworfen wird. Kevin erzählt von einem Beispiel, als er ein Award-System in seine Habit-Tracker-App einbauen wollte: Die Idee war noch nicht ausgereift, doch Windsurf konnte dennoch eine erste Oberfläche erzeugen, mit der man experimentieren konnte – inklusive Animationen. Der Code war nicht perfekt, aber als Sparringspartner war die KI extrem hilfreich.
Wir sprechen auch über den Unterschied zwischen eigenen Programmiersprachen und fremden: Ist man mit KI auch in der eigenen Sprache wirklich schneller? Und wie sinnvoll ist KI eigentlich für Junior-Entwickler:innen? Kevin und Vanessa sehen hier Chancen, aber auch Risiken. Während Stack Overflow oft ein notwendiger Umweg ist, bei dem man sich zwangsläufig mit dem Problem auseinandersetzt, liefern KI-Tools direkte Lösungen – ohne Umweg, ohne Kontext. Das kann zu schnellen Ergebnissen führen, aber auch dazu, dass Lernprozesse übersprungen werden.
Trotzdem: Gute Tools wie Windsurf ermöglichen inzwischen Rückfragen zur Codebase wie „Erklär mir mal die Architektur dieser App“ – und das kann gerade für weniger erfahrene Entwickler:innen ein echter Gewinn sein.
Ein weiteres Thema ist Codequalität. Kevin berichtet, dass er seine Habit-Tracker-App bewusst mit einer sauberen Architektur gebaut hat – auch wenn sie funktional simpel ist. Er merkt an: Je besser man selbst entwickelt, desto mehr stört einen der Output von KI, weil viele Vorschläge einfach qualitativ nicht mithalten können. Viel Code im Netz ist schlicht schlecht – und KI reproduziert diesen leider oft. Gute Entwickler:innen sind in den meisten Fällen noch deutlich besser als jede KI.
Zum Abschluss diskutieren wir noch mit Hans, ob man heute noch zusätzliche Libraries braucht – oder ob KI-Tools wie V0 von Vercel mit ihren fertigen Komponenten schon ausreichen, um direkt damit zu starten.
20. Mai 2025 | Kommentare deaktiviert für Revision 662: Entwickeln mit KI
Diesmal zu Gast: Jens Jacobsen (benutzerfreun.de, LinkedIn), Autor & Digital-Experte. Jens schrieb das Buch Websites entwickeln mit KI und erzählt Peter und Vanessa, wie das am besten geht, und warum er lieber von Webseiten „besser“, anstatt „schneller“ entwickeln spricht. Das Buch richtet sich an alle mit einem gewissen technischen Verständnis – etwa Produktmanager:innen, Entwickler:innen oder Designer:innen – aber auch erfahrenere Techies werden darin wertvolle Einblicke finden.
Schaunotizen
[00:01:30] Entwickeln mit KI
Im Gespräch geht es darum, warum es nicht ausreicht, sich in einer Minute eine Website „zusammenklicken“ zu lassen – selbst wenn einem viele Tools genau das versprechen. Zwar entsteht dann formal eine Webseite, doch in den seltensten Fällen eine gute. Jens betont, wie wichtig es ist, sich zunächst Gedanken über das Geschäftsmodell zu machen, bevor man überhaupt an die technische Umsetzung denkt. Besonders bei Portfolio-Seiten oder kleinen Online-Shops kann man zwar viel mit KI erledigen, aber ohne Substanz nützt das beste Tool wenig.
Wir diskutieren auch die wachsende Zahl an KI-Tools: Jens hat über 70 davon getestet – und nur drei haben ihn wirklich überzeugt. Die meisten Tools funktionieren nach einem simplen Prinzip: Man gibt einen Titel, vielleicht ein paar Stichpunkte ein, und bekommt daraufhin eine generische Website auf Basis eines Templates. Jens warnt davor, sich von solchen „auf Knopfdruck“-Lösungen blenden zu lassen. Gute Tools hingegen stellen erst einmal Fragen – etwa zur Zielgruppe oder zur Struktur der Seite – und entwickeln daraus eine erste Sitemap oder sogar Wireframes.
Auch das Thema Arbeitswelt spielt eine Rolle: Wird KI langfristig Jobs im UX-Design oder Vertrieb gefährden, weil es inzwischen KI-gestütztes User-Testing und automatisierte Verkaufsanalysen gibt? Peter merkt dazu an: „Wenn’s nichts kostet, kann man’s auch siebenmal ausprobieren.“ Eine Realität, die einerseits Chancen schafft, andererseits aber auch Druck auf klassische Rollen im Unternehmen ausüben könnte. Doch Jens kontert damit, dass man dann eben sieben Versionen von irgendeiner Webseite hätte, aber nicht einer, die den eigentlichen Zweck tatsächlich richtig erfüllt.
Am Ende bleibt festzuhalten: Man muss heutzutage wohl leider nicht mehr programmieren können, um mit KI Webseiten zu erstellen – aber ein gewisses technisches Verständnis hilft. Das heißt aber noch lange nicht, dass eine sinnvolle Webseite dabei herauspurzelt. Nur eben irgendeine. Die eigentliche Arbeit – worum es geht, die Texte, die Bilder – dabei kann KI sehr hilfreich sein und als ein Sparring-Partner dienen. Wer nicht nur auf schnelle Ergebnisse, sondern auf durchdachte, nachhaltige Weblösungen setzt, findet in Jens‘ Buch einen hilfreichen Wegweiser durch die Tool-Landschaft und den KI-Dschungel.
Links
📘 Das Buch von Jens:Websites entwickeln mit KI Ein praktischer Guide für alle, die Webseiten effizient mit KI planen und umsetzen wollen – ohne dabei Qualität und Strategie aus dem Blick zu verlieren.
22. April 2025 | Kommentare deaktiviert für Revision 658: State of JS 2024, Teil 4/4
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“.
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.
8. April 2025 | Kommentare deaktiviert für Revision 656: State of JS 2024, Teil 3/4
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.
1. April 2025 | Kommentare deaktiviert für Revision 655: State of JS 2024, Teil 2/4
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.
Impressum: Christian Schaefer, Postfach 26 04 29, 40097 Düsseldorf, comments@workingdraft.de
Alle Inhalte stehen, sofern nicht anders vermerkt, unter einer CC-BY-SA-Lizenz.
