© sakda maprachaub, 123RF

Mit Phoenix Liveview betankt Elixir-Entwickler Chris McCord den Browser über einen speziellen Kanal mit Daten vom Server. Das positioniert Liveview als Alternative zu Single-Page-Webanwendungen. Wie das Ganze funktioniert und warum Liveview so flott vorankommt, klärt der Artikel.

Server liefern Webseiten entweder als fertiges HTML-Dokument aus oder der Browser montiert sie mit Javascript als Single-Page-Webanwendung. Die zweite Variante kommt häufig zum Einsatz, um dynamische und sich selbstständig verändernde Inhalte darzustellen. Beide Wege benutzen einen »GET«-Mechanismus, um alle Informationen vom Webserver abzufragen.

Mit Phoenix Liveview [1] kommt nun ein weiterer Weg hinzu. Um ihn zu verstehen, ist die Analyse der Vor- und Nachteile der beiden anderen Wege sinnvoll.

Normale HTML-Seite

Die erste Webseite war eine statische HTML-Seite, von einem Menschen in einem Editor geschrieben oder programmiert. Vereinzelt gibt es heute noch immer rein statische HTML-Seiten. Sie haben den Vorteil, dass der Server sie sehr schnell ausliefert.

Aber die meisten Webseiten stellt ein Dienst dynamisch auf dem Server zusammen. Das geschieht meist mit Hilfe der Programmiersprachen PHP, Java, Python, Ruby oder Elixir [2]. Oft kommt der User nicht in direkten Kontakt mit der Programmiersprache, weil er ein CMS wie WordPress benutzt. Aber immer liest ein Prozess aus einer Datenbank Datensätze und erzeugt daraus die Webseite. Deshalb ist auch von einer dynamischen Seite die Rede.

Das Ergebnis dieses Prozesses kann wiederum eine reine HTML-Seite sein, ohne jegliches Javascript. In der Praxis hübschen jedoch fast alle Anbieter ihre Webseiten mit ein wenig Javascript auf oder bauen zumindest ein Javascript-basiertes Tracking (zum Beispiel Google Analytics) ein.

Während der Browser aber reine HTML-Seiten sehr schnell rendert und damit anzeigt, beginnen die Performance-Probleme gewöhnlich mit der ersten Zeile Javascript. Der Browser braucht dann je nach CPU- und RAM-Ausstattung ein Vielfaches der Zeit, um die Seite darzustellen, weil er die Skripte fertig laden oder übersetzen muss. Da hilft auch eine schnelle LTE-Verbindung nichts.

Statisches HTML verknüpft einzelne Webseiten über »<a href>«-Elemente im HTML-Code miteinander. Klickt ein User auf diesen Link, lädt der Browser diese Seite neu vom Server. Der Server liefert dann entweder statischen Content aus (etwa eine statische Seite oder eine Grafik) oder generiert dynamisch eine neue Seite und veröffentlicht sie.

Single-Page-Webanwendung

Den Wunsch nach Webseiten, die sich wie native Applikationen verhalten, realisierte anfänglich das Flash-Plugin. Damit erhielt der Browser die Möglichkeit, selbst auf Eingaben zu reagieren und die Seite selbstständig zu verändern. Flash hatte aber in Sachen Performance und vor allen Dingen in Sachen Sicherheit einige Defizite.

Vor allem dem 2011 verstorbenen ehemaligen Apple-Chef Steve Jobs ist es zu verdanken, dass dieses schwarze Kapitel der Webseiten-Entstehung vorbei ist. Er beschloss, Flash auf dem I-Phone nicht mehr zu unterstützen – und damit war es faktisch dem Tod geweiht.

Der Entwicklerwunsch nach möglichst dynamischen Webseiten bestand jedoch weiterhin. Ihn erfüllte eine zunehmende Menge an Javascript-basierten Single-Page-Webanwendungen (Single-Page Application, SPA, [3]). Sie verwenden ein minimales HTML-Dokument nur als Transport-Container für Javascript. Die eigentliche Webseite erzeugt das Javascript-Programm dann im Browser. Der rendert anschließend die fertige Seite, die dazu nötigten Daten fragt er über API-Calls beim Server ab.

Das erste Laden dieser Applikationen dauert zwar meist recht lange, die fertige Webseite ist dann aber – wenn sie gut gemacht ist – sehr reich an Features. Ein weiterer Pluspunkt: Neue Seiten muss die Anwendung anschließend nicht mehr vom Server laden, sondern die Single-Page Application generiert sie beim Klick des Users einfach selbst. Gut gemachte SPAs laufen zudem eine gewisse Zeit offline, um sich dann zu einem späteren Zeitpunkt mit dem Server zu synchronisieren. Aber das funktioniert nicht für alle Applikationen.

Der größte Nachteil von SPAs liegt in ihrem Ressourcenbedarf. Derartige Webseiten funktionieren sinnvoll nur auf schnellen Geräten und bei einer guten Internetanbindung.

Dank populärer Javascript-Frameworks wie Angular JS, React, Vue.js und Ember.js gibt es immer mehr SPA-Webseiten. Allerdings setzen viele Anbieter diese Technologie häufig ohne einen wirklichen Mehrwert ein.

Immer zwei Programmiersprachen und viel Overhead

