Macht euch die Plattform zu eigen

Was also ist die eine Sache, die Menschen tun können, um ihre Website besser zu machen? Um das zu beantworten, machen wir einen Schritt zurück in der Zeit ...

Das Jahr ist 1998, und das Web nimmt Fahrt auf. Mit dem Versuch, einen Überblick über die Architektur des WWW zu geben, veröffentlicht Tim Berners-Lee – ja, *der* Tim Berners-Lee – eine Arbeit namens „Web Architecture from 50,000 feet“. Der Bericht behandelt viele Dinge: Inhaltsaushandlung, das semantische Web, HTML, CSS und coole URIs (die sich nicht ändern), unter anderem.

In dem Artikel nennt Berners-Lee auch einige Designprinzipien sehr früh. Eines dieser Prinzipien ist die „Rule of Least Power“.

Die Rule of Least Power lautet wie folgt:

Bei der Gestaltung von Computersystemen steht man oft vor der Wahl, eine mehr oder weniger mächtige Sprache für die Veröffentlichung von Informationen, die Beschreibung von Einschränkungen oder die Lösung eines Problems zu verwenden. […] Die „Rule of Least Power“ legt nahe, die am wenigsten mächtige Sprache zu wählen, die für einen bestimmten Zweck geeignet ist.

Wir haben drei Hauptsprachen auf dem Web für das Frontend zur Verfügung

Die Rule of Least Power legt nahe, zu versuchen, so viel wie möglich mit HTML zu erledigen, bevor man auf CSS zurückgreift. Wenn CSS nicht mehr ausreicht, greife zu JavaScript – aber nur, wenn du es wirklich tun musst.

Wie Derek Featherstone schön formulierte

Im Web-Frontend-Stack – HTML, CSS, JS und ARIA – wenn du ein Problem mit einer einfacheren Lösung weiter unten im Stack lösen kannst, solltest du das tun. Es ist weniger anfällig, narrensicherer und funktioniert einfach.

💡 Halt: Das bedeutet nicht, dass du Schriftgrößen und Farben über Markup festlegen solltest – etwas, das wir früher in den „guten alten Zeiten“ des Webs getan haben. Ein Beispiel: Eine der Regeln in Berners-Lee's Arbeit ist die Trennung von Form und Inhalt.

Das kaputte Web

Es ist fast 25 Jahre her, seit Berners-Lee diesen Artikel veröffentlicht hat. Doch irgendwie ist die Botschaft, die er sendete, nicht angekommen, und viele Entwickler – aber nicht alle – sind sich dessen nicht bewusst. Nehmen wir diese Situation, die Drew Devault vor nicht allzu langer Zeit angetroffen hat.

Mein Browser ist seit 28 Jahren perfekt in der Lage, HTML-Formulare zu übermitteln, aber aus irgendeinem dummen Grund hat ein Entwickler beschlossen, das Formular in JavaScript neu zu implementieren, und jetzt kann ich meine Stromrechnung nicht bezahlen, ohne die Entwicklertools zu öffnen.

Leider ist dies kein Einzelfall, sondern ein bekanntes Phänomen. Allzu oft sehe ich Websites und Bibliotheken, die versuchen, schlau zu sein oder das Rad neu zu erfinden – hauptsächlich, indem sie eine Menge JavaScript darauf werfen. Dabei erreichen sie das genaue Gegenteil dessen, was sie anstrebten: Diese Websites werden weniger funktional, weniger zugänglich oder – noch schlimmer – funktionieren unter bestimmten Bedingungen gar nicht mehr.

Während ein Formular ein bekanntes Beispiel sein mag, gibt es weitere Situationen, in denen die Anwendung der Rule of Least Power bessere Ergebnisse liefert.

• Sanftes Scrollen?
  👉 Kein JavaScript nötig, denn CSS kann das.
• Müssen Sie Fehler von Ihrer JSON-basierten API übermitteln?
  👉 Verwenden Sie keinen HTTP 200 mit {error: true} im Antwortkörper, sondern einen HTTP-Statuscode, um den Fehler stattdessen zu kommunizieren.
• Ein <dialog> per JavaScript schließen?
  👉 Ein <form>-Element mit [method="dialog"] reicht vollkommen aus.
