Braucht man JavaScript für eine Website? Klarer Guide für Einsteiger

Die kurze Wahrheit zuerst: Du kannst heute sehr viel ohne JavaScript bauen - und manchmal solltest du das sogar. Aber wenn du Interaktionen brauchst, die über einfache Navigation, Formulare und Animationen hinausgehen, kommst du an JS meist nicht vorbei. Der Trick ist nicht „JS ja oder nein“, sondern: so wenig wie möglich, so viel wie nötig.

• TL;DR: Reine Inhalte, Landingpages, Blogs, Dokus und viele Formulare gehen mit HTML/CSS schnell und robust.
• JS wird nötig für Echtzeit-Updates, komplexe Zustände, Drag-and-drop, Rich-Editoren, Live-Suche, In‑Page‑Checkout und App-ähnliche Oberflächen.
• Baue erst ohne JS (Progressive Enhancement), miss dann Effekte (Performance, Zugänglichkeit), und ergänze gezielt kleine Skripte.
• Nutze Browser-Features: details/summary, form-Validation, :has(), CSS-Animationen, native Media-Controls, serverseitige Suche.
• Setze ein Budget: kleine Sites < 50-70 KB JS; prüfe Core Web Vitals; meide unnötige Third‑Party‑Skripte.

Was geht ohne JavaScript? (Und was nicht?)

HTML liefert Struktur und Inhalt, CSS das Layout und Interaktionen wie Hover, Fokus, Animationen und sogar einfache Zustandswechsel. Das reicht weiter, als viele denken. Wenn du gerade startest, ist das eine gute Nachricht: Du kannst schnell eine nutzbare, schnelle und barrierefreundliche Site bauen, ohne dich sofort mit Build-Tools, Bundlern und Frameworks zu beschäftigen.

Was geht ohne JS stabil und angenehm?

• Inhaltsseiten: Blog, Doku, Portfolio, Landingpage, einfache Firmenseite.
• Navigation: Header, Footer, Seitenleiste; mobile Menüs sind mit CSS-Checkbox-Trick oder :has() möglich.
• FAQ, Akkordeons, Tabs: details/summary liefert aufgeklappte Bereiche out of the box; Tabs gehen mit :target oder :has().
• Formulare: HTML5-Validierung (required, type, pattern), Input-Typen für E‑Mail, Datum, Zahl; Fehlermeldungen kommen vom Browser. W3C und MDN dokumentieren das sauber.
• Medien: Video/Audio mit nativen Controls, Bild-Galerien mit CSS-Grid und :target Lightbox.
• Animationen und Effekte: CSS-Transitions, Keyframes, Scroll-Snap; mit prefers-reduced-motion respektierst du Nutzerpräferenzen.
• Suche: klassisch serverseitig (Formular schickt Anfrage, Ergebnis als neue Seite).

Was wird ohne JS schwierig oder unpraktisch?

• Echtzeit- und Live-Funktionen: Live-Suche mit Sofortergebnissen, Chats, Börsenticker, kollaborative Bearbeitung, WebSocket-Streams.
• Komplexe Zustände: interaktive Dashboards, Kanban-Boards, umfangreiche Form-Wizards mit dynamischen Feldern und Abhängigkeiten.
• Drag-and-drop, Rich-Text-Editoren, Karten mit Pins und Clustering, komplexe Diagramme.
• Client-seitige Offline-Funktion (PWAs), Background Sync, feingranulare Caching-Strategien.
• In-Page-Checkout und moderne Zahlungs-SDKs: Viele Anbieter verlangen Client-JS zur Tokenisierung und 3‑D‑Secure-Flows.

Suchmaschinen und Zugänglichkeit? Reine HTML/CSS-Seiten sind hier naturgemäß stark. Google bewertet echte Inhalte und Ladezeit; Core Web Vitals messen das. CSR‑Single‑Page‑Apps ohne Server-Rendering können ranken, aber brauchen Extra-Arbeit (SSR/Prerendering/Hydration). Für Barrierefreiheit ist weniger Client‑Magie oft besser: Semantische HTML-Elemente bringen Rollen und Tastatur-Fokus gleich mit.

