JavaScript? Gern, aber bitte in Maßen

JavaScript wird in einem einzelnen Thread ausgeführt. Nur I/O-Operationen werden asynchron außerhalb des Threads ausgeführt, aber eine CPU-Aufgabe blockiert den Thread. CPU-intensive Aufgaben sorgen folglich dafür, dass man nicht mehr mit der Seite interagieren kann. Führen wir also viel Geschäftslogik aus, blockieren wir den Thread und die Seite wirkt wie eingefroren. Heute können wir Code mit Hilfe von Web-Workers auf einem separaten Thread ausführen. Allerdings ist das gerade in älteren Browsern nicht möglich, was die Performance auf älteren, schwächeren Geräten weiter verschlechtert.

Zudem zieht die unkontrollierte Ausführungsumgebung ebenfalls Konsequenzen nach sich. Auf dem Server können wir uns die Version unserer Programmiersprache aussuchen (z. B. JDK 7). Webbrowser gibt es hingegen in unglaublich vielen verschiedenen Versionen. Selbst die neuesten Versionen aller Browser unterstützen nicht alle spezifizierten Features. Die Komplexität des Testens ist also immens höher.

Zusammengefasst bringt das Verschieben von Routing, Templates und Präsentationslogik weitere Verantwortlichkeit mit sich. Zusätzlich sind weitere Infrastruktur, Koordination, Duplikation und Indirektion erforderlich und wir transportieren dabei Code von einer kontrollierten Ausführungsumgebung in eine widrige Umgebung.

Ein alternativer Architekturansatz

Gehen wir einen Schritt zurück und vergleichen den oben beschriebenen Architekturansatz mit dem, den wir bei einer klassischen GUI-Anwendung hätten, die wir beispielsweise mit .NET, Swing oder Eclipse RCP entwickelt hätten. Wir stellen fest, dass die Unterschiede gar nicht besonders groß sind. Darin liegt für viele Teams die Attraktivität, gerade wenn bislang keine Webanwendungen entwickelt wurden. Eine bekannte 3-Schichten-Architektur wird auf das Web übertragen. Als Ablaufumgebung kommt nicht Windows, die CLR oder eine JVM zum Einsatz, sondern die JavaScript- Runtime des Browsers.

Leider ignoriert dieser Ansatz trotz seiner Popularität die eigentlichen Stärken des Webs, die vor allem von deklarativen Sprachen geprägt sind und damit zu einer außerordentlich fehlertoleranten Architektur führen. Ein Terminologiewechsel trägt dazu bei, diesen Punkt zu illustrieren: Der Browser ist eine High-Performance- Grafik-Engine und ist auf praktisch allen Plattformen die optimierteste Anwendung. Er ist in C, C++ oder anderen systemnahen Sprachen wie Rust implementiert und nutzt die Hardwarebeschleunigung des darunter liegenden Systems bestmöglich aus. Diese Möglichkeiten können wir nutzen, indem wir aus JavaScript per API darauf zugreifen. Alternativ lassen sich die eigens dafür entwickelten deklarativen Sprachen HTML und CSS verwenden. Der systemnahe Code des Browsers kann sie schneller als alles andere parsen, interpretieren und in das für die Darstellung benötigte Document Object Model (DOM) umsetzen.

Weil die Sprachen genau für diesen Einsatzzweck gebaut wurden, sind sie aus Performancesicht optimal. Außerdem sind sie deklarativ und besonders fehlertolerant in der oben skizzierten widrigen Ausführungsumgebung Browser. Gibt es einen Fehler im JavaScript- Code, wird eine Exception geworfen und der Rest des Codes nicht ausgeführt. In CSS werden unbekannte Regeln hingegen einfach übersprungen und in HTML unbekannte Tags einfach als <span> behandelt. Die deklarative Natur erlaubt es zusätzlich, außerordentlich große Kompatibilität über verschiedene Browserversionen hinweg zu gewährleisten. So können serverseitig gerenderte HTML- und CSS-Seiten von älteren und neueren Browsern und selbst auf Geräten, die es zum Zeitpunkt der Erstellung des Codes noch gar nicht gab, in der Regel zumindest so weit interpretiert werden, dass sie benutzbar sind.

