Wie kann ich meine Software zukunftssicher machen und für meine Nutzer auf möglichst vielen Devices und Plattformen zur Verfügung stellen? Schließlich besitzen Endanwender im privaten Leben in der Regel mehr als ein elektronisches Gerät, mit dem sie arbeiten – oder zumindest Daten sichten und bearbeiten. Windows ist schon lange nur noch eines unter vielen Betriebssystemen. Die Tablets und Smartphones dieser Welt haben zudem mittlerweile auch im Geschäftsumfeld den Siegeszug angetreten. Ein Umstand, dem Softwarehersteller realistisch entgegensehen müssen.

Mit Christian Weyer, Microsoft MVP und Google Developer Expert, sprechen wir unter anderem über sein Verständnis von Cross-Plattform-Entwicklung, warum Tools wie Electron und Cordova so gut zu Angular passen, Services und Backend-Anforderungen und über den Release-Cycle von Angular.

Cross-Plattform ist mehr als „mal eine App für verschiedene Betriebssysteme erstellen“. Was ist Cross-Plattform aus deiner Sicht, was macht echtes Cross-Plattform aus?

Christian Weyer: Cross-Plattform umfasst die Betrachtung heute zu unterstützender Plattformen und regt dazu an, den Blick (so weit wie möglich und sinnvoll) nach vorne gerichtet zu halten: Was könnte künftig noch als Ausführungsumgebung dazu kommen? Und vor allem: Wer wird die Benutzerbasis meiner Anwendungen sein? Hier muss man sich Gedanken machen, welche Plattformen (Betriebssysteme) und Gerätegrößen (Formfaktoren) die zu bauende Anwendung als Ziel haben soll. Zusätzlich muss man sich überlegen, welche technologische Basis dies erfüllen könnte. Idealerweise möchte man große Teile (wenn nicht sogar 100 Prozent) des Codes nur einmal schreiben müssen. Dabei sollte jedoch– je nach Use Cases – nicht vergessen werden, auch die Plattform-immanenten Bedienungskonzepte zu beachten und auch etwaige native Integrationen wie Hardwarezugriff mit in die Betrachtung aufzunehmen.

In den vergangenen Jahren hat sich für die „Write Once, Run Anywhere“-Analogie das Web als besonders vielversprechende Basis herausgestellt – vor allem, weil künftige Generationen (von Benutzern und Entwicklern) sehr stark auf das Web setzen und noch weiter setzen werden. Aber auch andere Technologien wie Qt oder .NET mitsamt Xamarin, UWP und Unity sind mögliche Kandidaten – je nach Anwendungsfällen und konkreten Anforderungen.

Für unsere Projekte und Kunden war jedoch in der Tat immer der webbasierte Ansatz der zu präferierende. Vor allem im Hinblick auf die positiv rasante Weiterentwicklung des Webs in Richtung Progressive Web-Apps (PWA) ist ein Investment in Webtechnologien wie JavaScript/TypeScript, CSS3 Flexbox und SPA-Frameworks sicherlich lohnenswert. Nicht zuletzt durch das intensive Vorantreiben von Web Assembly werden wir zusätzlich zu den Web-nativen JavaScript-basierten Ansätzen auch mehr und mehr Cross-kompilierte Tools sehen. So experimentiert bspw. Microsoft aktuell mit .NET und Web Assembly – wir werden sehen, inwieweit sich das bewähren wird.

Insgesamt bin ich der Meinung: Das Web hat „gewonnen“ ?

Der Bedarf für echtes Cross-Plattform ist inzwischen auch immer häufiger beim Kunden anzutreffen. Welche Geschäftsmodelle bilden die Kunden damit derzeit ab und wo, denkst du, führt der Weg noch hin?

Christian Weyer: Wir als Technologieberater unterstützen die unterschiedlichsten Branchen in der Konzeption und auch Umsetzung von echt Cross-Plattform-fähigen Anwendungen auf Basis leichtgewichtiger Service-basierter Architekturen. In der Tat lässt sich hier keine wirkliche Eingrenzung vornehmen: Egal ob Einzelhandel, medizinisches Umfeld, Banken, Versicherungen, ob klassische Enterprises oder aber ISVs – alle kommen und sehen einen enorm hohen Bedarf an eben diesen Lösungen. Was in Zukunft immer wichtiger und zentraler werden wird, ist weniger „vorne“ – also im Frontend – zu suchen, sondern eher „hinten“, also im Backend. Doch das ganze Themengebiet Service-Orientierung, Microservices & Co. sowie Cloud wird immer wichtiger – für Enterprises und ISVs, wenn auch mit jeweils unterschiedlichen Beweggründen, Ausprägungen und Schwerpunkten.

