© Excellent backgrounds/Shutterstock.com
Java Magazin
Fast Forward to Productivity

Polymer 0.8: Das Experiment ist vorüber

Als Experiment für eine standardisierte Komponentenbildung bei Webapplikationen gestartet, ist Polymer nun mit Version 0.8 auf dem Weg zur ersten produktiven Version im Google-Maßstab. Dieser Artikel möchte diskutieren, welche Erfahrungen und Motivationen hinter der aktuellen Vorgehensweise stecken, welche Neuerungen es gibt und wie Webkomponenten nach Polymer 0.8 migriert werden können.

Patrick Hillert, Christian Meder


Eines sollte gleich vorweg gesagt werden: In der Entwicklung von Polymer 0.8 blieb kaum ein Stein auf dem anderen. Matt McNulty, einer der Köpfe hinter dem Thema Webkomponenten bei Google, bezeichnete die Entwicklung von Polymer und der Webkomponenten vor Version 0.8 als ein gemeinsames großes Communityexperiment unter der Leitfrage, wie komplexe Webapplikationen zukünftig strukturiert werden [1]. Sind Webkomponenten ein vielversprechender Ansatz, um die Entwickler von Webapplikationen produktiver werden zu lassen? Mit kurzen Feedback- und Iterationszyklen wurde in einer sehr interaktiven Art und Weise getestet, ob sich die Kombination aus vorgeschlagenen Webstandards (nativ und als Polyfill), Polymer-Bibliothek und bestehenden Komponenten für die alltägliche Entwicklung von Webapplikationen eignet. Diese Phase wurde mit Polymer 0.5 erfolgreich abgeschlossen.

Aber es blieb eine Reihe von Fragen offen. Werden die anderen Browserhersteller neben Chrome die vorgeschlagenen Standards nativ implementieren? Und wenn ja, wann? Gesetzt den Fall, dass ein Webbrowser Webkomponenten nicht nativ unterstützt, welche Performance ist dann mit Polyfills möglich und welche Einschränkungen müssen dafür gegebenenfalls in Kauf genommen werden? Ab wann und wie kann ich eine komplexe Webapplikation mit zahlreichen Webkomponenten über alle wichtigen Webbrowser, sowohl Desktop als auch mobil, produktiv und ohne Bedenken einsetzen?

Das noch junge Webkomponentenökosystem stand vor der Frage, wie es angesichts dieser unklaren und nicht komplett beeinflussbaren Rahmenbedingungen den Weg in die Produktion finden sollte. Das Polymer-Team entschied sich, nicht auf die native Implementierung der Webkomponentenspezifikationen durch die Browserhersteller zu warten. Stattdessen wurde untersucht, ob es möglich wäre, mit einer gründlichen Komplettüberarbeitung des gesamten Stacks und gepaart mit permanenten und sorgfältigen Performancemessungen den Geschwindigkeitsverlust gegenüber einer nativen Implementierung auf allen unterstützten Browsern auf 10 bis 20 Prozent zu begrenzen. Nach den ersten vielversprechenden Ergebnissen zur Zeit des Chrome Developer Summits im letzten Jahr bildete dieser Ansatz die Grundlage für die Polymer-Version 0.8. Dabei handelt es sich um einen robusten, skalierbaren und für den Produktionseinsatz optimierten Webkomponentenunterbau auf allen unterstützten Browsern – schlank, aber dennoch funktional nahe an den Möglichkeiten von Version 0.5. Die Geschwindigkeitsein...

Java Magazin
Fast Forward to Productivity

Polymer 0.8: Das Experiment ist vorüber

Als Experiment für eine standardisierte Komponentenbildung bei Webapplikationen gestartet, ist Polymer nun mit Version 0.8 auf dem Weg zur ersten produktiven Version im Google-Maßstab. Dieser Artikel möchte diskutieren, welche Erfahrungen und Motivationen hinter der aktuellen Vorgehensweise stecken, welche Neuerungen es gibt und wie Webkomponenten nach Polymer 0.8 migriert werden können.

Patrick Hillert, Christian Meder


Eines sollte gleich vorweg gesagt werden: In der Entwicklung von Polymer 0.8 blieb kaum ein Stein auf dem anderen. Matt McNulty, einer der Köpfe hinter dem Thema Webkomponenten bei Google, bezeichnete die Entwicklung von Polymer und der Webkomponenten vor Version 0.8 als ein gemeinsames großes Communityexperiment unter der Leitfrage, wie komplexe Webapplikationen zukünftig strukturiert werden [1]. Sind Webkomponenten ein vielversprechender Ansatz, um die Entwickler von Webapplikationen produktiver werden zu lassen? Mit kurzen Feedback- und Iterationszyklen wurde in einer sehr interaktiven Art und Weise getestet, ob sich die Kombination aus vorgeschlagenen Webstandards (nativ und als Polyfill), Polymer-Bibliothek und bestehenden Komponenten für die alltägliche Entwicklung von Webapplikationen eignet. Diese Phase wurde mit Polymer 0.5 erfolgreich abgeschlossen.

Aber es blieb eine Reihe von Fragen offen. Werden die anderen Browserhersteller neben Chrome die vorgeschlagenen Standards nativ implementieren? Und wenn ja, wann? Gesetzt den Fall, dass ein Webbrowser Webkomponenten nicht nativ unterstützt, welche Performance ist dann mit Polyfills möglich und welche Einschränkungen müssen dafür gegebenenfalls in Kauf genommen werden? Ab wann und wie kann ich eine komplexe Webapplikation mit zahlreichen Webkomponenten über alle wichtigen Webbrowser, sowohl Desktop als auch mobil, produktiv und ohne Bedenken einsetzen?

Das noch junge Webkomponentenökosystem stand vor der Frage, wie es angesichts dieser unklaren und nicht komplett beeinflussbaren Rahmenbedingungen den Weg in die Produktion finden sollte. Das Polymer-Team entschied sich, nicht auf die native Implementierung der Webkomponentenspezifikationen durch die Browserhersteller zu warten. Stattdessen wurde untersucht, ob es möglich wäre, mit einer gründlichen Komplettüberarbeitung des gesamten Stacks und gepaart mit permanenten und sorgfältigen Performancemessungen den Geschwindigkeitsverlust gegenüber einer nativen Implementierung auf allen unterstützten Browsern auf 10 bis 20 Prozent zu begrenzen. Nach den ersten vielversprechenden Ergebnissen zur Zeit des Chrome Developer Summits im letzten Jahr bildete dieser Ansatz die Grundlage für die Polymer-Version 0.8. Dabei handelt es sich um einen robusten, skalierbaren und für den Produktionseinsatz optimierten Webkomponentenunterbau auf allen unterstützten Browsern – schlank, aber dennoch funktional nahe an den Möglichkeiten von Version 0.5. Die Geschwindigkeitsein...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang