This content is in the "archives" of Gadgetopia. It has been moved to this subdomain as it is no longer considered relevant to the site. It is being hosted here for a indeterminate period of time. Its existence at this URL is not guaranteed, and it may be removed at any time. If you would like to refer to this content in the future, you are encouraged to save it to your local file system.

On ASP.Net Web Forms

Originally published by "dbarker" on 2007-03-16 10:24:00Z

I was looking through the MonoRail project today, and I found this little nugget:

[…] Developers that were introduced to Web development using pure WebForms also lack the basics http protocol concepts required to use MonoRail (or any other web framework for that matter).

I’ve been working with ASP.Net a lot lately. There are somethings like I like – ViewState can be nice, as can the form validators and data binding. However, in general, I can’t stand it. And I do agree with the above statement a bit, though I wouldn’t have been so caustic about it.

ASP.Net is such an abstraction. It’s like one day Bill decided that we all knew too much about how the Web worked, and he needed to invent a framework that changed all the rules and hid all the scary HTTP stuff so that a generation of Web developers that he trained on his stuff exclusively would have a very skewed perspective about how the Web actually worked.

I hope that didn’t sound arrogant, but I do think that if you’ve never done any Web development except ASP.Net using Web Forms, then there’s a lot you missed about Web development.

Every Web developer is well-served by getting “close to the metal” occasionally with a language that has no framework or big set of rules behind it. Digging into HTTP requests and responses at the ASCII level is really pretty interesting. (Would you believe that I read the original HTTP spec once, all the way through? RFC1945, I think, but it’s been a long time.)

I’ve always maintained that there’s a difference between a “Web Developer” and a “[insert platform here] Developer”. If you’ve never done any work outside of ColdFusion, then you’re not a Web Developer, you’re a ColdFusion Developer. This is fine if you work in an exclusively ColdFusion shop, but you’re depriving yourself of a lot of learning by not digging into other languages and the core protocols in general.

Neal Stephenson – of Cryptonomicon fame – wrote a famed essay years ago called “In the Beginning Was the Command Line.” In it, he wrote this utterly brilliant paragraph about why it helps to learn more than one operating system. It’s long-ish, but do yourself a favor and read it (emphasis mine):

Young Americans who leave their great big homogeneous country and visit some other part of the world typically go through several stages of culture shock: first, dumb wide-eyed astonishment. Then a tentative engagement with the new country’s manners, cuisine, public transit systems and toilets, leading to a brief period of fatuous confidence that they are instant experts on the new country. As the visit wears on, homesickness begins to set in, and the traveler begins to appreciate, for the first time, how much he or she took for granted at home. At the same time it begins to seem obvious that many of one’s own cultures and traditions are essentially arbitrary, and could have been different; driving on the right side of the road, for example. When the traveler returns home and takes stock of the experience, he or she may have learned a good deal more about America than about the country they went to visit.

I’m way off track now, sorry. So, to get back to our discussion about ASP.Net Web Form exclusivity —

The problem with Web forms is classic Microsoft – they have a big set of rules and “extensions” to the core than you grow to depend on to the exclusion of everything else, and you don’t bother to learn how things actually work. Take away those extensions and you’re in trouble.

ASP.Net, for example, has a tendency to abuse the concept of GET and POST. If it were up to Bill, everything would be a POST and no one would ever know about silly things like querystring arguments, request bodies, etc. The whole “one FORM tag to rule them all” theory alone has caused me more heartache and frustration than I can articulate.

I think what annoys me the most is that I really like C#. It’s a great language, and the .Net framework is awfully well put-together. I really enjoy spending time with C#, but then along comes ASP.Net like the loud, overbearing, half-drunk uncle at a family reunion, tips over our picnic basket, and ruins everything.

When I first starting working with ASP.Net, I was convinced that I could abandon Web Forms completely. I tried working with just StringTemplate and HttpHandlers, but it became obvious that I was building an app for a client that a very limited number of people would be able (or willing) to maintain.

