ASP.NET Is a Leaky Abstraction

A manipulation of the classic Mona Lisa shows her holding a mask revealing a smiling, ugly face. At work, we have been using .NET and C# since around 2002. Writing from a mid-tier development perspective, I have to admit I have liked it. However, writing as a web developer using ASP.NET (Microsoft’s attempt to abstract away the creation of HTML so that it can target non-web developers/mid-tier/VB-like developers to use their IDEs and platform) is another story!

ASP.NET has been problematic for many web developers/designers trying to do the “right thing”, such as

  • Use web standards
  • Output semantically meaningful markup
  • Develop to standards, rather than browsers for cross-browser development
  • Use progressive enhancement concepts to cater for as many user preferences and technology limitations as possible
  • Create sites that are as accessible as possible without unnecessary trade-offs with the visual design
  • Create sites that are friendly for SEO
  • Create lean and optimal markup for quicker download
  • etc.

(ASP.NET 1 was far worse, and version 2 allows many of the above to happen, but not all, and not always easily.)

Describing the problems caused by the poor quality and bloated markup and the weird/wonderful/complex/ugly/hacky ways to work around this seems to take ages. Some fans of ASP.NET don’t like to hear it when going into these details, and react defensively. And, to be fair, these problems are not unique to ASP.NET, either.

But recently, I rediscovered a summary explanation to help explain why ASP.NET is often problematic from a web developer’s perspective:

ASP.NET is a leaky abstraction:

That term, “leaky abstraction”, was coined some time ago (end of 2002) by Joel Spolsky, a prominent writer on software development and he was noting the problems with ASP.NET way back then.

In teaching someone about ASP.NET programming, it would be nice if I could just teach them that they can double-click on things and then write code that runs on the server when the user clicks on those things. Indeed ASP.NET abstracts away the difference between writing the HTML code to handle clicking on a hyperlink (<a>) and the code to handle clicking on a button. Problem: the ASP.NET designers needed to hide the fact that in HTML, there’s no way to submit a form from a hyperlink. They do this by generating a few lines of JavaScript and attaching an onclick handler to the hyperlink. The abstraction leaks, though. If the end-user has JavaScript disabled, the ASP.NET application doesn’t work correctly, and if the programmer doesn’t understand what ASP.NET was abstracting away, they simply won’t have any clue what is wrong.

Joel Spolsky, The Law of Leaky Abstractions, November 11, 2002

I think this is a decent summary description that can be useful for constructive discussion on what to do about it (if anything).

Abstraction without understanding = problems

Of course, this is not just an ASP.NET issue, but a general problem in software development, as Spolsky added:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

Joel Spolsky, The Law of Leaky Abstractions, November 11, 2002

This helps explain:

Why non-web developers or IE-only web developers like ASP.NET
It is an abstraction, so you don’t worry about it
Why web developers/designers despise ASP.NET
The abstraction leaks, horribly at times, and you want to worry about what is being abstracted

What is still interesting is that as a software developer (not necessarily a web specialist), Joel has understood some of the problems web developers and designers will have with .NET even though many Microsoft converts and ASP.NET fans do not!

Many software developers look down on web developers, thinking things like HTML and CSS are beneath them (its “just” the UI, or that JavaScript is not a real programming language, etc).

While those attitudes are generally changing, many software/mid-tier/non-web developers I come across still hold some of these views and don’t want to write anything in these languages, preferring the safety and familiarity of their IDE! (To be fair, some of these concerns are quite valid, too, and the principle for supporting the abstraction is actually often good; it is just that with web technology at the level it is at now, some of that abstract necessarily has to leak…)

Negative perception of IE and ASP.NET for Web Developers

It is interesting to note at various conferences like @media, @media AJAX, and on various blogs by noted web developers and designers, Microsoft gets a lot of stick for its IE web browser (as it is recognized as the poorest in quality of all the modern browsers, with the most bugs, biggest divergence from web standards and causing the most headaches for modern web development).

