Wednesday, April 28, 2010

Everyone celebrate, it’s Notepad day.

I would like to declare today (or possibly tomorrow, seeing as today has gone already, or even the whole week) “notepad day” as a direct result of the frustration that a developer “friendly” tool has created for a site I’m trying to get live.

It’s a pretty simple scenario – a form that needs to be filled in, which the designers have mocked up with nice text box hints, and validation behaviours. All very simple in HTML/CSS/JS terms. The problem arises because MSFT, in their infinite wisdom, decided to make it really “easy” for .NET developers to auto-magically add the correct validation hooks by adding code attributes inside the model class definitions (it’s an MVC app) – i.e. it auto-generates the HTML, a set of dynamic CSS attributes to decorate the output and some JS to manage the behaviour.

So, this model annotation:

Class annotations

Combined with this view:

View definition

Outputs this HTML and associated JS:

HTML output JS outputAs a result, when there is a problem with the UI code and you turn to your HTML developer he then tells you he has no idea where the HTML comes from – it’s a .NET thing. So you ask the .NET developer, who knows where it comes from, but does not know either how to affect the output, or what the output should ideally look like.

There is absolutely no reason for the the Html.EditorFor helper – not only does it not save time, it pulls the .NET developer across the line and into the HTML. (It also means recompiling the code to change the validation which is insane.)

This is not the first time they’ve done this – they have quite a heritage in the trying-to-be-simple-but-totally-missing-the-point stakes:

1. In VB6 there was some crazy model that involved compiled VB6 apps emitting HTML. Never went anywhere. (I can’t even find out what it was called. Although I did come across this – which has to win a prize for most optimistic course organiser – VB6 for Beginners, starting April 2010…)

2. ASP.NET WebForms – instead of respecting HTTP/HTML, they designed a model that involved replicating the eventing model of a local app by manipulating something called the ViewState and which resulted in developers spending most of their time asking themselves in what order the chain of 874 events fired, and where in the stack of 400 child controls the problem lay.

3. MVC – having finally got the message, and adopted the clean lines of the rest-of-the-world’s favoured model, they decide that implementing MVC wasn’t enough. What developers really want/need is a way of ignoring the problem that HTML is harder than it looks, and different to C#. MSFT – please STOP.

A website is more complex than a server app if only because it involves a skills laminate – designers, HTML and server-side all come together around the same output, and in order to allow each of these to do their jobs effectively they need to have clearly-defined roles. HTML developers are responsible for what is displayed in the browser, and they can’t take on this responsibility if HTML is being cooked up behind the scenes by some opaque process.

I presume this happens because MSFT are keen to look after the smaller development shops where they don’t have the luxury of split roles, and one developer is doing everything, but it’s a royal PITA for teams who want to do the job properly, and only serves to undermine the impression that non .NET designers / HTML developers / project managers / testers etc. have of the platform. Which is unfair, as it is actually rather good.

No comments: