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.
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.