Für diejenigen, die den serverseitigen Code schreiben, lässt sich das HTML als Komponentenkonfiguration betrachten: Die bestehenden Komponenten wie Text- und Eingabefelder, Select-Elemente (Listen), Video- und Audioelemente müssen nicht implementiert, sondern benutzt werden. JavaScript schließlich kommt selbstverständlich auch zum Einsatz, aber nicht als notwendige Zutat für ein Funktionieren der Seite, sondern als zusätzliches Element, um sie im Bezug auf Ergonomie und Optik zu verbessern.

Für den Ansatz, sich auf die Basisfeatures des Browsers zu verlassen und die drei Schlüsseltechnologien konform zu diesen Grundprinzipien zu verwenden, haben wir eine Website mit Best Practices angelegt und ihr einen Namen gegeben: ROCA (für Resource Oriented Client Architecture).

Was macht man denn nun konkret?

Bis jetzt haben wir über eine abstrakte Architektur gesprochen, aber wie sieht das nun in der Praxis aus? Können wir uns wirklich eine Webanwendung ohne JavaScript vorstellen? Wir haben uns vielleicht daran gewöhnt, dass wir irgendwelche JSON-Strukturen vom Server erhalten und daraus DOM-Elemente generieren. JSON ist aber nicht die Sprache des Webs. HTML ist die Sprache des Webs. Warum müssen wir also unbedingt den Zwischenschritt über JSON gehen, aus dem dann ein JavaScript-Framework HTML erzeugt? Fast jedes Backend- Framework bringt eine Templating Engine mit, über die man direkt HTML generieren und ausliefern kann. Die Basis-Spring-Boot-Anwendung kommt beispielweise mit Thymeleaf gebundled, womit wir direkt HTML-Seiten ausliefern können, ohne irgendwelche JavaScript-Frameworks zu verwenden.

Make it work: HTML

Wenn wir jetzt eine von JavaScript unabhängige Anwendung entwickeln wollen, ist der erste Schritt, eine funktionierende Webanwendung zu schreiben, die nur aus HTML besteht. HTML5 versammelt eine ganze Reihe von Elementen mit viel Funktionalität. Drei Beispiele dafür sind:

• <input type="date"> erzeugt einen Datepicker.
• <audio> erzeugt einen Audiospieler.
• <video> erzeugt einen Videospieler.

Außerdem gibt es immer einen Fallback für diese Elemente, damit ältere Browser auch weiterhin funktionieren können. Oft ist es auch so, dass die Browser bessere Entscheidungen über das Rendering solcher Elemente treffen können als wir. Ein <input type="date"> auf einem Smartphone ist darauf ausgerichtet, dass der Benutzer das Datum mit seinem Finger auswählen möchte, und ist deswegen einfacher zu benutzen als der Datepicker einer JavaScript-Bibliothek. Wir dürfen auch nicht vergessen, dass HTML nicht nur für Darstellungslogik gedacht ist. Mit einem einfachen Link können wir von einer Seite zur anderen springen. Außerdem sind HTML-Formulare extrem mächtig und erlauben uns anhand vom Benutzereingaben dynamisch HTTP Requests zu generieren, die dann zum Server geschickt werden. Der Server führt schließlich die Änderung aus (Abb. 4).

Manchmal sollen anhand der Benutzereingaben unterschiedliche Seiten angezeigt werden. Da der Server jetzt die Funktionalität in der Anwendung steuert, er auch mit einem Redirect entscheiden, was als Nächstes passiert (Abb. 5).

Einer der größten Vorteile dieses Ansatzes besteht darin, dass HTML ohne viel Aufwand von Screenreadern konsumiert werden kann. Deswegen ist es relativ einfach, Barrierefreiheit in der Anwendung zu implementieren. Das A11Y Project ist eine gute Ressource für weitere Verbesserungen. Natürlich ist es auch möglich, eine JavaScript-zentrische Anwendung barrierefrei zu gestalten, erfordert in der Regel aber zusätzlichen Aufwand und besonderes Augenmerk.

Wiederverwendbarkeit

Ein weiterer Vorteil von HTML lautet, dass man die Elemente beliebig ineinander verschachteln kann. Um die Wiederverwendbarkeit unserer UI-Elemente zu verbessern, können wir einige Elemente in Komponenten extrahieren. Komponenten sind eine wiederverwendbare HTML-Struktur, die wir als Abstraktion für unsere Funktionalität benutzen können.

