Ein Online-Shop lädt auf dem Smartphone vier Sekunden lang, das Menü springt beim Laden nach unten, und der Button „In den Warenkorb“ reagiert erst beim zweiten Tippen. Technisch ist an dieser Seite vielleicht nichts kaputt. Trotzdem verliert sie Kundschaft, rutscht in den Suchergebnissen ab und ist für Menschen mit Screenreader kaum benutzbar.

Genau an solchen Stellen zeigt sich, wie sich Webentwicklung verändert hat. Vor einigen Jahren ging es vor allem darum, ob eine Seite überhaupt funktioniert und auf dem Handy passabel aussieht. Heute entscheiden Architektur, Rendering-Strategie, Typsicherheit, Barrierefreiheit und messbare Ladezeiten darüber, ob ein Webprojekt gut ist. Dieser Überblick erklärt die wichtigsten Bausteine und ordnet ein, welche davon für welche Projekte zählen.

Das Fundament bleibt: HTML, CSS und JavaScript

An der Grundlage hat sich nichts geändert. Jeder Browser versteht drei Sprachen: HTML beschreibt Struktur und Bedeutung einer Seite, CSS regelt Layout und Gestaltung, JavaScript macht sie interaktiv. Jedes Framework, jedes Content-Management-System und jeder Website-Baukasten erzeugt am Ende genau diese drei Dinge. Wer tiefer einsteigen möchte, findet die Grundlagen im Beitrag HTML, CSS und JavaScript im Zusammenspiel.

Verändert haben sich die Fähigkeiten dieser Sprachen. CSS beherrscht inzwischen Dinge, für die man früher JavaScript oder Präprozessoren brauchte: Grid- und Flexbox-Layouts, Variablen (Custom Properties), Verschachtelung, Container Queries (Komponenten passen sich an die Breite ihres Elterncontainers an statt an die des Bildschirms) und den Selektor :has(). Auch JavaScript hat mit Modulen, fetch und async/await die alten Hilfsbibliotheken wie jQuery weitgehend überflüssig gemacht. Die Technik, die früher unter dem Namen AJAX lief – Daten im Hintergrund nachladen, ohne die Seite neu aufzubauen –, ist heute schlicht Standard.

Ein zweiter, oft übersehener Fortschritt: Die Browser sind sich einig wie selten zuvor. Der Internet Explorer spielt keine Rolle mehr, Chrome, Edge, Firefox und Safari setzen neue Standards weitgehend zeitgleich um. Die Initiative „Baseline“ der Browserhersteller kennzeichnet, welche Funktionen in allen gängigen Browsern verfügbar sind. Für Teams heißt das: weniger Sonderwege, weniger Polyfills (Ersatzcode für fehlende Browserfunktionen).

Websites, Webanwendungen und die Frage nach dem Framework

Die alte Unterscheidung trägt noch: Eine Website informiert, etwa die Seite eines Handwerksbetriebs oder ein Firmenblog. Eine Webanwendung verarbeitet Daten und Nutzereingaben, etwa ein Buchungssystem, ein Kundenportal oder ein internes Dashboard. Die Grenze verschwimmt, aber sie hilft bei der wichtigsten Entscheidung am Projektanfang: Wie viel JavaScript braucht das Projekt wirklich?

Für Webanwendungen mit viel Interaktion haben sich komponentenbasierte Frameworks durchgesetzt. Eine Komponente bündelt Darstellung und Verhalten eines Bausteins, etwa eines Warenkorbs oder eines Datumsfelds, und lässt sich wiederverwenden. Die bekanntesten Bibliotheken sind React, Vue, Angular und Svelte. Darauf setzen sogenannte Meta-Frameworks auf, die Routing, Datenladen und Rendering mitbringen: Next.js für React, Nuxt für Vue, SvelteKit für Svelte. Für inhaltsgetriebene Websites ist Astro beliebt, das standardmäßig fast kein JavaScript an den Browser schickt.

