Werter Leser! Seit einigen Tagen bringt die Idee eines Bloggers die Netzwelt durcheinander. Der Vorschlag lautet: Werft JavaScript weg und integriert Mono um statt JavaScript .Net als Plattform zu verwenden. Abgesehen davon, daß damit nun eine wohl definierte, typisierte, objektorientierte Sprache zur Verfügung stehen würde, stünde damit eine Sprache zur Verfügung, in der man auch große Web-Anwendungen deutlich leichter modularisierter und wiederverwertbar entwickeln kann, als das bisher der Fall ist.

In diesem Zusammenhang muß ich unweigerlich an etwas ganz anderes denken. Dazu müssen wir 15 Jahre in der Zeit zurück gehen. 15 Jahre - das bedeutet, daß damals gerade mal der Intel Pentium erschienen war. Rechner waren damals vielfach noch mit Windows 3.1 ausgestattet. Microsoft hatte gerade einen GUI-Quantensprung geschafft und Windows 95 auf den Markt gebracht. In dieser Zeit - vor 15 Jahren - erblickte die Programmiersprache Java das Licht der Welt. Das Novum: Programme werden in Bytecode übersetzt und nicht in nativen Maschinencode und von einem Interpreter ausgeführt, statt direkt vom Prozessor verarbeitet zu werden. Dem zu Grunde lag das Konzept der "Virtual Machines", also Laufzeitumgebungen, die Programme ausführen. Und warum ist das für uns interessant? Java lief im Web-Browser! Die berühmten Java Applets, die heute keine Rolle mehr spielen.

Vor 15 Jahren waren Browser einfachste Anzeigegeräte für Internetseiten, die man über HTTP holen konnte. CSS wurde zu diesem Zeitpunkt gerade noch erfunden. (Der Standard CSS1 erblickte erst 1996 das Licht der Welt.) Web-Anwendungen beschränkten sich damals primär darauf, ein bischen was interaktives eingebettet in einer Webanwendung darzustellen. (Die Vorform von Flash war gerade eben erst erfunden worden und noch nicht verbreitet.)

Über die Jahre haben sich die Dinge massiv weiterentwickelt. Ein Browser ist heute nicht mehr ein einfaches Anzeigegerät von Inhalten sondern eine Programmierplattform. Vor 15 Jahren entwickelte man Anwendungen, die man ins System installierte. Heute kann man Anwendungen entwickeln, die von einem Browser ausgeführt werden. Die Binaries dazu liegen dabei nicht mehr lokal auf der Platte sondern sind Textdateien, die auf einem Server liegen. Sie werden letztendlich in Form von HTML-Webseiten verbunden mit CSS und eingebettetem JavaScript geladen und vom Browser ausgeführt. Der Browser mutiert damit zu einer Programmausführungsplattform. Diese Programme sind Webanwendungen: Spezielle Fachanwendungen, aber auch einfach nur Online-Shops, Suchmaschinen oder Internetseiten mit Blogs, wie die, auf der Sie sich gerade befinden.

Es gibt offenkundig eine Bewegung weg von installierten Anwendungen hin zu Anwendungen, die über das Netz geladen und ausgeführt werden. Der Nachteil ist klar: Hat man kein Netz, hat man keine Anwendung. Der Vorteil liegt aber ebenfalls auf der Hand: Man spart sich die Mühe der Installation einer Anwendung.

Kehren wir zurück zu der Idee, eine .Net-basierte Laufzeitumgebung (-> Mono) in den Browser zu integrieren und statt JavaScript C# oder eine andere .Net-Sprache zu verwenden. Dies wäre ein Quantensprung: Die Laufzeitumgebung im Browser könnte dann noch deutlich komplexere Web-Anwendungen ermöglichen. Zeichenprogramme und Texteditoren, ja ganze Entwicklungsumgebungen könnten dann als Webanwendungen realisiert und direkt im Browser ausgeführt werden. Die Verlagerung weg vom Betriebssystem hin zu einem Browser als Ausführumgebung wäre dann komplett.

Allerdings haben wir hier ein Problem. Wie wir von JavaScript und CSS her kennen ist es schwierig Standards durchzusetzen. Viele Browser hatten zumindest bisher massive Eigenheiten, allen voran der Internet Explorer. Ich vermute daher, es dürfte schwierig werden über alle Browser hinweg eine einheitliche .Net-Laufzeitumgebung zu etablieren, zumal alle Browser bis auf den IE sicherlich eine Implementierung von Mono nutzen würden und Microsoft stattdessen sicherlich seine eigene Implementierung nutzen wird. Microsoft wird kaum einen fremden Klon eines Produktes des eigenen Hauses in den IE integrieren. Unterschiede sind dann vorprogrammiert und der Kampf der Browser um Marktanteile wird aufs neue entfacht. Es würde daher auf zwei Dinge hinaus laufen: Bestimmte Anwendungen würden nur in bestimmten Browsern laufen. Und da viele Unternehmen auf Grund nicht ganz nachvollziehbarer Entscheidungen ausschließlich auf Internet Explorer setzen wären Probleme und Inkompatibilitäten vorprogrammiert. Ferner würden Techniken wie Java Applets, JavaFX, Flash und Silverlight / Moonlight und andere vollständig obsolet werden.