Um die Übersichtlichkeit unserer Komponenten zu verbessern, können wir sie mit einem System wie Atomic Design strukturieren. Näheres dazu findet sich im Artikel von Ute Mayer ab Seite 58. Hier aggregieren größere Komponenten immer kleinere Komponenten. Der einfachste Weg das praktisch umzusetzen ist, einmal ein HTML-Schnipsel zu definieren und danach immer wieder das Markup zu kopieren sowie den Inhalt auszutauschen. Langfristig ist das aber nicht wartungsfreundlich. Die meisten Templating-Bibliotheken bieten daher einen Weg, wie wir HTML-Schnipsel einmal definieren und dann wiederverwenden können. In Thymeleaf etwa funktioniert das mittels th:replace oder th:insert.

Zu den großen Vorteilen dieses Ansatzes zählt auch, dass man anhand dieser HTML-Struktur die Komponenten stylen kann. Damit fangen die größeren Herausforderungen an.

Make it pretty: CSS

Jetzt kommen wir an die Stelle, an der es leicht passieren kann, dass wir scheitern. Einerseits könnte man argumentieren, dass es am wichtigsten ist, dass die Anwendung funktioniert, auch wenn sie nicht sonderlich gut aussieht. Andererseits möchte niemand eine schlecht aussehende Anwendung bedienen. In diesem Zusammenhang sind einige ästhetische Aspekte wichtig (s. Box: „Ästhetik fürs Web“).

Obwohl die „Schönheit“ der Seite eine subjektive Beurteilung ist, lässt sich an diesem Punkt viel Zeit in Themen wie Design und Typographie investieren und dabei ein Gefühl entwickeln, wie die Dinge am Ende aussehen sollen. Leider fehlt es vielen Entwicklern an der nötigen Zeit oder Lust, sich viel mit dem Thema auseinander zu setzen.

Zum Glück müssen wir aber nicht immer das Rad neu erfinden. Es ist möglich, fertige Komponentenbibliotheken wie Bootstrap oder Foundation zu verwenden. Hier haben Designer schon die wichtigsten Entscheidungen getroffen, damit die Anwendung für Endbenutzer brauchbar ist.

Wer diese Komponentenbibliotheken anpassen und um eigene Komponenten erweitern möchte, dem ist ein Pattern-Library-Werkzeug wie Fractal sehr dienlich. Es ist besonders hilfreich, wenn die Komponenten zwischen Projekten wiederverwendet werden sollen. Für größere CSS-Projekte empfiehlt es sich, einen Präprozessor wie Sass zu verwenden, damit das CSS in mehrere Dateien aufgesplittet werden kann. Für eine HTML-Komponente kann das dazu passende CSS in einer Datei direkt daneben in den gleichen Ordner gelegt werden. Hier können wir auch eine Namenskonvention wie BEM für die CSS-Komponenten nutzen. Eine Asset-Pipeline wie faucet-pipeline kann dann dafür sorgen, dass das CSS kompiliert wird. Wenn wir ebenso JavaScript schreiben, lässt sich faucet-pipeline auch dafür verwenden.

Make it fast: JavaScript

Wir haben einen Punkt erreicht, an dem wir aufhören könnten: Wir haben eine funktionierende Webanwendung, die auch schön aussieht. Allerdings können wir mit JavaScript jetzt die Anwendung optimieren und verbessern. Der Grund, warum eine Single Page App sich oft schneller anfühlt, ist, dass man CSS und JavaScript nicht bei jedem Seitenwechsel neu parsen und evaluieren muss. Mit einer Bibliothek wie Turbolinks erreichen wir genau das: Wenn ein Benutzer auf einen Link klickt, kann das HTML auf der Seite ausgetauscht werden, ohne dass das CSS und JavaScript neu geladen werden müssen.

Mit HTML-Formularen lässt sich etwas Ähnliches erreichen: Anstatt den Browser den Inhalt eines Formulars zum Server schicken und mit dem Ergebnis eine neue Seite aufbauen zu lassen, kann man den Request stattdessen per Ajax abschicken und das HTML, das zurückkommt, bearbeiten sowie Teile der Seite austauschen.

class MeineKomponente extends HTMLElement {
  connectedCallback() {
  // Instanziiere Komponente
  }
}
customElements.define("meine-komponente", MeineKomponente)