Vorne wie hinten: Client- und Server-Cross-Plattform

Inhaltsverzeichnis

Die Sommerpause ist vorbei – stürzen wir uns also frisch in den Cross-Plattform-Sumpf und beleuchten zunächst die Optionen für die Client- und die Server-Seite. Ob es wirklich sumpfig ist? Ob es wirklich schmutzig wird? Ich glaube nicht. Doch will die Wahl überlegt sein, basierend auf unterschiedlichen Faktoren.

"Cross-Plattform" ist ja in aller Munde. Gerne möchte ich sensibilisieren, was mit Cross-Plattform gemeint ist, und warum man es macht beziehungsweise benötigt – und zwar sowohl auf der Client- als auch auf der Serverseite. Und dass das Ziel der einen Seite nicht notwendigerweise das Ziel der anderen Seite sein muss. Dabei ist mein persönlicher und beruflicher Fokus immer die klassische Business-Anwendung. Ich rede hier nicht von Spielen oder anderen "Randgruppen".

Ist Cross gleich Cross?

Nehmen wir uns einmal Java als wohl die prominenteste Technologieplattform, die uns Betriebssystem- und Basisplattformunabhängigkeit versprochen hat, als Exempel. Java wollte das allumfassend tun: auf dem Client wie auf dem Server.

Wirklich gelungen ist es nur auf der Serverseite. Das hat seine Gründe, und diese Gründe liegen in den unterschiedlichen Zielstellungen von Cross-Plattform.

Reichweite & Zukunft

"Vorne" auf dem Client kommt es primär – wie im ersten Blog-Beitrag versucht wurde, bildhaft darzustellen – auf die maximale Reichweite (neudeutsch: Reach) in alle verfügbaren Basisplattformen an. Dabei muss vor allem auch mit der Ungewissheit kokettiert werden, dass das Rad der Entwicklung sich immer weiter dreht und neue Plattformen oder zumindest Formfaktoren und Device-Ausprägungen hinzustoßen werden. Diese Ungewissheit rührt originärerweise von der Benutzerschar der jeweiligen Anwendungen her.

Betrieb & Lizenzen

"Hinten", also auf der eher unsichtbaren Serverseite, ist die Lage anders. Hier hat man in den meisten Fällen keine Ungewissheit, welches OS man heute hat und welches morgen dann in aller Munde ist. Vielmehr sticht hier hinsichtlich des Aspekts der Cross-Plattformfähigkeit der Trumpf der optimierten Betriebsmöglichkeiten und sicherlich auch das Ass der verbundenen Lizenzbedingungen und -kosten.

Technologien für "hinten"

Dann lassen Sie mich einen Blick auf die heute üblichen Verdächtigen im Serverumfeld werfen. Die folgende Liste ist in keiner Weise basierend auf echten Marktanteilen oder aber persönlichem Gusto erstellt worden, von Vollständigkeit freilich ganz zu schweigen. Sie dürfte aber das aktuell gegenwärtige Ökosystem ganz gut treffen (und C++ steht der Vollständigkeit halber mit auf der Liste).

Server-Technologien:

• C++
• Java
• .NET/Mono
• Node.js

Wie bereits gesagt: Java ist hier wohl der Platzhirsch. Gefühlt auf alle Fälle, wenn man sich die Durchdringung in deutschen Unternehmen betrachtet. Java ist lange auf dem Markt und sehr erprobt. Die JVM ist solide und gestählt für diverse Betriebssysteme – was will man mehr für den optimierten Betrieb seiner Server-Anwendungen?

Interessant ist Microsofts .NET im Server-Umfeld: Seit jeher konnte man mit der Open Source-Parallel-Implementierung der CLR (Common Language Runtime) und Teile des .NET Frameworks namens Mono serverseitige Anwendungen auf Windows, Linux und OS X laufen lassen. Seit einiger Zeit unterstützt Microsoft das Open-Source-Projekt sogar aktiv und bringt somit Leben in die Bude. Zudem bastelt Microsoft selbst quelloffen an .NET Core – einer schlanken und leichtgewichtigen Neuimplementierung gewisser .NET-Funktionen – und stellt diese von sich aus für Windows, Linux und ebenfalls OS X bereit. Sowohl die Reife und die Stabilität von Mono und vor allem von der CoreCLR reichen derzeit nicht an die JVM heran – aber vielleicht heilt die Zeit ja einige Wunden.