Es würde wohl darauf hinaus laufen, daß die Technik ausschließlich in eng begrenztem Umfeld eingesetzt werden könnte. Und wenn dann meistens in der Art, daß geprüft wird, ob eine Kompatibilität mit dem jeweiligen Browser existiert und - falls nicht - eine "tut uns Leid, geht bei Ihnen nicht" - Anzeige erscheinen müßte. Wenn Opera (noch) kein .Net integriert hat funktioniert die betreffende Web-Anwendung schlichtweg nicht in allen Opera-Browsern nicht. Jetzt ist Opera aber nur eine Randerscheinung. Viel schlimmer ist das mit dem IE: Dieser Browser besitzt Schätzungen zu Folge einen Marktanteil von etwa 60%. Ein Großteil aller User wäre damit nicht in der Lage, die Webanwendung auszuführen, wenn man diese auf .Net-Basis realisiert hat. Eine Situation, die jeglichen kommerziellen Einsatz dieser Technik ad absurdum führt.

Einer solchen Technik würde es also so ähnlich gehen, wie den Java-Applets. Sie würde nur in wohl definierten Bereichen einer Internetseite verwendet werden und kaum genutzt werden können. Und ich spekuliere weitere, wenn man schon die mächtigen Möglichkeiten der Sprache nutzen kann, würden die Menschen sich vielleicht sogar vom Konglomerat aus (X)HTML/CSS/SVG in der Anzeige abwenden und statt dessen lieber ihre darzustellenden Inhalte programmatisch selbst rendern. Dann käme die Integration von .Net wirklich dem gleich, was wir mit Java-Applets hatten bzw. haben.

Nun, der Gedanke, .Net zu integrieren ist dennoch äußerst interessant. Die Frage ist aber, ob man nicht den umgekehrten Weg gehen sollte: Die Anzeige von Webanwendungen in .Net integrieren und eine Plattform schaffen, die Awendungen verwaltet. Werter Leser, überlegen wir noch mal, warum Browser-Anwendungen so beliebt sind. Denn wenn man bedenkt, daß Web-Anwendungen (zumindest wenn es komplexe Fachanwendungen sind) einen immens höheren Aufwand in der Erstellung verursachen als wenn man sie als Standalone-Anwendungen umsetzt, muß es gute Gründe für Webanwendungen geben:

• Bequemlichkeit: Man muß nichts installieren
• Wartungsarmut: Man muß sich nicht um Updates kümmern
• Einfachheit: Es ist vergleichsweise einfach etwas daran zu ändern
• Integrierbarkeit: Diverse Wenanwendungen können ineinander integriert werden

Diese Ziele lassen sich auch auf anderem Weg technisch erreichen. Man könnte eine (.Net-basierte) Plattform schaffen, in der Anwendungen automatisch als Modul hineingeladen und ausgeführt werden. Updates könnten automatisiert durchgeführt werden. Die Einfachheit der Änderungen wäre gegeben, wenn die Anwendung grundsätzlich im Quelltext vorliegen würde und erst lokal in der Ausführumgebung in Binärcode übersetzt werden würde. Und die Integrierbarkeit ist eigentlich jetzt schon gegeben: Kaum eine Anwendung heute ist nicht komponentenbasiert.

Eigentlich war es Aufgabe des Betriebssystems, eine solche Ausführumgebung zu sein. Und wenn man sich die Paketverwaltung von z.B. Linux ansieht, wie einfach hier z.B. mit Synaptic neue Anwendungen installiert und über die Paketverwaltung auch automatisiert geupdated werden können, unterscheidet sich das - bis auf die Integration mit dem Besuchen von Internetseiten - interessanterweise gar nicht so extrem von obigen Anforderungen.

Es wäre durchaus überlegenswert, das Konzept einer solche Paketverwaltung als Basis zu nutzen und sie plattformübergreifen zu etablieren. Stellen Sie sich vor, Sie haben nicht einen Browser, sondern ein anderes Ding, in dem Sie einen URL eingeben. Dieses andere Ding ist eine Laufzeitumgebung und läft gemäß des URLs automatisch die betreffende Anwendung über das Netz und führt sie lokal aus. Eine Installation ist nicht mehr erforderlich. Updates auch nicht: Darum kümmert sich die Paketverwaltung. Auf Grund des Konzepts der Virtual Machines würde sich die Anwendung sogar auf Teilbereich des Systems beschränken lassen um die Sicherheitsproblematik zu adressieren (die in diesem Blog sogar noch außen vor gelassen wurde). Stellen Sie sich vor: Sie surfen im Internet, klicken auf einen URL und automatisch wird diese Anwendung über das Netz geladen und ausgeführt. Kein lästiges Installieren mehr, kein lästiges updaten mehr. Plattformübergreifend. Und das Beste: Dadurch, daß es .Net Anwendungen sind, könnten sie alle auf einem einfachen Weg eine ganze Menge mehr leisten, als es Web-Anwendungen - wenn überhaupt - nur mit Klimmzügen könnten. Und würde man noch die Anzeige von Internetseiten als Komponente in die .Net-Laufzeitumgebung (plattformübergreifend) integrieren hätte man exzellente Möglichkeiten für eine leichte verschmelzende Nutzung aller Technologien.

Das sind nur Überlegungen. Der Siegeszug der Web-Anwendungen wird in jedem Fall weiter gehen. Die Browser werden immer komplexer und aufwändiger werden. Und die eingesetzten Technologien immer vielfältiger und umfangreicher. Daran besteht kein Zweifel. Eine Integration von .Net in den Browser wäre flächendeckend schwierig, aber grundsätzlich hoch interessant. Fraglich ist, ob man aber nicht lieber die Installation und Verwaltung von Anwendungen im Betriebssystem überarbeiten und aufpolieren sollte, statt alles im Browser nachzubauen. Wir werden sehen wie sich die Dinge entwickeln. Es bleibt jedenfalls spannend!