Interview mit Christian Weyer

„Angular 2 & Co. meistern besser, woran Java scheiterte: Write once, run anywhere“

Redaktion JAXenter
weyer_christian

Christian Weyer

Schnelllebig geht es her, in der Welt der Webentwicklung. Doch dass Angular 2, die Neuauflage Googles Client-seitigen JavaScript-Frameworks für Single-Page-Anwendungen, das nächste große Ding wird, daran wird wohl kein Webentwickler zweifeln wollen. Wir beleuchten auf JAXenter den aktuellen Entwicklungsstand von Angular 2 in einer Themenwoche. Zum Start bringt uns Christian Weyer auf den aktuellen Stand und erklärt, warum mit Angular das alte Paradigma „Write Once, Run Anywhere“ endlich Wirklichkeit werden könnte.

„Write once, run anywhere“ – dieses Motto hatten sich die Urväter von Java einst auf ihre Flaggen geschrieben. Dass der Versuch, dies zu bewerkstelligen, scheiterte, hat Entwickler nicht davon abgehalten, weiter davon zu träumen. Dank neuer Frameworks und Technologien wie Angular 2 und HTML5 scheint die Verwirklichung in greifbare Nähe zu rücken. In seiner W-JAX-Session zeigt unser Speaker Christian Weyer, wie man mit Tools wie Cordova und Electron in Angular 2 echte Anwendungen für alle relevanten Plattformen und Devicegrößen bauen kann. Im Interview mit JAXenter beleuchtet er die Hintergründe.

 

JAXenter: Eine einzige Codebasis für alle Client-Plattformen: Das war einst der Traum der Java-Welt mit ihrem Bytecode-Konzept. Weshalb sollte jetzt ausgerechnet HTML5 (+ Cross-Plattform-Tools) diesem Traum näherkommen als Java?

Christian Weyer: Browser sind ja schon seit einiger Zeit überall zu finden. Jeder von uns nutzt vermutlich mehrmals am Tag einen (oder vielleicht sogar mehrere) Webbrowser. In der Regel tun wir das zum „Surfen“ auf Webseiten – und finden das auch alles ganz normal und natürlich. Was sich seit einiger Zeit geändert hat, ist die Tatsache, dass man mit HTML5-basierten Ansätzen und entsprechenden JavaScript-Frameworks nun „echte“ Anwendungen bauen kann, die im Browser laufen.

Man muss nicht mehr unbedingt auf die native Ebene runtergehen. Java hat damals versucht, mit Bytecode und einer Ausführungsumgebung (JVM) das „Nicht-alles-nativ-schreiben-müssen“-Dilemma zu lösen – ist jedoch bekanntermaßen gescheitert. Die Tatsache, dass Java im Browser dann auch nur mit einem Plug-in funktioniert, hat diesem Ansatz vermutlich schlussendlich das Genick gebrochen – wie Flash oder Silverlight auch. 😉

Moderne Browser sind mehr als nur Markup-Anzeige-Maschinen. Es sind sehr potente und mächtige Ausführungs- umgebungen.

Moderne Browser sind mehr als nur Markup-Anzeige-Maschinen. Es sind sehr potente und mächtige Ausführungsumgebungen mit hoch optimierten JavaScript-JIT-Compilern. Zudem besitzen sie eingebaute Datenspeicher wie SQL- oder NoSQL-Datenbanken, mit denen auch komplexe Szenarien realisiert werden – bspw. eine komplette Offlinefähigkeit der HTML5-Anwendung. Alle großen Browser-Hersteller investieren viel Zeit und Geld in die Stabilisierung und Weiterentwicklung ihrer „Stöberer“.

Apropos JavaScript: Mit JS als Programmiersprache wird ja nun nicht jeder Entwickler so richtig warm. Hier steht aber eine gute Alternative zur Verfügung: TypeScript. Die Sprache wurde erfunden und wird getrieben vom „Erfinder“ von C# (und Delphi und Turbo Pascal), Anders Hejlsberg – hier steckt also durchaus profundes Wissen und sehr große Erfahrung dahinter. Diese Sprache kann von Java- und .NET-Entwicklern leicht erlernt werden und bietet dabei sowohl die Vorzüge aus der dynamischen als auch der typisierten Welt.

JAXenter: Welche Rolle spielt Angular 2 bei der Cross-Plattform-Entwicklung, also wieso ist dieses Framework besser zur Cross-Plattform-Entwicklung geeignet, als andere?