Indeed, since winning the “browser war” IE has stagnated and because of its dominance, web technologies have hardly changed in the last 10 years (we are still on HTML 4.01/XHTML 1.0, CSS 2.1 etc). As I posted earlier, IE has slowed down web development progress in recent years.

Combine that with the poor quality markup typically generated by ASP.NET, there has been a lot of criticism from the web development community aimed at Microsoft for either not caring about standards (or, as with ASP.NET 2 and IE 8) caring about it as an after thought or when threatened by rivals.

Here is quite a telling quote summarizing some of the implications:

I sympathize with your situation, but you desperately need to get your seniors and peers to understand what’s happening, and to assign your team way more resources. IE is a first-impression MSFT product for most web developers, and yet you all continue to underestimate the dramatic spillover effect this poor developer experience has had and will continue to have on your other products and services.

Let me drive this point home. I am a front-end programmer and a co-founder of a start-up. I can tell you categorically that my team:

– Won’t download and play with Silverlight
– Won’t build a Live widget
– Won’t consider any MSFT search or ad products in the future

And the reason is because of IE – because MSFT disregards its most important relationship with us. Until this relationship is repaired, nothing else stands a chance.

Please fight the good fight and drive this point home in your org. Good luck.

Anonymous commenter to The First Year of IE7, November 30, 2007

It may be seem a bit harsh, as some developers and technical managers at Microsoft certainly seem to “get it”, but for whatever reason it has happened and left a sour taste in the mouths of many web designers and developers.

Leaky abstractions lead to productivity loss and unnecessary trade-offs

As I blogged earlier, the WYSIWYG paradigm that Visual Studio and other such IDEs encourage, is often inappropriate for web development as it encourages bad practice such as non-semantic markup.

The perceived productivity gains of such editors vanish when needing to deal with typical web related concerns (semantic markup, accessibility, progressive enhancement, SEO, etc). In fact, what often occurs is unnecessary trade-offs. E.g.

  • A back-end developer uses an ASP.NET control that offers quick development with sophisticated capabilities just by dragging it onto a canvas and setting a few properties.
  • A web developer then claims that control is poor from all the web development perspectives and lists a number of things to change.
  • The back-end developer resists (especially if it comes from a “lowly” web developer!).
  • Trade-offs are then made (or not).
  • Reworking in full (if embraced at all) takes a long time.

Even though ASP.NET 2.0 is far better than 1.x, the abstractions still leak; it is too easy to create sites that either

  • Rely on JavaScript
  • Violate, or easily encourage ignoring, basic accessibility
  • Encourage further leaky abstractions because of the ease at which various ASP.NET controls can be created (the idea is good, but the fundamental leakage means that it will carry through to various controls).

So what can people do?

As an overall thought: by its nature, abstracting away HTML is almost guaranteed to result in a leaky abstraction.

Instead, it may be better to embrace the reasons for the leak, and provide cleaner separation while empowering people to work with the markup, given it is so crucial from so many perspective.

So here are some examples of a few ways to deal with the challenge, all with their merits for different purposes. Your mileage with each option will vary according to need. In addition, it is not a complete list; there may be other ways to achieve what you need:

Strict discipline with the controls you choose to use

The controls idea is certainly nice. ASP.NET and others (e.g. Java Server Faces) have put a lot of resources into this approach, and is certainly appealing from various perspectives (packaging components, reusability, productising components, etc).

Despite the problems, trying to stick with the principle of controls based abstraction may still be worth trying to pursue.

If so, I think it would require being VERY careful about third party controls you use, or purchase.

The other problem I see with this is in the case of medium/large teams; this strict discipline is unlikely to hold for too long, and eventually a developer with less experience on web development (or no inclination to do the web bit) will insist on using some poor quality controls that offer perceived productivity gains (“they can fix the problems you highlight to them!”, or “it looks okay”, or “people with accessibility needs don’t use the web, so it doesn’t matter!”).

Your mileage on this option will vary, depending on your team and project, etc.

Inherit and override problematic controls

Don’t like the way asp:label outputs its HTML? Override its Render() method. Same with any other control.

