Was ist nicht alles spekuliert worden vor der BUILD, der Entwicklerkonferenz Microsofts, die erstmalig in Anaheim, Californien stattfand und damit die bisherige PDC abgelöst hat. „WPF und Silverlight werden ersetzt“, konnte man lesen. „Nur noch HTML5 und JavaScript wird langfristig von Microsoft unterstützt werden!“. Oder gar: „Das .NET Framework wird abgelöst“. C# sollte verschwinden, genau wie Visual Basic – nur noch C++ und JavaScript sowie HTML5 überbleiben.
Alles Quatsch.
Um es gleich vorweg zu sagen: Es wird neue Versionen vom Framework geben, es wird ein C# 5.0 und ein C# 6.0 geben und auch ein Visual Basic 12 und 13.
Eigentlich dürfte ich es schon nicht mehr bemerkenswert finden, dass man es niemals allen Menschen Recht machen kann. Die einen möchten eher eine – nennen wir es mal – „Ökosystemstabilität“ in Sachen Technologie, mit anderen Worten, „bloß nix Neues!“. Die anderen fordern Hunderte mehr Features. Also ist ein Konzern wie Microsoft geneigt, Kompromisse zu machen zwischen Abwärtskompatibilität und der Weiter- oder Neuentwicklung von Technologien. Die schlimmsten sind die, die sich immer beschweren: „Diese neue Technologie ist viel zu langsam“, und geht Microsoft einen etwas radikaleren Weg, und bringt eine sehr viel schnellere Technologie, wie die neuen Metro-Apps in Windows 8, dann schreien die gleichen Leute „Ha, wie schlimm, Microsoft zwingt uns alles neu zu schreiben – wie können die nur!“.
Mit dem Erfolg des iPhones und des iPads ist Microsoft nicht nur ein Wenig von der Entwicklung aktueller Benutzerschnittstellentechnologien überholt worden. Die Anwender kennen nun auf einmal „Apps“ von ihren iPhones und Apple Tablets, die „geil und sexy“ sind, und ich finde es ist keine unverschämte Forderung, ein solches „User Experience“, wie es so schön heißt, auch auf den Businessanwendungen haben zu wollen – jedenfalls da, wo es Sinn macht oder Sinn machen könnte. Sinn machen heißt: Niemand wird vermutlich auf die Idee kommen, ein Buch ausschliesslich auf einem Tablet-PC, also nur mit Touch-Keyboard ohne physische Tastatur zu schreiben (und ich spreche hier nicht von Spracherkennung – das kann durchaus funktionieren). Aber Power-Point Präsentationen zusammen zu draggen und zu sliden und zu tappen und zu swipen – warum eigentlich nicht? Ich denke schon, dass das gut geht. Produktiver vielleicht, als im Mausi-Klicki-Bunti-Stil.
Nur, diese neue Technologie der Tablet-Bedienung hat einen entscheidenden Nachteil oder vielmehr eine entscheidende Herausforderung an die Entwickler, die sie umsetzen: Sie duldet per se keine Verzögerungen im Bedienungsablauf. Jeder, der schon mal eine iPhone App vor sich hatte, weiß das: Hakt so ‘nen Ding zwischendurch ‘mal – und es gibt gar nicht so wenige Apple-Apps, die wirklich oft haken – dann wird es mehr als nervig. Der Mausbedienung mögen wir schon 'mal Verzögerungen verzeihen. Beim Touchen und Swipen hingegen erwarten wir einfach, dass ein Element genau unter bzw. hinter dem Finger herläuft, bzw. an diesem quasi kleben bleibt.
Weder Silverlight noch WPF sind ausreichend schnell, um das zuverlässig zu leisten. Ich würde sogar noch weiter gehen, und sagen: Weder Silverlight noch WPF sind ansatzweise so schnell, um das nur halbwegs zuverlässig zu leisten. Man möge mich nicht falsch verstehen: Ein guter Entwickler könnte in WPF ja sogar in Windows Forms ausreichend schnelle Apps entwickeln, um diese fließende „User Experience“ zu realisieren. Aber er müsste sich enorm disziplinieren und wirklich effizienten Code schreiben. Und er müsste wissen, welche der Silverlight, WinForms oder WPF-APIs er sicher benutzen kann, um flüssig zu bleiben, also sein Umfeld genau kennen.
Nun hat das .NET Framework so um die 14.000 Typen und weit über 100.000 Methoden. Man mag sich vorstellen, dass es da schwierig wird, alle Typen mit ihren speziellen Verhaltensweisen so zu kennen, dass eine entsprechende flüssige Umsetzung wirklich garantiert ist. Microsoft hat in dieser Hinsicht einiges an Forschung betrieben und kommt zu dem Schluss, dass alles, was länger als 50 ms dauert, vom Anwender eigentlich schon als Ruckeln oder zumindest wahrnehmbare Verzögerung empfunden werden kann. Mit anderen Worten: Jede Touch-App sollte das, was länger als 50 ms dauert, von dem Prozessorkern, der die Interaktivität mit der Benutzeroberfläche gewährleistet, trennen, und einen zweiten Prozessorkern abarbeiten lassen.
Das ist aber nur die erste Anforderung. Microsoft braucht zweierlei, um richtig „geile“ und „sexy“ Apps für Windows 8 in ausreichender Menge entstehen zu lassen. Entwickler und Designer, denen man den kommenden Industriestandard HTML5 und JavaScript nicht verschließt, sowie die vorhandene Entwickler-Base, die, sagen wir mal, in Anbetracht des zuvor gesagten nur ein wenig reglementiert werden muss, damit sie in Sachen „lahme, blockende Algorithmen“ keinen Blödsinn bauen können. Ach so, und dann vielleicht noch ein Framework, dass auch auf Geräten, die, weil sie leicht sein sollen und ihr Saft laaaange reichen muss, eben nicht über mit 6 GHZ laufenden 12 Core-Prozessoren verfügen müssen, sondern vielleicht nur über extrem langsame aber sparsame Atom- oder sogar ARM-Prozessoren. Und voila: Wie sind mitten bei dem, was auf der BUILD vorgestellt wurde, mitten bei der Entwicklung von Metro-Apps unter der sogenannten Windows Runtime von Windows 8, kurz WinRT genannt und in etwa „Win Arrr Tieh“ ausgesprochen – das „Arrr“ dabei moeglichst texanisch gerrrrollt.
Und hier gerät Microsoft mit der gerade neu vorgestellten Framework-Technologie in ein Kreuzfeuer, das ich so gar nicht nachvollziehen kann. Man stelle sich folgendes Szenario vor: Eine Firma namens ConvCars baute bislang Kabrios, und ist Marktführer auf diesem Gebiet. Diese Firma sieht im Bestreben, zu expandieren und ihre Marktposition zu festigen, einen gewaltigen Markt im Transportergeschäft und traut sich durchaus auch zu, qualitativ hochwertige Transporter zu bauen. Sie stellen einen durchaus konkurrenzfähigen Lastwagen vor, aber Kritiker werfen ConvCars nun vor, man könne nicht nur das Dach dieses Transporters nicht mehr aufmachen, nein, die Zubehöranbieter von Windschotts und Leder-Persennings würden damit ja nun ihr Zubehörsortierment einstampfen müssen. Blödsinn, oder?
Genauso argumentieren aber zurzeit viele Kritiker, die Microsoft vorwerfen, es würde innerhalb eines Jahrzehntes wieder einen kompletten Wandel in den Entwicklertechnologien machen, das .NET Framework würde über kurz oder lang verschwinden, alle Investitionen der letzten .NET-Jahre wären vergebens, blablabla. Auf der BUILD habe man ja gesehen, dass JavaScript und HTML5 sowie C++ deutlich in den Vordergrund getreten sein, nur noch Metro sei dort vertreten, man würde überhaupt keine Kommittents zu WPF und Silverlight erkennen können. Ja hallo? Wieso soll eine Firma auf einer Konferenz, einer Ausstellung oder einer Messe denn ihre alten Produkte vorstellen? Die kennt doch schon jeder!
Microsofts Kommittent zu .NET, C#, Visual Basic steht. Microsoft bietet eine Runtime an, die das Framework, das im Übrigen ein vollständiges Framework.NET ist, so beschneidet, dass für Performance-Stunts in Sachen Metro-UIs nicht so viel Spielraum lässt, und das kann doch nur im Sinne des Entwicklers sein. Gelöst wird das über ein .NET-Framework Profil, das wir bereits von dem verkleinerten Subsets des Frameworks beim Client-Profil oder vom Silverlight-Framework kennen. Also, nichts Schlimmes, eher eine gut durchdachte Unterstützung des Entwicklers. Die Windows Runtime muss besonders schnell und besonders effizient entwickelt sein, um möglichst viel aus den langsamen kleinen Devices herauszuholen, und das, ohne die Akkus eines kleineren, mobilen Gerätes in 15 Minuten leer zu saugen. Aus diesem Grund hat Microsoft die bewährtesten Features von COM und die des .NET Frameworks gepaart. Aber zu sagen, die Windows Runtime sei COM, wäre nicht nur nicht ganz richtig, es wäre den Entwicklern gegenüber schlicht weg total unfair. Die Windows Runtime ist das Beste aus beiden Welten, und dabei ging vor allen Dingen um folgendes: Funktionen so schnell wie möglich aufrufbar zu machen, und gleichzeitig eine nahtlose Verbindung zum .NET-Framework einerseits, und zu JavaScript-Anwendungen andererseits zu schaffen. Als solches wurde die Windows Runtime konzipiert, alle betroffenen Teams haben gemeinsam daran gearbeitet, und zwar mit dem gleichen Ziel: Eine sinnvolle Plattform fuer die Tablett-Anwendungen von morgen zu schaffen. So, wie es momentan noch ausschaut, könnte es sogar ohne schmerzhafte Kompromisse gelingen, diese eierlegende Wollmilchsau zum Leben zu erwecken.
Um an dieser Stelle mit Spekulationen Schluss zu machen: Technisch verhält es sich mit .NET und der WinRT vereinfacht dargestellt also folgender Maßen:
· Das Framework sitzt auf der Windows Runtime, mit CLR, Garbage Collector, und allem was zum .NET Framework gehört.
· Besondere Runtime Callable Wrapper (RCWs) erlauben das Instanziieren von Objekten der Windows Runtime und das Aufrufen entsprechender statischer Methoden oder Methoden dieser Objekte. Einzige Voraussetzung dazu: Entsprechende Using (C#) bzw. Imports (VB)-Anweisungen binden die Funktionen der Windows Runtime in die eigenen .NET-Code ein. Besondere Referenzen zu setzen ist unnötig, denn die Windows Runtime ist ja immer „da“.
· Einziger Kompromiss: Das Framework wird durch ein spezielles Framework Profil auf solche Typen und Methoden beschnitten, die kompatibel zu Metro-Apps sind, also nach Möglichkeit Non-Blocking-Charakteristik aufweisen.
Was Silverlight und WPF anbelangt: Es gibt einiges an Neuerungen im .NET Framework 4.5, das als solches erst mal nichts mit der WinRT zu tun hat. Das .NET Framework 4.5 wird wie auch Visual Studio 11 auch unter Windows 7 laufen. Vorhandene Silverlight und WPF-Anwendungen (und natürlich auch immer noch Windows Forms-Anwendungen!) werden performance- und featuremäßig wie gehabt vom .NET Framework 4.5 profitieren. Die Windows Runtime zu nutzen und damit die Möglichkeit, Metro Apps laufen zu lassen oder zu entwickeln, besteht natürlich nur unter Windows 8.
Eines sollten einige da draußen vielleicht lernen: Es gibt Anwendungen, die sind, wie sie sind, die müssen nicht zum 100ersten Mal migriert werden. Mercedes baut die G-Klasse, den Geländewagen, seit nahezu 40 Jahren unverändert. Und warum? Das Ding ist gut und fertig, da gibt’s einfach nichts dran zu ändern, was ihn besser machen würde – hier und da gibt es sicherlich einige gute Detailverbesserungen, und die sind auch im Laufe der Zeit immer wieder gemacht worden, aber das war’s auch schon im Großen und Ganzen.
Entwickler sollten sich im Hinblick auf Windows 8 nicht fragen, wie sie ihre vorhandenen Anwendungen auf Metro migrieren, sondern wie sie sie mit zusätzlichen Metro Apps um sinnvolle Touch-Funktionalität ergänzen können. Und wenn eine Anwendung komplett als Metro-App Sinn machen würde: Na gut, es ist eine neue Technologie, dann muss die alte Anwendung eben daran angepasst werden. Wie anders sollte es denn sonst funktionieren? Deswegen ist das .NET Framework doch noch lange nicht das neue VB6. Jedenfalls erstmal nicht. Und selbst wenn: VB6 wird, wenngleich es zugegebener Maßen schon unter Windows 7 an allen Ecken und Enden zickt und hakt, so wie es ausschaut, auch prinzipiell unter Windows 8 noch funktionieren. Und das zeigt, was garantiert auch für die Voraussagen derjenigen gilt, die das .NET-Framework jetzt schon durch WinRT ersetzt sehen, jedenfalls wieder eines: Totgesagte leben länger.
Just my 2 Cents.
d90f731a-dab1-41b0-bf14-e3cf4fdd4678|5|5.0
Tags: windows 8, metro, framework 4.5 |
Categories: