I’m reluctant to get involved in this – but I feel like there’s another side to this story which is worth considering.

Since it was first presented at altnetconf – the decision to require users¹ to have to specify which methods on controllers are available to be routed to ([ControllerAction]) and which view (RenderView()) to render has come in for a lot of criticism.

Lots of the brightest and best minds in the .net world are screaming about this in various forums. Claiming that it violates:

• the DRY principle
• convention over configuration
• best practice in other frameworks
• commonly accepted laws of physics

Not one of the people complaining is going to use this framework vanilla. They are going to add their own layer of behavior over the top. It’s been designed to make it easy (trivial in this case) to extend and change the policy.

Sane defaults are really important for frameworks. Yes they get in the way of power users. Yes it normally takes a power user 10 minutes to work around them and add that piece of code to their toolbox from then on.

I don’t know how many people were following the emergent rails community back in 2005 when the Google Web Accelerator was released – but many of them (including the smartest² ) got a salient lesson in GET idempotence. (i.e. GET Order?id=23&action=delete – should never delete anything).

Here was a situation where the framework (rails) came with not so safe defaults and bad example code which encouraged doing the wrong thing. These days – rails has absorbed this lesson so completely that it could be described as a REST server and in some ways leads developers into following best practices for web apps by default.

I really don’t understand what the huge deal is here? This seems as clear cut to me as the built in RequestValidation in ASP.NET or automatically escaping SqlParameters for SQL injection. Sure – if your a power user it can be a pain – but it takes 10 seconds to turn off and then your responsible when your site get p0wn’d.

It’s not like ControllerBase is sealed.

1. by default – but easily modifiable
2. or is that loudest?

ASP .NET templated controls did almost nothing to encourage separation of orthogonal concerns. It simply ended up separating concerns that aren’t separate concerns.

Pure Genius – this summarises an entire field of criticism (e.g. [1][2]). The whole issue with the OnRowDataBound/FindControl() style of programming is that things which are fundamentally simple (iteration and string concatenation) are impossibly complex because concerns have been separated which are not orthogonal.

There’s an important caveat to this – which is that WebForms is actually trying to solve a different problem from the one that I and many other developers build web apps are trying to solve. WebForms was intended to allow VB6 windows programmers to build web based apps – without having to understand HTTP, HTML, CSS, Javascript, GET/POST/HEAD etc.

This has actually proven to work pretty well in specific circumstances. e.g. A team of developers building an inhouse (intranet) line of business app. A good friend of mine was tasked to lead a team of 20 or so Oracle Designer developer in building a next gen version of the product they had been working on in ASP.NET 1.1. They were able to pick it up and get productive remarkably quickly because they could continue to work with a Control based, form based model that was familar to them.

Where it’s made life immeasurably harder is for developers who are building public facing web apps. Apps the HTML they’re actually emitting matters, where cross browser compat is something that needs to be deeply understood – not abstracted away (thats a whole ‘nother post).

The reason this is even an issue is because of the Microsoft DevDiv monoculture. If it’s a Microsoft solution then it’s obviously the best. In the Java world – there’s JSP (classic asp using Java) and JSF (roughly webforms) – but there’s a whole boatload of other solutions to problems.

I don’t see anyone arguing that the only right way to build web apps using java is to use JSF. People are free to examine the problems they face, look at the solutions proposed by various other people who have published their work (e.g. Tapestry, Grails, RIFE, Struts, WebWork, Struts 2 etc…) and either use an existing solution or roll their own. Same in the Python (Django, Web.py, Zope), PHP (Zend Framework, Cake, various PEAR libraries), Perl and pretty much any other community you care to examine.

Which tool is right for you depends entirely on your context (the problem, your experience, your team, their experience etc). If Webforms is working for you – then fantastic but it’s not the right solution for everyone.

1. Giles Bowkett made an interesting post on his blog:
   

   “[T]his has always been my fear for Rails; that in five to ten years, the worst jobs you could get will be Rails jobs where you’re maintaining stuff built by non-programmers who figured Rails made programming so easy that they didn’t really need to understand what they were doing.”

2. In Avi Bryant‘s ETech presentation Applied Web Heresies (slides) he makes the following statement:
   

   “Meaningful URLs don’t carry enough meaning
   Names make me think too much
   DRY (not everything is an API)”

This is reminiscent of Visual Basic (and VBA, Access etc..). I know I’ve done maintenance on some scary code which was written by someone who didn’t understand enough about what they were doing.

Not Everything is an API

The obsession of Rails dudes with making every object a REST endpoint is a particularly scary form of religion. In VB6 every “class” was exposed as a COM object. For those of you who are not familiar with COM – this means that every public class in your application was exposed as an API. Weather you wanted it available to other applications or not. As you can imagine – this resulted in some truly monstrous misuse of parts of applications by other applications and lead to the worst kind of spaghetti dependencies imaginable (circular build dependencies etc).

In general API’s should be carefully thought through, designed and exposed as a separate development exercise from building a web application. For example:

1. Google maps was released
2. People started hacking mashups using it.
3. The GMaps team went away and designed a JavaScript api which is:
   • versioned
   • licenced
   • secure
   • supportable