Ein (nicht mehr ganz so) neuer Stern am Cross-Plattform-Himmel ist Node.js. Trotz ein paar Monaten der Identitätssuche findet Node.js immer mehr Anhänger, auch jenseits der Welt der Entwickler-Tools, aus der es ja schon seit längerer Zeit nicht mehr wegzudenken ist. Das etwas andere Konzept der Node.js Engine hinsichtlich der Single-Threaded-Ausführung serverseitigen JavaScript-Codes findet in der Tat zunehmend mehr Anhänger. Sowohl Unternehmensentwickler als auch ISVs (Independent Software Vendors) lugen immer häufiger auf den "New Kid" im Block. Zu Recht, wie ich meine.

Der Vollständigkeit halber möchte ich noch die Idee der Container-Anwendungen, wie sie etwa Docker realisiert, ansprechen. Container helfen bei einer homogenisierten Bereitstellung und Versionierung – jedoch soll mein Fokus in diesem Beitrag auf Implementierungen mit den Basistechnologien liegen, die man dann beispielsweise per Docker verteilen kann.

Technologien für "vorne"

Spannend wird die ganze Geschichte, wenn wir uns den heiligen Gral der modernen Business-Software-Entwicklung anschauen: die Frontends, die Clients. Welche offensichtlichen realistischen Optionen bieten sich heute im Jahr 2015? Auch diese Liste ist hoffentlich bezüglich der Elemente und der Reihenfolge nicht zu eingefärbt :

Client-Technologien:

• Java
• Xamarin/C#
• HTML5 & JavaScript

Und wieder Java. Ich denke, ich kann für die Mehrheit der Leser konstatieren, dass die "Write Once, Run Anywhere"-Idee von Java ganz gut gedacht, aber weniger gut gemacht war. Es ist am Ende nicht aufgegangen. Ähnlich erging es dann in der Folgezeit auch Flash und Microsofts Silverlight. Allesamt setzten sie sehr stark auf das Vorhandensein von Browser-Plug-ins. Als vor allem Apple beschlossen hatte, dass weder auf dem iPhone noch auf dem Apfel-Tablet Plug-ins im Browser zum Laufen kommen werden, war dieser Ast angesägt – bis er schließlich abgebrochen ist, denn mittlerweile sind die respektiven Plug-in-Schnittstellen in den aktuellsten Ausprägungen der großen Browser bereits deaktiviert.

Eine Multi-Plattform-Option für .NET und C# gewöhnte Entwickler bietet sich mit Xamarin an. Hier kann man C#-Code schreiben und über eine Cross-Kompilierung Apps für iOS, Android und Windows ausspucken lassen (es gibt auch eine Option für OS-X-Anwendungen). In meinen Augen ist dieser Ansatz nicht Cross-Plattform, sondern eben nur Multi-Plattform – denn alle wichtigen Plattformen erreiche ich nicht.

Das Web als omnipräsente und omnipotente Plattform

Und mit die wichtigste – heute und vor allem in der Zukunft – ist der Browser. Und diese Plattform ist omnipräsent und wird immer leistungsfähiger. Mit HTML5- und JavaScript-Ansätzen im Browser (oder einer Browser-Engine) lassen sich in der Tat vollumfänglich echte Cross-Plattformen-Anwendungen entwickeln. Sei es rein für den oder die diversen großen Browser – oder mit entsprechenden Toolkits wie Apache Cordova oder NW.js als native mobile App oder aber auch Desktop-Anwendung.

Mit HTML5 kann man komplett offline-fähige Clients schreiben, Frontends, die einer nativer Anwendung performancemäßig in nichts nachstehen. Man kann 2D- und 3D-Visualisierungen realisieren. Man kann vieles, wenn nicht gar alles machen mit den heutigen modernen Webtechniken. Und die großen Hersteller investieren weiterhin strategisch in die Weiterentwicklung der Browser.

An dieser Stelle würde ich gerne der Vollständigkeit wegen auf Remoting-Techniken wie RDP, Citrix oder Ahnliches hinweisen – nur liegen diese nicht im Fokus dieses Blog-Beitrags. In diesem Blog werde ich in der Folge auf hoffentlich alle interessanten Use Cases, Architekturthemen, Technologien und Lösungen aus dem Cross-Plattform-HTML5-Umfeld eingehen. So, dann: Voran in die neue Cross-Plattform-Welt. Und "Happy Cross-Plattform-ing". ()