Ein Hauptproblem bei SPA-Applikationen besteht darin, dass Entwicklerteams zwei völlig verschiedene Programmiersprachen beherrschen müssen. Im Frontend ist das immer Javascript. Es gibt einige Teams, die auch auf dem Server Javascript einsetzen, aber die Mehrzahl benutzt im Backend PHP, Ruby, Python oder Elixir. Und zusätzlich muss sich noch jemand um das CSS kümmern, damit auf den fertigen Webseiten auch alles schick aussieht.

Die bekannten Javascript-Frameworks zeichnen sich jedoch nicht nur durch eine umfassende Feature-Vielfalt, sondern auch durch extreme Beweglichkeit aus. So gibt es alle sechs Wochen eine neue Ember.js-Version [4]. Auch wenn das Upgrade von einer Minor- auf eine andere Minor-Version simpel ist, bedarf es trotzdem eines Prozesses, der kontinuierlich darüber wacht, dass alle Komponenten aktuell und getestet sind.

Ach ja: Als eine zusätzliche Unbekannte in diesem Spiel entpuppen sich die permanenten Änderungen auf Seiten der Browser. Diese aktualisieren sich ja mittlerweile automatisch und selbstständig. Die Zeit, in der Entwickler eine Webseite einmal programmierten, um sie dann drei bis vier Jahre laufen zu lassen, sind dank der SPAs schon lange vorbei.

Phoenix Liveview als dritter Weg

Phoenix-Erfinder Chris McCord hat mit einem im Phoenix-Framework integrierten Channel-System den Grundstein für einen neuen Weg für interaktive Webseiten geschaffen. Über die Channels schiebt der Webserver jederzeit neue Daten oder neuen HTML-Code zum Browser.

Darauf aufbauend arbeitet Liveview. Es besteht aus einem kleinen Javascript-Teil, den der Anbieter auf der Webseite einbindet. Dieses Liveview.js und Morphdom [5] kommen zusammen komprimiert auf eine Größe von 29 KByte. Im Vergleich dazu braucht eine React-Anwendung mindestens 112 KByte. Entsprechend zügiger führt der Browser den Liveview-Code aus.

Und jetzt wird es spannend. Der Javascript-Code verfügt im Gegensatz zu einer SPA über keine eigene Intelligenz. Er reicht einfach jede Eingabe an den Server weiter. Auf dem läuft eine normale Phoenix-Applikation, die dann den neuen Inhalt der Webseite oder einzelner Website-Elemente per Channel an Liveview.js pusht (Abbildung 1). Morphdom baut den Inhalt dann in die aktuelle Webseite ein.

Abbildung 1: In seinem Blogpost [7] erklärt Chris McCord, wie Phoenix Liveview unter der Haube funktioniert.

Auf den ersten Blick denkt sich ein unbefangener Beobachter sicher: “Das kann doch gar nicht schnell sein.” Aber die bereits existierenden Liveview-Beispiele sprechen eine andere Sprache. Anhand einer frühen Betaversion zeigte Chris McCord im Rahmen einer Keynote auf der 2018er Elixirconf [6] eine Webseite, deren Inhalte der Server mit 60 FPS (Frames per Second) aktualisierte. Mit dieser Geschwindigkeit ließe sich auch ein Onlinespiel problemlos auf einer Webseite umsetzen. Mittlerweile gibt es eine stabile Liveview-Version, die sogar noch etwas schneller läuft.

Um das zu verstehen, muss der Betrachter sich noch einmal vor Augen halten, dass Single-Page-Webanwendungen im Prinzip riesige Javascript-Applikationen sind, die entsprechend langsam arbeiten und alle benötigten Daten zusätzlich vom Server holen müssen.

Und die schnellen Updates mit Liveview funktionieren im Wesentlichen deshalb, weil die dafür eingesetzte funktionale Programmiersprache Elixir sehr effizient arbeitet. Wenn der Server für das Rendern eines neuen Seitenelements mehr Zeit bräuchte, würde die Idee schon nicht mehr funktionieren.

Schön ist aber nicht nur die Geschwindigkeit, sondern auch der Verzicht auf Javascript als zusätzlicher Programmiersprache. Alle Programmierlogik steckt in Elixir und im Phoenix-Framework. Und im Gegensatz zu einer SPA, bei der der Browser die Daten auswertet, bleiben bei Liveview Firmengeheimnisse weiterhin auf dem Server.

Licht und Schatten

Der Hauptvorteil von Liveview ist also die Reduktion auf Elixir. Ein Team kann sowohl das Backend als auch das Frontend entwickeln und damit schneller zu Ergebnissen kommen.

Ein wesentlicher Nachteil besteht darin, dass Elixir eine noch wenig verbreitete Programmiersprache ist. Wer aus dem objektorientierten Umfeld kommt, muss beim Umstieg auf das funktionale Elixir eine steile Lernkurve meistern. Da Liveview zudem nur bei einer aktiven Verbindung funktioniert, gibt es keine Möglichkeit, eine Offline-Version zu betreiben.

Entscheidungshilfe

Alle drei aufgeführten Arten von Webseiten haben ihre Daseinsberechtigung. Entwickler und ihre Auftraggeber setzen die Technologien häufig aber ohne Gewinn ein, einfach weil sie gerade hip sind. So ließen sich die meisten Webshops am einfachsten mit dynamisch auf dem Server generierten Webseiten abbilden. Gern auch mit dem berüchtigten Javascript-Zweizeiler zur Zierde. Nur wenige Webapplikationen müssen wirklich als Single-Page-Webanwendungen vorliegen.

Liveview wandert zwischen den Welten. Der weitgehende Verzicht auf Javascript als Entwicklungs-Programmiersprache ist dabei der größte Gewinn.