4 ms·

Over time I've developed some opinions not shared by most. I only use a framework when under extreme duress. I use static pages wherever possible. I measure pay

Over time I've developed some opinions not shared by most. I only use a framework when under extreme duress. I use static pages wherever possible. I measure payload size. I'm also beginning to re-think CSS. I love CSS, but just like with OO, I'm thinking it may tempt us to think of structural considerations when we may just be wasting our time. I think the next app I write, I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes. In much the same way, in FP you can just make it work, then generalize, then group, then eventually create modules/classes full of generalized functions. This way of thinking seems to result in far quicker execution and far less complexity. Not sure if it translates to CSS, though. It'll be interesting to try it out.

deleted 11y ago
[deleted]
eric_bullington 11y ago
> ...I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes. I'm sure it will load spectacularly fast, but that sounds like a maintenance nightmare. I spent a lot of effort on my "brochure" sites making sure that non-JS users will have a good experience (that includes being able to navigate the site, a privilege an increasingly large number of sites don't extend to non-JS users)[1]. Loading even part of my CSS through JS would ruin that experience. 1. I do make web apps that require JS, but only for actual applications that work in a similar manner to desktop apps, not for informational sites like blogs.
- DanielBMarkham 11y ago
  Yes, that's the standard answer: good structure costs very little now but pays off greatly in maintenance and upkeep. And I believe it -- up until a point. After that point, too much structure becomes its own kind of hindrance, where you're looking at a UI and wondering "What the hell cascades do I have going on here to make that two pixels too far to the right?" (Or something like that) So I don't think we disagree. The only thing I'm adding is that to determine the right amount of structure, add it in only as needed. So I imagine by the time you got to a multi-page site you'd be using external stylesheets and common classes. You just wouldn't start there. Sure do like me some Bootstrap, though. And a good reset sheet is a no-brainer. Need to think about this some more. I think the key question is: how much of this do you really need? For instance, right now I'm writing a small personal app to take a movie script in native file format and display it as a web page. Where did I start? With the function to do the translation, of course. Now that it's working, I can always manually execute it if I need to. I may just stop here. I've done enough. If I really, really want something I can upload scripts to online, I'll write a page. Or two. Then I'll throw my uploaded file at my pre-existing function, return the file name, and I'm done. I may have spent 10 hours on this so far. By contrast, the "old" way of doing it was to start with setting up a site using all sorts of frameworks. Maybe decide on a color scheme. On the back-end side, I'd be creating a class graph and working through my persistence strategy. Maybe I could use Mongo! Wouldn't Ruby be awesome? I tend to easily get focused on tooling and technique instead of just doing the fucking work. (Apologies for the profanity, but this took me a long time to figure out). So I've discovered for my own work, I need to concentrate on making sure I grow only the needed complexity. Nothing more. Way too easy for me to screw up in this area. In the case of my little app, sure, I could start adding frameworks. Or I could just emit some HTML. Who knows? Maybe plain HTML with a few classes and some style information in the HEAD might be fine. That's a win.
- jnmandal 11y ago
  Who are these non-JS users. Can you point to some statistics here? Using developer time on it seems more wasteful than trying to support old versions of IE.
  - kccqzy 11y ago
    See here for example: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
    - noir_lord 11y ago
      Interesting but that was over 2 years ago and frankly even if it is still 1.1% since I write web applications not sites I'm not devoting any time to supporting people without JS. Anything over 1% of the total dev time would be a poor RoI and frankly I'd sooner spend that time making things more accessible to screen readers and such (something that many web applications already do very poorly frankly).
moron4hire 11y ago
I know what you mean. The key is to remember that semantic HTML is responsive by default. If you are struggling to get an eefect to work with CSS, that is a code-smell that you are hurting more than helpinh your site. I iterate back and forth between including my stylesheet and not including it, while developing the HTML. I try to get the unstyled layout to make as much sense as possible, to be a complete presentation on it's own, albeit looking like it's from 1995. I then add styling just to make it look good. Since the flow of the page already makes sense and is readable to a user, the CSS is usually much smaller and less intrusive. I don't use CSS resets. The entire concept to me is the devil. You're design should not be trying to rewrite the world. You will probably get it wrong if you try.

deleted 11y ago

[deleted]

eric_bullington 11y ago

> ...I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes. I'm sure it will load spectacularly fast, but that sounds like a maintenance nightmare. I spent a lot of effort on my "brochure" sites making sure that non-JS users will have a good experience (that includes being able to navigate the site, a privilege an increasingly large number of sites don't extend to non-JS users)[1]. Loading even part of my CSS through JS would ruin that experience. 1. I do make web apps that require JS, but only for actual applications that work in a similar manner to desktop apps, not for informational sites like blogs.

DanielBMarkham 11y ago
Yes, that's the standard answer: good structure costs very little now but pays off greatly in maintenance and upkeep. And I believe it -- up until a point. After that point, too much structure becomes its own kind of hindrance, where you're looking at a UI and wondering "What the hell cascades do I have going on here to make that two pixels too far to the right?" (Or something like that) So I don't think we disagree. The only thing I'm adding is that to determine the right amount of structure, add it in only as needed. So I imagine by the time you got to a multi-page site you'd be using external stylesheets and common classes. You just wouldn't start there. Sure do like me some Bootstrap, though. And a good reset sheet is a no-brainer. Need to think about this some more. I think the key question is: how much of this do you really need? For instance, right now I'm writing a small personal app to take a movie script in native file format and display it as a web page. Where did I start? With the function to do the translation, of course. Now that it's working, I can always manually execute it if I need to. I may just stop here. I've done enough. If I really, really want something I can upload scripts to online, I'll write a page. Or two. Then I'll throw my uploaded file at my pre-existing function, return the file name, and I'm done. I may have spent 10 hours on this so far. By contrast, the "old" way of doing it was to start with setting up a site using all sorts of frameworks. Maybe decide on a color scheme. On the back-end side, I'd be creating a class graph and working through my persistence strategy. Maybe I could use Mongo! Wouldn't Ruby be awesome? I tend to easily get focused on tooling and technique instead of just doing the fucking work. (Apologies for the profanity, but this took me a long time to figure out). So I've discovered for my own work, I need to concentrate on making sure I grow only the needed complexity. Nothing more. Way too easy for me to screw up in this area. In the case of my little app, sure, I could start adding frameworks. Or I could just emit some HTML. Who knows? Maybe plain HTML with a few classes and some style information in the HEAD might be fine. That's a win.
jnmandal 11y ago
Who are these non-JS users. Can you point to some statistics here? Using developer time on it seems more wasteful than trying to support old versions of IE.
- kccqzy 11y ago
  See here for example: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
  - noir_lord 11y ago
    Interesting but that was over 2 years ago and frankly even if it is still 1.1% since I write web applications not sites I'm not devoting any time to supporting people without JS. Anything over 1% of the total dev time would be a poor RoI and frankly I'd sooner spend that time making things more accessible to screen readers and such (something that many web applications already do very poorly frankly).

moron4hire 11y ago

I know what you mean. The key is to remember that semantic HTML is responsive by default. If you are struggling to get an eefect to work with CSS, that is a code-smell that you are hurting more than helpinh your site. I iterate back and forth between including my stylesheet and not including it, while developing the HTML. I try to get the unstyled layout to make as much sense as possible, to be a complete presentation on it's own, albeit looking like it's from 1995. I then add styling just to make it look good. Since the flow of the page already makes sense and is readable to a user, the CSS is usually much smaller and less intrusive. I don't use CSS resets. The entire concept to me is the devil. You're design should not be trying to rewrite the world. You will probably get it wrong if you try.