- GOV.UK-Dienste sollten HTML-first funktionieren, damit Nutzer ihre zentralen Aufgaben unabhängig von Browser, Gerät oder Verbindungsstatus abschließen können; für alle staatlichen Dienste ist Progressive Enhancement erforderlich
- HTML ist durch seine Fehlertoleranz robust: Unbekanntes Markup wird ignoriert und weiter geparst, sodass grundlegende Navigation und Funktionen selbst in älteren Browsern oder auf teilweise fehlerhaften Seiten mit hoher Wahrscheinlichkeit erhalten bleiben
- CSS und JavaScript sind fragilere Schichten: Bei CSS kann ein gesamter Regelsatz ignoriert werden, wenn ein unbekannter Selektor vorkommt, und bei JavaScript kann die Ausführung des restlichen Codes durch nicht unterstützte Syntax oder API-Fehler stoppen
- JavaScript sollte nicht zentrale Funktionen ersetzen, sondern HTML und CSS erweitern; auch Autovervollständigung sollte auf Basiselementen wie
<select>aufbauen, damit Nutzer bei einem Ausfall weiterarbeiten können - Client-seitige JavaScript-Frameworks und SPAs können Belastungen bei Performance, Barrierefreiheit und Wartbarkeit verursachen und sind für Dienste, die auf dem GOV.UK Design System basieren und keine komplexe UI haben, nicht nötig
Grundprinzipien von Progressive Enhancement
- Gute Dienste sollten robust gebaut sein, und Progressive Enhancement ist ein Ansatz, bei dem Websites und Anwendungen zunächst mit HTML funktionieren
- Erst nachdem das Grundverhalten mit HTML umgesetzt ist, werden zusätzliche Schichten wie CSS und JavaScript ergänzt
- Alle staatlichen Dienste sollten Progressive Enhancement befolgen; dieses Prinzip gilt auch dann, wenn Teile des Dienstes oder ein übergeordneter Dienst JavaScript benötigen
- Progressive Enhancement bringt unter anderem folgende Vorteile
- Der Dienst wird robuster und qualitativ hochwertiger
- Er funktioniert mit höherer Wahrscheinlichkeit unabhängig von Browser oder Gerät
- Die grundlegendsten Funktionen laufen und erfüllen die zentralen Bedürfnisse der Nutzer
- Best Practices wie semantisches Markup werden gefördert, was die Barrierefreiheit verbessert
- Auch Nutzer mit Geräte- oder Verbindungsbeschränkungen können den Dienst leichter verwenden
- Wenn COTS-Lösungen eingesetzt oder Dienste an externe Anbieter vergeben werden, sollte erwogen werden, Progressive Enhancement in die Anforderungen der Beschaffungsstrategie aufzunehmen
Mit HTML beginnen
- Staatliche Dienste sollten auch nur mit HTML funktionieren
- Beispiele für Dienste, die nur mit HTML funktionieren sollten
- Transaktionsdienste wie Formulare, mit denen Nutzer dem Staat Informationen bereitstellen
- Dienste im Stil von smart answers, zum Beispiel Registering a birth abroad
- Inhaltsbasierte Websites wie die foreign travel advice von GOV.UK
- Die HTML-Schicht ist von Natur aus fehlertolerant
- Browser ignorieren Markup, das sie nicht verstehen, und parsen nach Möglichkeit weiter
- Selbst wenn HTML Fehler enthält oder Funktionen nutzt, die nur in modernen Browsern vorhanden sind, ist es wahrscheinlich, dass ältere Browser den Dienst dennoch laden können
- Nutzer sollten den Dienst auch nur mit HTML navigieren können
- Es sollte korrektes semantisches Markup verwendet und Quellreihenfolge und Dokumentstruktur logisch aufgebaut werden
Wie CSS eingesetzt werden sollte
- CSS kann verwendet werden, um den Dienst im Stil von GOV.UK zu gestalten
- Die CSS-Schicht ist relativ fehlertolerant
- Browser ignorieren einzelne Deklarationen, die sie nicht verstehen
- Wenn Eigenschaften verwendet werden, die nur moderne Browser unterstützen, kann nur die jeweilige Deklaration ignoriert werden
- Trifft der Browser jedoch auf einen Selektor, den er nicht versteht, kann er den gesamten Regelsatz ignorieren
- CSS kann aus verschiedenen Gründen nicht geladen werden
- Um sicherzustellen, dass die Website auch dann korrekt aussieht, wenn JavaScript nicht geladen wird, sollten Techniken wie CSS-in-JS vermieden werden
Wie JavaScript eingesetzt werden sollte
- JavaScript kann verwendet werden, um dem Dienst interaktive Elemente hinzuzufügen
- Die JavaScript-Schicht ist nicht fehlertolerant
- Wenn Syntax verwendet oder eine API aufgerufen wird, die der Browser des Nutzers nicht unterstützt, tritt ein Fehler auf
- Tritt ein Fehler auf, wird das übrige JavaScript nicht mehr ausgeführt
- Wird ein Dienst ohne Berücksichtigung dieser Möglichkeit entworfen, können Nutzer ihn möglicherweise nicht verwenden
- Folgende Maßnahmen erhöhen die Wahrscheinlichkeit, dass JavaScript in verschiedenen Browsern korrekt funktioniert
- Feature Detection für Browser-APIs einsetzen
- Polyfills für moderne Browser-Funktionen einbinden
- JavaScript in eine gemeinsame Syntax transpilen, die die Zielbrowser verstehen
- Automatisierte Tests oder Linter verwenden
- Regelmäßig manuell testen, auch auf alten oder leistungsschwachen Geräten
- Transpiling und Polyfills können die Größe von JavaScript erheblich erhöhen
- Die damit verbundenen Abwägungen sollten berücksichtigt werden
- Da sich die Browsernutzung verändert, sollten Entscheidungen regelmäßig neu überprüft werden
- Wo immer möglich, sollte JavaScript HTML und CSS erweitern, die bereits dieselbe Kernfunktion bereitstellen
- Autovervollständigung kann so gebaut werden, dass sie ein
<select>-Element oder ein ähnliches Basiselement erweitert - Selbst wenn JavaScript ausfällt, können Nutzer die benötigte Aufgabe weiter ausführen
- Autovervollständigung kann so gebaut werden, dass sie ein
Alternativen zu JavaScript und ergänzende Kanäle
- Wenn ein Dienst anscheinend nur mit JavaScript gebaut werden kann, sollte zuerst geprüft werden, ob eine einfachere Lösung mit HTML und CSS die Bedürfnisse der Nutzer erfüllen kann
- Wenn interaktive Diagramme mit JavaScript bereitgestellt werden sollen, können folgende Alternativen in Betracht gezogen werden
- Daten in einer Tabelle anzeigen
- Den Export der Daten ermöglichen, damit sie in anderen Anwendungen analysiert werden können
- Diagramme vorab als Bild rendern
- Wenn die Kernfunktion eines Dienstes ohne JavaScript nicht angeboten werden kann, muss Nutzern ein anderer Zugangskanal bereitgestellt werden
- Telefon
- Besuch vor Ort
Client-seitige JavaScript-Frameworks
- Wenn ein Dienst überwiegend aus Komponenten des GOV.UK Design System besteht und keine komplexe UI hat, ist ein Client-seitiges JavaScript-Framework nicht erforderlich
- Komponenten des GOV.UK Design System enthalten auch eine Möglichkeit, JavaScript ohne Framework in den Dienst einzubinden
- Client-seitige JavaScript-Frameworks können beim Erstellen komplexer UIs hilfreich sein, bringen aber zugleich verschiedene Probleme mit sich
- Mögliche Probleme beim Einsatz von Frameworks
- Sie vergrößern den gesamten Codebestand und verlagern Verarbeitung auf den Client, was bei langsamen Netzwerken oder leistungsschwachen Geräten zu Performance-Problemen führen kann
- Sie schaffen Abhängigkeiten von Third-Party-Code, den Entwickler nicht kontrollieren, sodass bei Änderungen am Framework größere Anpassungen am Dienst nötig werden können
- Wenn ein Framework mit der Zeit an Popularität verliert, kann es schwieriger werden, Personen mit den nötigen Wartungskenntnissen zu finden
- Wenn ein JavaScript-Framework verwendet wird, sollten folgende Bedingungen erfüllt sein
- Der Nutzen von JavaScript für die Nutzer muss sich mit Nachweisen begründen lassen
- Die negativen Auswirkungen müssen bekannt sein und gemindert werden können
- Es sollte geprüft werden, ob die Vorteile die potenziellen Probleme überwiegen
- Das Framework sollte nur für UI-Teile eingesetzt werden, die sich nicht allein mit HTML und CSS umsetzen lassen
- Jeder Teil der UI sollte als eigene Komponente entworfen werden
- Werden Komponenten getrennt, führt ein Ausfall beim Laden von JavaScript nur dazu, dass diese einzelne Komponente ausfällt, während der Rest der Seite normal lädt
- JavaScript sollte nur zur Erweiterung von HTML und CSS verwendet werden, und Nutzer sollten den Dienst auch dann verwenden können, wenn es ausfällt
Gründe, warum CSS und JavaScript ausfallen können
- CSS und JavaScript können aus vielen Gründen nicht geladen oder ausgeführt werden
- Vorübergehende Netzwerkfehler
- Third-Party-Browser-Erweiterungen wie Werbeblocker
- Ausfälle bei Drittanbietern beim Einsatz eines Content Delivery Network
- Fehlgeschlagene DNS-Auflösung
- Fehler durch Browser-Updates
- Fehler in Third-Party-JavaScript, das absichtlich auf derselben Seite ausgeführt wird
- Unternehmens-Firewalls, wie sie in großen Organisationen etwa Banken oder Ministerien eingesetzt werden, die Inhalte blockieren, entfernen oder verändern
- Mobile Netzbetreiber, die Inhalte verändern, um Ladezeiten und Bandbreitennutzung zu reduzieren
- Persönliche Firewalls oder Antivirensoftware, die Inhalte verändern oder blockieren
- Internetanbieter, die bei unsicheren Verbindungen eigenen Code in Seiten einfügen, der mit dem Code des Dienstes kollidiert
- Manche Nutzer können Browser-Funktionen absichtlich deaktivieren
- Dienste sollten die Entscheidung der Nutzer respektieren und auch für diese Nutzer weiterhin verwendbar sein
Warum Single-Page-Applications (SPAs) vermieden werden sollten
- Dienste sollten nicht als Single-Page-Application (SPA) gebaut werden
- Bei SPAs werden Seitenwechsel innerhalb des Dienstes durch JavaScript statt durch den Browser verarbeitet
- SPAs bringen kaum Vorteile und können die Barrierefreiheit verschlechtern
- Nutzer von Hilfstechnologien bemerken beim Wechsel zu einer neuen Seite möglicherweise nicht denselben Kontextwechsel
- Fokusmanagement bei Seitenwechseln kann fehlschlagen
- Nutzer können unter Umständen nicht mit den Zurück- und Vorwärts-Buttons des Browsers navigieren
- Nutzer können sich von Fehlern wie einem Verbindungsabbruch möglicherweise nicht erholen
Testkriterien
- Wenn bestimmte Komponenten eines Dienstes stark von JavaScript oder JavaScript-Frameworks abhängen, sollte geprüft werden, dass sie
- in verschiedenen Browsern und auf verschiedenen Geräten funktionieren
- zusammen mit Hilfstechnologien funktionieren
- Tests zur Sicherstellung guter Performance durchlaufen
- Wenn möglich, sollte mit Barrierefreiheitstests überprüft werden, dass die jeweiligen Komponenten im Dienst korrekt funktionieren
1 Kommentare
Meinungen auf Hacker News
„Wenn man ein JavaScript-Framework verwendet, sollte man fundiert begründen können, welchen Nutzen JavaScript für die Nutzer hat“ – Leute, kommt mal runter
Ein guter Maßstab ist: Wenn eine App wie eine Desktop-App offline-first funktionieren kann, ist es in Ordnung, sie als Single-Page Application zu bauen
Beispiele sind Photopea, Google Docs/Sheets oder tldraw; in solchen Fällen kann das schneller und besser sein als eine Browser-App mit mehreren Seiten
Dadurch verschwinden die größten Nachteile: Navigation zwischen Seiten und die Notwendigkeit einer Internetverbindung
Wenn die App aber Internetverbindung und mehrere Seiten braucht, ist es besser, den Browser die Navigation auf ausfallsichere Weise erledigen zu lassen
Wenn man offline oder auf mehreren Betriebssystemen etwas Desktop-GUI-Ähnliches braucht, ist eine Single-Page Application im Vorteil; wenn man einfach eine Website bauen will, ist eine Single-Page Application möglicherweise nicht optimal
Eine Single-Page Application an sich und die Komplexität, die nötig ist, um sie zu bauen, sind zwei verschiedene Dinge
Ich habe in den 90ern als Kind mit dem Web angefangen. Ich wusste nicht einmal, was CSS oder JS ist, und kannte JS nur als magisches Skript, das man kopierte und einfügte, damit irgendetwas blinkt
Später baute ich dynamische Websites für lokale Unternehmen mit PHP und lernte dabei auch etwas JS und CSS
Dann hörte ich mit Webentwicklung auf, weil ich es leid war, so viel Zeit damit zu verbringen, Dinge in den schlimmsten Browsern wie IE6 zum Laufen zu bringen
Nach fast sechs Jahren Pause kam ich etwa 2015 zurück, weil mir klar wurde, dass ein Webserver für meine Arbeit nützlich wäre
Ich war schockiert zu sehen, dass die Welt vieles vergessen hatte, was sie früher über HTML und CSS wusste
Früher erstellte man mehrere Stylesheets für eine Website, brachte sie zuerst ohne JS zum Laufen und fügte JS dann als verbesserndes Element obendrauf hinzu; diese Vorgehensweise war in Vergessenheit geraten
Ich sah auch, dass Webentwickler Formularvalidierung komplett nur in JS machten und auf dem Server gar nichts – und erstaunlicherweise ist das bis heute üblich
Das verbreitete Muster, bei dem der Server validiert und JS das Ergebnis nur anzeigt, scheint kaum jemand zu kennen. Alle scheinen es doppelt zu implementieren oder ganz auf Servervalidierung zu verzichten
Nachdem ich das gesehen hatte, beeindruckte mich nicht mehr, was Leute im Web taten. Es war nicht das Web, das ich kannte, sondern nur eine mit JS gebaute „Anwendung“, und für Web-first zu argumentieren war ein Kampf auf verlorenem Posten
Ich habe als Kind mit HTML 3.2/XHTML und CSS angefangen, arbeitete ein paar Jahre später mit Django + jQuery und wurde dann von Infrastruktur angezogen
Vor etwa einem Jahr arbeitete ich mit einem Webentwicklungsteam zusammen und schaute mir an, was sie machten, aber ich verstand nichts mehr
Die Komplexität war überwältigend, und es sah so aus, als verbrächten sie den Großteil ihrer Zeit mit Komplexitätsmanagement: Build-Zeiten reduzieren, Abhängigkeitsprobleme lösen, seltsame TypeScript-Probleme behandeln, Fehlerhandling über mehrere Komponenten hinweg
In der Django+jQuery-Zeit lag der Fokus noch immer auf dem, was Nutzer sehen und verwenden konnten
Natürlich kann man dem Client niemals vertrauen, also muss später auch der Server erneut validieren
Serverlast zu reduzieren ist nützlich
Es ist zwar ein guter Rat, aber streng genommen stimmt es doch nicht, dass „Nutzer von assistiven Technologien beim Wechsel auf eine neue Seite denselben Kontextwechsel nicht mitbekommen“, „der Fokus bei Seitenwechseln nicht behandelt wird“, „man nicht mit den Zurück-/Vorwärts-Buttons des Browsers navigieren kann“ oder „man sich bei unterbrochener Netzwerkverbindung nicht von Fehlern erholen kann“
Viele, vielleicht die meisten Single-Page Applications kümmern sich nur nicht darum; aber auch in Single-Page Applications kann man diese Dinge implementieren
Sobald man in den Bereich der Single-Page Applications geht, erfindet man viele Räder neu, um wieder auf ein gleichwertiges Niveau zu kommen, oder ersetzt native Funktionen durch JS-Ersatzlösungen
Man denke an mehrseitige Formulare: Wie viele Single-Page Applications speichern alles nur im Speicher und senden am Ende eine einzige Anfrage?
Ohne JS hätte das Backend den Zustand jedes Schritts gespeichert, damit man später zum Formular zurückkehren oder neu laden kann, ohne etwas zu verlieren
Warum sollte man solchen Müll aufzwingen, wenn eine einfache HTML-Website schon mit den Defaults gut funktioniert?
Wenn Nutzer nicht erlauben, den Navigationsverlauf nachträglich zu verändern, bleibt nur eine Option
Den Browserverlauf zu dem Zeitpunkt korrekt anzulegen, an dem der Verlauf verwendet wird
Ich wünschte, das gesamte Internet würde diesen Rat befolgen
Altes wird wieder neu
Sollte man nicht der einfachstmöglichen Lösung den Vorrang vor dem heute Modischen geben?
Nur weil der Rest der Branche von JS berauscht war, heißt das nicht, dass es alle waren
Warum steht Linux nicht auf dieser Liste?
https://www.gov.uk/service-manual/technology/designing-for-d...
Die etwas ernsthaftere, aber im selben Sinne gemeinte Antwort: Es gibt Dutzende Distributionen, und wenn man die Mozilla-Forks darin mitzählt, kommt man auch auf ungefähr zehn Browser.
Man könnte zwar eine offiziell anerkannte Distribution bzw. einen Browser auswählen, aber die Nutzerbasis genau dieser Auswahl wäre verschwindend klein.
Selbst Ubuntu scheint nach Zahlen, die sich aus Nebenindikatoren ableiten lassen, nur auf etwa 1 % Desktop-OS-Marktanteil zu kommen.
Ernst gemeinte Frage: Den Kommentaren nach scheint dieser Ansatz vielen zu gefallen.
Warum geht der allgemeine Trend dann in Richtung Frameworks wie React und JavaScript, manchmal sogar dort, wo es gar nicht nötig ist?
Sie sind leichtgewichtig, haben ein sauberes Layout, sind gut zugänglich und funktionieren meist mit minimalem JavaScript oder sogar ganz ohne.
Die meisten Single-Page-Applications dagegen mag ich nicht. Sie machen viele erwartete Browserfunktionen kaputt, sind ohne JavaScript nutzlos und laden oft jede Menge schwergewichtige Abhängigkeiten von diversen Drittseiten.
Aber was Nutzer mögen und was Entwickler mögen und schnell bauen können, ist oft etwas völlig anderes.
Wenn etwas als Branchenstandard gilt, ist es eine sichere Entscheidung, dem Strom zu folgen.
Außerdem macht niemand Developer Relations für HTML/CSS/Vanilla JS.
Wenn man danach sucht, wie man etwas macht, findet man fast ausschließlich Inhalte zu Frameworks.
Wenn man ein Programm schreibt, das auf dem eigenen Rechner läuft, trägt man diese Kosten selbst und muss zumindest der Finanzabteilung erklären, warum die Cloud-Kosten um 5 % gestiegen sind.
Aber wenn man wie ein Frontend-Entwickler Software auf den Geräten anderer Leute laufen lässt, entstehen einem fast keine Kosten.
Negative Signale kommen nur über Wege wie Nutzerberichte, Support-Tickets oder vielleicht Twitter-Posts zurück, und in diesem Prozess steckt viel Selection Bias, sodass man wahrscheinlich kein vollständiges Bild bekommt.
Am Ende ist das alles eine Frage der Incentives.
Das Web ersetzt traditionelle Fat Clients, und auch solche Clients setzten ziemlich stabile Netzwerkverbindungen und bestimmte Plattformspezifikationen voraus.
Regierungssysteme müssen, auch wenn der Fall selten ist, auf dem kleinsten gemeinsamen Nenner funktionieren.
Ein Tech-Startup kann anfangs schon mit einem einzigen Kunden existieren und mit wachsender Größe glauben, dass die eigenen Anforderungen im Großen und Ganzen üblich werden.
Eigentlich denke ich, dass Frontend-Entwickler diesen Ansatz gerade deshalb nicht mögen: Sonst gäbe es kaum noch ein Frontend zu entwickeln.
Das ist auch die Richtung, der ich folgen möchte: HTML mit serverseitig vorab geladenen Daten ausliefern, Dinge, die der Client erledigen kann, auf dem Client erledigen, um Server-Roundtrips zu reduzieren, responsive Layouts mit minimalem CSS bauen und Vanilla JS verwenden.
Wenn nötig, kann man es in separate Webseiten aufteilen.
Aber für meine Kollegen scheint es irgendwie seltsam und altmodisch zu klingen, nur HTML, CSS und Vanilla JS zu verwenden.
Es fehlt dabei eigentlich nichts.
Auch der Artikel sagt, dass es kein gutes Software Engineering ist, blind nur auf die Serverseite zu setzen.
Man sollte beachten, dass dort „kann Probleme verursachen“ steht, nicht „verursacht Probleme“.
Clientseitige JavaScript-Frameworks können beim Bau von Services mit komplexen Benutzeroberflächen helfen, sie können aber auch die Gesamtgröße der Codebasis erhöhen, Verarbeitung auf den Client verlagern und dadurch Performance-Probleme für Nutzer mit langsamen Netzwerken oder leistungsschwachen Geräten verursachen.
Sie können dazu führen, dass man von Drittanbieter-Code abhängt, den Entwickler nicht kontrollieren, und dass große Änderungen am Service nötig werden, um mit Veränderungen am Framework Schritt zu halten.
Wenn die Popularität eines Frameworks nachlässt, kann es außerdem schwierig werden, Leute für die Wartung zu finden.
Wenn man ein JavaScript-Framework verwendet, sollte man begründet rechtfertigen, welchen Nutzen es für die Nutzer hat, die negativen Auswirkungen verstehen und abmildern und abwägen, ob der Nutzen größer ist als die möglichen Probleme.
Außerdem sollte man es nur für die Teile der Benutzeroberfläche einsetzen, die sich nicht allein mit HTML und CSS bauen lassen, und jeden Teil als separate Komponente entwerfen.
Wenn Komponenten getrennt sind, fällt bei einem fehlgeschlagenen JavaScript-Load nur diese eine Komponente aus, während der Rest der Seite wie gewohnt lädt.