Mindfulness and Software

There is plenty more.

Viewstate, it adds page bloat and load times, true you can farm it off but that adds cpu cycles. Use handlers to implement your own framework ontop of asp.net and you can avoid it.

seperation of concerns, webforms sucks at MVC\MVP. If I want to cleanly what does what in terms of my view, logic to control diplay and take events and data from the rest of my app to feed all of this I can't in webforms. I have a view that's bound to its view logic too tightly for me to have any degree of clean seperation. You can do MVC\MVP in webforms (Rhino Igloo and Subsonic are examples), but its far from ideal.

You can implement MVC\MVP on the asp.net framework, Castle MonoRail is a key example and provides a framework to reduce the work you need to do to implement your own as Mike has done.

I second all of the above mentioned reasons, and I'll add two more items to the list:  Forms Authentication and default error handling.

Forms Authentication is great, but unfortunately it was decided that the entire namespace be sealed/internal.  Not saying this is bad in certain cases, but the applications that we develop rely heavily on RESTful AJAX usage, and redirecting to a presentation page (login.aspx, for example) tends to make the XHR object rather unhappy (**grin**).  So what we did is standardize on returning a status (think RPC) with every response, rather than a complete UI.  This lets us handle the need to re-gather credentials from anywhere in the app without disrupting the current state of the application.  Very nice UX for users, and a solid recovery pattern overall.

Error handling (out of the box) also has similar issues, in that it is oriented around returning an entire UI (redirect to errorPage.aspx, for example).  So again, we focused on returning a status that can be checked with every response.

I realize that architecting an application 100% around AJAX style techniques is a **radical** shift from the page-oriented paradigm that ASP.NET was designed on. However, I hope these examples shed some light on why we opted to replace the default pipeline with one that acts more in an RPC-oriented fashion.

Cheers!!

I honestly think that this is not a good idea.  While it seems cool that a developer has complete control, I have found that doing things on your own and outside of the norm is typically a bad thing.  What happens when someone else moves on and new developer is working on code?  They will have a steep and unnecessary learning curve.  It is best to go ahead and use the norm until there is solid and sufficient reason not to.  To make blanket statements that these types of operations are bad do not reflect the reality of a situation.

I work for a government organization where we ahve to be able to stick to the WCAG, W3C standards and the like, and the asp.net controls don't even come close to achieving this.

aThe main problem I encounter is that the controls churn out terrible HTML (mainly tables) and in some cases (including the Ajax controls as I discovered yesterday) different out put on different circumstances.

Its easier and faster for me to whip up a lightweight replacement than to bother with a lot of the controls, or over riding them with CSSAdapters.

There just to much focus trying to make the web environment and the desktop environment the same, and its really hurting development because they aren't.

I have read a few blog entries recently ( 1 , 2 )about how the design of ASP.NET is questioned because

There's something I think most developers are forgetting, and that is the time, and expertise needed to maintain and build a Web Application to begin with.  Microsoft made ASP.NET to minimize these costs by building upon an established model that many of it's core developers were used to.  ...Using this model, ASP.NET allowed Microsoft familiar developers to expand their territory into Web Applications.

Has that model outlived it's usefulness?  ...Probably.  Most developers who made the jump to Web Apps did so, and are now trying to learn the Web 2.0 techniques that ASP.NET was never designed for. ...But perhaps not.  There are a ton of Microsoft Developers who write and maintain applications, and then are approached by their managers to make it work in some kind of Web format.  ASP.NET's familiar architecture paves the way for that to be a real possibility.

Microsoft is supporting a stable architecture that allows third party developers to build quasi Web 2.0 functionality into Controls that companies can buy, or that Open Source Programmers can collaborate on.  Does it matter that Ruby and other formats can let a "single" programmer handle more code, and make a better portal than a single programmer on ASP.NET?  ...I would say that programmer ego may be overrating itself.  What has always been more important is collaboration, and Microsoft's architecture has always helped that quite nicely.

There probably will be new formats that increase web productivity, and it's great that these guys are pioneering it.  (And that the framework is flexible enough to let that exploration happen.)  But it seems that the old design has and will continue to accomplish many things for existing projects.  And it will look/be Web 2.0ish, even if it started off a solid Web 1.0 platform.

Ruffus,

that is an interesting issue that you bring up.  I do a lot of US Government work.  My experience has been that the ASP.NET Controls work really well in a government environment.  I have found that basic ajax operations work and are supported by varius upto date screen readers.  Have you looking into using the lightweight HTMLControls in ASP.NET?  Are you having trouble with the basic aSP.NET Controls or the the AJAX Control Toolkit.  Have you posted these concerns at the forums.asp.net site?  I'd like to hear more on this subject.

Wally

My previous post has gotten a lot of great feedback . Thanks everybody! I got some more important roadblocks

I wrote something up on this subject a few months back too :)