|
|
|
|
|
|
by ziles88
4173 days ago
|
|
|
I'm not sure if you're serious, and I think that's why nobody is stating the obvious - not everyone is building the same thing as you. There is not a chance in hell my company could get away with using just plain html. We have an interactive site, with a large team, with multiple workflows, client libraries and inter-connected dependencies. You're asking a really silly question, just because you made a shack in your backyard does not equate to making a house, then asking the home builders, "I made my entire shack out of wood and nails, why can't you make your house like that?" |
|
|
"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.