Sounds nice and easy enough, but this option is likely to run into trouble when someone invariably will want to use or integrate a composite, possibly third party, control written elsewhere that cannot be overridden (easily). So ASP.NET adaptors may be a better alternative than this one.

ASP.NET Control Adaptors

Also known as CSS Adaptors (which reveals a fundamental misunderstanding; developers want semantic markup for all sorts of reasons, not just creating CSS-based layouts).

This approach tries to give developers the opportunity to clean up the HTML output by overriding the default implementation.

The kind of problems I see with this approach:

  • Code examples I have seen that look awful — lots of string concatenations, obscure configuration settings, etc.
  • It may not always be easy to deploy a quick change after initial development (need to recompile a .NET Assembly, for example).

Despite the potential problems, it may still be a useful option if there aren’t any other alternatives.

(Does this approach help prove the abstraction fails?)

Do nothing (wait for Microsoft to fix it)

It may seem odd to entertain an option of “do nothing”, but I often think this is an option that should be considered in many situations, if not just for completeness but because pondering on this may let you think out of the box, so to speak.

Why should this option be entertained for ASP.NET? Well, you could take the approach of:

  • It’s not my problem; I just want to create cool apps
  • Microsoft will always fix it; we can just wait
  • If we get sued (accessibility compliance) or our bosses/managers complain, we can just blame Microsoft
  • The abstraction might be leaky now, but that doesn’t mean it always will — look at the improvement of ASP.NET 2 vs ASP.NET 1.x
  • I’m so fed up I have lost the will to live and do anything else other than just be assimilated 🙂
  • Problems? What problems? (Already assimilated a long time ago 🙂 )

And so on.

Needless to say, I would disagree with many of these perspectives. For example,

  • I feel as a web developer, it is out responsibility to use the tools available to create sites that are as accessible to as wide an audience as possible.
  • Claiming ignorance, or actively avoiding issues you know are there somehow does not feel right.
  • Microsoft may certainly fix these issues over time. Reading blogs and interviews of key people in ASP.NET and Internet Explorer teams certainly gives some hope for the future, but it depends on whether you think you can wait or not (and whether you have enough information on when they will release specific fixes that are important to you).
  • The controls paradigm might always be leaky regardless of what is done. I think it would still be important to know the output that is being created in order to fully understand the implications of what you are creating. If there are problems with the site, you are likely to have to sort it out, not Microsoft (or any other vendor/framework you go for).

For many web developers who know exactly what they need, having a tool do it for you, and to a lower quality, will be infuriating. Knowing it can be done better (not just for one’s own ego, but because it is good for the user/customer) can be compelling enough to want to do something about it.

Indeed, a principle behind a number of open source frameworks has been to try and make the web better, and keep it open because it is felt that open standards and related principles will lead to greater choice, diversity and vibrancy of the web. (Indeed, a lot of “Web 2.0” and the social web has come about because of open source technologies and ideas.)

Use an open source alternative

Those loyal to Microsoft will not like to hear this, but this is a decent option in many scenarios.

As Simon Willison, co-creator of the popular Django web framework said a few years ago, one of the key benefits of the open source approach is you are in charge of your own destiny.

(I’m not going to debate the open vs closed source paradigms here; that is not the purpose of this blog. I will just say that I didn’t use to buy the arguments of open source in the past, but in the last 3 or 4 years I have come to respect it a LOT more — I have not regretted moving to Linux at home recently, one bit, for example, and looking at the types of projects flourishing is quite encouraging.)

Don’t use ASP.NET, but don’t throw the baby (.NET) out with the bath water (ASP.NET)

Okay, so for some scenarios, completely changing platforms may not be an option.