Kurzer Realitätscheck 2025: Browser haben stark nachgerüstet. Der :has()-Selektor ist breit unterstützt, HTML liefert viele fertige Bausteine (form-Validation, details/summary, dialog), und CSS kann komplexe Layouts. Heißt: Bau so viel wie möglich „nativ“, reduziere JS auf echte Mehrwerte.

Schritt-für-Schritt: Website ohne JS bauen - und smart erweitern

So gehst du vor, wenn du eine Site aufbauen willst, die ohne JS solide läuft und bei Bedarf sanft erweitert wird. Ich nutze das selbst seit Jahren - es spart Zeit, Nerven und Ladezeit.

1. Scope festlegen: Welche Aufgaben sollen Nutzer direkt am ersten Tag erledigen können? Schreib die wichtigsten 3 Aufgaben auf (z.B. Angebot lesen, Kontakt schicken, PDF laden). Alles andere ist Kür.

2. HTML-Grundgerüst: Nutze semantische Elemente (header, nav, main, section, article, aside, footer). Eine klare H1, danach H2/H3-Hierarchie. Forms mit label und passenden type-Attributen. Das hilft Screenreadern und SEO.

3. CSS-Layout: Flexbox und Grid für Struktur, clamp() für responsive Schriftgrößen, Container Queries für flexible Komponenten. Setze ein typografisches System (Basisgröße, Zeilenhöhe, Spaltenbreite), dann Farben und Abstände. Denk an prefers-color-scheme für Hell/Dunkel.

4. Interaktionen ohne JS: details/summary für FAQs, :target für Lightbox, :has() für einfache Toggles (z.B. Menü-Button schaltet Klasse am Container). Achte auf Tastaturbedienung: focus-visible für klare Fokus-Stile.

5. Formulare richtig nutzen: Required, pattern, minlength/maxlength, und passende Typen (email, url, number). Nutze serverseitige Validierung zusätzlich - Client-Checks sind nur Komfort. Erfolg/Fehler als eigene Seiten oder Anker mit Klartext-Meldungen.

6. Server macht den Job: Suche, Pagination, Sortierung, Kontaktversand - alles geht per Request/Response ohne JS. Eine einfache statische Site kann das über ein Headless‑CMS oder ein kleines Backend leisten.

7. Performance früh prüfen: Lighthouse/Pagespeed, Core Web Vitals (LCP, CLS, INP). Ziele: LCP < 2,5s, CLS nahe 0, gute INP-Werte. Tipps: fonts-display: swap, Bilder in modernen Formaten, lazy-loading für Images, nur benötigte CSS-Regeln, kritisches CSS inline.

8. Erst dann: punktuell JS ergänzen. Beispiele: Menü-Button soll den Fokus ins Panel setzen; Live-Suche ab 3 Zeichen; Formular speichert Entwurf im Local Storage; Modal mit dialog-Element steuern. Jedes Skript sollte klein, gekapselt und wieder entfernbar sein (funktioniert die Seite weiter, wenn es fehlt?).

9. Drittdienste streng prüfen: Analytics? Nutze serverseitige Logs oder ein leichtes Skript. A/B‑Tests, Chat-Widgets, Maps - nur wenn wirklich nötig. Jeder Fremdskript-Aufruf kostet Zeit, Daten und oft auch Privatsphäre.

10. Deployment & Monitoring: Komprimiere (Gzip/Brotli), aktiviere HTTP/2/3, setze Caching-Header. Miss echte Nutzer mit einem RUM‑Tool (Core Web Vitals Field‑Daten). Überwache, ob neue Skripte die Performance kippen.

Progressive Enhancement in der Praxis: Baue den Ablauf so, dass Server und HTML immer eine vollständige, bedienbare Erfahrung liefern. JS hängt sich nur optional dran. Beispiel Kontaktformular: Ohne JS schickt es die Nachricht, zeigt eine Danke‑Seite und gut. Mit JS kommt Inline‑Feedback, Auto‑Save, und vielleicht eine Live‑Überprüfung der E‑Mail‑Domain dazu. Fällt JS aus, bleibt der Kern funktionsfähig.

