5 ms·

> Why bother? You're basically asking why half of us bother doing our jobs. It's not that you're criticizing; it's that you're cheerfully insulting people whil

> Why bother? You're basically asking why half of us bother doing our jobs. It's not that you're criticizing; it's that you're cheerfully insulting people while pretending to be inquisitive about something you have no interest in learning about. You don't care about this? That's great. Don't care. The people who built it aren't asking you to care.

graycat 12y ago
It's not personal; it's just Web page coding. I am "interested in learning", and that's exactly why I'm asking. If you are writing complicated code for Web pages, then maybe you have some reasons wby -- I was asking for your reasons. If such Web page functionality is your job, then the question would be, why? My Web pages at 800 pixels wide should look fine on any screen I can think of, although maybe on some really small screens some use of horizontal scroll bars might be needed. On a large screen on a desktop computer, just see all 800 pixels at once, and still my Web pages don't take up much room on the screen; I'm not trying to fill the screen and I'm guessing that that's a UX advantage.
- snlacks 12y ago
  As a front end developer, I think it is easier and more maintainable to use styles for the appearance, and JavaScript for the behavior... That being said, I find the complexity of many designs (CSS or JS driven) more distracting to users. Now, for marketing sites, built by designers, CSS is likely going to be much better for performance. If the JS works as intended. Designers benefit from not having to be focused on programming.
  - graycat 12y ago
    > JavaScript for the behavior.. What "behavior"? Are you implementing an on screen calculator, some word whacking software, the game of Nim, chess, checkers, a drawing program using some HTML5 scalable vector graphics (SVG), all in JS on the client side? Okay.
- ziles88 12y 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?"
  - graycat 12y ago
    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? Again, I'm trying to learn.

graycat 12y ago

It's not personal; it's just Web page coding. I am "interested in learning", and that's exactly why I'm asking. If you are writing complicated code for Web pages, then maybe you have some reasons wby -- I was asking for your reasons. If such Web page functionality is your job, then the question would be, why? My Web pages at 800 pixels wide should look fine on any screen I can think of, although maybe on some really small screens some use of horizontal scroll bars might be needed. On a large screen on a desktop computer, just see all 800 pixels at once, and still my Web pages don't take up much room on the screen; I'm not trying to fill the screen and I'm guessing that that's a UX advantage.

snlacks 12y ago
As a front end developer, I think it is easier and more maintainable to use styles for the appearance, and JavaScript for the behavior... That being said, I find the complexity of many designs (CSS or JS driven) more distracting to users. Now, for marketing sites, built by designers, CSS is likely going to be much better for performance. If the JS works as intended. Designers benefit from not having to be focused on programming.
- graycat 12y ago
  > JavaScript for the behavior.. What "behavior"? Are you implementing an on screen calculator, some word whacking software, the game of Nim, chess, checkers, a drawing program using some HTML5 scalable vector graphics (SVG), all in JS on the client side? Okay.
ziles88 12y 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?"
- graycat 12y ago
  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? Again, I'm trying to learn.