Wofür wir JavaScript einsetzen
Den größten Teil unserer JavaScript-Arbeit machen Shop-Frontends aus. Filter und Facetten, die den Katalog eingrenzen, ohne dass die Seite bei jedem Klick neu lädt. Warenkorb und Varianten, die sofort reagieren. Staffelpreise, Mindestmengen und Bestellvorlagen im B2B-Kontext. Dazu kommen Formulare, die mehr können als abschicken: Abhängigkeiten zwischen Feldern, Prüfungen vor dem Absenden, Uploads mit Rückmeldung. In TYPO3- und WordPress-Projekten ist der Umfang kleiner, die Anforderungen sind dieselben.
Der zweite Bereich ist die Redaktionsseite. Editoren, Vorschauen, Sortierungen per Drag-and-drop, kleine Werkzeuge, die Redakteuren Arbeit abnehmen. Hier gelten andere Regeln als im öffentlichen Frontend: Ein Backend-Werkzeug darf JavaScript voraussetzen, weil es niemand ohne Anmeldung sieht und keine Suchmaschine es lesen muss. Diese Unterscheidung treffen wir bewusst — sie entscheidet darüber, wie viel Aufwand in Fallback-Verhalten und Tastaturbedienung fließt.
Wie wir damit arbeiten
Wir bauen von unten nach oben. Erst steht das Markup, das ohne JavaScript vollständig funktioniert — Links sind Links, Formulare senden ab, Inhalte stehen im HTML. Danach kommt die Verbesserung: Ereignisse abfangen, Teile der Seite nachladen, Zustände sichtbar machen. Das ist kein nostalgisches Prinzip, sondern die einzige Bauweise, bei der eine schlechte Verbindung, ein blockiertes Skript oder ein Screenreader nicht zum Totalausfall führen.
Technisch bleiben wir nah am Standard. Moderne Browser-APIs statt Bibliotheken für Dinge, die der Browser kann. Bundling über Vite, in Shopware über dessen eigenen Build. Bei größerem Code wechseln wir auf TypeScript. Barrierefreiheit wird mitgebaut, nicht nachgerüstet: Fokusführung, ARIA nur wo nötig, Bedienbarkeit ohne Maus. Das BFSG macht daraus seit Juni 2025 für viele Shops eine Pflicht — technisch war es vorher schon richtig.
Grenzen: wann wir von JavaScript abraten
Wir sind kein JavaScript-Frontend-Haus, und das ist eine Entscheidung. Für Inhaltsseiten, Shops und Portale bauen wir serverseitig gerendertes HTML mit PHP 8, Symfony, Shopware 6 oder TYPO3. Wer eine Produktseite als Single-Page-Anwendung baut, räumt danach Suchmaschinen, Screenreadern und dem eigenen Ladeverhalten hinterher — und bezahlt für Server-Side-Rendering, Hydration und Routing genau das, was er vorher geschenkt bekommen hätte. Eine Produktseite braucht kein Framework, um eine Produktseite zu sein.
Es gibt Fälle, in denen eine echte Anwendung im Browser richtig ist: Konfiguratoren mit vielen Abhängigkeiten, Planungswerkzeuge, Oberflächen hinter dem Login, die ohne Seitenwechsel arbeiten müssen. Dann bauen wir das auch — als abgegrenzten Bereich, nicht als Umbau der ganzen Website. Für große React- oder Vue-Anwendungen als Hauptprodukt sind wir nicht die richtige Adresse. Wir sagen das lieber vorher als in der dritten Projektwoche.