Eine moderne Webanwendung wird natürlich in JavaScript implementiert und erzeugt ihr HTML clientseitig im Browser selbst. Sie kommuniziert mit dem Server nur, um über ein HTTP/REST-API-Daten im JSON-Format abzuholen – das, so scheint es, ist die gängige Weisheit. Aber haben die bewährten Ansätze wie serverseitiges HTML und Progressive Enhancement tatsächlich ausgedient? Im Gegenteil, damit lassen sich vermeintlich altmodische Anwendungen realisieren. Sie sind oft sehr viel besser als die mit dem Framework der Woche realisierte Single-Page-App.
Wie sieht das Problem aus? Betrachten wir die traditionelle Trennung zwischen Server und Client, dann liegen auf der Clientseite ausschließlich Aussehen und Verhalten. Zustand, Geschäftslogik, Routing sowie Präsentationslogik und Templating sind ausschließlich auf dem Server zu finden (Abb. 1).
Abb. 1: Traditionelle Trennung zwischen Server und Client
Mit dem Ziel, eine App zu bauen, die schneller und responsiver ist und vielleicht auch offlinefähig, wird nun oftmals Verantwortung vom Server auf den Client verschoben. In vielen Unternehmen ist ein zusätzlicher Anreiz, Abteilungen stärker zu trennen. Backend-Experten beispielsweise stellen nur ein API bereit und müssen sich um HTML/CSS/JS nicht kümmern. Zudem kursiert der Irrglaube, dass JSON kleiner sei als HTML. Jon Moore hat in einem Artikel erklärt, wieso das nicht stimmt [1]. Häufig werden die View-Logik sowie das Templating ins Frontend verschoben. Das passiert beispielsweise mit Technologien wie React oder Vue.js (Abb. 2).
Abb. 2: View-Logik und Templating werden ins Frontend verschoben
Ein weiterer Schritt ist oftmals, das Routing ebenfalls in den Client zu verlagern. In React zum Beispiel mit React Router, in Vue.js mit Vue Router. In Frameworks wie Angular oder Ember ist das Routing ebenfalls im Client angesiedelt.
