What I've built looks like a Web site to me;
the pages look quite usable.
"Client libraries" -- wow.
"Interactive" -- my Web site is interactive:
I wrote a session state store, have two more
back end servers, and have SQL Server. The server
side is plenty complicated, but the client side
is quite simple, and I'm still missing why
the client side situation should often be otherwise.
Or, what the heck is wrong with just HTML, some
CSS for a little convenience, and some JS if
necessary? HTML has the basics: Tables,
links, one line text boxes, multi-line text
boxes, text, images, etc.
Pull-downs and roll-overs --
as a user I don't like them, so as a programmer
I'm not using them. Anything that covers up
what's on the screen I don't like for anything
less important than announcing nuclear war.
With high irony, we're quite productively
using HN with simple HTML, no pull downs or
roll overs, nothing or next to nothing in
icons (I hate icons),
and, I just had Firefox save this
HN page, some HTML with only a little JS
with the HTML,
two GIFs, 65 lines
of CSS that looks nicely simple, and nothing else.
Works fine.
I would think that the "dependencies" would
be handled on the server side with some
help from, say, in real time a session state store and/or
for longer term a database.
For CSS, it finally dawned on me: There can be
another place to put such cases of commonality --
the code that writes out the data to be sent to
the client. I'm doing some of that and, then,
using the classes in Microsoft's ASP.NET to
generate the data sent to the client. So, to
change fonts, colors, change the color for
every other line of a table, etc., just do that
in the code that calls the ASP.NET classes.
Heck, if want,
change the colors of lines in the tables
based on the phases of the moon, the temperature
where the user's IP address is, for each time they
see a new copy of the page, with no reds next to
greens if know that the user is male (25% of the
male population is partially red-green color
blind, including me), etc. Try that in CSS!
Generally server side programming is easier than
client side programming because (1) on the server
have access to about all there is in computing and
(2) on the client are throttled by, ugh, JS and,
still, can't really see the stuff run.
For what bytes I'm sending
to the users, I'm trying to keep that simple.
I'm losing why it should be complicated,
say much more complicated than just HN,
or, really, why the CSS that is the subject of this
thread is such an aid. Or, for generating what
the user sees, I'm using essentially Microsoft's
most powerful programming language, the .NET
version of Visual Basic (C# is different
mostly only just in syntactic sugar) --
gotta be a lot more powerful than
JS on the client or CSS.
Why send complicated stuff to the clients?
Why program in JS unless really have to?
Why try to make new features of CSS
ways to write software? What's so
important to do that often need
JS instead of just HTML?
I'm just going to reply to a couple points on JS: We write code that runs on the client-side primarily for performance. Rendering without needing to send more data over the network or run more code on our servers is a huge win... Especially when we're not building traditional "web pages", but rather full web-apps - requiring fairly complex UI and business logic.
Plus, JS isn't something to be avoided these days. Its become a full-featured language and is as powerful if not more powerful than .NET
For my site, I'm just going for
"traditional web pages".
Sure, it did occur to me that I could program
my site so that the user saw only one
URL and that URL would keep changing as appropriate
for the user's dialog. A few minutes after
I noticed that possibility, I gave it up.
Sure, with that possibility, maybe the big
deal would be write nearly all the
'logic' in JS to run on the client, with
a lot of AJAX threads, using the server as
a remote database or some such. Okay, if
you want to do that. I'm not sure I've seen
many such Web sites. Maybe someday I will
want the architecture of my site to be
like that, but for now I'm staying with
tradition.
And for using a lot of JS on the client,
I'd be concerned about the ability of
a lot of advanced
JS to do what I wanted, reliably, on
all the mobile to desktop computers in the
world; instead I just want to
send some simple HTML, a little
CSS, and maybe some minimal JS that Microsoft
writes for me, which will be okay, I hope.
Okay, good: As long as I'm staying with
a traditional Web site architecture,
without JS I'm not
missing much. Good to know. I'll conclude
the same about version n + 1 of CSS.
"Client libraries" -- wow.
"Interactive" -- my Web site is interactive: I wrote a session state store, have two more back end servers, and have SQL Server. The server side is plenty complicated, but the client side is quite simple, and I'm still missing why the client side situation should often be otherwise.
Or, what the heck is wrong with just HTML, some CSS for a little convenience, and some JS if necessary? HTML has the basics: Tables, links, one line text boxes, multi-line text boxes, text, images, etc.
Pull-downs and roll-overs -- as a user I don't like them, so as a programmer I'm not using them. Anything that covers up what's on the screen I don't like for anything less important than announcing nuclear war.
With high irony, we're quite productively using HN with simple HTML, no pull downs or roll overs, nothing or next to nothing in icons (I hate icons), and, I just had Firefox save this HN page, some HTML with only a little JS with the HTML, two GIFs, 65 lines of CSS that looks nicely simple, and nothing else. Works fine.
I would think that the "dependencies" would be handled on the server side with some help from, say, in real time a session state store and/or for longer term a database.
For CSS, it finally dawned on me: There can be another place to put such cases of commonality -- the code that writes out the data to be sent to the client. I'm doing some of that and, then, using the classes in Microsoft's ASP.NET to generate the data sent to the client. So, to change fonts, colors, change the color for every other line of a table, etc., just do that in the code that calls the ASP.NET classes.
Heck, if want, change the colors of lines in the tables based on the phases of the moon, the temperature where the user's IP address is, for each time they see a new copy of the page, with no reds next to greens if know that the user is male (25% of the male population is partially red-green color blind, including me), etc. Try that in CSS!
Generally server side programming is easier than client side programming because (1) on the server have access to about all there is in computing and (2) on the client are throttled by, ugh, JS and, still, can't really see the stuff run.
For what bytes I'm sending to the users, I'm trying to keep that simple. I'm losing why it should be complicated, say much more complicated than just HN, or, really, why the CSS that is the subject of this thread is such an aid. Or, for generating what the user sees, I'm using essentially Microsoft's most powerful programming language, the .NET version of Visual Basic (C# is different mostly only just in syntactic sugar) -- gotta be a lot more powerful than JS on the client or CSS.
Why send complicated stuff to the clients? Why program in JS unless really have to? Why try to make new features of CSS ways to write software? What's so important to do that often need JS instead of just HTML?
Again, I'm trying to learn.