Thomas Bandt

Über mich | Kontakt | Archiv

Ene mene muh und raus bist du?

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.

Kommentare

  1. Rene Drescher-Hackel schrieb am Samstag, 22. Januar 2011 23:40:00 Uhr:

    Hallo Thomas,

    ja die Entwicklung der Webentwicklung hat in den Jahren einiges an Tempo zugelegt. Auch wenn ich mit MVC bislang noch nicht so Recht warm geworden bin, denke ich dennoch, dass einige der Argumente "pro MVC" "contra WebForms" ein wenig hinken: so beklagst du eigentlich, die Masse an schlechten Controls, wo dir die Kontrolle letzlich fehlt.

    Nun stelle dir vor, dir würde so etwas in der MVC Entwicklung unterkommen? Würdest du dann MVC auch verteufeln? Ich bin der festen Überzeugung, dass WebForms auf absehbare Zeit ihre Berechtigung behalten werden. Einzig die Vielfalt ist größer geworden, wie Webprojekte in .NET umgesetzt werden können: du wirst immer Anforderungen haben, wo WebForms besser passen, als MVC-Anwendungen oder als gar Silverlight-Anwendungen oder oder oder...

    Die Qualität der Customcontrolentwicklung wird letztlich vom Markt bestimmt. Wenn immer wieder ganze Bibliotheken trotz mangelnder Performance reizenden Absatz finden, weil es in das Budget passt, dann muss man mit den Einschränkungen auch leben.
    Ich hatte vor Kurzem auch gerade mir eine Bibliothek näher angesehen und dabei mehrere Produkte mit unseren Anforderungen abgeglichen - die, welche die Anforderungen nicht erfüllt haben, fielen dann einfach raus - so konsequent musst du dann halt sein - oder weiter suchen.

    Persönlich habe ich nach wie vor eine Abneigung gegen Klickibunti. Immer wieder höre ich aber auf Microsoftveranstaltungen, dass da nach wie vor das neue Zielpublikum gesucht wird. Mit Klickibunti-Lösungen macht man bestenfalls den Makrt kaputt, so dass dann mein kleiner Sohn komplexe Businessanwendungen zusammen klicken kann. Aber zum Glück sind Anforderungen an Webanwendungen so speziell, dass du es mit einfachen zusammenklicken nie lösen wirst.

    Es bleibt abzuwarten wo die Reise hingeht...

    Rene
  2. Thomas schrieb am Sonntag, 23. Januar 2011 19:20:00 Uhr:

    Hallo Rene,

    "so beklagst du eigentlich, die Masse an schlechten Controls, wo dir die Kontrolle letzlich fehlt. Nun stelle dir vor, dir würde so etwas in der MVC Entwicklung unterkommen? Würdest du dann MVC auch verteufeln"

    Ja. Es gibt ja schon Tendenzen auch in MVC analog zu WebMatrix Helper für Dieses und Jenes reinzupacken - für mich der grundfalsche Ansatz. Das Framework soll die Infrastruktur für eine saubere Arbeit bieten, aber keine Implementierung vorweg nehmen.

    Bei WebForms sind die Komponenten nur die Wirkung, nicht die Ursache. Das Problem ist das "falsche" Programmiermodell, was eben viele Desktopentwickler ins Web rüberziehen sollte und auch gezogen hat. Am Desktop kann ich mit einer WinForms-Komponente leben, die verhält sich in ihrem Ökosystem ja immer gleich. Im Web fahre ich damit ziemlich schnell in eine Sackgasse, denn die Browserlandschaft ist sehr heterogen - da sollte man dann schon wissen, was passiert und auch Einfluss nehmen können.

    Bis vor Kurzem hätte ich noch gesagt, dass vielleicht spezielle Forms-over-Data-Geschichten wie Grids mit Sortierung, Filterung, Inline-Editierung, Paging etc. ein Grund für WebForms-Komponenten wären - aber nicht mal da sehe ich einen großen Vorteil gegenüber einer eigenen Implementierung mit jQuery oder einem vorhandenen jQuery-Plugin.

    Von daher könnte WebForms von mir aus gerne schon morgen in die Tonne. Zumindest für alles Zukünftige.
  3. Lisa Haar schrieb am Sonntag, 30. Januar 2011 21:05:00 Uhr:

    Ich habe ich auch vor langer langer Zeit mal an ASP getraut. So wirklich hat es mir nie getaugt. ASP.NET ging dann bereits komplett an mir vorbei. Ich bin bei HTML, PHP und MySQL geblieben. Und ich bedauer es nicht :-D
  4. Rene Drescher-Hackel schrieb am Sonntag, 30. Januar 2011 22:32:00 Uhr:

    @Thomas: es kommt immer darauf an was man selbst zu lässt. Wenn du strikt beim MVC Konzept bleibst, solltest du zu Recht kommen. Soweit kann ich dir zustimmen hinsichtlich der Infrastruktur. In Bezug auf die Webcontrolentwicklung muss man immer nur eines einfordern - saubere Controls. Oubout hat da in Ansätzen einen für meine Begriffe guten Weg beschritten - sie bieten bei vielen ihrer Controls Schnittstellen zur eigenen Erweiterung an. Sie haben aber auch Controls dabei, die am Ziel vorbei gedacht sind.

    Ich für meinen Teil bin dieses Wochenende MVC wieder ein Schritt näher gekommen - mal sehen, wo das endet... ;-)

    @Lisa: PHP/MySQL kannst nicht wirklich mit ASP.NET vergleichen. Gegenüber ASP (VBScript) sehe ich schon Vorteile bei PHP aber nicht gegenüber .NET. Da wäre ein Argument von dir interessant gewesen.
  5. Thomas schrieb am Sonntag, 30. Januar 2011 23:00:00 Uhr:

    Ich glaube Lisa wollte nur kurz hallo sagen und für ihre Haarverlängerungen werben. Schade, dass ihr Link "verschwunden" ist ;-).


« Zurück  |  Weiter »