ASP.NET isn’t always the right tool

In my 2.0 isn’t a silver bullet post, Alex Lowe made it clear that my enterprise development perspective, while valid, only represents a portion of the ASP.NET developer community. The reality is that Alex is right, but should he be?  Alex argues that there are plenty of sites that “should be written using ‘crappy’ SqlDataSource control, DataSet, ‘improper’ paging, etc.” I honestly wonder, should these sites be written in ASP.NET to begin with?

I say it often, but ASP.NET is really hard. Sometimes I wonder if I over exaggerate how hard it is, or if I’m the only one who sees, but time and time again I see such horribly written code that I know I’m right. I joke not; today I’ll get to maintain an application that uses:

<!–#INCLUDE FILE=”footer.aspx”–>

And that’s just one of literally hundreds of ASP.NET WTFs I’ve run into over the past 5 years. In my experience, the dont-get-its far outweigh the get-its and I have a hard time believing I’ve just been really unlucky.  Visual Studio 2005 and ASP.NET 2.0 have done their best to make things better, but the difficulties are so fundamental that no amount of abstraction is going to work. Worse, the abstraction is so high level, and the details so low, that you often get pretty serious leaks.

Almost all of the features that make ASP.NET a superior enterprise choice are significantly more difficult than what’s offered by the alternative web technologies. The page lifecycle is an incredibly powerful tool when understood and harnessed, otherwise it’s just a stupid pain in the ass that’s going to get in your way. Postback and viewstate are great, but it’s a significant shift from simply posting to a different page. So much so that 2.0 lets you do cross page postbacks simply because the paradigm shift was too much. But crosspage postbacks are a perfect example of leaky abstraction – the first time you use it, it’ll make a hell of a mess.

The issue runs much deeper than ASP.NET. C# and VB.NET are relatively hardcore languages. The entire VB6 support fiasco is more than enough proof. VB.NET is much harder than VB6, VBScript or PHP. Drag and drop gets you so far, then you are stuck having to deal with exceptions and classes. If you are one of the developers Alex is talking about, you are likely much better off with an untyped, procedural language. Even turning off Option Explicit/Strict won’t get you 1/2 way there. Then there’s the .NET framework itself with the thousands and thousands of methods, which you’ll need to use. Whether it’s encoding  ADO.NET, XML or IO you’ll have to get your hands somewhat dirty.

In my very humble opinion, PHP is a far better alternative to ASP.NET when it comes to the type of application Alex is talking about (I’d say classic ASP too if it was still being developed and probably Ruby on Rails if I knew more about it).  As a language, despite some claims, it isn’t at all an OO framework or much of an OO language, it’s exception handling is pretty primitive and it’s untyped. It’s also a traditional web structure, doing away with complicated bound controls, postbacks and server controls. What to display 10 rows? loop through your record and echo out some tr’s and td’s – simple. The only hang up with PHP some might have is getting it installed and the language if you’re a VB’er – but again, you’ll have serious language issues in ASP.NET anyways.

Everything .NET is simply amazing. I love ASP.NET, C#/VB.NET, ADO.NET and SQL Server. I can’t imagine doing web programming without writing HttpHandlers, code generating my domain layer and creating a lot of simple custom server controls. I’m amused that anyone would attempt to do serious enterprise architecture in a language/framework that wasn’t so powerful and complete (there are other alternatives, PHP isn’t one). Like most development tools however, try as they might, Microsoft will never make ASP.NET the best enterprise tool while at the same time the best mom-and-dad solution (or even close to).

