Trust me; that's a good thing. Nasty, deeply misguided platform - whoever came up with the idea of PostBack and trying to make the web look like VB6 is definitely not on my Christmas card list. Ties you in knots trying to make the web something it fundamentally isn't.
I'll be quiet now, and get back to working on my MVC code. The day when I can finally stop having to work on WebForms code too will be a happy one :-)
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?
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.
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.
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.
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.
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.
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.
You can't fault it for what it tried to be, though - a plug-and-play, drag-and-drop toolset designed to make web development accessible to savvy end-users and inexperienced developers, at least for what consitutes perhaps 80% of most businesses' needs - simple CRUD apps.
I think there's a lot of value in that, and for as much frustration as maintaining Web Forms apps has caused me (and will continue to cause me) I think it would be neat if they open-sourced it...what's to be lost if the alternative is to just let it rot into obscurity? I would totally fork the repo.