Christian Weyer: Angular 2 ist eines der oben erwähnten JavaScript-Frameworks für Client-seitige Anwendungsentwicklung. Auf Basis dieser Frameworks entwickelte Anwendungen werden landläufig auch als Single-Page Web Applications (SPA) bezeichnet. Oft sind es einfach persönliche Präferenzen, welches Framework man nutzt und welches nicht – oder ob man überhaupt ein Framework benötigt.

Bei uns (Thinktecture AG) ist es so, dass wir den SPA-Markt schon sehr lange beobachten – wir haben sogar früher ein eigenes SPA-Framework für interne Zwecke entwickelt. Und primäres Ziel als Beratungs- und Implementierungsdienstleister ist es, den Kunden eine schlüssige und hilfreiche Empfehlung aussprechen zu können. Hier kommen neben den offensichtlichen technischen Aspekten auch immer strategische Betrachtungen hinzu.

 

Aus technischer Sicht ist Angular 2 sehr stark an komponentenbasierte Frameworks aus der klassischen Desktop-Entwicklung angelehnt mit der Zielsetzung, eine hohe Produktivität zu erreichen. In Angular 2 beginnt alles mit Komponenten und es zieht sich wie ein roter Faden durch die Programmierung durch. Das Erzwingen der Nutzung und Einhaltung gewisser erprobter Design-Patterns (bspw. Dependency Injection, Auslagerung von Logik in Services, eventbasierte Kommunikation) erachte ich als große Hilfe für Entwickler. Bei der Datenarchitektur andererseits bietet Angular 2 einen Spielraum: man kann klassischerweise nach dem MVC- oder MVVM-Pattern arbeiten oder aber mehr in Richtung CQRS/Redux gehen.

Der strategische Aspekt liegt auf der Hand: Hinter Angular 2 steht Google mit einem großen Team aus Festangestellten und einer riesigen Community mit hunderten Contributors rund um das Open-Source-Projekt. Angular 2 wird auch intern bei Google eingesetzt, wodurch sich vor allem für die Stabilität und die gewünschte Performance zur Laufzeit viel Feedback aus wirklich großen Projekten ergibt.

JAXenter: Als Tools für die Cross-Plattform-Entwicklung setzt du auf Cordova und Electron. Wo liegen jeweils die Stärken dieser Werkzeuge, wo die Schwächen?

Christian Weyer: Richtig, aktuell nutzen wir diese beiden Tools für die Erzeugung nativer Anwendungsrahmen – sowohl für Mobil- als auch für Desktopplattformen. Primäres Ziel ist aber eigentlich, alles im Browser ohne native Funktionalität laufen lassen zu können. Das vereinfacht die Entwicklung, das Testen und nicht zuletzt das Deployment. Allerdings geht das nicht immer gemäß Projektanforderungen.

Auf Knopfdruck eine App bekommen, das geht nur, wenn man sie von Beginn an mit Cross-Plattform im Kopf designt.

Die Stärken von Cordova und Electron sind sicherlich, dass man in den meisten Fällen seine Anwendung als reine Web-Anwendung bauen kann und dann über einen ausgefeilten Build-Prozess zusätzlich noch mobile und Desktop-Apps herausbekommt, die man auch in den App Stores vertreiben kann und die optional auf native Plattform-Features zugreifen können. Allerdings muss die Anwendung von Beginn an mit Cross-Plattform im Kopf designt werden. Die jeweils die passenden Use Cases für Smartphone, Tablet und Desktop müssen herausgearbeitet und in der Architektur sowie dem UI berücksichtigt werden. Einfach so „auf Knopfdruck mal ’ne App bekommen“, naja das geht – aber nur, wenn man von Beginn an dieses Ziel mit bedenkt und verfolgt.

Als Schwäche könnte man sehen, dass ja intern immer WebViews – also die Kern-Engines der Browser – verwendet werden und damit kein echt-natives UI möglich ist. In der Tat stellt sich in den Kundendiskussionen heraus, dass diese (und ihre Endanwender) oftmals gar kein natives UI wollen oder benötigen, sondern vielmehr ein UI dass sich überall vertraut anfühlt, das konsistent ist von der Bedienung her und dass sich anfühlt wie „unsere Anwendung“. Ein Nachteil kann manchmal die Performance sein, vor allem auf mobilen Endgeräten. Jedoch lassen sich sowohl die WebViews als auch CSS3 & JavaScript punktuell sehr gut optimieren, um auch überall die beste Experience für den Anwender liefern zu können.