Kleine Helfer statt großer Frameworks: Für Mini‑Interaktionen genügen ein paar Zeilen Vanilla‑JS. Alternativ gibt es Micro‑Libraries oder HTML‑first‑Ansätze (htmx, Alpine‑ähnliche Muster). Diese Lösungen bringen Dynamik, ohne gleich ein komplettes SPA‑Framework zu laden. Sie nutzen das HTML als Wahrheit und tauschen nur Teil‑HTML mit dem Server - gut für Performance und Wartbarkeit.

Wann ein Framework Sinn macht: Wenn du komplexe Zustände, viele interaktive Komponenten und Client‑Routing hast (z.B. ein Dashboard), solltest du zu einem Framework mit Server‑Rendering und Code‑Splitting greifen. Wichtig ist, dass die erste Ansicht vom Server kommt (SSR/SSG), damit Nutzer und Crawler sofort Inhalt sehen.

Entscheidungshilfe: Brauche ich JS? Heuristiken, Muster und Beispiele

Hier ist eine schnelle Denkhilfe. Sie hat mir oft Stunden gespart.

• Kann der Server die Aufgabe zuverlässig erledigen? Wenn ja, probiere es ohne JS.
• Gibt es ein passendes HTML-Element oder eine CSS-Lösung? Dann nimm die - native Mittel sind meist schneller und zugänglicher.
• Ist das Feature auch ohne JS sinnvoll nutzbar? Wenn nein, plane eine robuste Fallback-Variante oder streiche es.
• Wie oft wird die Interaktion wirklich genutzt? Selten genutzte Features verdient man sich mit einer Extra‑Seite statt Inline‑JS.
• Wie hoch ist der Wert pro KB? Lade ich 150KB JS für ein winziges Komfort‑Feature? Meist nicht gerechtfertigt.

Checkliste „No‑JS zuerst“:

• Navigation ist per Tastatur bedienbar, Fokus sichtbar.
• Formulare senden auch ohne Client‑Skripte korrekt ab; Server prüft alle Felder.
• Alle Inhalte sind ohne Hover erreichbar (Touch!).
• Bilder haben richtige Größenangaben (keine Layout‑Sprünge), lazy-loading wo sinnvoll.
• Keine Blocker: Externe Skripte sind asynchron/defer oder gar nicht vorhanden.

Entscheidungstabelle - was braucht JS, was nicht?

Praktische Budgets und Regeln:

• Start klein: Wenn du JS brauchst, peile < 50-70KB minifiziert für eine Marketing‑Seite an; bei Apps streng Code‑Splitting und nur pro Route laden.
• Third‑Party mit Misstrauen: Jeder Pixel, jedes Widget bringt Netzwerk‑Kosten und oft Datenschutz‑Themen mit. Reduziere, hoste selbst, wenn möglich.
• Core Web Vitals im Blick: Server‑Rendern, kritisches CSS inline, Skripte defer, Bildgrößen fixieren, Fonts lokal.
• Wartbarkeit vor Zauberei: Je mehr „Magie“ im Client, desto teurer die Pflege. Nutze klare, dokumentierte Muster (MDN‑Beispiele, W3C‑Elemente).

Beispiele aus dem Alltag:

• Blog/Doku: Ohne JS, statisch generiert, mit Suchfeld serverseitig. Später: Mini‑Skript für „Copy Code“-Buttons.
• Portfolio: CSS‑Grid‑Galerie, :target‑Lightbox. Später: kleines JS für Tastaturnavigation in der Lightbox.
• Lokaler Shop: Katalog, Warenkorb serverseitig, Checkout per Weiterleitung zum Zahlungsanbieter. Später: Live‑Filter per JS, wenn es den Umsatz wirklich erhöht.
• Dashboard: Von Anfang an SSR und Framework mit Hydration, aber harte Regeln für Code‑Splitting und Performance‑Budgets.

FAQ, Fallen und nächste Schritte 2025

Häufige Fragen und meine kurzen, klare Antworten.

• Ist eine Site ohne JS „unmodern“? Nein. Moderne heißt: schnell, benutzbar, robust. Viele preisgekrönte Seiten setzen sehr wenig Client‑JS ein und sind top in Core Web Vitals.

• Wie viele Nutzer haben JS deaktiviert? Sehr wenige. Aber du solltest auch an kaputte Netzwerke, blockierende Firmen‑Firewalls oder geblockte Dritt‑Skripte denken. Robustheit zahlt sich immer aus.

