// stack · frontend
Das Frontend ist die Schicht, die dein Besucher wirklich sieht und bedient. siteway baut sie aus den drei nativen Web-Technologien: sauberem HTML5, CSS mit Tailwind und Vanilla JavaScript — gebaut direkt auf der Browser-Plattform. Das Ergebnis ist schneller, wartbarer und hält über Jahre.
// definition
drei schichten · native plattform
Frontend mit Web-Standards heißt: Die sichtbare Seite entsteht aus den drei nativen Web-Technologien — semantisches HTML5, CSS mit Tailwind als Utility-Schicht und Vanilla JavaScript — die der Browser direkt versteht. Er rendert damit das, was er von Haus aus am besten kann. JavaScript kommt nur dort dazu, wo es echte Interaktion braucht.
Das ist keine Nostalgie, sondern eine Architektur-Entscheidung. Die Browser-Plattform ist erwachsen geworden: ES-Module, fetch, Web Components, das <dialog>-Element und View Transitions decken heute nativ ab, wofür früher eine zusätzliche Bibliothek nötig schien. Wir nutzen diese Plattform direkt — jede Zeile, die ankommt, gehört zur Seite selbst.
// praxis
von unten nach oben · in schichten
Frontend-Technik wird meist als Grundsatzfrage diskutiert. Für uns ist sie eine Methode: Wir bauen jede Seite von der belastbarsten Schicht aus nach Progressive Enhancement — von unten nach oben, Schicht für Schicht.
Zuerst steht das HTML: semantisch, vollständig, mit allen Inhalten. Diese Seite funktioniert schon, bevor eine einzige Zeile CSS oder JavaScript geladen ist. Darauf legen wir das CSS — Tailwind als Utility-Schicht, die nur beim Build läuft und eine schlanke Datei mit exakt den genutzten Klassen erzeugt. Zuletzt kommt JavaScript: gezielt, gekapselt, nur dort, wo echte Interaktion es rechtfertigt.
Interaktion liefern wir als eigenständige Module, die nur auf der Seite laden, wo sie gebraucht werden — die Command-Palette hier oben ist so ein Modul, ein Konfigurator oder eine Karte ein anderes. Kein globales Bundle, das jede Seite mitschleppt. Fällt ein Skript aus, bleibt die Seite bedienbar. Das ist der Unterschied zwischen „braucht JavaScript“ und „nutzt JavaScript“.
// p-01methode
HTML zuerst, CSS darüber, JavaScript zuletzt. Jede Schicht setzt auf der darunter auf. Schlechtes Netz, alter Browser, blockiertes Skript — der Kern der Seite bleibt lesbar und bedienbar.
prinzip: html › css › js
// p-02markup
Die richtigen Elemente für die richtige Bedeutung: nav, main, article, dialog. Das ist die Grundlage für Barrierefreiheit, saubere strukturierte Daten und Seiten, die Suchmaschinen und KI-Systeme verstehen.
basis: landmarks + a11y
// p-03styling
Tailwind ist ein CSS-Utility-Framework, kein JS-Framework. Es läuft beim Build und erzeugt reines CSS — nur die tatsächlich genutzten Klassen. Im Browser läuft keine Tailwind-Laufzeit. Design-Tokens halten alles konsistent.
output: reines css, purged
// p-04interaktion
Interaktion als gekapselte ES-Module, geladen nur wo nötig: Command-Palette, Filter, Karten, Konfiguratoren. Native APIs statt Framework — fetch, querySelector, Web Components. Kein globales Bundle auf jeder Seite.
laden: pro seite, defer
// p-05tempo
Framework-Seiten hydrieren nach dem Laden das HTML noch einmal, um es interaktiv zu machen — das kostet JavaScript und verzögert die erste Reaktion. Diesen Schritt gibt es bei uns nicht. Das HTML ist ab der ersten Sekunde bedienbar.
effekt: schnelles inp/lcp
// p-06wartung
Keine Runtime-Abhängigkeit heißt: kein erzwungenes Update auf die nächste Major-Version, kein Ökosystem-Bruch. Was heute läuft, läuft in fünf Jahren noch. Web-Standards altern langsam — das ist ein Vorteil, kein Kompromiss.
basis: web-standards
// beleg
lighthouse · mobil
„Schnell“ ist leicht behauptet. Unsere eigene Startseite zeigt, was der Ansatz kann: 100 / 100 / 100 / 100 in Google PageSpeed Insights — mobil, in allen vier Lighthouse-Kategorien. Ausgeliefert wird genau das, was die Seite braucht — und nichts, was erst noch aufgebaut werden muss.
Wie weit man ein Frontend treiben kann, ist eine Frage der Disziplin, nicht der Werkzeuge — mehr dazu unter Performance. Dieselbe Bauweise zahlt direkt auf Barrierefreiheit ein: semantisches HTML, das ohne JavaScript funktioniert, ist von Grund auf bedienbar.
Quelle: Google PageSpeed Insights, Startseite siteway, mobiler Test. Werte schwanken je nach Messung — der Ansatz macht 100 erreichbar.
// faq
Frontend mit Web-Standards heißt: Die sichtbare Seite entsteht aus den drei nativen Web-Technologien — semantisches HTML5, CSS mit Tailwind als Utility-Schicht und Vanilla JavaScript — die der Browser direkt versteht. Er rendert damit das, was er von Haus aus am besten kann. JavaScript kommt nur dort dazu, wo es echte Interaktion braucht. siteway baut so seit 2006.
Weil die Browser-Plattform heute alles mitbringt, was eine klassische Unternehmens-Website, ein Blog oder ein Portal braucht. Ein Framework bringt zusätzlich ein Runtime-Bundle mit, das geladen, geparst und ausgeführt werden muss, plus Hydration, bevor die Seite reagiert — diesen Weg sparen wir uns. Direkt auf Web-Standards gebaut ist die Seite schneller, wartbarer und über Jahre stabil, unabhängig davon, welche Major-Version ein Ökosystem als Nächstes bringt.
Progressive Enhancement baut eine Seite in Schichten: zuerst funktionierendes HTML mit allen Inhalten, dann CSS für die Gestaltung, dann JavaScript für zusätzliche Interaktion. Jede Schicht setzt auf der darunter auf, ersetzt sie aber nicht. Fällt JavaScript aus — schlechtes Netz, alter Browser, blockiertes Skript — bleibt die Seite lesbar und bedienbar. siteway baut jede Seite nach diesem Prinzip.
Tailwind ist ein CSS-Utility-Framework, kein JavaScript-Framework — der Unterschied ist entscheidend. Tailwind läuft nur beim Build und erzeugt reines CSS; im Browser läuft keine Tailwind-Laufzeit, kein JavaScript, keine Hydration. Der Nutzer bekommt eine schlanke CSS-Datei, die nur die tatsächlich genutzten Klassen enthält. Es beschleunigt die Entwicklung, ohne die ausgelieferte Seite zu belasten.
Hydration ist der Schritt, in dem ein Framework wie React nach dem Laden das fertige HTML im Browser noch einmal durchgeht, um es „interaktiv zu machen“. Das kostet JavaScript, Rechenzeit und verzögert den Moment, ab dem die Seite auf Klicks reagiert. Da siteway direkt auf Web-Standards baut, gibt es diesen Schritt nicht: Das HTML ist von der ersten Sekunde an bedienbar, Interaktion kommt gezielt per Vanilla JavaScript dazu.
So interaktiv wie nötig. Moderne Browser-APIs — fetch, querySelector, Web Components, das <dialog>-Element, View Transitions — decken fast alles ab, wofür früher ein Framework nötig schien. siteway baut Interaktion als gekapselte JavaScript-Module, die nur auf der Seite laden, wo sie gebraucht werden: Command-Palette, Filter, Karten, Konfiguratoren. Aufwendige Anwendungen mit viel Client-Logik lösen wir gezielt — dann aber bewusst und begründet, nicht als Standard für jede Textseite.
Ja, mehr denn je. Die Sprache und die Browser-Plattform haben aufgeholt: ES-Module, async/await, Template-Literals, native Web Components und breit unterstützte APIs machen Framework-Schichten für viele Aufgaben überflüssig. Vanilla JavaScript heißt heute: mit den Werkzeugen arbeiten, die der Browser selbst mitbringt — schlanker, schneller und unabhängig vom Release-Zyklus eines Frameworks. Genau deshalb setzt siteway darauf.
// zusammenhang
leistung & stack
// css · im detail
Utility-First im Detail: wie wir Design-Tokens und Tailwind verheiraten und warum das Bundle klein bleibt.
weiterlesen →
// leistung · buchbar
Diese Seite erklärt die Technik — hier buchst du die Umsetzung: dein Design als sauberes, schnelles Frontend gebaut.
zur leistung →
// stack · tempo
Warum ein schlankes Frontend schnell ist — Core Web Vitals, LCP, INP und wie wir die 100 in PSI erreichen.
weiterlesen →
// stack · a11y
Semantisches HTML, das ohne JavaScript funktioniert, ist von Grund auf bedienbar — nach WCAG 2.2 und BFSG.
weiterlesen →
// Ein Frontend, das hält und schnell ist?
Projekt anfragen