In deiner Session „Echte Cross-Plattform-Anwendungen mit Angular, Cordova und Electron“ erklärst du, wie man mit den genannten Tools Applikationen für alle relevanten Plattformen bauen kann. Erklär uns, warum ausgerechnet Tools wie Electron und Cordova so gut zu Angular passen.

Christian Weyer: Die eigentliche Ziellösung (langfristig) sollte meiner Meinung nach sein, alles über Webtechnologien und den Browser realisieren zu können. Soweit sind wir aber noch nicht. Mit den Progressive Web-Apps (PWA) entsteht gerade ein Quasi-Standard getrieben von Google, Mozilla und Microsoft, bei dem aktuell jedoch vor allem noch Apple fehlt (es gibt hier jedoch erste Lebenszeichen, es bleibt also spannend). Bis wir mit PWAs dort sind, dass die Browser auch native Funktionen vollumfänglich mit einem entsprechenden Sicherheitsmodell auf allen Plattformen realisieren, bedarf es für gewisse Anwendungsfälle immer noch der von dir genannten Tools. Ich möchte Cordova und Electron mal „Super Polyfills“ nennen.

Daher würde ich sagen: Angular passt also nicht notwendigerweise gut zu den Tools, sondern die Tools passen gut zu Angular und allen SPA Frameworks. Wir verwenden Angular in unseren Kundenprojekten, da wir sehr viel mit .NET/C#-Entwicklern und auch mit Java-Developern zu tun haben. Bei dieser Zielgruppe ist es in der Tat viel einfacher, Angular mit TypeScript zu vermitteln und in kurzer Zeit produktiv einsetzbar zu machen als bei anderen Frameworks.

Lass uns einen genaueren Blick auf Angular werfen. Seit Ende 2016 und beginnend mit Angular 4 hat sich das Angular-Team für die Major-Versionen einen Release-Cycle von sechs Monaten verordnet. Im März wurde Angular 4 final, vor kurzem ist die erste Beta von Angular 5 erschienen. Wie siehst du aus Enterprise-Sicht diese Entwicklung?

Christian Weyer: Dies ist ein heißes Thema. Ich habe hierzu auch meine Thinktecture-Kollegen zu ihren Erfahrungen aus der Projektpraxis befragt. In der Tat sind wir allgemein der Meinung, dass man, wann immer möglich, mit den neuen Versionen „mitläuft“ – nicht zuletzt deshalb, weil man sonst auf die Zeit hin gesehen aus den Security-Fixes rausfällt. Wir finden es schwierig, Versionen spät zu aktualisieren, weil man dann den Aufwand nicht gut einschätzen kann. Daher würden wir eher direkt mit jeder Version aufsteigen. Hierbei könnte eine Strategie wie folgt ausschauen: Am besten unmittelbar nach einem Release der eigenen Software sofort alle Dependency-Updates nachziehen. Damit hat man bis zum nächsten Release Zeit ggf. auftretende Probleme zu fixen. Wenn man das wirklich jedes Mal macht, ist der Aufwand überschaubar. Gilt natürlich nur, sofern der eigene Release-Zyklus schneller oder zumindest nicht viel langsamer als der Zyklus der Abhängigkeiten (wie Angular) ist. Dieser gesamte Vorgang ist zudem noch geschmeidiger zu gestalten, wenn man automatisierte Tests hat und daher Breaking Changes gleich sprichwörtlich rot vor Augen gehalten bekommt.

Wer nicht direkt auf eine höhere Version gehen kann oder will, für den lohnt sich ein Blick auf die LTS-Versionen von Angular. So wird bspw. Angular 4 bis Oktober 2018 supported: https://github.com/angular/angular/blob/master/docs/RELEASE_SCHEDULE.md – long-term-supported-lts-versions

Geschrieben von: Stefanie Schäfers

Stefanie Schäfers studierte zunächst Anglistik in Marburg und machte anschließend ihren Masterabschluss im Bereich Creative and Cultural Business an der Glasgow Caledonian University in Glasgow, Schottland. Seit August 2014 ist sie als Redakteurin in der Redaktion des PHP Magazins und des Entwickler Magazins bei Software & Support Media tätig. Zuvor absolvierte sie bereits mehrere Praktika in Online-Redaktionen und Verlagen.