onenaught.com

Posted on: Wednesday, January 2nd, 2008 at 7:41 pm

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/.

About this post

This entry was posted on Wednesday, January 2nd, 2008 at 7:41 pm and is filed under General Web Development, Server Side. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.