Zukunft der Webentwicklung: Webkomponenten und Progressive Web Apps, Teil 1
Seite 2: Polymer
Polymer – Elemente nach dem Periodensystem
Trotz Angular hat Google mit Polymer ein Projekt gestartet, das die Nutzung von Webkomponenten vorantreiben möchte. Es kombiniert Polyfills und syntaktischen Zucker zu einer Library, die die Nutzung von Webkomponenten in jedem halbwegs aktuellen Browser ermöglicht.
Zum Projekt gehören fertig einsetzbare Elemente, die der "chemischen" Namensgebung folgend in solche des Periodensystems unterteilt wurden. So finden sich unter "Md" (Mendelevium) viele Komponenten, mit denen sich das von Google propagierte Material Design umsetzen lässt. Es gab wohl viele Einwände gegen diese Art der Benennung, sodass Google bei den "App Elements" mittlerweile davon abwich. Hier finden sich unsichtbare Komponenten, die Aufgaben übernehmen, die Entwickler sonst mit Anwendungs-Frameworks angehen würden.
Angular vs. Polymer
Wer das Polymer-Team nach ihrem Verhältnis zu Angular fragt, bekommt erwartungsgemäß Antworten, die die Existenzberechtigung beider Projekte betonen. Es wäre tatsächlich möglich, beides zu verwenden. Beim Rewrite von Angular 2 schielte man schon in Richtung Webkomponenten. Wer in Polymer aber nur eine UI-Library sieht, die viele Aspekte von Angular außer Acht lässt, greift etwas zu kurz. Bei den "App Elements" des "Polymer Element Catalog" sind durchaus Überschneidungen mit Angular erkennbar.
Anfänglich stopften viele Polymer in die Schublade "Plug and Play". Nach dem Import wird das Element irgendwo auf der Seite eingesetzt – fertig. Das ist zwar möglich, aber bei komplexeren Anwendungen wird die Komponente eher als Teil einer eigenen genutzt, was sich sogar über zwei oder drei Ebenen fortsetzen kann, bevor das Element im Light DOM auftaucht.
Seit der IO 2016 wird deutlicher, wie sich Google die Zukunft der Internetentwicklung mit Polymer vorstellt. Die "Carbon Elements" wurden umbenannt, die "Polymer App Toolbox" eingeführt, und es gibt einen Shop für Oberbekleidung, der die neuen Möglichkeiten exemplarisch vorführt. Diese Anwendung wird hier näher betrachtet, wobei schnell klar sein dürfte, dass Google von Webentwicklern ein gewisses Umdenken verlangt.
Viele Webframeworks kommen mit einem Programm für die Kommandozeile (CLI), dass einem lästige Aufgaben abnimmt und so die Zeit bis zur ersten fertigen App verkürzt – so auch bei Polymer, dessen CLI auf Node.js basiert. Es unterstützt den gesamten Entwicklungsprozess vom Erstellen vorgefertigter Programmgerüste bis hin zur Kombination von Build-Tools, die das Projekt für das Deployment vorbereiten. Für größere Firmen interessant: Man kann alles auch ohne das CLI direkt in eigene Prozesse einbinden. Die Toolbox kombiniert also ein Hilfsprogramm mit den umfirmierten "App Elements", um bei Entwicklern Eindruck zu schinden, wie schnell sie eine App online bekommen. Selbstredend wird hier die Google-eigene Cloud-Umgebung Firebase unterstützt, die Entwickler auch nutzen können, wenn die App gar keine Datenbank benötigt.
Gebündelt oder nicht gebündelt?
Bei HTTP/1.1 entscheidet allein der Browser, was der Server laden soll. Das Laden jeder Ressource hat einen gewissen Overhead, da auch jedes Mal eine neue Verbindung aufgebaut wird. Deswegen macht es Sinn, die Dateien vor der Übertragung zu bündeln. HTTP/2 soll die Ladezeiten von Seiten verkürzen. Nicht mehr allein der Browser entscheidet, was geladen wird. Der Server nutzt seinen Informationsvorsprung und gibt einem schon geöffneteten Stream alles mit, was der Browser benötigt (noch bevor dieser das HTML analysiert hat). Das Bündeln von Dateien wäre hier kontraproduktiv, da der Server die Ressourcen für den Server-Push wieder herauslösen müsste. Daher produziert Polymer CLI zwei Varianten des Projekts, "bundled" und "unbundled" – je nachdem, ob der Webserver HTTP/2 unterstützt oder nicht.
Back-Button-Support
Je mehr eine Internetseite in Richtung Web-App geht, desto eher möchten Entwickler vermeiden, dass die Seite bei jeder Aktion der Anwender neu geladen wird. Nicht zuletzt, weil auch der Status der App dabei verloren geht. Entwickler setzen daher Single Page Apps ein, die zu Beginn der Nutzung nur einmal in den Browser geladen werden und sich ansonsten nur noch über XHR (AJAX), WebSockets oder Ähnliches mit dem Server austauschen.
Jetzt genügt aber ein Klick auf den Zurück-Knopf im Browser, und die App wird beendet. Inhalte, die die App verfügbar macht, sind auch für Suchmaschinen nicht mehr indizierbar, sie haben keine eigene URL. Für einen Shop wäre das fatal. Ein potenzieller Kunde könnte nicht einmal die Internetadresse zu einem Produkt in seinem Browser ablegen.
Als Lösung kommt "Client-side Routing" zum Einsatz. Der ursprünglich nur bei Netzwerkern verwendete Begriff meint bei Web-Apps den Prozess, eine URL auf Inhalte abzubilden. Die Internetadresse wird analysiert, um dann zu entscheiden, welche Teile des Programms welche Daten zur Ansicht bringen. In der Regel findet das auf dem Server statt, bei Single Page Apps ist das aber kein gangbarer Weg. Man muss allerdings tricksen, damit sich Suchmaschinen und Nutzer über Links in der App bewegen können, ohne dass die Seite neu geladen wird. Lange Zeit nutzte man hier den Hash, der zum Anspringen von Inhalten auf ein- und derselben Seite gedacht ist. Die URL ändert sich nur hinter dem "#", der Browser sieht keine Veranlassung, die Seite neu zu laden.
Zukünftig dürfte hier vermehrt die Methode pushState des history-Objekts zum Einsatz kommen. Alle gängigen Browser unterstützen die Manipulation des Browserverlaufs (der Internet Explorer ab Version 10). Mobil sperrt sich nur noch Opera Mini. history erlaubt es, sich in den Back-Button des Browsers einzuklinken. Die App wird informiert, wenn Besucher zurückwollen, und kann mittels pushState() die Anzeige der Adresse beeinflussen. Der Hash muss hier nicht mehr vorkommen. Zugleich wird der Klick auf einen Link abgefangen und via JavaScript abgewürgt, sodass der Browser die Seite nicht neu lädt. Selbstredend verwendet Google für seine Fallstudie die modernere Variante.
Jetzt haben Entwickler aber das Problem, dass eine im Browser (oder bei Google) gespeicherte Adresse nicht tatsächlich aufrufbar ist. Im Fall eines Shops adressiert sie ein Produkt, der Webserver geht jedoch davon aus, dass sich hinter der Adresse eine versendbare Datei befindet. Man benötigt für dieses Szenario eine gewisse Kontrolle über den Webserver, um alle Anfragen, die "ins Leere laufen", auf die Datei umzulenken, die den Shop lädt, typischerweise index.html. Beim Apache-Webserver erledigt das eine Rewrite-Anweisung.
