Sechs Monate lang hatte Marco jeden Abend Angular gelernt. Tutorials, Projekte, ein selbst gebautes Taskboard. Dann schrieb er seine ersten Bewerbungen. Von 14 Stellenanzeigen verlangten elf React, zwei Vue.js und genau eine Angular. Marco hatte das falsche Framework gelernt. Nicht, weil Angular schlecht wäre. Sondern weil er sich nie angeschaut hatte, was der Arbeitsmarkt tatsächlich verlangt.
Dieser Fehler passiert öfter, als man denkt, denn die Frontend-Welt bietet Hunderte Frameworks, Tools und Bibliotheken, und jede Woche erscheint etwas Neues auf Hacker News. Wer ohne Plan lernt, verliert Monate. Dieser Artikel sortiert: was Arbeitgeber 2026 tatsächlich verlangen, was Pflicht ist, was Kür, und was man getrost ignorieren darf.
Das Fundament: HTML, CSS und JavaScript
Drei Technologien bilden seit über 30 Jahren die Basis jeder Website: HTML definiert die Struktur, CSS das Aussehen und JavaScript das Verhalten. Kein Framework, kein Build-Tool und kein Compiler ändert daran etwas, denn React-Komponenten werden am Ende zu HTML, Tailwind-Klassen werden zu CSS und TypeScript wird zu JavaScript kompiliert. Ohne solide Grundlagen debuggt man später Probleme, die sich schlicht nicht einordnen lassen.
Das klingt trivial. Ist es nicht. Modernes CSS allein umfasst Container Queries, Cascade Layers, das :has()-Pseudoelement, Subgrid, View Transitions und Custom Properties mit komplexer Vererbungslogik, die selbst erfahrene Entwickler gelegentlich ins Grübeln bringt. JavaScript bietet Closures, Promises, async/await, Proxy-Objekte, WeakMaps und ein Modulsystem, das Anfänger regelmäßig verwirrt, weil sich ESM und CommonJS in vielen Projekten noch mischen. HTML bringt semantische Elemente mit, deren korrekte Verwendung direkt über die Barrierefreiheit einer Seite entscheidet.
Viele Bootcamps und Online-Kurse überspringen diese Grundlagen nach wenigen Wochen, um möglichst schnell zu React oder einem anderen Framework zu kommen. Das rächt sich. Absolventen können zwar eine React-App zusammenklicken, scheitern aber an einem CSS-Layout ohne Tailwind oder an der Frage, warum ein fetch()-Aufruf manchmal ein Promise und manchmal einen Fehler zurückgibt, weil ihnen das Verständnis für asynchrone Abläufe fehlt. Das halte ich für einen der größten Fehler in der Frontend-Ausbildung: Frameworks vor Fundamenten.
Wie viel Grundlagenwissen braucht man?
Eine sinnvolle Faustregel: Bevor man ein Framework lernt, sollte man in der Lage sein, eine mehrseitige Website mit Navigation, Formularen und responsivem Layout komplett ohne Framework zu bauen, also ohne CSS-Framework, ohne JavaScript-Bibliothek, nur mit den drei Grundtechnologien. Mit diesem Können erschließen sich die Probleme, die Frameworks lösen, und damit auch die Frameworks selbst deutlich schneller.
Drei bis vier Monate intensives Lernen sind für dieses Fundament realistisch, für Quereinsteiger ohne Programmiererfahrung eher sechs. Diese Investition zahlt sich über die gesamte Karriere aus, weil Frameworks kommen und gehen, aber HTML, CSS und JavaScript als Grundlage jeder Webentwicklung bestehen bleiben.
Konkret heißt das: Mit CSS-Flexbox- und Grid-Kenntnissen erkennt man sofort, was Tailwind-Klassen wie „flex items-center“ bewirken, und kann Layouts auch ohne Utility-Framework umsetzen. JavaScript-Promise-Kenntnisse erklären, warum ein useEffect-Hook in React manchmal Daten doppelt lädt, und semantisches HTML führt automatisch zu barrierefreieren Komponenten, ohne dass man jede ARIA-Rolle einzeln nachschlagen muss. Grundlagen sind kein akademischer Ballast, sondern das Werkzeug, mit dem man Framework-Probleme löst, die in keinem Tutorial stehen.
TypeScript: Vom Bonus zur Pflicht
TypeScript, die typisierte Erweiterung von JavaScript, hat einen bemerkenswerten Aufstieg hinter sich, der mittlerweile kaum noch jemanden in der Branche überrascht. Im Stack Overflow Developer Survey 2025 gaben 43,6 Prozent aller befragten Entwickler an, TypeScript regelmäßig zu verwenden [1], und seit August 2025 führt TypeScript laut GitHub die Liste der meistgenutzten Programmiersprachen auf der Plattform an, noch vor Python und JavaScript [2]. In der Praxis bedeutet das: TypeScript ist kein Nischen-Tool mehr. Es ist Standard.
Warum, liegt auf der Hand. TypeScript fängt Fehler ab, bevor der Code im Browser läuft, und statt einer kryptischen Fehlermeldung um 23 Uhr in der Produktion zeigt der Editor schon beim Tippen, dass eine Funktion den falschen Typ erwartet. In großen Codebasen mit mehreren Entwicklern ist das enorm wertvoll, weil Refactoring sicherer wird, die Autovervollständigung der IDE präziser arbeitet und die Dokumentation im Code selbst lebt.
Für Berufseinsteiger ergibt sich daraus eine klare Konsequenz: TypeScript-Kenntnisse sind in den meisten Stellenanzeigen 2026 nicht mehr optional, sondern Voraussetzung. Mit soliden JavaScript-Kenntnissen lässt sich TypeScript in vier bis sechs Wochen produktiv einsetzen, weil die Syntax weitgehend identisch bleibt und nur das Typsystem dazukommt. Früh umsteigen lohnt sich.
Ein verbreitetes Missverständnis: TypeScript sei eine eigene Programmiersprache. Technisch gesehen ist es ein Superset von JavaScript, was bedeutet, dass jeder gültige JavaScript-Code auch gültiger TypeScript-Code ist. TypeScript fügt lediglich ein Typsystem hinzu, das während der Entwicklung Fehler erkennt und beim Kompilieren wieder entfernt wird, sodass im Browser am Ende reines JavaScript läuft. JavaScript-Kenntnisse decken bereits den größten Teil des Weges zu TypeScript ab.
Frameworks: Was der Markt verlangt
Seit Jahren heißen die drei großen Frontend-Frameworks React, Angular und Vue.js, und daran hat sich auch 2026 nichts geändert. Neue Alternativen wie Svelte, Solid oder Qwik existieren und haben jeweils interessante technische Ansätze, spielen auf dem Arbeitsmarkt allerdings eine untergeordnete Rolle. Stellenanzeigen in Deutschland, Österreich und der Schweiz zeigen ein eindeutiges Bild.
Quelle: Stack Overflow Developer Survey 2025 [1], ergänzt durch W3Techs-Daten [4].
React: Der sichere Weg
React dominiert den Markt, und das ist kein Qualitätsurteil, sondern eine Bestandsaufnahme. Mit 44,7 Prozent Nutzung unter den befragten Entwicklern bietet React die breiteste Jobauswahl in der DACH-Region und darüber hinaus. Ob Startup in Berlin, Mittelständler in Stuttgart oder DAX-Konzern in München: React-Entwickler werden praktisch überall gesucht, vom Zwei-Personen-Team bis zum Konzern mit 500 Entwicklern.
Beim Einstieg ist die Lernkurve moderat, weil React eine Bibliothek ist und kein vollständiges Framework. Es gibt wenig Konventionen, dafür viele Entscheidungen: State Management (Zustand, Redux Toolkit, Jotai), Routing (React Router, TanStack Router), Datenabfragen (TanStack Query, SWR). Diese Freiheit macht React flexibel, aber auch unübersichtlich für Einsteiger, die sich in der Fülle der Optionen schnell verlieren können. Immerhin gehört die Dokumentation unter react.dev zu den besten im gesamten Frontend-Bereich und führt strukturiert durch alle Konzepte.
React hat mit Server Components und Server Actions zwei Konzepte etabliert, die die Architektur von React-Anwendungen grundlegend verändern und über Next.js seit 2023 nutzbar sind, bevor sie mit React 19 (Dezember 2024) offiziell stabil wurden. Komponenten können jetzt auf dem Server gerendert werden, ohne JavaScript an den Client zu senden, was Ladezeit verbessert und Bundle-Größe reduziert. Für Einsteiger verkompliziert das allerdings die Lernkurve erheblich, weil man jetzt verstehen muss, welcher Code auf dem Server und welcher im Browser läuft. Trotzdem: React bleibt die sicherste Wahl für den Berufseinstieg.
Angular: Die Enterprise-Wahl
Angular, entwickelt und gepflegt von Google, verfolgt einen völlig anderen Ansatz als React. Es ist ein vollständiges Framework mit festgelegter Projektstruktur, eigenem Routing, eigenem Formularsystem und eingebautem Dependency Injection, das den gesamten Entwicklungsprozess von der ersten Zeile Code bis zum Build vorgibt. Unternehmen schätzen diese Opinionierung, weil sie zu einheitlicherem Code führt, wenn 20 Entwickler am gleichen Projekt arbeiten.
Entsprechend liegt die Einstiegshürde höher als bei React, denn Angular verlangt TypeScript (nicht optional), setzt auf RxJS für reaktive Programmierung und hat insgesamt eine steilere Lernkurve. Dafür ist die Struktur nach der Einarbeitung klar. Für eine Karriere in Konzernen oder im öffentlichen Sektor (Banken, Versicherungen, Behörden-IT) bietet Angular häufiger passende Stellenangebote als React, weil große Organisationen die strikte Architektur dem freien React-Ansatz vorziehen.
Vue.js: Warum die Community es liebt
Vue.js gilt als das zugänglichste der drei großen Frameworks, weil die API intuitiv ist, die Dokumentation vorbildlich und der Einstieg vergleichsweise schnell gelingt. Viele Startups und kleinere Teams setzen auf Vue, weil es Entwicklerproduktivität mit einer angenehmen Lernkurve verbindet, ohne dabei an Leistungsfähigkeit einzubüßen. In der Zufriedenheitsumfrage von State of JS 2024 schnitt Vue beim Kriterium „Würde es wieder verwenden“ mit 87 Prozent sogar deutlich besser ab als React mit 75 Prozent.
Eine Einschränkung bleibt: In der DACH-Region ist der Vue-Stellenmarkt deutlich kleiner als der für React. Vue-Entwickler finden Jobs, aber die Auswahl fällt geringer aus. Eine bewusste Entscheidung für Vue fällt häufig, weil das aktuelle Unternehmen bereits Vue einsetzt oder ein konkretes Projekt Vue vorsieht. Als erste Framework-Wahl für maximale Jobflexibilität empfiehlt sich trotzdem React.
Braucht man ein Meta-Framework?
Ein Meta-Framework baut auf einem Framework auf und ergänzt es um Routing, serverseitiges Rendering (SSR), statische Generierung und Deployment-Optimierung, also genau die Teile, die ein reines Frontend-Framework bewusst offen lässt. Next.js (für React) ist hier der Platzhirsch: 71 Prozent der React-Stellenanzeigen erwähnen Next.js als Anforderung oder Vorteil [3]. Für Vue gibt es Nuxt, für Svelte SvelteKit und für Angular das neuere Analog.
Next.js hat sich von einer praktischen Ergänzung zum Quasi-Standard für professionelle React-Projekte entwickelt. Vercel, das Unternehmen hinter Next.js, beschäftigt mehrere Kernentwickler von React selbst, was nicht unumstritten ist, weil Teile der Community die enge Kopplung zwischen einem kommerziellen Anbieter und einer Open-Source-Bibliothek kritisieren. Gleichzeitig sorgt diese Verflechtung dafür, dass neue React-Features wie Server Components, Server Actions und Partial Prerendering oft zuerst in Next.js produktionsreif verfügbar sind.
Überraschend gut gelöst ist die Entwicklererfahrung in Next.js, besonders seit der App Router (eingeführt in Version 13, stabil seit Version 13.4) dateibasiertes Routing, verschachtelte Layouts und granulares Caching aus einer Hand liefert. Anfangs fühlt sich die Lernkurve steil an. Aber nach der Einarbeitung beschleunigt Next.js die Entwicklung spürbar, weil Entscheidungen wie Routing, Caching-Strategie und Datenladung bereits getroffen sind und man sich auf die eigentliche Anwendungslogik konzentrieren kann.
Meine Empfehlung: Wer React lernt, sollte Next.js direkt mitlernen. Die Trennung von „zuerst React, dann Next.js“ ist künstlich, weil die offizielle React-Dokumentation den Einstieg über ein Framework wie Next.js, React Router oder Expo empfiehlt.
Nuxt.js spielt für Vue-Entwickler eine ähnliche Rolle wie Next.js für React: geringere Verbreitung, aber in Vue-Projekten fast genauso selbstverständlich, weil es SSR, Routing und State Management bündelt. SvelteKit hat sich als Standard für Svelte-Projekte etabliert, ist im Stellenmarkt allerdings noch eine Seltenheit. Bei der Framework-Wahl sollte das zugehörige Meta-Framework gleich mitgelernt werden, denn die Zeiten, in denen man React-Projekte ohne Routing-Framework per Hand zusammengebaut hat, sind endgültig vorbei.
CSS in der Praxis: Mehr als Farben und Abstände
CSS hat sich vom simplen Stylesheet-Format zu etwas entwickelt, das in der Komplexität einer Programmiersprache nahekommt. Wie man CSS in einem Projekt organisiert, ist 2026 fast so kontrovers wie die Framework-Wahl, und drei Ansätze dominieren den Markt.
Tailwind CSS hat den größten Umbruch der letzten Jahre ausgelöst, indem es das Konzept von CSS-Klassen auf den Kopf stellt. Statt eigene Klassen zu schreiben, kombiniert man vordefinierte Utility-Klassen direkt im HTML: „class=“flex items-center gap-4 p-6 bg-white rounded-lg shadow“. 51 Prozent der Frontend-Entwickler nutzen Tailwind laut dem State of CSS 2025 Report [3], während Bootstrap, einst der unangefochtene Marktführer, kontinuierlich Anteile verliert.
Was lehrt die Tailwind-Krise?
Im Januar 2026 entließ Tailwind Labs 75 Prozent seiner Ingenieure [5], was paradox klingt, denn ein Tool mit Rekordzahlen bei der Nutzung baut drei Viertel seines Teams ab. Der Umsatz war um 80 Prozent eingebrochen. Grund: KI-Tools beantworten Tailwind-Fragen direkt im Editor, der Dokumentations-Traffic sank um 40 Prozent in zwei Jahren. Weniger Besucher auf der Doku-Seite bedeuten weniger Käufer für die Premium-Vorlagen von Tailwind Plus.
Für Frontend-Entwickler enthält diese Nachricht eine wichtige Lektion: Selbst das beliebteste Tool ist nicht immun gegen Verwerfungen, die sich aus technologischen Verschiebungen ergeben. Tailwind bleibt 2026 relevant und wird mit Version 4 sogar deutlich leistungsfähiger, aber die Entlassungen zeigen, dass Marktdominanz kein Garant für die Stabilität eines Unternehmens ist. Entwickler, die ihre gesamte Karriere auf einem einzigen Tool aufbauen, gehen damit ein Risiko ein, das sich mit breiteren Kenntnissen leicht vermeiden lässt.
CSS Modules, styled-components oder doch Plain CSS?
Neben Tailwind existieren mehrere andere Ansätze. CSS Modules (in Next.js standardmäßig unterstützt) kapseln Styles pro Komponente und verhindern Namenskonflikte. styled-components und Emotion betten CSS direkt in JavaScript ein (CSS-in-JS). Und manche Teams arbeiten erfolgreich mit klassischem CSS, organisiert nach der BEM-Methodik.
Welcher Ansatz passt, hängt vom Projektkontext ab. Für neue React-Projekte mit Next.js funktioniert Tailwind oder CSS Modules am besten, während CSS-in-JS-Lösungen an Bedeutung verlieren, weil sie mit Server Components schlecht harmonieren. Klassisches CSS mit BEM eignet sich weiterhin für kleinere Projekte ohne Build-Pipeline. Entscheidend ist, mindestens zwei dieser Ansätze zu kennen und flexibel zwischen ihnen wechseln zu können, weil jedes neue Projekt andere Anforderungen mitbringt.
Testing und Toolchain: Wenig glamourös, aber entscheidend
Kein seriöses Unternehmen liefert Frontend-Code ohne Tests aus, und trotzdem ist Testing das Thema, das Einsteiger am häufigsten vernachlässigen. Verständlich: Tests schreiben ist weniger befriedigend als Features bauen. Aber genau Tests sind es, die den Unterschied zwischen einem Hobby-Projekt und professioneller Software ausmachen, weil sie Fehler auffangen, bevor sie in die Produktion gelangen.
Welche Test-Tools setzen sich durch?
Im Frontend-Testing hat sich die Landschaft in den letzten zwei Jahren deutlich konsolidiert, und Playwright (von Microsoft) hat Cypress als bevorzugtes End-to-End-Testing-Tool bei vielen Teams abgelöst [7]. Playwright testet in echten Browsern (Chromium, Firefox, WebKit), läuft schneller als Cypress und unterstützt parallele Testausführung nativ, was bei größeren Testsuiten erheblich Zeit spart. Cypress bleibt eine solide Wahl, besonders für kleinere Teams, die seine intuitive Oberfläche schätzen.
Für Unit-Tests und Komponenten-Tests dominiert Vitest, die schnell wachsende Alternative zu Jest, die sich durch deutlich kürzere Startzeiten und native ES-Module-Unterstützung auszeichnet. React Testing Library ergänzt Vitest beim Testen von React-Komponenten, und die Kombination aus beiden für schnelle Einzeltests plus Playwright für browserbasierte Integrationstests deckt die meisten Anforderungen professioneller Projekte ab.
In der Praxis läuft Testing so ab: Ein Entwickler schreibt eine neue Komponente, etwa eine Suchleiste mit Autovervollständigung, und parallel dazu entstehen Unit-Tests, die prüfen, ob die Komponente bei bestimmten Eingaben die richtigen Vorschläge anzeigt. Ein Playwright-Test simuliert dann den gesamten Ablauf im Browser: Seite öffnen, Suchbegriff eingeben, Vorschlag anklicken, Ergebnisseite prüfen. Schlägt ein Test fehl, blockiert er den Pull Request, denn kein Code gelangt ohne bestandene Tests in die Produktionsumgebung. So lautet die Grundregel in professionellen Teams.
Der Werkzeugkasten im Alltag
Neben Frameworks und Testtools gibt es eine Reihe von Werkzeugen, die zum täglichen Handwerkszeug gehören. Ohne sie funktioniert professionelle Frontend-Entwicklung nicht.
- VS Code: Der Editor, den rund 76 Prozent der Webentwickler nutzen [1]. Leichtgewichtig, erweiterbar, mit integriertem Terminal und Git-Unterstützung.
- Git und GitHub/GitLab: Versionskontrolle ist Pflicht. Branching-Strategien, Pull Requests und Code-Reviews laufen über Git. Ohne Git-Kenntnisse ist ein Einstieg in professionelle Teams nicht möglich.
- Chrome DevTools: Das eingebaute Entwicklerwerkzeug in Chrome (und Chromium-Browsern) zum Debuggen von HTML, CSS, JavaScript und Netzwerkanfragen. Unverzichtbar bei der täglichen Arbeit.
- Figma: Designers’ Standard-Tool. Frontend-Entwickler müssen kein Design erstellen, aber Figma-Dateien lesen, Maße ablesen und CSS-Werte extrahieren können.
- npm/pnpm: Paketmanager für JavaScript-Abhängigkeiten. pnpm gewinnt Marktanteile durch schnellere Installation und effizientere Speichernutzung.
- ESLint und Prettier: Code-Qualität und Formatierung automatisiert sicherstellen. In den meisten Projekten als Pre-commit-Hook konfiguriert.
Diese Liste ist nicht erschöpfend. Docker, CI/CD-Pipelines (GitHub Actions, GitLab CI), Storybook für Komponentendokumentation und Performance-Tools wie Lighthouse kommen je nach Unternehmen hinzu. Aber die sechs oben genannten Werkzeuge sind in praktisch jedem Frontend-Projekt im Einsatz.
Barrierefreiheit: Gesetzliche Pflicht seit 2025
Barrierefreiheit (Accessibility, a11y) ist kein Nischenthema mehr, seit der European Accessibility Act (EAA) am 28. Juni 2025 in der gesamten EU in Kraft getreten ist [6]. Alle digitalen Produkte und Dienstleistungen müssen seitdem die Web Content Accessibility Guidelines (WCAG) in Version 2.1, Level AA erfüllen, und die Übergangsfrist ist abgelaufen. Unternehmen, die dagegen verstoßen, müssen mit Abmahnungen und Bußgeldern rechnen.
Für Frontend-Entwickler bedeutet das konkret: Semantisches HTML verwenden (nicht alles in div-Elemente packen). ARIA-Attribute korrekt einsetzen. Farbkontraste prüfen (mindestens 4,5:1 für normalen Text). Tastaturnavigation sicherstellen. Formulare mit Labels und Fehlermeldungen versehen, die Screenreader vorlesen können. Focus-Management bei dynamischen Inhalten beachten.
Technisch ist das nicht besonders schwer, erfordert aber Wissen, das in vielen Ausbildungswegen schlicht fehlt. Accessibility-Kenntnisse bieten 2026 einen echten Wettbewerbsvorteil auf dem Arbeitsmarkt, weil Unternehmen händeringend nach Entwicklern suchen, die gesetzliche Barrierefreiheitsanforderungen ohne Nachschulung umsetzen können. Als Einstieg eignen sich der a11y-Kurs von web.dev und die WCAG-Dokumentation des W3C besonders gut.
Tools wie axe DevTools (eine Browser-Erweiterung), Lighthouse und Pa11y automatisieren einen Teil der Prüfung und finden fehlende Alt-Texte, zu geringe Kontraste und falsche ARIA-Rollen. Aber automatisierte Tests decken nur etwa 30 bis 40 Prozent aller Barrierefreiheitsprobleme ab, weshalb der Rest manuell geprüft werden muss: ob die Seite per Tastatur bedienbar ist, ob die Tab-Reihenfolge logisch aufgebaut ist und ob dynamisch geladene Inhalte dem Screenreader korrekt angekündigt werden.
Ein Aspekt wird häufig übersehen: Barrierefreiheit geht weit über Screenreader-Unterstützung für blinde Nutzer hinaus. Menschen mit eingeschränkter Motorik navigieren per Tastatur, Menschen mit Sehschwäche brauchen hohe Kontraste und skalierbare Schriften, und Menschen mit kognitiven Einschränkungen profitieren von klarer Struktur und einfacher Sprache. All diese Gruppen berücksichtigen die WCAG-Richtlinien gezielt, und konsequente Barrierefreiheit führt am Ende zu besseren Produkten für alle Nutzer.
Fazit: Breite vor Tiefe, Grundlagen vor Hype
Groß ist die Technologielandschaft im Frontend, aber keineswegs unübersichtlich, wenn man Prioritäten setzt. HTML, CSS und JavaScript bleiben das Fundament, und TypeScript ist 2026 de facto Standard. Bei den Frameworks bietet React die breiteste Jobauswahl, Angular den Zugang zu Enterprise-Positionen und Vue die angenehmste Lernkurve, während sich Next.js als Meta-Framework für React-Projekte fest etabliert hat.
Tailwind dominiert beim CSS-Tooling, aber die Entlassungen bei Tailwind Labs zeigen, dass kein Tool blindes Vertrauen verdient, egal wie verbreitet es gerade ist. Testing mit Vitest und Playwright, Versionskontrolle mit Git und Barrierefreiheit nach WCAG 2.1 AA gehören zum Pflichtprogramm jedes Frontend-Entwicklers.
Wer React und TypeScript beherrscht, hat 2026 die breiteste Jobauswahl. Aber ohne solide HTML-, CSS- und JavaScript-Grundlagen baut man auf Sand. Ich empfehle jedem Einsteiger, sich mindestens drei Monate mit den Grundlagen zu beschäftigen, bevor das erste Framework ins Spiel kommt, denn der Markt belohnt Tiefe im Fundament mehr als oberflächliche Breite bei den Tools.
Im nächsten Teil geht es um die verschiedenen Wege in den Beruf: Studium, Ausbildung, Bootcamp oder Selbststudium, jeweils mit konkreten Kosten, realistischen Zeitrahmen und einer ehrlichen Bewertung, welcher Weg für wen am besten geeignet ist.
Quellen
[1] Stack Overflow Developer Survey 2025: Technology Most Popular Technologies (https://survey.stackoverflow.co/2025/)
[2] GitHub Blog: TypeScript overtakes Python as most-used language on GitHub, August 2025 (https://github.blog/)
[3] The Frontend Company: Frontend Development Statistics 2026 (https://thefrontendcompany.com/posts/frontend-development-statistics)
[4] W3Techs: Usage Statistics of JavaScript Libraries for Websites, Februar 2026 (https://w3techs.com/technologies/overview/javascript_library)
[5] DevClass: Tailwind Labs lays off 75% of its engineers, January 2026 (https://www.devclass.com/ai-ml/2026/01/08/tailwind-labs-lays-off-75-percent-of-its-engineers-thanks-to-brutal-impact-of-ai/4079571)
[6] European Commission: European Accessibility Act, in Kraft seit 28. Juni 2025 (https://accessible-eu-centre.ec.europa.eu/)
[7] Playwright vs Cypress: A Detailed Comparison 2025 (https://playwright.dev/)