• Wie sieht es mit SEO aus? Server‑gerenderte Inhalte sind für Crawler einfacher. CSR‑SPAs brauchen SSR/Prerendering, sonst leidet Indexierung und Time‑to‑Content. Google misst reale Nutzer-Signale (Core Web Vitals).

• Barrierefreiheit ohne JS? Mit sauberem HTML startest du stark: richtige Elemente, Labels, Fokus, Kontraste. JS kann A11y verbessern (z.B. Fokus-Fallen in Modals), aber auch kaputt machen. Teste mit Tastatur und Screenreader.

• Soll ich ein großes Framework nehmen? Nur, wenn die Komplexität es verlangt. Für Content‑Sites sind SSG/SSR‑Generatoren oder einfache Server‑Templates oft schneller und billiger.

• Was ist mit HTML‑first‑Ansätzen wie htmx? Gute Option, wenn du serverseitig rendern willst und nur kleine Inseln dynamisch brauchst. Es bleibt HTML‑zentriert, der Client lädt wenig Code.

• Gibt es Standards und Quellen? Ja: W3C (HTML/CSS‑Spezifikationen), MDN Web Docs (praktische Referenz), Google zu Core Web Vitals, HTTP Archive für Web‑Daten. Alle sind verlässlich und aktuell.

Fallen, die ich oft sehe:

• Interaktionen erfinden, die das Problem nicht lösen. Erst Nutzeraufgaben klären, dann Features bauen.
• Große UI‑Kits oder Frameworks laden „für alle Fälle“. Ergebnis: viel Code, wenig Nutzen.
• Formulare zu sehr auf Client‑Validation verlassen. Serverseitige Prüfung ist Pflicht.
• Nicht auf Tastatur testen. Ein Menü, das ohne Maus nicht geht, ist ein Bug.
• Unklare Verantwortlichkeiten: Server kann viel übernehmen, aber man stopft alles in den Client. Das rächt sich bei Performance und Wartung.

Nächste Schritte je nach Ziel:

• Bloggerin/Autor: Nutze einen statischen Site‑Generator (z.B. Hugo, Eleventy). Baue ohne JS; später kleine Komfort‑Skripte (Copy‑Button, Theme‑Toggle).

• Kleine Firma/Landingpage: Starte mit sauberem HTML/CSS, serverseitiges Formular, Analytics über Server‑Logs oder ein leichtes Tool. Kein Chat‑Widget, wenn es nicht direkt Umsatz bringt.

• Shop‑Betreiber: Katalog und Warenkorb serverseitig, Checkout beim Zahlungsanbieter. Ergänze Filter/Sortierung mit leichtem JS, wenn Nutzer es wirklich brauchen. Miss Conversion vor/nach dem Feature.

• Produktteam mit App‑UI: Wähle ein Framework mit SSR, setze harte Budgets, teile Code pro Route, messe INP im Feld. Komponenten‑Bibliothek nur, wenn sie tree‑shake‑bar und leicht ist.

Kurze Troubleshooting‑Hinweise:

• Menü springt beim Laden? Setze feste Höhen/Breiten, nutze CSS für initiale Zustände, lade Skripte mit defer.
• CLS‑Probleme? Bildgrößen angeben, Fonts lokal und mit Font‑Display, keine dynamischen Einbindungen oberhalb des Fold.
• Formvalidierung uneinheitlich? Setze klare pattern/required, gib serverseitig dieselben Fehlermeldungen aus.
• Langsame Seite trotz wenig JS? Prüfe Bilder (Format/Größe), Third‑Parties, Cache‑Header, Hosting‑Latenz.
• Interaktion ruckelt? Reduziere DOM‑Arbeit, nutze CSS‑Transitions statt JS‑Animationen, requestAnimationFrame für Updates.

Zum Schluss die Kernentscheidung: Starte mit HTML/CSS, liefere echten Inhalt, prüfe Performance und Zugänglichkeit. Ergänze JS dort, wo es Aufgaben schneller, sicherer oder deutlich angenehmer macht. So bekommst du stabile Seiten, zufriedene Nutzer - und weniger Technikschulden.