[graycat]

Not a rhetorical question: What's so wrong with Web Forms?

Postback? That's really part of HTTP. What the browsers send back to the server is as specified by HTTP, not Microsoft or Web Forms.

Viewstate? Okay, it's a bit of a tricky thing, but really can mostly ignore it. Else it provides a somewhat useful service.

Controls? Yes, for each HTML 'control', there is an ASP.NET class so to send the HTML for the control to the user, get an instance of the class corresponding to the control, assign values to the properties, attach the instance to a big tree that gets walked by the code in one of the ASP.NET 'events', maybe PAGE_PRERENDER, and move along. Why is this so bad?

Web Forms is my first and so far only way I've written Web pages. Explain what is wrong with Web Forms and what is much better and why?

[flomo]

IMO, there was nothing horribly wrong with WebForms itself when it was introduced -- So long as you were writing your HTML by hand and using HtmlControls rather than the drag-n-drop stuff.

ViewState was far better than other frameworks that shoved the client state into a server session object and broke the Back button. Plus the clients were saving state instead of wasting server memory. If it got too ugly, you didn't even have to use it, the http variables were still there.

Remember this was all designed back when Netscape 4 was a popular browser and any Javascript was considered exotic. Of course we have much better way to do things now, the WebForm approach broke down hard as soon as it encountered AJAX. But originally it was fine.

[UweSchmidt]

There are AJAX controls for webforms, so it hasn't really "broke[n] down hard"?

Drag an AJAX control on the form, and whatever is in there, that part of the page will be ajaxed.

[flomo]

I should have added a disclaimer that I haven't worked with web forms in many years, so my commentary is probably not the most infomred. The ajax controls always seemed a bit ugly to me.

[cwbrandsma]

The real issue is the amount of "Black Box" in WebForms. A lot of the guidance is "Do it this way". Why? "Because". You really can't know what is going on behind the scenes. ViewState and the PostBack model are both parts of that. I used them for years...never knew how they worked or what was going on to make them work.

This in turn forced people to go to the MVP pattern to manage those systems, but I still find plenty of clients with code behind that is THOUSANDS of lines long. Everything in one file.

Also, many of the controls were very hard to style, with some very strange html in there.

[snarfy]

Web Forms treats the browser as a dumb terminal. Everything is processed on the server. Javascript is relegated to making the boilerplate work. Almost nothing happens client side.

This is all fine if you are on the local network, but it ignores all the issues that go along with the network, such as latency. There is no silver bullet for latency. It's a physical constraint. The same goes for bandwidth. Throwing an UpdatePanel on the form doesn't solve the problem. Try using a Web Forms page on your phone some time with a 3G connection.

[graycat]

Thanks.

Right, Web Forms, and, really, HTTP and HTML, treat the client like a 'dumb terminal', one with some quite amazing capabilities but, still, 'dumb' in that the Web browser is just displaying some pixels and the user is just entering data via the standard HTML 'controls', text boxes, radio buttons, check boxes, etc.

For my site for now, treating the user's Web browser as a dumb terminal is what I wanted. One reason: There is less, hopefully nothing, new for a user to understand about how my user interface (UI) works.

But, yes, at times, a more 'dynamic' Web page could be of interest.

Right, JavaScript running in the client's Web browser can yield much more 'dynamic' Web pages. And, with AJAX, still more can be done to have 'dynamic' pages.

But so far for my Web site, I have yet to write a single line of JavaScript. Somehow ASP.NET writes some JavaScript for me and sends it to the user, but I don't know what that JavaScript code does and hope not to care.

My guess is that if I want to write some JavaScript somehow there is a way in ASP.NET Web Forms for me to do so, i.e., maybe just put my code in the file of JavaScript code that ASP.NET writes and Microsoft's IIS sends.

You mentioned a phone: My Web pages are just dirt simple and each just 800 pixels wide -- I hope that the pages will look good on nearly any device with a Web browser right up to date as of, say, five years ago.

For a 3G connections, at

http://www.pcworld.com/article/253808/3g_and_4g_wireless_spe...

there is a graph of 3G speeds by various vendors, etc. and about the slowest is 0.59 Mbps. Fine with me: One of my Web pages sends, including the JavaScript file, for about 400,000 bits. So, the page should download on the slowest 3G connection in about 1 second. If I take the extra blanks out of the JavaScript ASP.NET writes for me, then the page should load a little faster still.

At least at my site, Web Forms is sending mostly just some HTML; maybe, I don't know, ASP.NET Web Forms is slow on the server, but I'm not seeing just why what Web Forms is doing should be slower for the data transmission or the user's Web browser than some other way of sending HTML.