Aber eventuell werden wir ja Cordova künftig nicht mehr benötigen? Mit der Initiative der Progressive Web Apps (PWAs) sind – bis auf Apple aktuell – alle Browser-Hersteller auf dem Weg noch mehr native Features in die Browser-Engines einzubauen, sodass eine gewisse Notwendigkeit für Cordova in ein paar Jahren eventuell gar nicht mehr oder nur vermindert vorhanden ist. Bei Desktop-Lösungen könnte es auch in die Richtung gehen, da ist aber oftmals die Notwendigkeit der Integration mit lokalen OS-Features und Drittherstellersoftware mehr gegeben, und vor allem letzteres lässt sich nicht wirklich standardisieren.

JAXenter: Du bist Microsoft MVP und Google Developer Expert. Wie sieht es zurzeit beim Angular-2-Support in den aktuellen IDEs aus? Visual Studio, VS Code, evtl. auch WebStorm und Eclipse?

Christian Weyer: Das Schöne an der heutigen Situation in der Web-Welt ist ja, dass sich alle irgendwie lieb haben. Google nutzt bei Angular 2 eine Programmiersprache von Microsoft. Und Microsoft baut Features in TypeScript ein, um einem Google-Team zu helfen. Da ist es sehr angenehm, als Community-Mensch auch einen Brückenschlag machen zu können.

Wir schauen uns intern immer wieder die großen IDEs hinsichtlich der Produktivität an – bis auf Eclipse, denn da haben wir historisch einfach den geringsten Bezug zu. Bei Visual Studio ist die Unterstützung von Angular 2 und TypeScript aktuell noch nicht so, wie ich es mir wünsche. Bei Visual Studio Code ist dies schon um einiges besser und wird gewiss auch noch weiter verbessert werden. Unser momentanes Tool der Präferenz für das Programmieren von Angular-2-Anwendungen mit TypeScript ist WebStorm. Hier funktioniert die IntelliSense am besten, das Refactoring ist sehr mächtig und einfache Dinge wie Code-Navigation funktionieren einfach.

JAXenter: Angular 2 wird aller Voraussicht nach noch in diesem Jahr erscheinen. Was ist dein persönliches Highlight von Angular 2?

Christian Weyer: Oh, das ist eine fiese Frage 🙂 Aber wenn ich ein Feature herausheben möchte, dann wäre dies die offene Rendering-Architektur und -Pipeline. Der Default-Renderer in Angular 2 erzeugt Output für das DOM des Browsers. Allerdings kann man sich recht einfach eigene Renderer bauen. So geschieht das bspw. im Angular-Team selbst. Dort wird eine Lösung erstellt, um Angular-2-Code auch auf dem Server ausführen zu können. Hilfreich ist das bspw. beim optimierten Pre-Rendern von Views für das schnelle Ausliefern der Anwendung oder aber bei der Suchmaschinenoptimierung. Ein anderes Beispiel sei mit NativeScript genannt. Hier baut das Telerik-Team eine Erweiterung der Rendering Pipeline in Angular 2 ein, um aus einem speziellen Markup, das mehr an XAML erinnert, als dass es etwas mit HTML zu tun hat, native UI-Elemente für iOS und Android erzeugen und somit echt native Anwendungen erzeugen kann – die dann vor allem für diese Plattformen optimiert sind.

JAXenter: Was ist die Kernaussage deines Talks?

Christian Weyer: Ganz einfach: „Write once, run anywhere“ 🙂

weyer_christianChristian Weyer ist Gründer und Vorstand der Thinktecture AG sowie Google GDE (Developer Expert) und Microsoft MVP (Most Valuable Professional). Er spricht seit knapp zwei Dekaden auf unterschiedlichsten Softwarekonferenzen und -events weltweit – mit Leidenschaft und Engagement.
Geschrieben von
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "„Angular 2 & Co. meistern besser, woran Java scheiterte: Write once, run anywhere“"

avatar
400
  Subscribe  
Benachrichtige mich zu:
jim
Gast
„Java hat damals versucht, mit Bytecode und einer Ausführungsumgebung (JVM) das „Nicht-alles-nativ-schreiben-müssen“-Dilemma zu lösen – ist jedoch bekanntermaßen gescheitert.“ Sun ist mit dem damaligen Vorhaben „bekanntermaßen“ gescheitert? Interessant, insbesondere vor dem Hintergrund, dass Microsoft mit der CIL die Idee übernommen/abgekupfert hat, allein um das hausgemachte Sprach-Chaos in den Griff zu bekommen und eine seichte Migration hin zu modernen Sprachen zu erlauben – also noch nicht mal mit dem Ziel Plattform-Unabhängigkeit. Sun musste sicherlich feststellen, dass der Ansatz Grenzen hat, insbesondere wenn wichtige OS nicht mitziehen bzw. es nicht ermöglichen Runtimes besser einzubetten, um u.a. auf Browser-Plugins verzichten zu können. Microsofts… Read more »