Lucas Dohmen innoQ

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?

Joy Heron innoQ

Wir haben in der Praxis die Erfahrung gemacht, dass sich mit serverseitig gerendertem HTML in Verbindung mit Custom Elements, sorgsam modularisiertem CSS und dem sparsamen Einsatz von JavaScript architektonisch saubere, schlanke, schnelle und ergonomische Anwendungen entwickeln lassen.

Stefan Tilkov innoQ

Wer einmal eine Anwendung im ROCA-Stil gebaut hat, wählt unserer Erfahrung nach danach nur noch in Ausnahmefällen und aus gutem Grund – beispielsweise wegen der Offlinefähigkeit – einen SPA-Ansatz.

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.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 2.19 - "Moderne Frontend-Architektur"

Alle Infos zum Heft
579872088JavaScript? Gern, aber bitte in Maßen
X
- Gib Deinen Standort ein -
- or -