• Bilder mit Lazy Loading laden?
  👉 Das wird bald von allen modernen Browsern direkt in HTML-Markup mit einem Attribut unterstützt.
• Ein anpassbares <select>?
  👉 Das ist in Entwicklung, während wir hier sprechen.
• Animationen an einen Scroll-Offset koppeln?
  👉 Kein Bedarf an einer externen JavaScript-Bibliothek, da das jetzt eine native Browser-API ist und bald auch etwas, das nur mit CSS gemacht werden kann.
• Bestimmte Zeichen in Formulareingaben verhindern?
  👉 Deaktivieren Sie nicht das Einfügen, sondern wählen Sie stattdessen einen geeigneten Eingabetyp und/oder verwenden Sie das pattern-Attribut.
• Kollabierbare Abschnitte?
  👉 <details> und <summary> sind Ihre Freunde.
• und so weiter…

In all diesen Beispielen können wir einige Funktionalitäten von einer oberen in eine niedrigere Schicht verschieben. Berners-Lee wäre stolz auf uns.

Resilienz

Durch die Wahl einer Technologie weiter unten im Webstack, näher am Kern der Webplattform, gewinnen wir auch den Vorteil der integrierten Resilienz gegen Ausfälle.

JavaScript ist schlecht im Scheitern. Ein Skript, das nicht geladen werden kann oder dabei beschädigt wird, oder ein falsches Argument für eine Funktion, und Ihre gesamte App funktioniert möglicherweise nicht mehr. Wenn eine Fehlermeldung wie „Cannot read property x of undefined“ Ihnen bekannt vorkommt, wissen Sie, wovon ich spreche.

CSS hingegen ist sehr gut im Scheitern. Selbst wenn Sie einen Syntaxfehler in einem Ihrer Style-Sheets haben, funktioniert der Rest Ihres CSS trotzdem. Dasselbe gilt für HTML. Das sind fehlerverzeihende Sprachen.

Wenn Sie Zweifel haben, warum Sie die Rule of Least Power verwenden sollten, bringt uns Jeremy Keith die Antwort in seinem Artikel „Evaluating Technology“.

Wir neigen dazu zu fragen: „Wie gut funktioniert es?“, aber was Sie wirklich fragen sollten, ist: „Wie gut scheitert es?“

Jeremy Keith

Wir können es besser machen

Eine hochkarätige Website, die von der Rule of Least Power profitieren könnte, ist die Nike-Website. Wenn Sie ihre Seite mit deaktiviertem JavaScript besuchen, sehen Sie keine Bilder und können auch keine Schuhe bestellen.

Diese übermäßige Abhängigkeit von JavaScript ist nicht notwendig, da all diese kaputten Funktionen mit Technologien erstellt werden können, die weiter unten im Frontend-Stack angesiedelt sind.

• Warum nicht sofort <img>-Elemente einfügen, um die Schuhfotos anzuzeigen, anstatt sie dynamisch per JavaScript einzufügen?
• Warum nicht ein <form> mit einem <select> (zur Größenauswahl) und einem Submit-<button> verwenden, um die Schuhe zu bestellen, anstatt den gesamten Zustand und die Übermittlung über JavaScript zu verwalten?

☝️ Wenn Sie sich fragen, warum jemand das Web mit deaktiviertem JavaScript durchsuchen sollte: Oft ist es nicht seine Wahl, sondern ein externer Faktor, der stört. Sehen Sie „Everyone has JavaScript, right?“ für eine gute Erklärung des Themas.

Noch schlimmere Sünder in dieser Kategorie sind hochkarätige Seiten wie Instagram und Twitter. Ohne JavaScript funktionieren diese Websites überhaupt nicht. Sie geben Ihnen entweder eine Warnung oder bleiben einfach leer. Seit wann ist JavaScript erforderlich, um Text und Bilder im Web anzuzeigen?

Progressive Enhancement

Es muss nicht so schlimm sein wie dieses isolierte Nike-Beispiel. Manchmal sind es kleinere Komponenten, die sich weigern zu funktionieren, wenn JavaScript fehlschlägt. Nehmen wir zum Beispiel eine Tabbed-Oberfläche. Obwohl es vieleJavaScript-Bibliotheken gibt, die diese Funktionalität bieten, ist der Clou, dass Sie dafür kein JavaScript benötigen, da HTML, CSS und ARIA selbst schon sehr weit kommen können.