Welches Framework „das beste“ ist, lässt sich nicht pauschal beantworten. Wichtiger als Benchmarks sind meist drei Fragen: Was kann das Team schon? Wie groß ist das Ökosystem an Bibliotheken und Fachkräften? Und wie lange soll die Anwendung gepflegt werden? Ein internes Tool, das zehn Jahre laufen soll, profitiert von einem verbreiteten, gut dokumentierten Framework mehr als von der neuesten Idee.

Eine Gegenbewegung ist ebenfalls sichtbar: Bibliotheken wie HTMX setzen wieder auf serverseitig erzeugtes HTML und kommen mit wenig JavaScript aus. Für viele Formular- und Verwaltungsanwendungen ist das eine ernstzunehmende, oft einfachere Alternative.

Rendering-Strategien: Wo die Seite entsteht

Die vielleicht wichtigste Architekturfrage moderner Webentwicklung lautet: Wo und wann wird aus Daten und Code fertiges HTML? Die Antwort beeinflusst Ladezeit, Suchmaschinenoptimierung, Serverkosten und Komplexität.

Beim Client-side Rendering lädt der Browser zunächst eine fast leere Seite und baut den Inhalt per JavaScript auf. Das war lange der Standard für Single-Page-Applications, hat aber Nachteile: Auf schwachen Smartphones dauert es, bis etwas zu sehen ist, und Suchmaschinen sowie KI-Crawler sehen ohne JavaScript-Ausführung zunächst wenig.

Beim Server-side Rendering liefert der Server fertiges HTML aus, das der Browser sofort anzeigt. Anschließend „hydriert“ JavaScript die Seite, macht sie also interaktiv. Static Site Generation geht noch einen Schritt weiter: Alle Seiten entstehen schon beim Build und liegen als statische Dateien auf einem Webserver oder einem CDN (Content Delivery Network, ein weltweit verteiltes Netz von Auslieferungsservern). Das ist schnell, günstig und sicher, weil es zur Laufzeit keinen Anwendungsserver gibt, der angegriffen werden könnte.

Angenommen, ein mittelständischer Maschinenbauer baut seine Website neu: Produktseiten, Fachartikel, ein Kontaktformular. Hier ist statische Generierung fast immer die beste Wahl. Ein Online-Shop mit Lagerbeständen und Preisen pro Kundengruppe braucht dagegen SSR, zumindest für einen Teil der Seiten. Moderne Meta-Frameworks erlauben es, diese Strategien pro Seite zu mischen. React Server Components verschieben zudem Teile der Komponentenlogik ganz auf den Server, sodass weniger JavaScript beim Nutzer ankommt. Unsere Einschätzung: Diese Flexibilität ist ein echter Fortschritt, erhöht aber die Komplexität. Für einfache Projekte lohnt sich die einfachste Strategie, die die Anforderungen erfüllt.

TypeScript ist der neue Standard

TypeScript erweitert JavaScript um Typen. Entwickler:innen legen fest, dass eine Funktion etwa eine Zahl erwartet und einen Text zurückgibt, und der Compiler meldet Fehler, bevor der Code überhaupt läuft. Im Browser landet am Ende wieder normales JavaScript.

Was 2018 noch eine Option für große Teams war, ist inzwischen die Regel: Die gängigen Frameworks bieten TypeScript bei der Projekteinrichtung an, Angular und Next.js setzen es standardmäßig ein, und viele Bibliotheken bringen ihre Typdefinitionen gleich mit. Der Nutzen zeigt sich vor allem beim Ändern von Code. Benennt ein Team in einem Kundenportal das Feld kundennummer um, zeigt der Editor sofort alle Stellen, die angepasst werden müssen. Ohne Typen fällt das im schlechtesten Fall erst in der Produktion auf. Auch serverseitige Laufzeitumgebungen wie Node.js, Deno und Bun können TypeScript-Dateien inzwischen direkt ausführen, prüfen die Typen dabei aber standardmäßig nicht. Node.js entfernt die Typangaben lediglich, ohne zusätzliches Flag seit Version 22.18 bzw. 23.6.

Wer TypeScript in einem bestehenden Projekt einführen oder ein Team schulen möchte, findet dazu Angebote auf unserer Seite zur TypeScript-Entwicklung, Beratung und Schulung.

Barrierefreiheit: Pflicht statt Kür