(Even though I abandoned it, I still use handlers every once in a while. It’s nice – the joy of C# without the pain.)

I have quite a bit more to say about Web Forms and the whole “HTML control” concept, but it’s for a different post. I’ll stop now and open myself up to be shredded in the comments. Have at it.

Comment by "Taylor Hughes" on 2007-03-16 12:34:00Z
I'm with you on this almost 100 percent. I actually had a lot of experience with ASP.NET-only developers at an old internship and here in school; their code tends to abuse the viewstate and utilize heavy postbacks like nobody's business. These people came directly from programming VB6 and VB.NET applications for the desktop. The concept that the DataGrid just shouldn't be filled with data anymore after somebody reloads the page -- actually, after they follow a link -- actually, excuse me, after they fire a Click event on that "TextButton" control or whatever it's called -- is almost impossible to get across. The ASP.NET platform is great, C# is lovely, and I've lamented many times about essentially not being able to use it for any personal endeavors thanks to its Windows-only nature. But tailoring the platform to people who don't know anything about actual markup, how web form elements actually work, headers, content types, accessibility, usability, ... and the list goes on, should not be dumped into programming for the web. Additionally, trying to program any extended functionality into a standard web form -- like utilizing an Ajax library, for example -- is like pulling teeth. Non-ASP.NET elements and ASP.NET elements together are like oil and water, and the hacks you have to pull on the client side to get some cool stuff to work is less than desirable. I remember opening my first ASP.NET book and being absolutely amazed at all the stuff the platform just... did. It was like magic. Coming from PHP and value="", it was amazing. After figuring out how it worked and the kinds of monstrosities that could be produced with it, however, I was feeling a little bit less enthusiastic :)
Comment by "hammett" on 2007-03-16 12:34:00Z
Wonderful post! And btw, I wrote that nugget. I heard from a co-worker "how do I associate an event with a button using MonoRail?"
Comment by "Deane" on 2007-03-16 13:56:00Z
>These people came directly from programming VB6 and VB.NET applications for the desktop. And that's just it: *Web apps and desktop apps are different*. They cannot be programmed the same way, and ASP.Net is essentially an attempt to make the two disciplines interchangeable, and that's patently ridiculous. Let me say this for the record: if you're a desktop developer and you want to learn Web development, *ASP.Net is the worst platform you could possibly choose*. It's going to do nothing but instill a bunch of bad habits which your experience is going to mis-interpret as real progress. Pick something like PHP which is as close to the metal as possible. It requires you to learn things that you need to know. Better yet, pick Perl/CGI and hand-parse a few querystrings. I'll go even further and say don't pick something like Rails. While I think Rails is great, you need to do some "naked" Web development first. Some ugly, Model 1 programming. Get your hands dirty -- roll in the mud for a while. Until you've seen how *not* to do it, you won't appreciate what's right, true, and just. Once you do that for a while, go back to ASP.Net. You'll be a better developer for it.
Comment by "Brian" on 2007-03-17 07:58:00Z
C# - Good. ASP.Net -- BAAAAAAAAAD. I'm in the process of taking our .NET web app, leaving the back-end intact (C# + LLBLGen) but ripping the front-end completely off and replacing it with plain ol' html + javascript (using the Ext JS framework, to which I am also a contributor). After suffering through the absurdity of trying to make ASP.Net cooperate with other "standard" Ajax coding principles for a while, I gave up. Working with ASP.Net is like a prolonged kick in the nuts.
Comment by "Bob Grommes" on 2007-03-17 08:29:00Z
It is not widely remembered that very early in the alpha cycle for ASP.NET there was actually some talk of having the ability for one code base to execute against either a WinForms or a web application. This was abandoned as impractical but still a future goal, and then the whole idea sort of evaporated. So at some level I suspect MSFT recognizes they have pushed this idea too far. I think the market success of ASP.NET is that it is a comfortable level of convenience and abstraction for Getting Things Done (i.e., "RAD"), but this tends to develop a technological debt that eventually comes due. I've been in the ASP.NET trenches long enough that I'm starting to get tired of the maintenance headaches and the obscure problems that ooze up out of the sub-basement when the plumbing starts to leak. Especially when dealing with some of the ASP.NET frameworks like DotNetNuke, which add their own neurotic problems on top of that base. I don't hold out much hope for a widespread defection of the mainstream away from traditional ASP.NET (for more, see below) but I am starting to lay the foundation for getting away from it myself, as much as I can. [](
Comment by "Matt Smith" on 2007-03-17 08:47:00Z
Good post. I had some similar comments a while back: []( We are still slogging our way through a project at my day job where we have tried to integrate some cool new Ext JS stuff but keep running into issues with ASP.Net. Not to mention, the developers that continually say things like: "We need to avoid JavaScript because it is bad" I love my job!
Comment by "Guy Peled" on 2007-03-18 06:55:00Z
Hi, I wanted to introduce you guys to Visual WebGui which is an extension to ASP.NET which provides a different pipeline enabling full WinForms like programming over web including design time capabilities. This provides an excellent way to develop complex AJAX applications like outlook we access in a very short time that can be compared only to R.A.D. environments. Check it our here: []( There are also some quick start videos that saves the need to imagine how it is to work with here: []( Guy Peled Founder & Chief Architect Gizmox -- Visual WebGui
Comment by "James Higgs" on 2007-03-18 13:36:00Z
+1 from me. I too had similar comments a while ago: [](*postbacks*harmful.htm
Comment by "Matt Smith" on 2007-03-18 15:44:00Z
Guy, I'm not sure you grasped the message that Deane was trying to convey. He wasn't saying that he needed some other abstraction layer or 4GL tool to keep him from getting his hands dirty coding. The point of the article is that too many people are growing up relying on the MS way of doing things that totally corrupts the standard approaches to web development.
Comment by "Casey" on 2007-03-19 08:56:00Z
Personally I like ASP.NET What I don;t care for so much is the attempt with ASP.NET 2.0 to appeal to the 'newbie' programmer, or at least the way they have tried to do it. ASP.NET 2.0 has, as far as I am concerned, a great number of features that are implemented purely so the programmer doesn't have to *understand* what is actually going on. Very few of the new features are implemented in such a way that they make your life easier, but require an understanding of the implications. MY least favourite of these is ObjectDataSource, which is a a perfect example of the new trend. It is a poorly thought out idea, underneath the covers the way it actually achieves what it does is beyond terrible, but it makes binding datagrids to objects *look* really easy and quick. In fact, it makes it *really* easy and quick, but the repercussions in a system that uses it can be terrible if the person didn't realise how it worked. Poorly thought out data access strategies are the largest problem in most systems, and this is just something that will create a new generation of 'ASP.NET Programmers' who only know the drag and drop way. And when an employer gets my CV and theirs, how are they supposed to choose, when they both say ASP.NET. And when the other guy uses ObjectDataSource and the other 100 new controls of the same ilk, how is the employer supposed to know that it was due to incompetent programming, they didn't employ anyone who could show them the same system running 100x faster with less resources.
Comment by "Deane" on 2007-03-19 13:25:00Z
You reminded me of another thing I hate: draggable, spatial controls for non-visual objects. I remember the first time I sat down with an ASP.Net book and read, "Drag the data source onto your Web form..." Um, what?
Comment by "argatxa" on 2007-03-19 11:15:00Z
I agree 100% !!! < rant=""> I have been on a team of VB developers that became "web developers" overnight... oh my god.... I am dreading the time that they move into .NET pages with the same style as with the classic ASP. ASP.NET is fantastic for quick websites, nothing too complicated, but if you try to make a full Web application, windows like but web... get ready to spend loads of time trying to adjust pixel here and there, overloading already bloated base components and, hold to your guns, write factory of factory factorial classes... ohh, and "lighweight wan-ready" Ajax libraries. gosh, instead of polishing and improving actual architectures and let the developer learn how to use the tools properly, MS just makes everybody rush to the next big thing. .NET 4 anyone? .NET has some brilliant features, but hacking/ the language instead of developing really put me off. And the fact that anybody with a book like "ASP.NET for dummies" can be hired as programmer really pushes me to get out of that path as fast as I can!!! As far as I am concerned I am out of ASP.NET dev, < rant=""> But I am still studying the certification toolkit for c# though... For Rad C# is nothing to sneer at!!! Disclaimer: I am sure that proper trained people are doing amazing stuff in ASP.NET, but.... they are not that many out there... or bosses that would allow/understand that you need some groundwork before start churning out pages..
Comment by "Liming Xu" on 2007-03-20 16:03:00Z
I?m going to have to mostly disagree and I?d like to put my 2 cents on this issue. I?m a J2EE developer during my day job and a .NET developer of [my own project management software]( So when I had to make a decision of what platform to choose for my software, I was careful. I really could swing either way, didn?t matter to me. First of all, I do concur for those who?ve only done using web forms, they?ve missed quite a few good ideas out there like Struts and JSF, but is it fatal? No. Struts and JSF has their own pitfalls. Can this be said for those who only used J2EE, PHP and Cold fusion? That they?ve missed a lot? Sure, I can say the same thing. Every framework has its good ideas that the others should learn from. Second, it?s amazing that the author read up on the original HTTP spec. However, to look for the same thing in ?web developers? especially developers? That?s a bit harsh. I don?t agree with the fact anybody doing day to day web development has to know the http requests and responses at the ASCII level, let along reading HTTP spec. It?s like asking everyone who uses Unix to know the kernel details, that?s just too crazy for me. Asp.Net does abstract a lot of details away from the developers, but in my experience, .net developers on the contrary know a lot about the underlying mechanism. To simply understand how the postback works, you have to understand what ?POST? means. To effectively understand the page life cycle, how page is loaded, how events are fired, what comes first, what comes next, you can?t get pass it unless you study the underlying mechanism. To use ViewState, we understand where it is stored and how it is stored. Why is it good and why is it bad. Such most experienced developers rarely use view state manually or if any at all unless they have to, such as when developing composite controls. Struts MVC and JSF is nice, but where do they retrain their values? Two most commonly used ones are sessions and request. I?ve seen way too many code stores everything in session, no thanks, I?ll stick with view state. It is my opinion that ASP.NET on the contrary is for more experienced web developers. The whole GUI component binding framework is meant for a strong 3 tier development. ObjectDataSource for example enforces this methodology, for people with no object oriented programming background it?s not easy to grasp. As for web standards and accessibility, like any other web frameworks, those who cares are fully aware of them. In fact, that?s what the CSS Adapter is developed for. For those coming from desktop or elsewhere like php or simply has no web experience what?s so ever, they tend to abuse it and do things that aren?t meant to be used. Drag and drop, extensively use the first thing a book talks about. . Long post, my point is, bad developers will be bad no matter which framework you give it to them, I encourage those to read up more on ASP.NET as I personally think it?s a good alternative albeit not a better framework than Struts/JSF. The only reason I choose ASP.NET over J2EE/Struts/JSF for my software is not because of the framework. It's because J2EE development is not easy to first set up. There are lots of integration issues between various frameworks, building tools, in addition to compatibility issues with their deployment servers. For example, ACEGI filter no longer works here with the new Websphere You want help with it? Well, not everyone has websphere, good luck on finding support on it. (Good thing we finally did) It's due to these type of complexity of J2EE environment issues and from small business perspective, the issue of supporting deployment server like JBoss, Websphere and WebLogic, we said nope, ASP.NET is the only way to go for our business.
Comment by "Jeremy" on 2007-03-21 10:41:00Z
As a ASP.Net programmer I think you can only get the benefits you are willing to work for. The .Net framework is just that, a framework. Every single function it has is a wrapper for a real Windows API. Aside from that, it is a mental change. To do .Net properly you need to take object oriented to the nth degree and actually write supporting libraries for your applications. This leverages the power we have always wanted of code reuse, but comes at the cost of good planning and implementation. As for the issues with the designer... then don't use it! I rarely use the designer and instead write all my HTML myself. Sure you have to work a little harder to add Javascript events to your ASP.Net webform objects, but it is doable. .Net is just another way to do things. Is it the right way all the time? Certainly not. But it is one of a bunch of great solutions.
Comment by "Deane" on 2007-03-21 14:19:00Z
>Sure you have to work a little harder to [...] I'm not trying to be snarky here, but this is a recurrent theme with ASP.Net. Whenever I complain about something in some public forum, the responses all seem to be prefaced with "sure you have to work a little harder to [insert task here]". To be fair, ASP.Net does make some things easier. But there's a still a lot of kludge you apparently have to accept to work with it.
Comment by "abc" on 2007-03-29 08:22:00Z
Liming Xu: You confuse things. You're mostly wrong. >To effectively understand the page life cycle... This is the fundamental flaw of Asp.Net. Why should a page have to go through a lifecycle? Scott Guthrie and his boys tried to impose the behavior of a desktop application on the disconnected model of the web. That's why they ended up with a mind-boggling lifecycle that even experienced hands have difficulty to grasp. >... experienced developers rarely use view state ... True. But then other problems crop up. That's why Scott Guthrie and his boys introduced another kludge of a "control state" in Asp.Net 2.0. >As for web standards ... that's what the CSS Adapter is developed for. Yet another kludge. The boys of Redmond bent backward to improve DataGrid, resulting in GridView. Why didn't they re-engineer the damn beast and make it emit correct markup, in the first place? Why should you have to wrap a GridView in another layer of adapters and clutter your markup? >J2EE development is not easy to first set up. There are lots of integration issues ... That's what open source is about. Everybody does what pleases him. The one great thing about Microsoft software is that everything seems to work with everything. Furthermore, you get superb documentation.
Comment by "Mean Dean" on 2007-09-16 09:18:00Z
Good stuff as always Deane! I just came back from 4 days of Indoctrination at the Microsoft Tech*Ed South East Aisa 2007. Talk about abstraction. Every programming seminar's answer to SOA was to iAbstract iEveryThing down to an iSomethingOrOther class. A good practice in many cases, over-coding in others. And still no answer to my question -- how the heck am I expected to use Web Parts if they keep encapsulating everything in 3 nested tables, the middle one throwing invalid HTML? Meaning, yeah, WWF and WCF are dandy -- but if you want me to drink the Koolaid, you gotta sweeten it with some usable HTML.
Comment by "Ibus" on 2011-08-28 13:59:00Z
I have worked with ASP .Net since version 1.x (7 or 8 years now). I came up with the conclusion that it is poorly engineered a long tmie ago. however i see nothing wrong with a franmework that trys to hide complexity if it does it well. the problem with asp .net is that it really does not do this well. The whole problem with ASP .Net is that i am constantley having to code at a much lower level than i should have to, putting together boiler plate code time and again, becuase asp .Net so sh1te. a well engineered framework in my oppinion is one the effectlively hides complexity without forgoing too much flexibility. and on those grounds asp .net fails miserably. my 2c