Sobald Sie diese Basisschichten eingerichtet haben, nutzen Sie JavaScript, um die Erfahrung weiter zu verbessern. Betrachten Sie JavaScript als eine Verbesserung statt als eine Anforderung.

Dasselbe gilt für bestimmte CSS-Funktionen, die möglicherweise verfügbar sind oder auch nicht. Bieten Sie grundlegendes Styling an, und wenn eine Funktion verfügbar ist – erkennbar mit @supports –, verbessern Sie das Ergebnis, das Sie bereits hatten.

Dieser Ansatz ist bekannt als progressive enhancement: Sie fügen Funktionalität hinzu, wenn mehr Funktionen verfügbar werden, wodurch das Ergebnis im Hinblick auf die Erfahrung besser wird, aber nicht so sehr, dass die Funktion ohne diese zusätzlichen Verzierungen nicht funktionieren kann.

Und für Browser, die eine bestimmte neue Funktion noch nicht unterstützen, können Sie versuchen, ein Polyfill zu finden, das diese Funktionalität für die Browser bereitstellt.

Das Web holt auf

Seit den Anfängen des Webs hat die Webplattform im Laufe der Zeit viele neue Funktionen erhalten. Neue HTML-Elemente wurden definiert, JavaScript (die Sprache) hat sich weiterentwickelt und CSS hat viele leistungsstarke neue Funktionen zum Erstellen von Layouts, Animieren von Elementen usw. erhalten.

Dinge, die vor Jahren unmöglich waren und nur durch den Rückgriff auf externe Technologien wie Flash möglich waren, sind jetzt im Browser selbst integriert.

Ein klassisches Beispiel sind die Funktionen, die jQuery eingeführt hat. Vor über zehn Jahren war jQuery das Erste, was in ein Projekt eingefügt wurde. Heute ist das nicht mehr der Fall, da die Webplattform aufgeholt hat und nun document.querySelectorAll(), Element.classList usw. integriert hat – alles Funktionen, die von den Funktionen von jQuery inspiriert sind. Man könnte sagen, jQuery war ein Polyfill, bevor Polyfills überhaupt Polyfills genannt wurden.

Während jQuery ein bekanntes Beispiel sein mag, gibt es viele andere Situationen, in denen das Web aufgeholt hat.

• Probleme mit der sehr schlechten Date() API in JavaScript?
  👉 Die Temporal API ist angenehmer zu verwenden.
• Verwenden Sie eine JavaScript-Bibliothek von Drittanbietern, um Elemente auf dem Bildschirm zu animieren?
  👉 Warum probieren Sie nicht die integrierte Web Animations API aus? Sie ist sehr leistungsfähig.
• Farbige Radiobuttons und Checkboxen?
  👉 Die neue CSS-Eigenschaft accent-color erledigt das für Sie.
• Verlassen Sie sich auf einen Präprozessor, um CSS-Variablen verwenden zu können?
  👉 CSS Custom Properties sind die größte einzelne Ergänzung zu CSS in den letzten 20 Jahren.
• und so weiter…

Das zentrale Thema hier ist, dass diese Funktionen nicht mehr auf ein Polyfill oder eine externe Bibliothek angewiesen sind, sondern näher an den Kern des Web-Stacks verschoben wurden. Das Web holt auf.

Während einige dieser neuen APIs ziemlich abstrakt sein können, gibt es Bibliotheken, die Sie in Ihren Code einbinden können. Ein Beispiel ist Redaxios, das fetch im Hintergrund verwendet und gleichzeitig eine entwicklerfreundliche, Axios-kompatible API anbietet. Es würde mich nicht überraschen, wenn diese Komfortfunktionen schließlich auch in die Webplattform Einzug halten.

Zum Schluss

Was Berners-Lee vor fast 25 Jahren schrieb, hat die Zeit überdauert. Es liegt an uns, den Entwicklern, diese Botschaft zu ehren. Indem wir annehmen, was die Webplattform uns bietet – anstatt dagegen anzukämpfen –, können wir bessere Websites erstellen.

Halten Sie es einfach. Wenden Sie die Rule of Least Power an. Bauen Sie mit progressive enhancement im Hinterkopf.

HTML, CSS und JavaScript – in dieser Reihenfolge.