Webmatrix - Rückfall in schlimme alte Zeiten?
Ich erinnere mich noch an meine erste Reaktion, als mir der geschätzte (damalige) Kollege Buberl seinerzeit ein bisschen Code von ASP.NET 1.0 zeigte, das muss Ende 2001 oder Anfang 2002 gewesen sein: "Wer will denn bitte so viel Kontrolle über seinen HTML-Code aus der Hand geben?". Das wird wohl vielen Leuten so gegangen sein, die damals mit ASP oder PHP arbeiteten.
Es kam wie es kommen musste - für ASP war mit Version 3.0 Schluss, ab sofort gab es nur noch ein Thema: ASP+ ASP.NET. Es folgte noch im Jahr 2002 die erste Literatur zum Thema in meinem Regal, den wirklichen Umstieg zu ASP.NET 1.1 und Visual Studio 2003 habe ich dann aber erst im Jahr 2004 vollzogen. Ich ließ Websites mit grauenhaften Tabellen-Layouts, tonnenweise unnützen automatisch generierten Scripts, für Suchmaschinen hinter Postbacks unerreichbaren Bereichen ins Web und schusterte mir erste Masterpage-Lösungen zurecht.
Irgendwann mit ASP.NET 2.0, das muss 2005 gewesen sein, kam dann auch XHTML in Mode und die Ambitionen, sauberes Markup zu generieren, stiegen. Es folgten "CssAdapter" von Microsoft um die furchtbaren Ausgaben von GridView, Menu-Control und Co zu optimieren, und es kam irgendwann 2006 oder 2007 ASP.NET Ajax samt passendem Control Kit. Es hatte, obwohl ich meine Wurzeln sozusagen in der klassischen Webprogrammierung hatte, auch für mich seinen Reiz Teile einer Seite in ein Update-Panel zu werfen und die Magie geschehen zu lassen (einige meiner für Kunden entwickelten Applikationen laufen heute noch damit). In dieser Zeit waren das dann aber auch schon die einzigen Innovationen, die das ASP.NET-Team hervorbrachte. Die Produktpflege fiel ansonsten recht spärlich aus.
Das änderte sich erst Ende 2007, als ASP.NET MVC das Licht der Welt erblickte (und von mir argwöhnisch beäugt wurde). Insbesondere der zu diesem Zeitpunkt immer größer werdenden Gemeinde der Entwickler, die sich hin zu Dingen wie Clean Code, automatisierten Tests und überhaupt moderneren Entwicklungsmethoden gezogen fühlten, trug das neue (Sub-)Framework Rechnung. Zufälligerweise stand ich in meinem eigenen Entwicklungsprozess zu dieser Zeit auch gerade an diesem Punkt, ich wusste es damals nur noch nicht ;-).
Mit MVC besann man sich wieder etwas mehr auf die Wurzeln: denn anders als in einschlägigen Hannoveraner Verlagshäusern gemeinhin behauptet bricht die Produktivität mit MVC für einen versierten Entwickler nicht ein, sie steigt sogar. Damit meine ich jetzt gar nicht die Möglichkeit, Controller zu testen (was die Produktivität tatsächlich eher massiv einbrechen lässt, aber das ist ein anderes Thema ...), sondern die Möglichkeit sehr effizient Webanwendungen realisieren zu können. Und zwar einerseits mit der 100%igen Flexibilität was die Ausgabe (Views) als auch die Kommunikation zwischen Client und Server angeht, und andererseits mit dem enorm mächtigen Unterbau des .NET Frameworks.
Mögen Klickibunti-WebForms-Entwickler noch ächzen, dass dieser ganze Inline-Code nach altem ASP riecht, ist er das nun ganz und gar nicht - im Gegenteil. Durch den Wegfall von Web- bzw. Custom-Controls entfallen auch die schwer wartbaren Blackboxes, die irgendwas tun, im Zweifel nur nicht das Richtige. Und man muss auch kein Request.QueryString[] auf Serverseite manuell benutzen - das Model-Binding von ASP.NET MVC war schon in Version 1 so gut, dass 90% aller Aufgaben mit der (natürlich erweiterbaren) Standardimplementierung funktionieren.
Was als Sahnehäubchen oben drauf kommt: Microsoft hat sich vom eigenen Ajax-Framework verabschiedet und liefert stattdessen nun die freie Bibliothek jQuery aus und arbeitet sogar an ihr mit (mit den gleichen Rechten aller anderen Entwickler!). jQuery - oder jedes beliebige andere Framework - sorgt nun in der Kombination mit MVC auf der Serverseite dafür, dass echte Ajax-Funktionen kinderleicht implementiert werden können. Und sollte einmal Geld oder Zeit oder beides fehlen, um eine Funktion selbst zu bauen, besteht die Möglichkeit sich aus einem Pool unzähliger jQuery-Plugins zu bedienen. Diese mögen in den Samples mit PHP funktionieren - aber wen interessiert das? Das Backend ist schnell ausgetauscht ...
Kleine Nebenbemerkung: vielleicht liest man schon meine Abneigung gegen fertige Komponenten heraus. Klar, auch ich nutze z.B. ein Tree-Control von Telerik oder den CuteEditor ... halt. Nein, genau den nutze ich nicht mehr. Warum? Weil ich ihn neulich um ein paar Dialoge und Funktionen für unser CMS erweitern wollte und immer wieder in undokumentierte Sackgassen oder Code lief, der durch den Obfuscator gedreht wurde. Nun hatte ich die Wahl für 8000$ eine Open-Source-Lizenz zu kaufen oder ... einfach Open Source zu verwenden. Heute werkelt in unserem CMS der CKEditor mit genau den Plugins, die ich für den CuteEditor nicht hinbekommen habe. Zwar hat mich die Implementierung auch hier ein paar graue Haare gekostet, aber es war alles dokumentiert und mit massenhaft nicht durch den Fleischwolf gedrehten Samples auch gut möglich.
Wo waren wir? Ach ja, ASP.NET. Ich pflege zwar, weil das mein Job so mit sich bringt, nach wie vor noch eine ganze Reihe an WebForms-Applikationen und auch unser CMS basiert im Frontend noch darauf, für Neuentwicklungen setze ich heute aber konsequent auf ASP.NET MVC. Es ist einfach die sauberste und zugleich flexibelste aller Lösungen.
Nun schreiben wir 2011 und Microsoft hat still und heimlich eine weitere Tür zum Raum der hauseigenen Webentwicklungstechnologien aufgemacht. Dahinter steht: WebMatrix (nicht dieses hier). Auf den ersten Blick hat es mir da wahrlich den Magen umgedreht und so ganz wohl dabei ist mir auch heute noch nicht. Wenn man sich anschaut wie hier wieder Geschäftslogik, Datenbankzugriff und Markup gemischt werden, weiß man nicht, ob das grausames Classic ASP oder Consultant-ASP.NET sein soll. Vielleicht beides?
Aber zu meiner Überrasung ist das Echo auf WebMatrix gar nicht so verheerend wie zunächst gedacht. Und tatsächlich: wenn ich einmal kurz die Luft anhalte und so richtig darüber nachdenke, dann könnte WebMatrix gerade zusammen mit NuGet und dem WebPlatform-Installer "The Next Big Thing" für die kleine Entwicklung zwischendurch sein. Saubere URLs, einfaches Arbeiten mit Datenbanken, viele Helper, eine ganz passable Entwicklungsumgebung - die Lernkurve gerade für Neueinsteiger dürfte dramatisch sinken.
Dann hätten wir aber drei Schienen, die es zu pflegen gilt: ASP.NET WebForms, ASP.NET MVC, WebMatrix. Für meinen Geschmack ist das wenigstens eine zu viel ...
Szenario 1: WebMatrix floppt genau wie die aufs Web ausgerichteten Expression-Produkte auf ganzer Linie und wird in zwei Jahren still und heimlich eingestellt.
Szenario 2: Die Entwicklung an WebForms wird nicht weitergeführt. Man wird es zwar nicht sterben lassen und genau wie Classic ASP weiterhin unterstützen, aber die eh schon sehr leidliche Weiterentwicklung des eigentlichen Frameworks wird beendet.
Wäre da nicht Sharepoint - ich würde glatt auf Nummer zwei tippen. Sharepoint ist aber da und wird auch innerhalb der Microsoft-Strategie nicht unwichtiger. Deshalb bin ich gespannt, was passiert. Ich hoffe nicht, dass alle drei Technologien weiter am Leben gehalten werden - für viel mehr dürfte es dann bei der Größe des ASP.NET-Teams vermutlich nicht reichen.
In zwei Jahren krame ich diesen Eintrag dann wieder mal raus.