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