I’m not much for technology recommendations. Most technology choices should probably be driven by familiarity and cost. For instance, Ruby on Rails is easily the most mature web stack out there, but if you’re a Python programmer with no familiarity with Ruby, Flask or Django is likely to be a better choice. It’s not helped by the fact that a number of “technology change” stories turn out to be stories of replacing bad code in one stack with good code in another. The rest tend to be stories about reducing running costs by moving off Windows or Heroku. Most technology choices, especially in the web space, tend to be “good enough”.
There’s one huge exception to this rule: Asp.Net WebForms. It’s poison for productivity and it’s poison for production. It took me a long time to accept this. I had been developing uSwitch.com for nearly four years. We had developed the majority of the site in WebForms (this was before MVC was even an option). Except, weirdly, for the most profitable parts. They were in an unholy mix of ASP, XSLT and C# for the business logic. Although a pain to work with, I’m no longer convinced it was actually worse than WebForms where it counts.
The Choice That Destroyed a Company
Now, rather than the implementation success stories that glut the internet, let me tell you about a failure. uSwitch is now a successful project run by ForwardTek. However, it’s shocking what happened to uSwitch in the last years I was there. The firm was bought for $366 million in March 2006 with big plans for expansion. In July 2007, these plans were dust and there were huge layoffs (I was already gone). Within two years, with no expansion in sight, February 2008 saw the purchaser effectively write down the firm to zero. Now, the reasons for this are always many and varied (buy me a beer sometime), but a fair proportion of this horrible crash can be ascribed to one project, and a fair proportion of that to its technology choice. I’m not going to claim that there weren’t bad project management decisions, or that all of the code we delivered was perfect, but choosing WebForms was a mistake, and a big one.
The truth is, I thought the writing was on the wall by the start of 2007. The project known as the redesign, which began at about the same time as the buyout, had been live for a couple of months. It was a disaster:
- It had frozen the entire website for over six months, allowing competitors to eat our lunch.
- Our flagship energy product was actually slower at the end of it than at the beginning.
- The new structure wasn’t actually flexible enough to handle the changes we were then asked to implement.
- It took over 50 developers, including quite a few contractors, about seven months to deliver. We had to pay contractors to work weekends. When the project was over, so little leave had been taken the firm had to institute buy-back. The cost of the project was just plain more than the firm could take.
- And, worst of all, the uptick in conversion the project promised just plain didn’t happen.
(There is an irony associated with that last point. The original project proposal a 10% improvement (don’t quote me on the exact figures after all this time). Some quick-win patches we instituted in February garnered about half of that. This left us with a large project to gather the other 5%. With that in mind, it’s not clear the project was worth doing even at the start. That and the decision that we couldn’t have an inconsistent look on the site really, really hurt us. I did say there were other factors.)
This post is getting extremely long, but hopefully I’ve got your attention. I distinctly remember one day in July, the fourth month of this project. I had just finished a two hour debugging session with another developer on some issue to do with dynamically generated content, one of the many issues that plagues WebForms development, when it occurred to me that after three years of working with the technology, I was far from convinced the productivity benefits of learning it were there at all. It’s pretty tough accepting that you’ve spent the last three years driving in the wrong direction, but the longer I thought about it, the more solid my opinion became.
Wait, What Has This Got To Do With WebForms?
You’ll note that I haven’t said the code was bad. It wasn’t. It had a fair number of automated tests against it, some nice automated health checks in Watir. A little while after release, it even gained an automated deployment system.
WebForms has a number of things that just make it a horribly inappropriate technology for a dotcom website.
- It wants to generate all of your HTML. This is a serious problem if you’re trying to produce a skinnable application. Yes, I’m fully aware of the skinning technology in WebForms; it’s completely inappropriate for the kind of work dotcoms actually want to do.
- It generates huge hidden state fields. This means your programmers end up fighting WebForms every time they need a page to be fast. Sadly, this is all of the time.
- It generates large numbers of complex munged IDs. In addition to making your page slow, it obstructs debugging.
- The standard model is to post back to the same page and then redirect to the next. This involves reconstructing the state of the previous page in order to process the events. This is way too slow at a computational level and involves too many round trips.
- Specifying your own URLs was generally regarded as deep magic until 2010. Seriously.
Seriously, there’s no other web stack I can think of that makes it so hard to just deliver some HTML in a form and get a post back. Now, if you’re a WebForms expert, you’ll be taking a look at the previous list and thinking “but there’s ways around all of these issues”. You’d be right, but that’s missing the point. There’s no other web stack that requires expertise to get these things right. But even if you can crack these issues, your problems are just beginning.
For instance, have you heard of the “off by one” issue? Let’s say you have a form that changes the number of controls on the page under certain circumstances. It’s quite easy to get into a situation in which it’s showing the wrong stuff on the page. If you add a dummy button, pressing it will correct the page. Debugging issues like this is a nightmare. Things get worse if you have data driven controls. While we’re on the subject, I remember watching one developer trying to replicate the functionality of repeater. Even after decompiling the original code, he couldn’t get it to work with the declarative syntax, leading us to believe that the repeater is actually magic. The kind of magic that comes out of Neville Longbottom’s wand. Oh yes, and you’ve got to understand the ASP.NET event model, a construct more complex than Cloud Atlas and significantly less fun to read.
Oh yes, and I haven’t even mentioned theses issues yet:
- there’s no support for any kind of CSS or JS asset pipeline. If you want some, you’ll have to roll your own build system. Rails comes with this stuff baked in.
- testing? You have two options: Selenium or clicking on a web browser.
WebForms: Just Say No
WebForms is productivity poison; in fact, it’s so bad it’s probably not just hurt little firms like mine, it’s a technology (again, part of a larger picture) that killed Microsoft as a cloud platform. Someone reading this undoubtedly believes WebForms is better in 4.5. It probably is, but it remains the wrong idea in the first place. It’s quite hard to fix that. I don’t write that many websites these days, but even for internal stuff I never, ever, touch WebForms.
Of course, it’s worth pointing out there are other sites on the internet that used WebForms at the same time. Not many, but it’s worth considering that the two I can think of are Orkut and MySpace. They were both technical disasters and unable to match the pace of a firm like Facebook that had delivered its entire functionality in PHP, a technology that’s closest relative in the Microsoft world is classic ASP.
Colour Coding 