Barrierefreiheit bedeutet, dass auch Menschen mit Seh-, Hör- oder motorischen Einschränkungen eine Website nutzen können, etwa mit Screenreader, Tastatur oder Vergrößerung. Lange galt das als nettes Extra. Inzwischen ist es für viele Unternehmen eine gesetzliche Anforderung.

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG). Es setzt den European Accessibility Act der EU um und betrifft unter anderem Online-Shops und andere Dienstleistungen im elektronischen Geschäftsverkehr für Verbraucher. Kleinstunternehmen, die Dienstleistungen anbieten, sind ausgenommen. Als technischer Maßstab dienen in der Praxis die Web Content Accessibility Guidelines (WCAG) des W3C, die über die europäische Norm EN 301 549 einfließen. Ob und wie ein konkretes Angebot betroffen ist, sollte im Zweifel rechtlich geprüft werden.

Technisch beginnt Barrierefreiheit beim sauberen HTML: echte Überschriften statt fett formatierter Absätze, Buttons statt anklickbarer div-Elemente, Alternativtexte für Bilder, beschriftete Formularfelder und ausreichende Farbkontraste. Wer diese Grundlagen von Anfang an beachtet, zahlt wenig dafür. Teuer wird es, wenn eine fertige Anwendung nachträglich umgebaut werden muss. Praktische Hinweise dazu sammelt der Praxisleitfaden für barrierefreies Web.

Ladezeit messbar machen: Core Web Vitals

Wie schnell sich eine Seite anfühlt, lässt sich messen. Google fasst drei Kennzahlen unter dem Namen Core Web Vitals zusammen und berücksichtigt sie als eines von vielen Signalen in der Suche:

• Largest Contentful Paint (LCP): Wann ist das größte sichtbare Element geladen, etwa ein Titelbild? Als gut gelten bis zu 2,5 Sekunden.
• Interaction to Next Paint (INP): Wie schnell reagiert die Seite sichtbar auf Klicks und Eingaben? Gut sind bis zu 200 Millisekunden. INP hat 2024 die ältere Kennzahl First Input Delay abgelöst.
• Cumulative Layout Shift (CLS): Wie stark springen Inhalte beim Laden? Ein Wert bis 0,1 gilt als gut.

Das Beispiel vom Anfang zeigt alle drei Probleme: langsames Titelbild (LCP), springendes Menü (CLS), träger Button (INP). Die häufigsten Ursachen sind unkomprimierte Bilder, zu viel JavaScript, nachgeladene Schriften und Werbe- oder Tracking-Skripte. Messen lassen sich die Werte mit den Entwicklerwerkzeugen der Browser, mit Lighthouse und mit Felddaten echter Nutzer, die Google in der Search Console anzeigt. Felddaten sind dabei aussagekräftiger als Labortests auf einem schnellen Entwicklerrechner. Wie sich solche Probleme systematisch beheben lassen, beschreibt unsere Leistung Web-Performance und Optimierung.

Backend, Cloud und Progressive Web Apps

Hinter fast jeder Webanwendung steht ein Server, der Daten speichert, Geschäftsregeln anwendet und mit anderen Systemen spricht. Die Wahl der Sprache ist hier freier als im Browser: Java, C#, Python, PHP, Go oder JavaScript mit Node.js sind verbreitet. Die Schnittstelle zwischen Frontend und Backend bilden meist REST- oder GraphQL-APIs, also klar definierte Endpunkte, über die Daten im JSON-Format ausgetauscht werden.

Die Kommunikation läuft über HTTP, und zwar fast ausschließlich verschlüsselt per HTTPS. Browser markieren unverschlüsselte Seiten als unsicher, und viele moderne Browserfunktionen stehen nur auf HTTPS-Seiten zur Verfügung. Neuere Protokollversionen wie HTTP/2 und HTTP/3 beschleunigen die Übertragung, ohne dass Entwickler:innen dafür viel tun müssen.

