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.

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!

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.

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.

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…)

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!

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.

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