Thanks for the overview of Dreamweaver: I didn't
know anything about it and wondered. Right,
if it takes me very far from HTML, then I
wouldn't like it. E.g., right, sometimes
when something's not working, I will
just have my Web browser save to a file what my
Web server sends and look at what
was saved. So, some of my badly written
CSS gets
pruned, etc. I've gotten some answers that way.

> You might be absolutely fine not knowing those things, but at some point down the road you are going to be lacking some essential knowledge of how HTTP works. To put it simply: everything - Ruby, PHP, ASP.NET, you name it - uses GET and POST requests underneath it all. Learning about them would be of great benefit to you in the long term.

Right. But I do understand GET and POST, and, again,
via some classes in ASP.NET have access to that
data, including raw, if I want it. Occasionally
I considered looking at the raw data but too
quickly found ASP.NET classes that had the
data I wanted already all parsed, etc. in
properties of the classes; I don't think
I've touched the raw GET/POST data yet.

Yes, ASP.NET does some things for me, e.g.,
ViewState, which took a while to understand.
Okay.

I didn't like the way ASP.NET and IIS
handled user session state so
just grab a GUID, convert it to a
string, put it in a hidden field,
and send it to the user. Then
on postback, I get the GUID, and that's
my session ID for that user.
That session ID, just as the string
is the key in a little
key-value store I wrote as
a separately running Visual Basic
.NET console application
using
class instance de/serialization,
TCP/IP, and two instances of
a .NET collection class
(hopefully AVL trees or red-black
trees). The key-value store is
single-threaded so doesn't need
to use the concurrent versions of
the collection classes. Timings
indicate that on a 3.0 GHz single
core processor, the store should
be able to send or receive
2000 key-value pairs a second, enough
to send 1000 Web pages a second.

As far as I know, I don't really use
Web Forms. I use placeholders,
tables, buttons, and text boxes
via static HTML and/or the corresponding
ASP.NET classes. ASP.NET builds
a big tree of all the 'controls',
etc., and at 'render time' does apparently
a depth first traversal of the tree
and scribbles out the corresponding
static HTML to send to the user.
And if ASP.NET wants to send the user
some JavaScript, it writes and sends
that, too -- so far have yet to write
a single character of JavaScript. Fine
with me.

So far my Web pages are next to dirt simple
and, with the JavaScript, send from my server
(not counting data from ad servers)
for about
400,000 bits each. Likely much of the
JavaScript is boilerplate and can be
shrunk, but that's for later. I have
no pull-downs, pop-ups, or roll-overs;
each screen is exactly 800 pixels wide;
there is some simple text, a few
simple images, some push buttons and
text boxes, all arranged in tables
for layout. Some of the screens have
to be a bit dynamic so get generated
in loops in Visual Basic code and
are not just static HTML, but the
only dynamic part is the number
of rows in some tables -- we're still
talking simple.

I guess, "If it ain't broke, then don't fix it.".