Viewstate and lifecycle events are still very confusing for new ASP.Net programmers. There is no easy way for them to immediately "get it" -- they have to spend the time in the trenches, watching their data disappear on post back, or double-bind, and flail around with building and rendering their own web controls. They have to see the DataGrid spew its html diarrhea and spend hours customizing it. They have to have that client ask them "what the hell is all this javascript, and why are the pages so big?" and figure out just what the heck all that gibberish on their pages are.

Moving up the experience chain, Viewstate and lifecycle events represent a significant amount of design and front-end time on a web application even for those that have been doing it for a while. You have to balance your state management with your html optimization, caching, and application maintainability. Often you have to build your own state-tracking structures or extend existing ones. You have to carefully consider whether to roll your own custom controls or buy third party interfaces and rely on their javascript and state programming (or maybe their support team!) And for very simple "read-only" web sites, viewstate just gets in the way.

So in summary, Viewstate and lifecycle are still be a pain in the butt, and still represent hurdles for new programmers. Years ago, it was worth the annoyances and problems, because you could write strongly typed, object oriented portable code without getting lost in folders and folders of scripted sites. So why might it be dying? Well…

The first item on the agenda is Silverlight. ASP.Net represented significant advantages for writing portable code that was closer to classic desktop programming, as it abstracted out much of the xhtml. But now I've seen web application developers swoon over Silverlight. If their reaction is any indication, and the amount of momentum that Microsoft is putting into WPF, many shops are going to give up programming their internal or non-public projects in ASP.Net and move to Silverlight instead. I'm personally still skeptical about Silverlight's market penetration, as there are many gaps it doesn't fill for content publishers. But it's not a minor consideration.

Second is the new ASP.Net MVC framework. MVC is an old model that's rapidly gaining traction in the web world, and with the introduction of the ASP.Net MVC framework, it is hard to see any clear advantage to the older webforms model. From Scott Guthrie's Introductory MVC post a couple months ago:

To help enforce testability, the MVC framework today does not support postback events directly to server controls within your Views. Instead, ASP.NET MVC applications generate hyperlink and AJAX callbacks to Controller actions -- and then use Views (and any server controls within them) solely to render output. This helps ensure that your View logic stays minimal and solely focused on rendering, and that you can easily unit test your Controller classes and verify all Application and Data Logic behavior independent of your Views.

And finally, we come to REST, another model that is gaining traction. True REST and webforms are mutually exclusive since REST involves heavy reliance on mapping resource locators to known states of an application. This model has lots of advantages for web services and data-based applications, especially in the realms of testing, while ASP.Net Webform applications are often built around one URL for many states, using Viewstate and Session as your state map, which are of course lost between sessions and server restarts.

So long story short… I think we're seeing the beginning of a new paradigm. In 5 years, will anyone still be developing with true ASP.Net Webforms? It will be interesting to see!

Look at this post on "Real World" for crying out loud. Peter Seale has a rebuttal that does a great job at summing up my thoughts about the article, but one thing that continually fails to be addressed is "why". Why Silverlight? Why do we need it? Do we need to make web apps behave like desktop apps? Maybe developers do…. but the average web surfer today is a different story. In fact, I'd go so far as to say that Joe Web will likely resist Silverlight unless it can be introduced seamlessly, won't degrade web performance/user experience, and user interfaces are developed properly… unlike when Flash was first introduced. The average web surfer expects a web page to act like a web page, and you have 4 seconds for it to load if you want to keep them there. When was the last time you enjoyed hanging out at an all-flash web site? And maybe last but not least, if a high-profile security exploit were to be associated with Silverlight at this juncture, it might be a lot of trouble for corporate adoption.

So if Silverlight is going to succeed, there is a lot to overcome. And maybe it's great for app developers, but content publishers still have many unanswered questions and it doesn't look like there are many answers right now. Not to mention, the demo applications that I've seen have run like turds on any machine older than 3 months, and the 1.1 Alpha release (1.1 alpha??) has drawn a lot of developer ire.

Don't get me wrong -- I heartily approve the concept. The point is, Silverlight needs to satisfy a lot more than just application developers. RIA's make up a small portion of the internet. The real web runs on content, from the Library of Congress down to your dog's Facebook application. And every time I hear Silverlight, a little voice in my head whispers "ActiveX ActiveX ActiveX"… I guess I'm still getting over that nuclear disaster.  This reaction to Silverlight just reeks of the reaction to Longhorn during the first couple years of feature marketing (WinFS!), and we all know what happened to Vista.  I'm going to sit on the skeptic fence for a little while longer.