"Angular ist eine Plattform. Es funktioniert auch in Umgebungen ohne DOM."

Julian Steiner: Das ist natürlich nur der provokante Titel. Ich greife hier Miško Heverys Klarstellung aus einer Keynote vom letzten Jahr auf. Angular ist eine Plattform, und das Web-Framework ist nur ein Teil dieser Plattform.

Angular vereint viele Funktionen unter einem Dach, die in der Vorversion noch durch externe Werkzeuge und Bibliotheken geliefert wurden. Zum Beispiel ein Kommandozeileninterface, i18n oder sogar fertige UI-Widgets mit Angular Material.

Zur richtigen Plattform wird es dadurch, dass Angular durch ein höheres Abstraktionslevel in Umgebungen funktioniert, die kein DOM (Document Object Model) und keine Browser-APIs bereitstellen. Ich kann also mit Angular auch für völlig andere Umgebungen als das Web entwickeln. Der Vorteil ist, dass Entwicklungssprache und Framework-Konzepte wie DI (Dependency Injection) über die Plattformen hinweg dieselben sind. Das ermöglicht es Webentwicklern, viel Wissen und zu einem großen Teil auch Code direkt für die Entwicklung auf anderen Plattformen zu übernehmen. Und genau das werde ich in meiner Session praktisch zeigen.

Steiner: Doch, es eignet sich sogar sehr gut dazu, aber eben nicht nur.

Zur verbesserten SPA-Entwicklung sind gegenüber AngularJS, also der 1.x Versionen, viele Probleme neu angegangen worden. Das umständliche Zusammenspiel aus Controllern, Scope und Direktiven ist enorm vereinfacht worden. Auch hat sich die Perfomance durch die Einführung des Virtual- oder Shadow-DOMs und eines unidirektionalen Databindings per Default enorm verbessert.

Und mit dem CLI (Command Line Interface) und den verschiedenen IDE-Integrationen gibt es auch noch einmal einen erheblichen Produktivitätsschub.

Ich behaupte, dass der primäre Fokus von Angular nach wie vor das Web ist, gerade eingedenk der Herkunft Angulars als Basis für Googles internes CRM.

Steiner: NativeScript ist eine Laufzeitumgebung, um mobile Apps mit JavaScript zu entwickeln. Im Gegensatz zu Hybrid-Apps wird keine Webview genutzt, sondern es werden vollständig native Objekte und Darstellungselemente erzeugt. Dafür wird der JavaScript-Code in einer JavaScript VM ausgeführt, V8 auf Android oder JavaScript Core auf iOS. NativeScript (und auch ReactNative) sind also keine Cross-Compiler nach Android-Java oder ObjectiveC/Swift. Die Magie geschieht in den gepatchten JavaScript VMs, die einen Zugriff auf die nativen Instanzen ermöglichen und verwalten.

Dieser Ansatz bietet eine radikal verbesserte Performance im Vergleich zu klassischen Hybridapps – der Overhead durch die JS VM ist gering und die nativen Views laufen butterweich, wo Webviews häufig unter Verzögerungen leiden.

Keine Webview bedeutet aber eben auch kein verfügbares DOM, also erstmal keine Chance Web-Frameworks für die Applikationsstruktur zu nutzen. Nun bietet Angular ein virtuelles DOM und hat auch Hooks vorgesehen, um andere Renderer vor diese virtualisierten Elementbäume zu schalten.

Das ist genau der Schritt, den Progress mit NativeScript gegangen ist. Nachdem Google früh im Angular2-Entwicklungsprozess auf das NativeScript-Team zugegangen war, entwickelte das Team einen Angular-Renderer für NativeScript-Markup. Man kann NativeScript-Apps vollständig in Angular entwickeln, und benutzt dafür in den Komponententemplates kein klassisches Browser-HTML, sondern NativeScript-Markup. Es wird somit also das Plattform-Versprechen erfüllt und man kann einen großen Teil des Angular-Codes auf allen Umgebungen wiederverwenden.

Steiner: Einen? Viele! Mein erster Tipp für Tooling-verwöhnte .NET-Entwickler: Akzeptiere, dass die Web-Entwicklungswelt einfach heterogener und kleinschrittiger geworden ist. Den vollen Überblick kann und muss man auch nicht behalten. Der große Vorteil ist, dass durch die stark erhöhte Modularität eine falsche Technologiewahl an einer Stelle, nicht mehr unbedingt projektgefährdend ist.

Erstellt Metriken! Die Zukunftsfähigkeit von Open-Source-Projekten lässt sich sehr gut an öffentlichen Zahlen ablesen wie zum Beispiel die Anzahl der Stars, Commits, Contributors oder Issues auf github.

Versuche die Philosophie und das Ökosystem hinter der Technologie zu verstehen! Zum Beispiel unterscheidet sich Angular mit seiner „Alles-aus-einer-Hand“-Philosophie deutlich von React, das eigentlich nur eine Bibliothek für den UI-Layer einer SPA ist. Dieser Unterschied alleine gibt schon eine gute Indikation, für welchen Projektcharakter sich der jeweilige Ansatz eignet.

Generell sind mir Technologieauswahlprozesse häufig viel zu lösungsorientiert und nicht problembezogen genug. Man sollte funktionale und nicht-funktionale Anforderungen ausreichend ermitteln und dann erst Technologie recherchieren. Natürlich spielen auch andere Faktoren eine Rolle: Was beherrscht mein Team? Was könnte vielleicht in einem Piloten Spaß machen? Was lohnt sich zu evaluieren?

Auf der Web Developer Conference, die am 9. und 11. Oktober in München stattfindet, hält er eine Session mit dem Titel Angular ist kein Web-Framework.