Betrieben werden Anwendungen heute meist in der Cloud, etwa bei AWS, Microsoft Azure oder Google Cloud, oder bei spezialisierten Anbietern für Frontend-Hosting. Container und sogenannte Serverless-Funktionen (kleine Codeeinheiten, die der Anbieter nur bei Bedarf startet) erleichtern die Skalierung. Für Unternehmen in der EU kommen Fragen der Datenhaltung und der DSGVO hinzu, die bei der Wahl des Anbieters früh geklärt werden sollten.

Progressive Web Apps (PWAs) galten 2018 als die Zukunft des mobilen Webs. Eine PWA ist eine Website, die sich installieren lässt, über einen Service Worker (ein Hintergrundskript des Browsers) auch offline funktioniert und Benachrichtigungen senden kann. Die Bilanz ist gemischt: Native Apps haben PWAs nicht verdrängt, und Apple unterstützt Web-Push auf dem iPhone erst seit 2023 für Webanwendungen, die zum Home-Bildschirm hinzugefügt wurden. Für interne Anwendungen, Außendienst-Tools und Angebote, bei denen sich eine App-Store-Veröffentlichung nicht lohnt, sind PWAs aber eine solide Wahl. Mehr dazu auf der Seite zu Progressive Web Apps.

Was das für Ihr nächstes Webprojekt bedeutet

Die Werkzeuge sind heute besser als je zuvor, die Zahl der Entscheidungen aber auch. Aus unserer Sicht zählen bei einem neuen Projekt vor allem diese Punkte:

1. Rendering zuerst klären. Statisch, serverseitig oder clientseitig – diese Entscheidung prägt alles Weitere und ist später teuer zu ändern.
2. So wenig JavaScript wie nötig. Überschätzt wird oft der Bedarf an Interaktivität. Jedes Kilobyte Skript kostet Ladezeit, besonders auf älteren Smartphones.
3. TypeScript von Anfang an. Der Mehraufwand ist gering, der Nutzen wächst mit jeder Änderung am Code.
4. Barrierefreiheit und Performance als Anforderungen formulieren, nicht als Aufgabe für die letzte Woche vor dem Livegang.
5. Verbreitete Technik vor neuer Technik. Ein Framework mit großer Community ist leichter zu pflegen und zu besetzen.

Unterschätzt wird schließlich, wie wichtig ein gemeinsames Verständnis im Team ist. Viele Probleme entstehen nicht durch falsche Technik, sondern weil Designer:innen, Entwickler:innen und Fachabteilung unterschiedliche Vorstellungen davon haben, was „fertig“ bedeutet.

Wer Frameworks auswählen, eine bestehende Anwendung modernisieren oder ein Team auf aktuelle Frontend-Technik schulen möchte, findet auf unserer Themenseite Web- und Frontend-Technologien Beratung und Seminare dazu.

Häufige Fragen zur modernen Webentwicklung

Womit sollten Einsteiger beginnen?

Mit HTML und CSS, danach mit JavaScript. Frameworks bauen auf diesen Grundlagen auf und lassen sich ohne sie kaum verstehen. TypeScript lohnt sich, sobald die ersten eigenen Projekte etwas größer werden.

Braucht jede Website ein JavaScript-Framework?

Nein. Eine Unternehmenswebsite oder ein Blog kommt oft mit einem statischen Generator oder einem CMS aus und braucht im Browser kaum Skripte. Frameworks spielen ihre Stärken bei Anwendungen mit viel Interaktion und Zustand aus, etwa Dashboards oder Konfiguratoren.

Welche Sprache eignet sich für das Backend?

Die, die zum Team und zur bestehenden IT passt. Java und C# sind in Unternehmen weit verbreitet, Python ist stark bei Datenverarbeitung und KI, Node.js erlaubt es, Frontend und Backend in derselben Sprache zu schreiben. Wichtiger als die Sprache sind saubere Schnittstellen und eine gute Testabdeckung.

Sind Progressive Web Apps noch aktuell?

Ja, aber als Werkzeug für bestimmte Fälle, nicht als Ersatz für alle nativen Apps. Wenn eine Anwendung auf vielen Geräten laufen soll, offline nutzbar sein muss und keine tiefen Gerätefunktionen braucht, ist eine PWA oft günstiger als zwei getrennte Apps für iOS und Android.