In addition, I have to admit, programming in .NET (C# 2, etc) is nice.

Although Microsoft may be losing credibility with web developers because of the poor quality Internet Explorer browser and because of the problems of ASP.NET from a web designer’s perspective, .NET more generally is actually quite good.

Unlike on the Internet Explorer side of things, the MSDN blogs seem to be more active regarding on-going developments on .NET. Scott Guthrie, for example, has an immensely useful and popular blog on all things about Visual Studio, ASP.NET etc. (Scott Guthrie is General Manager of development teams that build the .NET CLR and the core .NET Base Class Libraries, ASP.NET, Silverlight, IIS 7.0, Visual Studio Tools for ASP.NET, WPF and Silverlight.)

For some projects we have successfully used .NET but by-passed the ASP.NET controls, using XSLT instead.

XSLT — an open standard

Using XSLT to generate the output can be one way to overcome limitations of proprietary frameworks where you lack control of the output (ASP.NET) or where other frameworks may be open source but you have to learn their templating conventions.

XSLT can also make the markup generation simpler to unit test as part of a developer’s daily work, which is not always the case (or not necessarily as simple) in other templating systems, because you don’t have to be dependent on a running web server and all the set up that would come with it (thus making unit tests quick to run as well, increasing the likelihood of them being used and maintained).

Being platform agnostic, XSLT can be an effective part of a View in an MVC framework and be applied to different frameworks and platforms, reducing up-skilling costs in the long term.

If you consult or contract for a number of customers/clients, it would be nice if there was one common skill that is portable across all these frameworks (just like HTML/CSS/JavaScript typically is on the client side). XSLT could be such a thing, potentially, all the while giving you full control of the markup that you need to be create.

In my experience, and those of some of my colleagues at work, using XSLT to by-pass .NET controls has actually been more productive from an overall development perspective because we save time that would otherwise be needed battling the controls trying to force or work alternative markup options, building accessibility, etc. (And we have architected/developed sites for one of the largest online retailers in the world, so the strategies are not merely wishful thinking, but reasonably proven).

XSLT may not always be appropriate in all cases, and many are certainly put off by its oddities or perceived limitations. But, perhaps XSLT deserves another look?

(Indeed, a follow-up post does just that, starting by looking at XSLT in server side web frameworks.)

Do you find these problems with ASP.NET for your sites? How do you overcome them, or do you just stick with it?

Image credits

“Mona Unmasked” reposted with kind permission from gravityx9 from flickr. See the original image at http://www.flickr.com/photos/gx9/354387041/.

23 thoughts on “ASP.NET Is a Leaky Abstraction

  1. Hello Anup,

    This is awesome! I came across your blog as a result of your kind reply to my inquiry at ParticleTree. Thank you very much, by the way, for taking the time to explain that JavaScript querystring issue to me.

    After reading the ParticleTree article again, it dawned on me that it could be a PHP or .htaccess re-write thing.

    At any rate, I love your blog and especially this article. I am having almost exactly the same issue at work. I’m the development manager (it’s just a title), coming from old school web design. All my developers are C#.NET whiz-kids who know a ton about frameworks and design patterns…but almost nothing about X/HTML and client-side issues.

    Thank you for taking the time to write such a great article. I’m certainly going to print this out and study it in more detail.

    Keep up the good work!

    WebGyver

  2. Anup,

    Good post – I was just checking out your site following the comment you made on mine.

    I will just add one bit as something to think about in addition to all the points made above. When work started on the ASP.NET UI framework, and indeed a lot of the ASP.NET infrastructure is independent of, there were two things motivating the form it took:
    – The type of developers who needed to be attracted to the platform, and the type of components and building blocks that spoke to them. The point was to get some level of high-level components for a quick start, as opposed to making one think about the underlying HTML all the time.
    – At the time, the abstractions over HTML and CSS were actually much more useful – browsers had all sorts of differences and levels of support of HTML/CSS – think HTML 3.2 and HTML 4 co-existing. Deep familiarity of HTML was also missing in the target audience.

    I’m not claiming the abstraction was not leaky. I think times have changed – there is deeper familiarity with the underlying platform, and the underlying platform has matured a lot, as well as become much more uniform than it ever was… at which point abstracting it raises some questions. I still think there are however lots of developers who will find the abstractions useful.

    ASP.NET certainly has a large spectrum of customers of who bring different requirements, and perspectives… in some sense that is a result of the success of the platform 🙂

  3. Nikhil,

    It is very kind of you to comment on this minor blog, given your high prominence in the whole ASP.NET development, so thank you for your feedback.

    Your points are fair, and indeed I recognize that ASP.NET was targeted to a large audience base, many not web developers.

    I certainly appreciate that it has helped with wider adoption. VB-type developers and others who are used to dropping controls onto canvases and having stuff done for you in this way is certainly appealing.

    In fact, when ASP.NET first came out, I really liked this aspect. In training seminars that I conducted back in 2001 and 2002 when getting people onto .NET I often gave some previews of ASP.NET and the calendar controls in particular.

    It was later around 2003 I think that I became aware of web standards, semantic markup etc, and so that is why as developer coming from say a mid-tier or GUI background, I can see the appeal of ASP.NET, and why if I put on a web standards developer hat on, I see issues on the client-side of things!

    You make an interesting point about the state of HTML at the time, with 3.2 and 4 etc — I remember hearing about ASP+ around 1999 or 2000, I think. It is interesting that the scale of .NET naturally meant it took a while to deliver, and perhaps something that is hard to know over such a time is what the state of web development would be over time.

  4. Excelent article.

    I started to use XSLT for front-end programming 3 years ago, when I worked with classic ASP. For the last year and half I been doing strictly ASP.NET WebForms, and I must say I’m done with it, but for an architectural reason, it is not good practice for your coordinator layer to depend on the presentation layer (that’s a WebForms vs. MVC discussion). WebForms without postbacks looses it’s appeal.

    However, I don’t agree on the “Abstractions are leaky” point. You’ve said it before, “Abstraction without understanding = problems”, but if you do understand then it’s OK. Controls can render good markup, unfortunately many of the built-in ones don’t. Also you can have more control of the markup using ITemplate properties.

    I’m currently using Saxon on .NET, XSLT 2.0 is to good to look back. .NET is too good to look elsewhere. Go Mono!

  5. @maxtorog: Thanks for your comments. But do my first three options as to what to do cover your concerns?

    I acknowledged that you can create decent markup with the controls but that it requires discipline. I didn’t make it clear, but my point about the problem with this approach is in a medium/large team environment it may be hard to maintain that discipline, whereas on an individual/small project maybe it is easier. (I will try to update that section shortly to clarify that).

    Also, I mentioned options to override control rendering, but the problem I see is when dealing with complex third party controls; it may be a lot harder to change them (especially if they are producing lots of JavaScript etc…)

  6. Another option you have missed it the upcoming ASP.NET MVC Framework.

    At MS they acknowledged that the WebForms (the problem is WebForms, not ASP.NET as whole concept), while was successful because it allowed tons of VB developers and WinForm developers to move to the web development world, hide to many details of the web development scenario. So they are now building an alternative web framework built on the MVC pattern.

    If you haven’t, I recommend you have a look at it.

  7. @Simone,

    Thanks for the comment. Yes, have seen (only very briefly) the ASP.NET MVC framework. I thought I mentioned it above, but clearly I haven’t. I double checked and saw I mentioned it in the follow-up XSLT article. I will try to add something here, to that effect, shortly.

  8. You have completely misunderstood Joel and the concepts of abstractions and leaky abstractions. What Joel mean by his blog is that ALL abstractions leak. Now to fix that we need to stop using abstractions which of course is completely insane to do since then we’d hardwire bits onto the CPU when creating software. Though what you should not do according to Joel is to trust your abstractions to work without you having to get knowledge about how they work and why they work the way they do. One of your quotes from Joel even says it without you probably realizing it yourself; “So the abstractions save us time working, but they don’t save us time learning.”…

    I am using knowledge about CISCx86 real-time assembly development EVERY DAY in my work even though I haven’t developed one line of code in ASM in more than 10 years. Though to truly take advantage of things which are “extreme abstractions” like managed languages, HTML and CSS I still need to know how a CPU works. That’s the whole point, to say that “ASP.NET is a leaky abstraction” is like saying “you get wet if you swim in the ocean”. Of course it’s a leaky abstraction. ALL abstractions are leaky!

    ALL abstractions are leaky!

  9. @Thomas: Thanks for your comment. Yes, I agree, Joel’s point was not just about ASP.NET, but about software in general. I even noted that above in the article stating, “Of course, this is not just an ASP.NET issue, but a general problem in software development.”

    I wrote this post with a web developer audience in mind, specifically raising concerns about abstracting away the ability to control the HTML generation for web developers who want more control over these aspects. Hope that clarifies things.

  10. ASP.NET contains many controls which don’t add any HTML, CSS, or JavaScript markup, such as the HTML server controls, the Literal control, the ListView control, the PlaceHolder.

    Learn to use ASP.NET properly and you can do whatever you want with it. I only use the controls mentioned above.

  11. ASP.NET Web Form is just one attempt to abstract web development. It’s an attempt with huge success. Most Enterprise applications used to be Win form based, but Win form based apps are hard to deploy and upgrade. That’s why now they are all converted to Web based app because it’s single point of deployment. Under those circumstances, who cares about web standards? Who cares about browsers. You have to use IE and as long as it works and you can develop the app in the shortest amount of time, you are gold.

    I can tell you that business managers/directors will not have any patience to listen to your explanation about Web Standards, etc. If you can’t deliver the app in one week, your web standards are rubbish. They become your excuse not being able to deliver on time and within budget.

    They don’t care if it’s aesthetically appealing, or if you can change the skin with great ease. They want the functionalities and the deadline is yesterday!

    So for the vast number of applications, Web Forms deliver! And Web forms are changing for the better. It’s just second iteration. Give it time.

  12. great comments from Michael C. Neel I thought I would like to share:

    http://devlicio.us/blogs/vinull/archive/2008/07/25/the-mvc-minefield.aspx

    The MVC Minefield

    There is a bit of turbulence in the ASP.NET airspace over MVC (yes, I’m making this post while on the fight back from the ASPInsiders Summit). Even among the ASPInsiders, who are supposed to be at the cutting edge of ASP.NET, there is little agreement over what is MVC and what it’s for.

    MVC, or Model View Controller, is an age old pattern found in many places. ASP.NET providers follow the pattern, as does Service Oriented Architecture. The general idea to have some code called a Model that works with your data storage, other code called a View that displays the data, and last plumbing code that ties these two together, called the Controller. I call it a pattern because implementations differ in the details – the View may render a button, but when the user clicks that button should the click action be handled by the View or Controller? The Model and View should know nothing of each other, but is the Controller allowed to be tightly coupled to them both? (If your first thought above was the Controller should handle the button action, think now what this means about being loosely coupled between the View and Controller).

    ASP.NET MVC is a framework in development that is intended to closely match the MVC pattern. The minefield lies in answering the pragmatic question of what does ASP.NET MVC offer over WebForms, and when would you use MVC? In taking with those excited by MVC the reasons range from supporting TDD, clean URLs and avoiding postbacks by sending actions to a controller, better control over HTML output (including getting rid of ViewState), and being closer to the http protocol.

    TDD, or Test Driven Development, will always come up in any ASP.NET MVC conversation, but TDD itself isn’t an explicit part of MVC. The MVC pattern is very amendable to TDD however, and thus the association. I generally support testable code even if there are no tests around the code. Testable code is much easier to maintain, enhance, refractor, and replace. I don’t find the process of test-first development helpful, but I do write tests in the same session as the code when I know I’m writing some critical piece of functionality that needs to survive multiple versions of the software. As Hanselman noted, I’m like the “person who goes to church on Easter and Christmas” and I’m sometimes looked down upon by the congregation who attend weekly. I’m okay with this, but I have some reservations with MVC as a framework for TDD.

    To say you cannot test WebForms is a strawman argument; there is no trouble in separating the Model and testing it thoroughly. Depending on how you go about it, you can also separate the Controllers and test them – I generally have very simple Controllers that pass user input into the Model as is, so testing the Controller is not that important to me. Testing the View in WebForms is very difficult – and this isn’t specific to WebForms. My objection to claiming MVC has testable Views is the implied definition of testing. Verifying the output HTML of a View is not helpful at all – it’s just string comparison. I want to write tests like Asset.JavascriptRunsOnSafariMac() and Assert.IE8RendersSameAsFireFox3(). If MVC could do that, then I would be switching to it today!

    WebForms provides a very robust SiteMapProvider interface that makes it easy to clean up urls of dynamic content. Global.asax can be using to control routing of requests (in fact this is how MVC does it as well). The biggest problem I’ve had here isn’t WebForms fault, but IIS6’s inability to allow ASP.NET to handle requests without an ASP.NET extension in them: this is solved in IIS7.

    You can get fine grain control of HTML in WebForms, ever with just the stock controls. There is also an entire collection of HTML server controls to match HTML tags to make it easy to generate HTML from code (I hate seeing tags hardcoded in source file, feels dirty and hackish). About the one thing that is hard to do in WebForms I deal with somewhat often is controlling the client side ID’s, which can become quite long and fugly looking. For CSS you can just assign a class name instead of using ID references (and there aren’t many places I’m using CSS IDs except for layout divs that aren’t coming from ASP.NET controls anyway). Javascript is trickier; you need to inject a reference of Control.ClientID on the server in the client script, and the need is much more common than with CSS. If you have an external JavaScript file this can get worse, but I believe that an external JS method should take the ID of the control they work with as a parameter making it easier to read the external file without the need to reference the aspx code. At the end of the day however, I’m not willing to throw the “baby out with the bath water” and will lean more on Microsoft to fix this issue in WebForms rather than jump to MVC.

    The last reason for MVC I mentioned, being closer to the http protocol and its stateless nature, I simply don’t grok. Any application with a basic level of user interaction will need to mask the http protocol’s implementation details to provide a positive user experience. Web programmers of all frameworks and languages have realized there are only a few methods to solve this problem; cookies, url parameters, and hidden fields. Any state solution will involve one or all of these – even if state is stored on the server’s side. WebForms supports all of these methods, and you can disable things like ViewState (hidden fields) if desired. (I am aware there is also ControlState that will be still emitted if ViewState is disabled, but I’m willing to say that if these few bytes are an impact you are working on an edge case).

    I’m not here to bash ASP.NET MVC – to the contrary I’m here to help by outlining the faults in the current arguments for MVC. If MVC is defined by the features in or not in WebForms, then it’s going to be hard for those deep into WebForms to see value in MVC. It becomes a song of “anything you can do, I can do better (no you can’t, yes I can)” and will deadlock when neither side is listening to the other. ASP.NET MVC need to be defined without claiming faults in WebForms, because that only says use MVC because WebForms is broken – leading one to say, “why not just fix WebForms?”

    I wish I could end here with a new explanation of ASP.MVC meeting the requirements I’ve just stated, but I’m afraid I can’t. This is a fault with me, and not the MVC framework – I’m too close and deep into WebForms to see a need for MVC I can’t fill already. It’s my hope and request that instead of seeking to pick apart this post, the supporters of MVC come out to define MVC without attaching that definition to the perceived faults (for that’s the minefield) of WebForms.

  13. Pingback: Foray into ASP.NET MVC « nicholascloud.com

  14. Very interesting article, but I have some big questions around some of the “headlines”!

    Joel does go on to say that you are pretty much guaranteed leaking in any reasonably complex abstraction, so I think its wrong to present it as a solvable problem. Or as something uniquely bad in ASP.NET…

    If an abstraction of web page development were to be entirely non-leaky it would not be an abstraction at all, it would in fact be a translation.

    Lets be quite clear, abstraction (even in its inevitable leaky form) is a VERY good thing. Without it we would all have to know everything about the lowest level details of every task we undertake and productivity would literally seize up.

    The story of software development is the story of increasing abstraction. Its unwise to try and stand in the way of this march of progress! ;>)

    We just do not have the capability or capacity (or the inclination) to train the numbers of people required to learn the non-abstracted version of web development.

    Now we come to the more subtle point that every abstraction of a domain will leak in different ways.

    Maybe you just don’t like the ways that the ASP.NET abstraction leaks?

    Or maybe you are a die-hard purist and can live without any abstraction of web development at all – well, that too is fine but what about the rest of us mortals?!

    I think its actually quite an “elite” view to give the impression that the millions of useful/interesting/valuable web pages produced by this ASP.NET abstraction are somehow not of any worth?

    And if you don’t think they are worthless (don’t want to put words in your mouth!), then you surely have to give some credit to the “leaky abstraction” of ASP.NET that allowed people to produce them?

    Let me put it another way, not every machine that people use to perform useful/valuable/enriching work or leisure has to be an example of the finest engineering.

    Its like saying we must all be driving around in highly engineered Ferraris, when for most of us we can get what we want from a car with a Nissan.

    I think there is a certain purist attitude (which I can understand) that is offended by these “awful Nissans” filling up the pages of the web with their poor underlying engineering.

    But the truth is if they do the job they are intended for then that is my definition of perfect engineering.

    All-in-all a great article though and very thought provoking!

  15. To put it another way: I don’t think that the leakiness of the ASP.NET abstraction was a “trap” that the developers fell into. Rather, this leakiness is an essential aspect of the ASP.NET project.

  16. Jon, some interesting comments there. Few thoughts:

    The article was specifically about the frustrations that ASP.NET Web Forms has for web developers who want a lot of control over the markup produced. Of course, HTML/JavaScript/CSS are themselves abstractions (with their own leaks!). Everything on top of 1’s and 0’s are an abstraction, so I am not saying that leaky abstractions are bad per se.

    My specific gripe at the time was about control of markup being difficult with ASP.NET Web Forms. Especially where client side performance, accessibility, progressive design type of concerns have long put off many web developers and designers from working with ASP.NET, which is a shame as much of the .NET platform is quite powerful.

    Since writing the above article (about 3.5 years ago) ASP.NET MVC has come out. In my opinion, their MVC implementation is really good and from what I can understand of the various reasons MS came out with it, one of them included the ability to provide web developers better markup control (as well as improving testability, and so on). That alone tells me they recognized that the markup control was a particular issue they wanted to address.

    (ASP.NET MVC had just started to come out when I wrote the above article so didn’t mention it as much as I hadn’t really looked at it then though some others did in the comments). Since then, I’d be really willing to consider MVC over the above-suggested XSLT approach which has worked well in some scenarios.)

    Nikhil Kothari’s comment above also hints that for the time ASP.NET was created it was probably what their target audience needed, which is fair enough. But just a few short years after it was out, the landscape had already changed; a lot of developers wanted more markup control and it isn’t easy in an ASP.NET Web Forms world (certainly not impossible as I also note).

    ASP.NET MVC certainly feels like it has addressed this particular problem. I should probably update the title of this page now to say ASP.NET *Web Forms* is a Leaky Abstraction, anyway 🙂

  17. Hi Neil,

    The Joel Spolsky quote I used had an example (link buttons that require javascript to post back when clicking a link and don’t work with JS turned off).

  18. So do you recommend avoiding all uses of AJAX too? I would find that a hard call to make with any technology let alone ASP.NET WebForms.

  19. Hi Neil, no of course not 🙂

    Maybe more specifically Microsoft’s Update Panel mechanism for AJAX may be something to avoid from time to time as it posts back everything and in some cases (as they have noted) it can be slower than a normal post back. It is certainly a nice idea, to make developers not worry about the JavaScript plumbing needed for it, but that is perhaps another example of an abstraction that leaks (kind of).

    As I said in the article, if you are aware of the various issues then you are better prepared to use them if needed – its all appropriate trade-offs at the end of the day – there are times when we’ve opted to use Update Panels in certain circumstances for our back office app where pragmatic (the cost of refactoring/rewriting the controls that take part in the Update Panel was too high, for example).

    Since writing the above (a long time ago now), MS have of course embraced jQuery which has a lot of ajax capabilities which you can control more, too.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.