21.11.2023
Von Peter Hecker, Inhaber von HECKER CONSULTINGReact, Angular, Vue.js und Svelte im Vergleich: Unterschiede, Meta-Frameworks wie Next.js und Nuxt, Core Web Vitals und Kriterien für die Auswahl.
Angenommen, ein mittelständischer Maschinenbauer will sein Kundenportal neu bauen lassen. Drei Agenturen geben Angebote ab. Die erste schlägt React vor, die zweite Angular, die dritte Vue.js. Alle drei begründen ihre Wahl überzeugend, alle drei zeigen Referenzen. Wer in der Geschäftsführung oder der IT-Leitung entscheiden soll, steht vor einer Frage, die nach Technik klingt, in Wahrheit aber eine Frage nach Personal, Wartung und Laufzeit ist: Mit welchem Werkzeug lässt sich diese Anwendung auch in acht Jahren noch pflegen?
Die Auswahl ist seit Jahren groß und sie ist nicht kleiner geworden. Gleichzeitig hat sich verschoben, worüber eigentlich entschieden wird. Vor einigen Jahren ging es vor allem um die Bibliothek für die Benutzeroberfläche. Heute fällt die wichtigere Entscheidung oft eine Ebene darüber, bei den sogenannten Meta-Frameworks wie Next.js oder Nuxt. Und seit Google die Ladezeit und Reaktionsgeschwindigkeit von Seiten mit den Core Web Vitals messbar gemacht hat, ist die Technologiewahl auch eine Frage der Sichtbarkeit in Suchmaschinen. Hier finden Sie den aktuellen Stand, die Unterschiede in verständlicher Form und eine Einschätzung, welches Framework für welche Ausgangslage passt.
Das Frontend ist alles, was im Browser passiert: Formulare, Tabellen, Menüs, Diagramme, die Reaktion auf jeden Klick. Für eine einfache Firmenwebsite genügt dafür HTML mit etwas CSS und ein paar Zeilen JavaScript. Bei einer Anwendung, die sich eher wie ein Programm anfühlt als wie eine Webseite, wird es schnell unübersichtlich. Ein Bestellformular, das Preise live neu berechnet, Lieferzeiten nachlädt, Eingaben prüft und Rabatte anzeigt, muss ständig wissen, was sich gerade geändert hat und welche Teile der Seite deshalb neu gezeichnet werden müssen.
Genau diese Buchhaltung nehmen Frontend-Frameworks den Entwicklern ab. Drei Grundideen haben sie gemeinsam:
Streng genommen bezeichnet sich React selbst als Bibliothek, nicht als Framework, weil es nur die Oberfläche abdeckt und Routing, Datenabruf oder Formulare anderen Paketen überlässt. Angular dagegen liefert all das aus einer Hand. Im Alltag spricht man trotzdem bei allen von Frameworks, und diese Unterscheidung ist für die Auswahl wichtiger als die Wortwahl: Ein Komplettpaket nimmt Entscheidungen ab, eine Bibliothek lässt Freiheit – und verlangt, dass jemand diese Freiheit verantwortungsvoll nutzt.
Seit gut zehn Jahren teilen sich drei Projekte den größten Teil des Marktes. Sie unterscheiden sich weniger darin, was sich mit ihnen bauen lässt – das ist bei allen praktisch alles –, als darin, wie sie Teams organisieren und welche Entscheidungen sie vorgeben.
React wurde bei Facebook entwickelt, dem heutigen Meta-Konzern, und 2013 als Open Source veröffentlicht. Es ist das am weitesten verbreitete Werkzeug für Web-Oberflächen; in Entwicklerumfragen und Stellenanzeigen liegt es seit Jahren vorn. Die Oberfläche wird in JSX beschrieben, einer Schreibweise, die HTML-ähnliche Elemente direkt in JavaScript einbettet. React arbeitet mit einem virtuellen DOM, also einer Kopie der Seitenstruktur im Speicher, die mit dem echten Stand verglichen wird, bevor der Browser etwas neu zeichnet.
Seine Stärke ist das Ökosystem: Für fast jede Aufgabe gibt es mehrere ausgereifte Pakete, für fast jede Frage eine Antwort im Netz, und Entwicklerinnen und Entwickler mit React-Erfahrung sind vergleichsweise leicht zu finden. Die Kehrseite: Weil React nur die Oberfläche regelt, muss jedes Projekt Routing, Datenhaltung und Projektstruktur selbst festlegen. Zwei React-Anwendungen aus verschiedenen Häusern können sich deshalb sehr unterschiedlich anfühlen. Mit React 19 kamen Server Components und Actions in die stabile Version; der React Compiler, der Optimierungen automatisch übernimmt, die früher von Hand geschrieben werden mussten, ist seit 2025 als stabile Version verfügbar.
Angular stammt von Google und ist der Nachfolger von AngularJS, einem der ersten großen Frameworks, dessen Unterstützung Ende 2021 auslief. Angular bringt alles mit, was eine große Geschäftsanwendung braucht: Routing, Formulare, Anbindung an Schnittstellen, Testwerkzeuge und eine feste Projektstruktur. Es setzt von Anfang an auf TypeScript, eine Erweiterung von JavaScript um Datentypen, die Fehler schon beim Schreiben sichtbar macht.
Diese Vorgaben sind Absicht. In einem großen Team mit wechselnder Besetzung hilft es, wenn jede Anwendung gleich aufgebaut ist und Neue sich schnell zurechtfinden. Wer aus Java oder .NET kommt, erkennt viele Muster wieder, etwa die Dependency Injection, bei der Bausteine ihre Abhängigkeiten nicht selbst erzeugen, sondern zugeteilt bekommen. Der Preis ist eine steilere Lernkurve. Neue Hauptversionen von Angular erscheinen in festem Rhythmus – bis Version 22 halbjährlich, seitdem einmal im Jahr – und haben feste Supportzeiträume, für IT-Abteilungen, die Updates planen müssen, ein echter Vorteil. Die vergangenen Versionen haben das Framework spürbar modernisiert: Signals als neues Reaktivitätsmodell, Komponenten ohne Module und der Abschied von der bisherigen Änderungserkennung über die Hilfsbibliothek Zone.js.
Vue.js entstand 2014 als Projekt des Entwicklers Evan You und ist bis heute unabhängig von einem großen Konzern; es finanziert sich über Sponsoren und Unternehmen, die das Projekt unterstützen. Vue gilt als besonders zugänglich. Wer HTML, CSS und JavaScript kann, versteht eine Vue-Komponente oft auf Anhieb, weil Vorlage, Logik und Gestaltung übersichtlich in einer Datei stehen. Vue lässt sich zudem schrittweise einführen, etwa zunächst für ein einzelnes interaktives Formular auf einer bestehenden Seite.
Mit Vue 3 und der Composition API ist das Framework auch für große Anwendungen gut gerüstet. Vue 2 erreichte Ende 2023 sein Supportende; wer noch Anwendungen darauf betreibt, sollte die Migration fest einplanen. Der Arbeitsmarkt ist kleiner als bei React, aber stabil, und wer React oder Angular beherrscht, findet sich in Vue meist schnell zurecht.
Neben den drei Großen hat sich eine zweite Reihe etabliert, deren Ideen oft wichtiger sind als ihr Marktanteil. Viele Neuerungen der letzten Jahre sind dort zuerst entstanden und später von React, Angular und Vue übernommen worden.
Svelte, entwickelt von Rich Harris, verfolgt einen anderen Ansatz: Es ist im Kern ein Compiler. Statt eine Laufzeitbibliothek mit in den Browser zu schicken, übersetzt Svelte die Komponenten beim Bauen der Anwendung in schlanken JavaScript-Code. Das Ergebnis sind kleine Downloads und schnelle Oberflächen. Mit Svelte 5 kamen 2024 die sogenannten Runes hinzu, eine ausdrücklichere Schreibweise für reaktive Daten, die auch größere Anwendungen übersichtlich hält. Das zugehörige Meta-Framework heißt SvelteKit. Wer den Ansatz ausprobieren möchte, findet im Seminar Svelte und SvelteKit einen strukturierten Einstieg. Für Svelte spricht die Entwicklerzufriedenheit, die in Umfragen regelmäßig hoch ausfällt, gegen Svelte der deutlich kleinere Markt an Fachkräften und Zusatzpaketen.
Solid hat das Prinzip der Signals populär gemacht, von dem gleich noch die Rede ist. Qwik versucht, beim ersten Laden fast gar kein JavaScript auszuführen und Code erst dann nachzuladen, wenn der Nutzer tatsächlich klickt. Preact ist eine sehr kleine Alternative mit nahezu derselben Schnittstelle wie React. Lit wiederum baut auf Web Components auf, einem Browserstandard für eigene HTML-Elemente, die unabhängig von jedem Framework funktionieren – interessant für Designsysteme, die in mehreren Anwendungen mit unterschiedlicher Technik eingesetzt werden. Für die meisten Unternehmen sind das eher Spezialwerkzeuge als erste Wahl.
Einen bewussten Gegenentwurf bietet htmx. Die kleine Bibliothek erweitert HTML um Attribute, mit denen Teile einer Seite direkt vom Server nachgeladen werden. Die Logik bleibt auf dem Server, etwa in Java, C#, Python oder PHP, und im Browser läuft nur wenig Code. Für viele interne Anwendungen, Verwaltungsoberflächen und Formularstrecken ist das eine ernsthafte Alternative, gerade für Teams, die ihre Stärken im Backend haben. Für hochinteraktive Oberflächen wie Planungstafeln oder Editoren stößt der Ansatz an Grenzen.
Wer die Frameworks zuletzt vor drei Jahren verglichen hat, sollte einige Entwicklungen kennen. Sie verändern weniger, welches Framework „gewinnt“, als die Art, wie heute Webanwendungen gebaut werden.
Signals sind Werte, die sich merken, wer sie verwendet. Ändert sich ein Signal, wird gezielt nur die Stelle der Oberfläche aktualisiert, die davon abhängt – nicht die ganze Komponente. Man kann sich das vorstellen wie eine Tabellenkalkulation: Ändert sich eine Zelle, rechnet Excel nur die Formeln neu, die darauf verweisen. Angular hat Signals seit 2023 schrittweise zum Standard gemacht, Vue arbeitet intern seit Langem mit einem ähnlichen Prinzip, Svelte 5 nutzt es mit den Runes, Solid hat es bekannt gemacht. Es gibt sogar einen Vorschlag, Signals als Bestandteil von JavaScript selbst zu standardisieren. React geht einen eigenen Weg und setzt stattdessen auf den Compiler. Wer Angular-Anwendungen modernisiert, findet im Seminar Angular Signals die Umstellung Schritt für Schritt.
Lange galt die Single-Page-Anwendung als Ideal: Der Browser lädt einmal eine große JavaScript-Datei und baut danach alles selbst auf. Das fühlt sich nach dem Laden flüssig an, macht aber den ersten Seitenaufruf langsam und erschwert Suchmaschinen die Arbeit. Inzwischen schwingt das Pendel zurück. React Server Components laufen ausschließlich auf dem Server, holen dort Daten aus Datenbank oder Schnittstelle und schicken nur das fertige Ergebnis an den Browser. Der Code dieser Komponenten landet gar nicht erst beim Nutzer. Ähnliche Ideen verfolgen andere Frameworks mit eigenen Mitteln.
Für Entscheider ist wichtig: Diese Architektur ist leistungsfähig, aber auch anspruchsvoller. Ein Teil der Anwendung läuft im Browser, ein Teil auf dem Server, und die Grenze dazwischen muss das Team verstehen. Dass dabei auch neue Angriffsflächen entstehen, zeigte Ende 2025 eine kritische Sicherheitslücke in der Server-Components-Verarbeitung, die zahlreiche React- und Next.js-Anwendungen betraf und schnelle Updates erforderte.
Fast unbemerkt hat sich der Unterbau vereinheitlicht. Vite, ein Entwicklungs- und Build-Werkzeug aus dem Umfeld von Vue, ist heute die Grundlage vieler Frameworks, auch außerhalb der Vue-Welt. TypeScript ist in professionellen Projekten zum Normalfall geworden; neue Projekte starten kaum noch ohne. Und Node.js, die Laufzeitumgebung für JavaScript auf dem Server, bekommt mit Deno und Bun Konkurrenz. Für die Framework-Wahl heißt das: Die Werkzeuge rund um die Frameworks sind sich ähnlicher geworden, ein Wechsel zwischen ihnen ist für erfahrene Teams leichter als früher.
Ein Meta-Framework baut auf einem Frontend-Framework auf und ergänzt, was eine vollständige Webanwendung braucht: Routing über Dateistruktur, Datenabruf, Rendern auf dem Server, Optimierung von Bildern und Schriften, Anbindung an Hosting-Plattformen. Wer heute ein neues Projekt mit React startet, beginnt in der Regel nicht mehr mit React allein, sondern mit einem Meta-Framework darüber. Die React-Dokumentation empfiehlt das inzwischen ausdrücklich.
Die wichtigsten Paare im Überblick:
Warum ist das die eigentliche Entscheidung? Weil das Meta-Framework festlegt, wie die Seiten entstehen. Grob gibt es vier Verfahren. Beim clientseitigen Rendern baut der Browser die Seite selbst zusammen – passend für Anwendungen hinter einem Login, bei denen Suchmaschinen keine Rolle spielen. Beim serverseitigen Rendern erzeugt der Server bei jedem Aufruf fertiges HTML, gut für aktuelle, personalisierte Inhalte. Bei der statischen Erzeugung entstehen die Seiten einmal beim Veröffentlichen, ideal für Produktseiten oder Ratgeber, die sich selten ändern. Und beim Inselprinzip ist die Seite im Grunde statisch, nur einzelne Bereiche wie ein Konfigurator oder ein Suchfeld werden interaktiv.
Angenommen, ein Onlinehändler betreibt einen Katalog mit 20.000 Artikeln und einen Kundenbereich mit Bestellhistorie. Die Artikelseiten sollen schnell laden und bei Google gut gefunden werden – hier ist statische Erzeugung oder Server-Rendering die richtige Wahl. Der Kundenbereich dagegen ist eine klassische Anwendung hinter dem Login. Moderne Meta-Frameworks erlauben, beides in einem Projekt zu mischen. Das ist ihr größter Vorteil gegenüber den reinen Single-Page-Anwendungen von früher.
Ein Punkt verdient bei der Auswahl Aufmerksamkeit: die Bindung an einen Anbieter. Next.js läuft am bequemsten auf der Plattform von Vercel, lässt sich aber auch auf eigenen Servern oder bei anderen Cloud-Anbietern betreiben – mit etwas mehr Aufwand. Wer Daten aus Datenschutzgründen in eigenen Rechenzentren oder bei europäischen Anbietern halten will, sollte das vor dem Projektstart klären und nicht erst beim ersten Deployment.
Ältere Vergleiche bewerten Frameworks oft nach Kennzahlen wie First Meaningful Paint oder Time to Interactive. Beide spielen keine Rolle mehr: Google hat sie aus seinem Messwerkzeug Lighthouse entfernt. Maßgeblich sind heute die Core Web Vitals, drei Kennzahlen, die das Nutzererlebnis abbilden sollen und in die Bewertung der Seitenerfahrung bei Google einfließen:
Im Labor, also bei Tests auf dem eigenen Rechner, ergänzt die Total Blocking Time (TBT) das Bild. Sie zeigt, wie lange der Browser durch JavaScript blockiert ist und deshalb nicht auf Eingaben reagieren kann. Entscheidend für Google sind aber die Felddaten echter Besucher, die Chrome anonym sammelt. Bewertet wird der Wert, den drei Viertel der Seitenaufrufe erreichen oder unterbieten.
Was hat das mit der Framework-Wahl zu tun? Mehr, als viele denken. Je mehr JavaScript eine Seite beim Laden ausführen muss, desto schlechter fallen in der Regel LCP und INP aus, besonders auf günstigen Smartphones im Mobilfunknetz. Eine große Single-Page-Anwendung, die erst eine umfangreiche Datei laden und ausführen muss, bevor überhaupt Text erscheint, startet mit einem Nachteil. Server-Rendering, statische Erzeugung und das Inselprinzip setzen genau dort an.
Benchmarks, in denen ein Framework ein anderes um Millisekunden schlägt, sollten Sie trotzdem gelassen sehen. Sie messen meist künstliche Aufgaben wie das Anlegen von tausend Tabellenzeilen. In der Praxis entscheiden die Architektur und die Sorgfalt des Teams weit mehr: zu große Bilder, unnötige Drittanbieter-Skripte für Tracking und Chat, Schriften, die zu spät laden. Eine sorgfältig gebaute React-Seite schlägt eine nachlässig gebaute Svelte-Seite jederzeit. Meine Empfehlung: Legen Sie Zielwerte für die Core Web Vitals in die Anforderungen, bevor die Technik feststeht, und lassen Sie sie im Projekt regelmäßig messen.
Die folgende Übersicht fasst die wichtigsten Unterschiede zusammen. Sie ersetzt keine Prüfung im eigenen Projekt, zeigt aber, wo die Schwerpunkte liegen.
Der Punkt Sicherheit verdient eine Erläuterung. Alle vier Frameworks schützen standardmäßig vor Cross-Site-Scripting (XSS), also davor, dass Angreifer über Eingabefelder eigenen Schadcode in eine Seite einschleusen. Sie zeigen Texte so an, dass darin enthaltener Code nicht ausgeführt wird. Jedes Framework hat aber auch eine Hintertür, um HTML ungeprüft einzufügen, und genau dort entstehen in der Praxis die meisten Lücken. Ein größeres Risiko liegt heute ohnehin oft in den Abhängigkeiten: Eine typische Anwendung bindet Hunderte Pakete aus dem öffentlichen Verzeichnis npm ein. 2025 kam es dort mehrfach zu Angriffen, bei denen beliebte Pakete mit Schadcode versehen wurden. Regelmäßige Updates und eine Prüfung der Abhängigkeiten gehören deshalb in jedes Projekt, unabhängig vom Framework.
Technisch lässt sich mit jedem der großen Frameworks fast jede Anwendung bauen. Die Unterschiede, die über Erfolg oder Ärger entscheiden, liegen deshalb meist außerhalb der Technik.
Die wichtigste Frage lautet: Wer soll die Anwendung in den nächsten Jahren weiterentwickeln? Ein Team, das seit Jahren erfolgreich mit Angular arbeitet, sollte gute Gründe haben, für das nächste Projekt zu wechseln. Wer neu einstellt oder mit externen Dienstleistern arbeitet, profitiert von einem großen Markt – ein Argument für React. Und wer ein starkes Java- oder .NET-Team hat, findet sich in Angular mit seinen vertrauten Mustern oft schneller zurecht als in der offenen React-Welt. Auch ein Blick auf htmx lohnt sich für solche Teams.
Eine Marketingseite für eine Kampagne lebt ein Jahr, ein Kundenportal oder eine Fachanwendung zehn Jahre und länger. Je länger die Lebensdauer, desto wichtiger werden planbare Updates, eine verlässliche Organisation hinter dem Framework und gute Migrationspfade. Angular punktet hier mit festen Release- und Supportzyklen, React mit seiner Verbreitung und einer Gemeinschaft, die so schnell nicht verschwindet. Für inhaltsstarke Websites mit wenig Interaktion lohnt die Frage, ob es überhaupt ein großes Framework braucht oder ob eine statische Lösung wie Astro genügt.
Seit Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG). Es verpflichtet viele Anbieter von Produkten und Dienstleistungen für Verbraucher, etwa im Onlinehandel, ihre digitalen Angebote barrierefrei zu gestalten; für Kleinstunternehmen bei Dienstleistungen gibt es Ausnahmen. Kein Framework macht eine Seite automatisch barrierefrei, und keines verhindert es. Entscheidend ist, ob die verwendeten Komponentenbibliotheken für Menüs, Dialoge und Formulare sauber mit Tastatur und Screenreader funktionieren. Fragen Sie danach, bevor Sie eine Bibliothek festschreiben. (Das ist eine allgemeine Einordnung, keine Rechtsberatung.)
Eine reine Single-Page-Anwendung lässt sich als Sammlung statischer Dateien auf nahezu jedem Webserver betreiben. Server-Rendering braucht dagegen eine laufende Server-Umgebung, die überwacht, aktualisiert und abgesichert werden will. Klären Sie früh, wer das übernimmt, wo die Server stehen und ob personenbezogene Daten dabei Drittländer erreichen. Die Lizenzfrage ist dagegen meist unkritisch: React, Angular, Vue und Svelte stehen unter der MIT-Lizenz und dürfen auch kommerziell frei eingesetzt werden.
Wenn zwei Optionen ernsthaft infrage kommen, ist ein kurzer Prototyp aufschlussreicher als jeder Vergleichsartikel. Zwei Entwickler bauen in zwei Wochen dieselbe typische Maske – etwa eine Suchliste mit Filter und Detailansicht – in beiden Frameworks. Danach lassen sich Aufwand, Ladezeiten, Lesbarkeit des Codes und das Bauchgefühl des Teams vergleichen. Das kostet wenig im Verhältnis zu einer Fehlentscheidung, die man zehn Jahre mitschleppt.
Viele Probleme in Frontend-Projekten haben weniger mit dem Framework zu tun als mit dem Umgang damit. Einige Fehler begegnen einem besonders häufig:
KI-Assistenten schreiben inzwischen in vielen Teams einen erheblichen Teil des Frontend-Codes mit. Sie erzeugen Komponenten nach Beschreibung, setzen Entwürfe aus Designwerkzeugen in Code um, schreiben Tests und erklären fremden Code. Für die Framework-Wahl hat das eine Folge, über die selten gesprochen wird: Die Assistenten sind dort am besten, wo es am meisten öffentlichen Beispielcode gibt. React profitiert davon besonders, und auch Angular und Vue sind gut abgedeckt. Bei kleineren Frameworks und bei ganz neuen Versionen schlagen die Assistenten dagegen häufiger veraltete Schreibweisen vor, etwa die Svelte-Syntax vor den Runes oder Angular-Muster ohne Signals.
Das verstärkt die Stellung der Großen, macht aber keine Wahl falsch. Wichtiger ist eine zweite Folge: Wenn Code schneller entsteht, wird das Prüfen wichtiger. Ein Assistent, der in Sekunden eine Formularmaske baut, fragt nicht nach Barrierefreiheit, Datenschutz oder der Sicherheitslücke in einer veralteten Abhängigkeit. Code-Reviews, automatisierte Tests und klare Architekturregeln gewinnen deshalb an Gewicht.
Und dann ist da noch KI als Funktion in der Anwendung selbst: Chat-Oberflächen, Assistenten im Kundenportal, Zusammenfassungen von Dokumenten. Hier sind React und Next.js besonders verbreitet. Fertige Bausteine, etwa um Antworten eines Sprachmodells Wort für Wort anzuzeigen, gibt es aber auch für Vue und Svelte, und möglich ist das mit allen Frameworks.
Das „beste“ JavaScript-Frontend-Framework gibt es nicht, aber es gibt für fast jede Ausgangslage eine naheliegende Wahl. Als grobe Orientierung:
Überschätzt wird in solchen Debatten fast immer die Leistungsfrage. Alle großen Frameworks sind schnell genug, wenn sie richtig eingesetzt werden; die Core Web Vitals einer Seite hängen weit mehr an Architektur, Bildern und Drittanbieter-Skripten als an der Wahl zwischen React und Vue. Unterschätzt wird dagegen, wie teuer ein Wechsel später wird. Ein Framework begleitet eine Anwendung oft länger als die Menschen, die es ausgesucht haben.
Meine Empfehlung: Entscheiden Sie zuerst, welche Seiten wie entstehen sollen – vom Server, statisch oder im Browser –, dann, welches Team die Anwendung pflegt, und erst danach über das Framework. Wer diese Reihenfolge einhält, landet selten bei einer schlechten Wahl.
Formal eine Bibliothek, denn React kümmert sich nur um die Oberfläche. Zusammen mit einem Meta-Framework wie Next.js entsteht aber ein vollständiges Framework. In der Praxis werden beide Begriffe für React verwendet; für die Auswahl zählt, dass Sie bei React mehr Architekturentscheidungen selbst treffen.
Selten allein aus technischen Gründen. Eine Neuentwicklung kostet viel und bringt den Nutzern zunächst nichts Neues. Ein Wechsel ist sinnvoll, wenn das alte Framework nicht mehr gepflegt wird – etwa AngularJS oder Vue 2 –, wenn sich keine Fachkräfte mehr finden oder wenn eine größere Überarbeitung ohnehin ansteht. Dann ist ein schrittweiser Umbau, Seite für Seite, meist sicherer als ein großer Schnitt.
Oft nicht. Eine Unternehmensseite mit Texten, Bildern und einem Kontaktformular kommt mit einem Content-Management-System oder einem statischen Seitengenerator gut aus. Frameworks spielen ihre Stärken bei Anwendungen aus: Portalen, Konfiguratoren, Buchungsstrecken, internen Werkzeugen.
Für neue Projekte nur noch in Ausnahmefällen. Viele Funktionen, für die jQuery einst nötig war, beherrschen moderne Browser heute von selbst. In bestehenden Anwendungen kann jQuery aber durchaus weiterlaufen, solange es aktuell gehalten wird; ein Umbau lohnt sich meist erst im Zuge einer größeren Modernisierung.
In professionellen Projekten ja. TypeScript macht Fehler früher sichtbar, verbessert die Unterstützung durch Entwicklungsumgebungen und KI-Assistenten und erleichtert die Arbeit in größeren Teams. Angular setzt es ohnehin voraus, bei React, Vue und Svelte ist es der übliche Standard.
Einen Überblick über Seminare zu React, Angular, Vue.js, Svelte, TypeScript und Node.js finden Sie auf der Themenseite JavaScript. Die Trainings richten sich an Einsteiger ebenso wie an erfahrene Entwickler, auch aus dem Java- und .NET-Umfeld, und lassen sich auf die Technik und den Projektstand Ihres Teams abstimmen.
Wir erweitern ständig unser Beratungsportfolio. Über 600 Beratungsleistungen haben wir für Sie im Programm. Selbstverständlich lassen sich die einzelnen Themen kombinieren. So erhalten Sie genau die Beratung, die Sie wünschen und brauchen.
Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>Nach dem Seminar entwickeln Sie Single Page Applications mit Vue 3: Komponenten mit script setup, reaktiver Zustand, Formulare, Routing, Pinia-Stores und API-Anbindung bis zum Produktions-Build.
Sie verwalten Serverzustand in React mit TanStack Query: Query Keys und Cache gezielt steuern, Mutationen mit optimistischen Updates absichern, unendliche Listen bauen und Daten beim serverseitigen Rendern vorladen.
Sie bauen Oberflächen mit Svelte 5 und Runes, strukturieren Zustand ohne Store-Ballast und bringen mit SvelteKit eine vollständige Anwendung samt Formularen, Serverlogik und Deployment in Produktion.
Fortgeschrittene Navigation für gewachsene Anwendungen: Sie laden Daten mit Loadern, verarbeiten Formulare mit Actions, typisieren Routen mit TypeScript, schützen Bereiche vor dem Rendern und teilen das Bundle per Lazy Loading.
Remix-Anwendungen im Bestand sicher weiterführen: Sie verstehen Loader, Actions und verschachtelte Routen aus Remix-Sicht und stellen Ihre App schrittweise auf den Framework-Modus von React Router um.
Sie schreiben JavaScript, das sich vorhersagbar verhält: reine Funktionen, unveränderliche Daten, Komposition statt verschachtelter Schleifen – und Fehlerbehandlung, die ohne verstreute try/catch-Blöcke auskommt.
Ihr Code bleibt JavaScript, wird aber vom TypeScript-Compiler geprüft: Sie annotieren Typen mit JSDoc, liefern Bibliotheken mit .d.ts-Dateien aus und erzeugen daraus eine API-Dokumentation.
LLM-Anwendungen in TypeScript mit LangChain.js: Prompt-Vorlagen, Chat-Modelle, Output-Parser und strukturierte Ausgabe zu Workflow-Ketten verbinden – ergänzt um RAG, Agenten mit LangGraph.js und Deployment auf Node.js.
An einem Tag bauen Sie mit htmx eine kleine interaktive Webanwendung: Anfragen per Attribut, gezielter Austausch von HTML-Fragmenten, Trigger, Ladeindikator, Polling und Übergänge – mit einem schlanken Demo-Server statt eines JavaScript-Frameworks.
Sie frischen die jQuery-Grundlagen auf, die Sie im Bestand brauchen, bringen Altanwendungen auf einen sicheren Stand und ersetzen Selektoren, Events, Ajax und Effekte Modul für Modul durch natives DOM, fetch und CSS-Übergänge.
In zwei Tagen von der ersten Komponente zur kleinen React-App mit Vite: Sie verstehen JSX, Props und State, bauen Listen und einfache Formulare und wissen, wohin Server Components führen.
Erzeugungs-, Struktur- und Verhaltensmuster so umsetzen, wie Node.js sie nahelegt – mit Modul-Caching, EventEmitter, Proxy, async Iteratoren und Streams – und erkennen, wann ein einfaches Modul das bessere Muster ist.
Mit htmx bauen Sie dynamische Webanwendungen, bei denen der Server HTML-Fragmente liefert – mit wenigen Attributen statt aufwendiger JavaScript-Programmierung und ohne Build-Schritt.
Die Intensiv-Schulung vertieft Next.js mit dem App Router: Sie entscheiden pro Route über Rendering und Caching, sichern Server Actions ab und bringen die Anwendung auf Vercel oder den eigenen Server.
Sie bauen einen GraphQL-Server mit Node.js und Apollo Server von Grund auf: Schema, Resolver, Persistenz mit MongoDB und SQL, Mutationen, DataLoader gegen das N+1-Problem, Fehlerbehandlung und Tests.
Schritt für Schritt vom ersten HTTP-Server zur Web-Anwendung mit REST-Diensten, Echtzeit-Nachrichten und Datenbank – und dabei verstehen, warum Node.js viele gleichzeitige Anfragen mit wenig Ressourcen bedient.
Sie lernen kompakt, wie JavaScript eine HTML-Seite zum Leben erweckt: Elemente ändern, auf Klicks und Eingaben reagieren und Daten mit fetch nachladen – Schritt für Schritt mit kleinen Übungen im Browser.
Sie übertragen Ihr JavaScript- und TypeScript-Wissen Konzept für Konzept auf Rust und setzen Rust dort ein, wo es neben JavaScript am meisten bringt: als WebAssembly-Modul im Browser und als native Node-Erweiterung.
Sie bauen Ihre ersten Svelte-Komponenten Schritt für Schritt: Markup, Runes, Logikblöcke, Ereignisse, Bindungen und Übergänge – mit HTML-, CSS- und JavaScript-Grundlagen als einziger Voraussetzung.
Nach dem Kurs wissen Sie, wie Node.js mit Event Loop und Kernmodulen arbeitet, und schreiben eigene Kommandozeilenwerkzeuge, die Dateien verarbeiten, Streams nutzen und mit dem eingebauten Test-Runner abgesichert sind.
Sie kennen JavaScript und wollen Typen: Nach dem Kurs beschreiben Sie Daten mit Interfaces, Unions und Generics und stellen ein bestehendes JavaScript-Projekt Schritt für Schritt auf TypeScript um.
Mit Express 5 bauen Sie REST-APIs und Webserver aus Routen, Routern und Middleware, behandeln Fehler auch in asynchronen Handlern zentral, validieren Eingaben und sichern die API mit helmet, CORS und Tests ab.
Aktuelle und interessante Themen und Beiträge für Sie zusammengetragen und aufbereitet.