ASP.NET is cool, but if you don’t get it I’d strongly urge you to use something else – I keep hearing amazing things about Ruby on Rails. Remember, it’s in Microsoft interest to tell you how great their products will be for you, but it might not really be the case.  Use the right tool for the right job, and if you don’t even understand the tool, than it isn’t the right one!

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to ASP.NET isn’t always the right tool

  1. adso says:

    I agree. ASP.NET is hard.
    As a 20 year veteren programmer who used to code three times faster than my peers on average, I have had trouble teaching myself this technology. What would have taken me hours in classic ASP takes days with .NET. There are gotchas everywhere. And the books don’t seem to come close to touching on the real problems that you get when you get your hands dirty. Even now I’m mystified as to why Control.Focus() sometimes works and sometimes doesn’t. So in the interests of time I am going to abandon it and do it the old fashioned way with javascript.

  2. stephen says:

    after all the years of dotnet being in existance, this article is still right on the nail.

    i work with a russian programmer, who proudly boasts:

    “.net is great, when i amend the work of colleagues, i see that they all do things in different ways – you have no idea until you open it. it is really exiting”.

    a support nightmare.

    in classic asp i had my working vocabulary down to about 7 pieces of syntax.

    just google all the idiots recursing through object libraries of controls to clear a form in dotnet when good old html has the reset button.

  3. bryan says:

    i do suspect that there’s more to the picture than just a technology or toolset. yes, programming is hard and in getting to grips with anything hard, there’s the obvious "what", but there’s also the "how". focusing software education on languages, OO, frameworks is more difficult if you haven’t been consciously taught to think critically and logically. these "soft" skills [inter-alia] are usually by-products of good training methodologies but very rarely the focus. if a programmer is taught [mentored] into "thinking" about what they are doing, perhaps they’d be more inclined to confront themselves along they way.. and ask "WTF am i actually trying to do? this doesn’t fit into the INSERT TECH HERE "philosophy/way/mindset"

    – and those with the ability, have the responsibility…

  4. karl says:

    I’m certainly not blaming the tool (or the tool creators). I agree that you’ll see bad code in INSERT TECH HERE. My point though is that maybe the tool’s too hard and so it isn’t the right tool.

    An apt anology might be giving someone a hammer and telling him to screw in all the screws. Of course he’ll just pound them in.

    Before a good manager even decides to send off his crew on proper training, he/she should figure out they need to be trained in.

  5. shebert says:

    I believe there are two types of programmers – performers and seat-warmers.  WTF code like the <!– include… bit you mention is mostly created by the former.  These are developers who approach a new platform by first trying to shoehorn their understanding into it.  When all else fails, the start reading.  I’ve seen this happen to developers for years, whether it was DOS->Windows, c->c++, VB3->VB5 or c++->c#/java

    Unfortunately, MS has tried to attract seat-warmers by calling them Morts and developing tools around them.  I think this changed somewhat with .Net as MS finally abandoned the OO-mini model that <=VB6 supported, but not completely.

    Not only is ASP.NET difficult, but programming itself is difficult.  If it wasn’t, demand for programmers would be a non-issue.  It would be nice to see tool builders focus on performers instead of seat-warmers and then see how the tools evolve.

  6. ewise says:

    “And that’s just one of literally hundreds of ASP.NET WTFs I’ve run into over the past 5 years. In my experience, the dont-get-its far outweigh the get-its and I have a hard time believing I’ve just been really unlucky.”

    If you give an idiot a hammer, and they pound a hole in the wall, it’s not the hammer’s fault.

    Actually I’m in the process of re-writing an enterprise asp .net 1.1 app. The existing app suffers from a multitude of performance, reliability, and maintainability problems. What is the root cause in almost every problem we find?


    You see in this app what you are posting about above, people coding in .NET like it is classic ASP, or Foxpro, or .

    It’s not the fault of the toolset, it’s the fault of the developers who don’t know the tools, and the fault of the managers that toss them into new tech without proper time for training.

  7. Alex Lowe says:

    While I share some views you’ve expressed Karl, I also differ on a few…..

    *I believe that much of the “ASP.NET WTFs” exist because of legacy knowledge of classic ASP. I mean, these things exist not necessarily because of anything to do with ASP.NET but because we as humans like to be comfortable and because Microsoft made it possible for us to stay comfortable (potentially to a fault).

    *The problem, in my mind, with saying that PHP or ASP are a better tool for smaller applications is one of context. I contend that some decent percentage of these applications are written by people who, if left with PHP/ASP and the IDE/tools that support those languages, couldn’t produce what they can with ASP.NET and the supporting IDE/tools. That is to say, ASP.NET 2.0/VS2005 provides a much more powerful toolset for the uber novice developer to build applications than PHP/Zend IDE.

    Now, I do recognize that there is a class of developer who is not an uber novice but who also is not capable, willing, or interested in fully grasping ASP.NET. I’m not sure what the solution is for these people. Microsoft obviously felt it best to allow them to continue doing things the “old way” even in the newer technology (which leads to ASP.NET WTFs for those who dont think that way).

    At the end of the day, for me, I believe Microsoft/ASP.NET team has done a pretty good job taking the only path they really could take if they wanted to make their toolset available to a large developer audience. Yes, it’s a “one size fits all” path but when you break down the developer audience on the web it is quite possibly larger than the developer audience in any other arena. The tools definitely work for 80% of any developer’s scenarios and I think that is a commendable goal for a toolset with this kind of reach/audience. That’s not to say there are many improvements to be made or other approaches that could have been as successful. If I were a betting man though I’d have taken the path that the ASP.NET took with the toolset.

  8. the problem is the coder, developers often assume that they don’t need to study or read on new stuff, I’ve seen way too much C# that is "VBish", just because the guy is a "architect" or "senior developer" they think the way they do things is the right way, and if it works, they don’t worry about exploring finding better ways