Don't like it that ASP.NET dumps tons and tons of encoded state information into your pages? Just override some methods and compress it. I guess what I'm missing is why you'd use it at all for any complicated application. You gain some up front productivity for sure, but at the cost of having no control over your HTML, making cross browser work a royal pain. More importantly there's no transparency here, so if one of those controls ever stops working, say it posts on the "onchange" event but the server doesn't do anything about it, good luck debugging
Am I missing some major advantage to the postback/viewstate/event driven model? For my money it's great for visual basic where everything is controlled and you don't have the client side/server side separation. But that's inherent to the web. It can't be easily abstracted behind some simplistic browser sniffing and a couple of lines of javascript (how well does that viewstate form work on a screen reader or a mobile device?) If you commit to the viewstate model, you've tied your application forever to whatever Microsoft deems fit to provide you, and whatever browser technology they deem fit to support. There's certainly no competitive advantage there. And likely, it's going to make it difficult to even "hand implement" a few key features that are important to your application. Once you've added about 30-40 forms to your application, you're going to find that what you really needed was something at a higher level, to manage the the interaction of the business logic with the presentation layer, and that code behind pages really don't cut it.
From what I know, this goes for Java Server faces as well. If anyone can enlighten me as to what the draw is, that would be great...seems like trading some short term gains in for lots of pain down the road.
You're kidding me right? Okay, here's some comments:
1. You gain some up front productivity for sure, but at the cost of having no control over your HTML, making cross browser work a royal pain.
Cross browser development has never been an issue for me because I have 'browserCaps' in the configuration file configured correctly so that the asp.net worker process never renders to modern browsers and down level browser as it would normally. The only cross browser issues I encounter have nothing to do with ViewState and are all on how that particular browser renders a tag; such as the differance in the box model between IE and NS - that would be an issue if you were writing in TextPad.
2. More importantly there's no transparency here, so if one of those controls ever stops working, say it posts on the "onchange" event but the server doesn't do anything about it, good luck debugging
Seriously, don't you think that if there was an issue with it ASP.NET wouldn't have the huge audience it has? It's a core foundation concept to ASP.NET - it would've never of gone to release 4 years ago if there was an issue with it. That's just a weak arguement.
3. Am I missing some major advantage to the postback/viewstate/event driven model?
Yes. When you do a windows app do you hand wire the each pipe for each event or do you just use the event model? Unless your writing C, I seriously doubt you mess with the message pipes.
4. For my money it's great for visual basic where everything is controlled and you don't have the client side/server side separation.
You forgot to mention C# and several other .NET languages.
5. But that's inherent to the web. It can't be easily abstracted behind some simplistic browser sniffing and a couple of lines of javascript (how well does that viewstate form work on a screen reader or a mobile device?)
Hmmm...well I think most people would same from experiance that letting another already well written, well tested, well supported, set of functionallity will do a much better job than doing all the joyful programming you would have to do without it and hoping that you get it right the first time. Then there's the cost of development, supportability, reusability...doesn't take an experianced project manager to know that if you can use built in technology of one language that saves money in time to develop and is stable, that it's a much better option than building your own event model.
It works fine on mobil devices - have you left the 20th century yet? Do some research!
6. And likely, it's going to make it difficult to even "hand implement" a few key features that are important to your application. Once you've added about 30-40 forms to your application, you're going to find that what you really needed was something at a higher level, to manage the the interaction of the business logic with the presentation layer, and that code behind pages really don't cut it.
Again a very weak arguement. A good developer actually usually has 1 or 2 base classes that all other forms derive from so that things that are needed at a higher level across all forms can be encapsulated by putting it in that base class, also they don't include ANY business logic into their presentation layer. Who in their right mind is going to tightly couple their presentation layer to their business layer anyway???!!! That's just poor design, regardless of the implementation langauge. Microsoft preaches N-Tier development in so many places I can't count; developers who don't understand that concept or don't implement it are the one's to be blamed for failed applications; not the language.
Do yourself a favor, research, and try the language for a year (with an open mind) before you say it's a worthless language (which you did in so many words, it's not going away and you'd be wise to learn it as the people who know it will probably being taking your job in the next 5-10 years if you don't.
I wasn't as clear as I could have been, and that's my fault, but you also didn't answer any of my questions.
I'm not talking about a specific language, I'm talking about the entire event-driven model as applied to the web. The "visual basic" (any typical locally implemented GUI program really, not just VB) event driven model with forms and controls, and events attached to them that trigger code, and mapping it onto code running on the web browser and the web server is what I'm talking about.
Locally this works fine because there is no HTML to render. The problem you dismiss (different browsers rendering html differently) is exactly the problem.
After having built an extensive from scratch application with it, I think I might have mellowed a bit in thinking that the model isn't quite as fundamentally flawed as thought, and it's more an implementation problem in ASP.net 1.0. 2.0 defintely sounds like it fixes some of the problems, particularly with the forced "post to same page no matter what" insanity and overriding/altering the HTML rendering of various controls.
Especially since I wrote this Ajax has hit so large. It's the event-driven model only without the hacks. As the tools around this mature, it's going to become more and more workable to have the client controls all directly fire events and run code on the server. Still assuming reasonable latency though, which is fine if you're Google or Yahoo, but I'm not sure how well it's all going to work in more typical, higher-latency situations.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: