Aufbau robuster Frontends durch Progressive Enhancement

Wie man robuste Frontends baut: Progressive Enhancement

• Mit HTML beginnen

  • Staatliche Dienste sollten allein mit HTML funktionsfähig sein
  • Die HTML-Ebene ist fehlertolerant und kann daher auch in älteren Browsern funktionieren
  • Es sollten korrektes semantisches Markup und eine logisch aufgebaute Dokumentstruktur verwendet werden

• CSS verwenden

  • Mit CSS kann der Dienst gestaltet werden
  • Die CSS-Ebene ist fehlertolerant, da einzelne Deklarationen ignoriert werden können
  • Techniken wie „CSS-in-JS“ sollten vermieden werden

• JavaScript verwenden

  • JavaScript wird verwendet, um interaktive Elemente hinzuzufügen
  • Die JavaScript-Ebene ist nicht fehlertolerant und kann Fehler verursachen
  • Die Kompatibilität kann durch Feature Detection für Browser-APIs, das Einbinden von Polyfills, Transpilierung usw. verbessert werden
  • JavaScript sollte HTML und CSS ergänzen

• Alternativen zu JavaScript

  • Es sollten einfache Lösungen in Betracht gezogen werden, die Nutzeranforderungen auch ohne JavaScript erfüllen können
  • Alternativen sind etwa die Anzeige von Datentabellen, der Export von Daten oder das Vorab-Rendern von Diagrammen als Bilder

• Clientseitige JavaScript-Frameworks verwenden

  • Wenn es sich nicht um komplexe Benutzeroberflächen handelt, sollte der Einsatz von Frameworks vermieden werden
  • Beim Einsatz von Frameworks können Probleme wie eine größere Codebasis, Performance-Probleme und Abhängigkeiten von Drittanbieter-Code entstehen
  • Wenn Frameworks verwendet werden, sollte jede Benutzeroberfläche als separate Komponente entworfen werden

• Warum CSS oder JavaScript nicht geladen oder ausgeführt wird

  • Ursachen können Netzwerkfehler, Browser-Erweiterungen, Ausfälle bei Drittanbietern, fehlgeschlagene DNS-Lookups oder Bugs durch Browser-Updates sein
  • Manche Nutzer können Browser-Funktionen absichtlich deaktivieren

• Single-Page-Applications (SPA)

  • Dienste sollten nicht als Single-Page-Application aufgebaut werden
  • SPAs können die Barrierefreiheit beeinträchtigen und Probleme wie fehlerhafte Fokusbehandlung beim Seitenwechsel oder nicht funktionierende Zurück-/Vorwärts-Buttons verursachen

• Dienste testen

  • Komponenten, die stark von JavaScript oder JavaScript-Frameworks abhängen, sollten in verschiedenen Browsern und auf unterschiedlichen Geräten funktionieren
  • Es sollte auf Barrierefreiheit getestet werden

• Fallstudien und verwandte Leitfäden

  • Warum Progressive Enhancement verwendet wird
  • Design für unterschiedliche Geräte
  • Wie man Frontend-Performance testet
  • WCAG 2.2 verstehen

Zusammenfassung von GN⁺

• Progressive Enhancement ist eine Methode, Websites in der Reihenfolge HTML, CSS und JavaScript aufzubauen
• Diese Methode erhöht die Fehlertoleranz des Dienstes und sorgt dafür, dass er in unterschiedlichen Browsern und auf verschiedenen Geräten funktioniert
• JavaScript sollte eine ergänzende Rolle spielen, und alternative Lösungen sollten berücksichtigt werden
• Single-Page-Applications sollten wegen Problemen mit der Barrierefreiheit vermieden werden
• Tests des Dienstes sollten die Barrierefreiheit in unterschiedlichen Umgebungen sicherstellen

[GN⁺]

Hacker-News-Kommentare

• Beim Einsatz eines JavaScript-Frameworks sollte man nachweisen können, welchen Nutzen es den Nutzern bringt

  • Wenn eine App auch offline wie eine Desktop-Anwendung funktionieren kann, ist es sinnvoll, sie als Single-Page-Application (SPA) zu bauen
  • Beispiele sind Photopea, Google Docs/Sheets, tldraw usw.
  • Wenn eine App eine Internetverbindung benötigt und aus mehreren Seiten besteht, ist es besser, die Navigation vom Browser handhaben zu lassen

• Genannte Nachteile von SPAs

  • Nutzer von Hilfstechnologien bemerken beim Seitenwechsel die Kontextänderung nicht
  • Der Fokus wird beim Seitenwechsel nicht korrekt behandelt
  • Die Zurück- und Vorwärts-Schaltflächen des Browsers können nicht genutzt werden
  • Wenn die Netzwerkverbindung abbricht, ist keine Wiederherstellung nach einem Fehler möglich
  • Diese Probleme lassen sich jedoch auch bei SPAs lösen

• Es wäre schön, wenn das gesamte Internet diesem Rat folgen würde

• Einfache Lösungen sollten priorisiert werden

• Ich frage mich, warum Linux nicht auf der Liste steht

• Viele Menschen scheinen diesen Ansatz zu mögen

  • Ich frage mich, warum der allgemeine Trend darin besteht, unnötig JavaScript und Frameworks wie React zu verwenden

• Man verwendet HTML und bereits vom Server geholte Daten und verarbeitet auf dem Client das, was auf dem Client erledigt werden kann

  • Es werden nur minimales CSS und Vanilla JS verwendet
  • Für Kollegen mag das altmodisch wirken, aber man verpasst nichts

• Viele SPAs sind problematisch, aber nicht alle SPAs sind problematisch

  • Beispiele wie VitePress und SolidJS zeigen, dass es gut funktionieren kann
  • Es gibt kaum Menschen, die kein JS verwenden
  • Auch auf leistungsschwachen Geräten gibt es keine Probleme bei der Verarbeitung von JS
  • Barrierefreiheitsprobleme hängen nicht damit zusammen, ob man eine SPA verwendet
  • Svelte hat sogar eingebaute Warnfunktionen für Barrierefreiheit

• Server-Side Rendering ist ebenfalls nicht automatisch gut

  • Beim Einsatz von clientseitigen JavaScript-Frameworks ist Vorsicht geboten
  • Die Codebasis wird größer, und weil mehr auf der Client-Seite verarbeitet werden muss, können Performance-Probleme entstehen
  • Man wird von Third-Party-Code abhängig, was die Wartung erschweren kann
  • Beim Einsatz eines JavaScript-Frameworks sollte man nachweisen können, welchen Nutzen es den Nutzern bringt
  • Man sollte die negativen Auswirkungen kennen und abmildern können
  • Ein Framework sollte nur dort eingesetzt werden, wo es sich nicht allein mit HTML und CSS umsetzen lässt
  • Jeder Teil der Benutzeroberfläche sollte als separate Komponente entworfen werden
  • Auch wenn JavaScript nicht geladen wird, sollte der Rest der Seite weiterhin normal geladen werden