Wer die volle Kontrolle über die Optik einer WordPress-Webseite erhalten möchte, kommt um die Entwicklung eines eigenen Themes nicht herum. Natürlich gibt viele freie oder auch kommerzielle Themes – über 6000 verschiedene Themes werden allein im offiziellen Theme-Verzeichnis und noch viele mehr auf diversen Plattformen angeboten. Diese Themes lassen sich auch oft mit mehr oder weniger Aufwand an die eigenen Bedürfnisse anpassen. Aber sie bringen meist auch unnötigen Ballast mit sich und nicht immer ist jedes gewünschte Feature verfügbar.
Starter-Themes
Wer für sich oder Kunden ein neues Theme entwickeln möchte, kann sich die Arbeit durch den Einsatz eines sogenannten Starter-Themes, auch Theme-Boilerplates genannt, sehr erleichtern. Das sind Themes mit einem durchdachten Grundgerüst, das dann je nach Bedarf erweitert wird.
Underscore (minimales Theme, von Automattic gepflegt)
Das WordPress-Starter-Theme Tonik
An dieser Stelle möchte ich kurz das WordPress-Starter-Theme Tonik vorstellen, das vom gleichnamigen polnischen Designstudio Tonik entwickelt und kostenlos angeboten wird. Obendrauf gibt Tonik eine umfangreiche und aktuelle Dokumention mit auf dem Weg, die nur wenige Fragen offen lässt.
Paketverwaltung mittels Composer und Node Package Manager (npm),
Webpack für das Bundling und die Optimierung aller Stylesheets und Skripte,
Modernes PHP u.a. durch Einsatz von Namespaces und eines Service-Containers,
Übersichtliche zentrale Konfigurationsdateien,
Erweiterung durch den Einsatz von Actions und Filtern,
Echte Templates, denen Parameter übergeben werden können.
Tonik setzt also auf moderne Entwicklungsmethoden.
Dateistruktur
Die Dateistruktur ist übersichtlich und durchdacht:
Dateistruktur des Tonik-Starter-Themes.
Im Resources-Ordner befinden sich die eigenen Stylesheets, Bilder, Schriftarten und JavaScript. Mit Webpack werden diese gebündelt und in den Public-Ordner kopiert. Außerdem befinden sich dort die Sprachdateien und nicht zuletzt die verschiedenen Templates.
Die Konfiguration von Webpack geschieht im Build-Ordner, während sich im Config-Ordner allgemeine Konfigurationsdateien zum Theme befinden.
Logik des Themes
Die Logik des Themes findet sich im App-Ordner, die gut strukturiert ist und beliebig angepasst und erweitert werden kann.
So werden im Unterordner Setup in jeweils getrennten Dateien die für das Theme notwendigen Actions, Filters und Services definiert. Hierhin gehören auch eigene Erweiterungen, wie beispielsweise eigene Customizer-Funktionen oder beispielsweise auch WooCommerce-Anpassungen.
Für jede WordPress-Eigenheit ist im Unterordner Structure eine eigene Datei angelegt, so für eigene Post-Types, Shortcodes, Navs oder auch Thumbnails.
Fazit
Tonik hat für dieses Starter-Theme einen sehr guten Kompromiss gefunden: einerseits ist das Tonik-Starter-Theme extrem schlank und frei von unnötigem Ballast. Andererseits enthält es ein komplettes und gut durchdachtes Theme-Grundgerüst, das – nach einer gewissen Einarbeitungszeit – sehr leicht und flexibel an die eigenen Bedürfnisse angepasst werden kann. Ein Theme für Entwicklerinnen und Entwickler, die auf moderne Werkzeuge wie Webpack nicht verzichten wollen und Wert auf eine gute strukturierte Architektur legen.
Dieser Artikel gibt eine Einführung in die Entwicklung von Webkomponenten mit Hilfe von Stencil. Stencil ist ein Kompiler für plattformunabhängige Webkomponenten, der zur Zeit vom Team hinter dem Ionic-Framework entwickelt wird und erst kürzlich im August auf dem Polymer Summit 2017 zum ersten Mal der Öffentlichkeit vorgestellt wurde.
Webkomponenten sind eine Erweiterung der HTML- und DOM-Spezifikation, die aktuell durch das Word Wide Web-Konsortium (W3C) vorgenommen wird. Es handelt sich dabei um in sich gekapselte, wiederverwendbare Widgets und Komponenten, die in Webseiten und Webapplikationen eingebunden werden können. Webkomponenten sind auch ein elementarer Bestandteil von Progressiven Web Apps (PWA), auf die wir in einem früheren Beitrag eingegangen sind.
Hier soll nun eine erste deutschsprachige Einführung in Stencil gegeben werden. Er wird erläutert, um was es sich bei Stencil handelt und wie mit dieser noch sehr neuen Technologie eigene Webkomponenten erzeugt werden können. Links zu weiterführenden Informationen rund um Stencil bzw. Webkomponenten finden sich am Ende dieses Artikels.
Kurz als Warnung: Stencil ist schon jetzt sehr rund und zumindest beim Ionic-Team auch schon im professionellen Einsatz. Aber die Software befindet sich in einem frühen Stadium und ist noch immer in der Entwicklung. Dennoch lohnt sich schon jetzt ein Blick auf diese möglicherweise zukunftsweisende Technologie.
Die folgende Kurzanleitung setzt Erfahrung mit Javascript, Git und Node.js bzw. NPM voraus. Darüber hinaus sind Grundkenntnisse in Angular, React, TypeScript und SASS hilfreich. Hier wird das Nötigste dazu kurz erklärt, kann aber in einem kurzen Artikel natürlich nicht komplett abgedeckt werden.
Stencil ist ein Kompiler, mit dessen Hilfe plattformunabhängige Webkomponenten erstellt werden können. Konkret werden mit Hilfe von Stencil benutzerdefinierte Elemente (Custom Elements) erzeugt, wobei der erzeugte Code aus nichts weiter als Vanilla-JavaScript, HTML und CSS besteht und daher in jedem modernen Browser ausführbar ist.
Webkomponenten gemäß der V1-Spefizikation werden von Haus aus in den Browsern Chrome und Safari dargestellt, während für Edge und Firefox an der Unterstützung gearbeitet wird. Stencil verwendet jedoch einen dynamischen Lader, über den mit Hilfe sogenannter Polyfills schon heute weitaus mehr Browser die von Stencil erzeugte Webkomponenten unterstützen: zusätzlich zu Chrome und Safari auch Firefox, Edge und sogar der Internet Explorer 11. Der aktuelle Stand findet sich auch auf caniuse.com.
Stencil ist also weder ein neues Framework, noch eine Bibliothek. Vielmehr können die mit Stencil erzeugten Webkomponenten in beliebigen anderen Frameworks genutzt oder auch einfach direkt in den HTML-DOM eingebunden werden. Das macht sie zu flexiblen, wiederverwendbaren Bausteinen moderner Webseiten und Webanwendungen wie PWAs.
Bevor wir uns gleich eine Beispiel-Webkomponente mit Hilfe von Stencil erzeugen, eine kurze Übersicht zu den Eigenschaften von Stencil-Webkomponenten und ihre Vorteile:
Stencil vereint in sich einige bewährte sowie einige sehr neue Konzepte anderer Frameworks wie Angular oder React:
Virtueller DOM – eine Repräsentation des eigentlichen DOMs, über die eine schnellere Bearbeitung und Aktualisierung desselben erfolgen kann; ähnlich wie es die Frameworks Vue.js und React umsetzen.
Lazy Loading – die Komponenten werden asynchron und damit deutlich schneller geladen und können mit anderen weiteren Komponenten kombiniert werden.
Asynchrones Rendering – ähnlich wie in der Entwicklerversion von React („Fiber“) gelöst.
Reaktives Data-Binding – reaktive Bindung zwischen den Daten im DOM und in der Komponente.
TypeScript – wie schon Angular oder Ionic unterstützt auch Stencil im Quellcode TypeScript, die Erweiterung des neuen ECMAScript-Sprachkerns u.a um Klassen, Interfaces und statische Typisierung.
JSX – eine einbettbare XML-artige Syntax, aus der JavaScript-Code erzeugt wird; als Teil von React entwickelt wird JSX nun auch von TypeScript unterstützt.
Mit Stencil erzeugte Webkomponenten weisen einige Vorteile gegenüber herkömmlichen Ansätzen auf:
Performance – die Komponenten sind im Vergleich zu Lösungen mittels Frameworks ohne unnötigen Ballast und dementsprechend schnell.
Stabilität – der Code besteht aus bewährtem Standard-Javascript/HTML/CSS und unterliegt daher nicht den permanenten Versionsänderungen moderner Frameworks.
Interoperabilität – die Komponenten lassen sich in allen größeren Frameworks verwenden.
Vertrautheit – viele bewährte Elemente anderer Frameworks sind in kompakter Form auch in Stencil realisiert worden.
Das Stencil-Team stellt auf GitHub eine einfache Beispiel-Webkomponente zur Verfügung, die mittels Git einfach heruntergeladen werden kann. Über NPM werden dann alle erforderlichen Module nachgeladen und installiert:
Der Quellcode der Webkomponente befindet sich im Unterordner src. Dieser wird mit dem Befehl npm start kompiliert und die erzeugte Webkomponente im Unterordner www abgelegt:
$ npm start
>@stencil/starter@0.0.1 start /home/onno/Development/Stencil/my-app
>npm run dev
>@stencil/starter@0.0.1 dev /home/onno/Development/Stencil/my-app
>sd concurrent "stencil build --dev --watch""stencil-dev-server"
[34:13.0] build, dev mode, started ...
[34:13.0] compile started ...
[34:15.2] compile finished in 2.18 s
[34:15.2] bundle styles started ...
[34:15.2] bundle modules started ...
[34:15.3] bundle styles finished in 146 ms
[34:15.4] bundle modules finished in 220 ms
[34:15.4] build finished, watching for changes... in 2.45 s
Unsere erste Stencil-Webkomponente ist damit schon fertig. Schauen wir sie uns an!
Um die Komponente mit einem Browser anzuschauen, muss der Inhalt des www-Ordners samt der index.html-Datei durch einen Server ausgeliefert werden. Dazu kann der Inhalt des www-Ordners einfach auf einen Server übertragen werden. Noch einfacher ist es mit dem kleinen Webserver, den Stencil gleich mitliefert und der automatisch nach dem obigen Kompilierungsprozess gestartet wird. Dieser liefert über die URL http://localhost:3333/ die Webkomponente an einen Browser aus und erneuert die Ausgabe auch automatisch nach jeder Änderung am Code.
Die Ausgabe der Beispiel-Webkomponente in zunächst wenig spektakulär:
Dahinter verbirgt sich aber ein höchst flexibler Mechanismus, mit dessen Hilfe auch deutlich komplexere Darstellungen komfortabel umgesetzt werden können. Im Folgenden werfen wir einen Blick auf den sich hinter der Ausgabe verbergenden Quellcode.
Oben im Header wird die Webkomponente app.js geladen, welche durch den Stencil-Kompiler erzeugt wurde. Diese befindet sich natürlich nicht im src-Ordner, sondern wurde von Stencil unter www/build/ abgelegt. Beim Erzeugen der Webkomponente wurde auch die index.html-Datei aus dem src-Ordner in den www-Ordner kopiert.
Die Webkomponente wird in der index.html ganz einfach durch das dazu gehörige Custom Element my-name eingebunden:
<my-name first="Stencil" last="JS"></my-name>
Hier werden auch gleich zwei Input-Parameter für die Webkomponente gesetzt: first und last, welche durch die Komponente ausgewertet werden. Die dazu gehörige Programmlogik der Webkomponente steckt in der Datei my-name.tsx, welche sich im Ordner src/my-name/ befindet. Die Datei trägt die Endung .tsx, da sie TypeScript- und JSX-Code enthält:
import { Component, Prop } from '@stencil/core';
@Component({
tag: 'my-name',
styleUrl: 'my-name.scss'
})
exportclass MyName {
@Prop() first: string;
@Prop() last: string;
render() {
return (
<p>
Hello, my name is {this.first} {this.last}
</p>); }}
In der ersten Zeile werden jene Teile aus dem Paket @stencil/code importiert, die wir für die Datei benötigen. Das ist zunächst der @Component()-Dekorator. Dekoratoren (engl. decorators) wurden mit TypeScript bzw. ECMAScript6 eingeführt. Mit ihrer Hilfe kann einer Klasse zusätzliche Meta-Angaben hinzugefügt werden. Hier ist dies der Name des HTML-Elements der Komponente (tag) sowie die für die Optik der Komponente zuständige SASS-Datei (styleURL). Aus der SASS-Datei erzeugt der Kompiler dann die CSS-Datei.
Es folgt die Definition der Klasse MyName, welche mit dem Setzen zweier @Prop()-Dekoratoren beginnt. Mit diesen werden der Klasse zwei Argumente first und last zur verfügung gestellt, die öffentlich (public) sind und deren Werte im Custom Element gesetzt werden. Da dies in TypeScript geschieht, wird den Argumenten auch der Typ (hier: string) mitgegeben.
Schließlich wird in der render()-Funktion die Ausgabe der Webkomponente definiert. In diesem Fall ist dies ein Absatz mit einem einzigen Satz, bei dem die beiden Argumente first und last eingesetzt werden. Die Funktion render() enthält eine deklarative Template-Syntax wie sie mit JSX eingeführt wurde. Die mit @Props() definierten Eigenschaften werden von der Komponente überwacht und bei jeder Änderung der Werte wird die render()-Funktion erneut aufgerufen.
Die Ausgabe kann auch Entscheidungen, Schleifen und weitere Eingaben enthalten. Einen Überblick gibt die Stencil-Webseite. Auf der Webseite werden auch die weiteren Elemente der Stencil-API erläutert:
@Component() – wie oben erwähnt, werden damit der tag des Custom Elements sowie das zu verwendende style sheet festgelegt.
@Prop() – erzeugt eine Eigenschaft der Komponente, die vom Custom Element aus gesetzt wird ist. Änderungen bewirken ein erneutes Rendern der Komponente.
@State() – erzeugt einen internen Zustand der Komponente, der nicht von außen zugänglich ist. Änderungen bewirken ein erneutes Rendern der Komponente.
@Method() – wird verwendet, um eine Methode der Komponente zu veröffentlichen, d.h. dem Custom Element zugänglich zu machen.
@Listen() – Hört (listen) auf Events, die von Kinderkomponenten ausgedendet werden.
@Element() – gibt eine Instant eines HTML-Elementes zurück, um es der Komponente zugänglich zu machen.
Darüber hinaus verwendet Stencil weitere Konzepte wie Hooks, die zu definierten Punkten im Lebenszyklus einer Komponente aufgerufen werden, serverseitiges Rendering oder auch einen eigenen Router, über den Webkomponente über festgelegte URL-Pfade gestartet werden können.
Progressive Web Apps sind der neue heilige Gral in der Welt der Webanwendungen. Seit Google den Begriff 2015 geprägt hat, gewinnt das Konzept der PWAs mehr und mehr an Popularität. Es könnte dabei die Art und Weise, wie wir Webanwendungen entwickeln und verwenden, in den kommenden Jahren vollständig umkrempeln.
Die Idee hinter PWAs: Statt eine Anwendung (beispielsweise einen Onlineshop) auf einer Webseite und parallel als Apps für verschiedene Plattformen wie iOS oder Android anzubieten – samt dem damit verbundenen mehrfachen Entwicklungsaufwand – wird die Anwendung in eine einzige, plattformunabhängige Progressive Web App gesteckt.
Aus Anwendersicht ist eine PWA nichts weiter als eine App mit einem responsiven Layout, die auch offline funktioniert und die per Browser über eine URL erreichbar ist, aber gleichzeitig auch dauerhaft auf dem Homescreen von mobilen Geräten gespeichert werden kann.
Aus Entwicklersicht ist eine PWA ein Bündel aus HTML5, CSS3 und JavaScript, bei dem ein sogenannter Service Worker die Offline-Funktionalität bereitstellt und die über HTTPS mit einem Server kommuniziert.
Im Folgenden sollen kurz die Eigenschaften von PWAs und ihre möglichen Folgen für die App-Entwicklung skizziert werden. Am Ende werden verschiedene Tools und Frameworks für die Entwicklung von PWAs vorgestellt.
Eigenschaften von PWAs
Schauen wir wie Google Progressive Web Apps definiert, finden wir unter anderem eine Checkliste für PWAs, wie Google’s Lighthouse-Tool sie vorgibt, mit dem u.a. die Performance und Qualität von PWAs getestet werden kann. Zusammengefasst hat eine PWA folgende Eigenschaften:
Progressivität
Eine PWA läuft auf jedem Gerät und in jedem Browser (so jedenfalls die Idee; bisher noch nicht überall erreicht, siehe weiter unten).
Responsive
Das Layout der PWA passt sich an die Bildschirmauflösung von Desktop-Monitoren, Tablets und Smartphones an.
Offline-Funktionalität
Die PWA funktioniert grundsätzlich auch offline oder mit einer schlechten Internetverbindung.
Sicherheit
Die PWA wird über verschlüsseltes HTTPS ausgeliefert und kommuniziert auch ausschließlich über HTTPS.
Push-Nachrichten
Benutzerinnen und Benutzer können per Push-Nachrichten auf die PWA aufmerksam gemacht werden.
Installierbarkeit
PWAs lassen sich direkt aus dem Browser heraus auf dem Homescreen installieren. Sie benötigen daher keinen App-Store mehr.
Verlinkbarkeit
einfache Verbreitung über eine URL. Keine komplizierte Installation mehr.
Was haben PWAs für Folgen?
Wenn mehr und mehr Funktionalität in die Browser übertragen wird, inklusive Hardware-Unterstützung wie das Auslesen der Kamera und anderer Sensoren wie zum Beispiel des Standardortes über GPS und dergleichen, sind Progressive Web Apps auf dem besten Weg, einige herkömmliche Technologien überflüssig zu machen. Bis heute sind noch SDKs für native Apps oder beispielsweise Apache Cordova/Phonegap für hybride Apps notwendig, um einer App diese Hardware-Unterstützung zu bieten. Sobald dies über den Browser angeboten wird, können PWAs die meisten Aufgaben herkömmlicher Apps übernehmen.
Den Gedanken zu Ende gedacht könnte die Zukunft von Betriebssystemen für mobile Geräte allein aus einer Kombination aus Kernel und Browser bestehen.
Bisher wurden Apps primär über die App-Stores für Android und iOS ausgeliefert. Eine PWA, die direkt über den Browser heraus dauerhaft installiert werden kann, macht solche Stores überflüssig. Dazu kommt der große Vorteil, dass PWAs direkter und damit schneller aktualisiert werden können. Das geht bis zu der Idee, dass für kleine Änderungen auch nur die entsprechenden Komponenten aktualisiert werden statt die ganze App auf einmal.
PWAs ermöglichen einen direkteren Kontakt zwischen Entwicklerinnen und Entwicklern mit den Usern ihrer Apps.
Progressive Web Apps basieren auf zwei durch das des WWW-Konsortium W3C festgelegte Spezifikationen: dem Web App Manifest und den Service Workers. Praktisch wird eine PWA in HTML5, CSS3 und JavaScript umgesetzt, wobei der Service Worker die Offline-Funktionalität bereitstellt.
Der Service Worker ist eine in JavaScript geschriebene Browsertechnologie, die im Hintergrund läuft und vor allem zwei Funktionen vorhält: Die Speicherung von Daten und Inhalten unabhängig von einer Internetverbindung sowie die Annahme von Push-Nachrichten, die von einem Server gesendet werden.
Der Service Worker ist auch der Grund dafür, dass PWAs noch nicht auf allen Browsern lauffähig sind. Dies betrifft vor allem die Browser Safari und Edge, für die aber bereits an einer Implementierung des Service Workers gearbeitet wird. Der aktuelle Stand des Supports für verschiedene Browser kann auf der Webseite Is Service Worker Ready Yet? abgerufen werden.
Zusätzlich kann die Entwicklung durch die Verwendung von Frameworks erleichtert werden, die viele der benötigten Funktionen und Elemente schon von Haus aus mitbringen:
Angular
ist ein TypeScript- bzw. JavaScript-basiertes Webapplikationsframework für das Front-End. Um Verwechselungen zu vermeiden wird der Vorgänger statt Angular 1 mittlerweile AngularJS genannt, während die aktuelle Version schlicht Angular heißt. Angular wird von Einzelpersonen und Unternehmen unter der Führung Googles entwickelt und steht unter der freien MIT-Lizenz. Mehr dazu auf der Angular-Webseite.
Polymer
ist eine freie, unter der BSD-Lizenz stehende JavaScript-Bibliothek für die Entwicklung von Webanwendungen mittels Web-Komponenten. Polymer wurde im Mai 2015 von Google veröffentlicht und mittlerweile in verschiedenen Google-Diensten eingesetzt. Mehr dazu auf der Polymer-Webseite.
Vaadin
ist ein freies, unter der Apache-Lizenz stehendes Framework mit Fokus auf der Entwicklung von Web-Komponenten, wobei die Logik vor allem in Java auf der Serverseite untergebracht ist. Mittels Polymer können Vaadin-Komponenten in PWAs integriert werden. Mehr auf der Vaadin-Webseite.
Ganz frisch veröffentlicht ist Stencil, ein Kompiler mit dem plattformunabhängige Web-Komponenten für PWAs erstellt werden können. Mehr dazu auf der Stencil-Webseite. Stencil wurde im August 2017 auf dem Polymer Summit vom Ionic-Team vorgestellt, die mit zu den PWA-Vorreitern gehören.
Zusammengefasst
PWAs haben das Potenzial, die Art und Weise wie wir Apps entwickeln und benutzen zu revolutionieren. Sollten PWAs sich in der breiten Masse durchsetzen, wird dies zudem einen starken Einfluss auf das Betriebssystem auf mobilen Geräten haben und nicht zuletzt völlig neue Vertriebswege von Apps abseits der althergebrachten Stores auftun.
