Hacker News Reader

Comment by spking | Hacker News Reader

Picnic is another very nice and compact option:

I've been meaning to put picnic to use in future projects. I very much like the minimal reliance on JS and the semantic class names (nothing irks me quite like CSS concerns bleeding into the HTML).

What is the difference to Skeleton [1]?

[1] https://skeleton-framework.github.io/

I can vouch for skeleton, modified a few variables (default page max-width not fit for modern monitors) and tweaked things to my liking but hurrah - base functionality makes for super simple & nice layout and works on everything from desktop to phone. Have no regrets on fact that it hasn't been updated for 4 years at present.

> (nothing irks me quite like CSS concerns bleeding into the HTML)

Don't knock it till you try it! If you're generating HTML dynamically, define functions in code for your custom style classes which consist of a set of atomic styles provided by something like Tachyons.css. Then just call those in your template while rendering.

All the benefits of CSS variables and tooling like Sass/Less/etc. without the need for any special tooling!

Typically, by the time I'm at the point where I'm dynamically generating HTML, I'm also at the point where I've got enough tooling around it already that adding Sass/Less to the mix ain't much of a big deal.

So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change.

Workflow under Tachyons: change html, reload page to see change, change html, reload, change html, reload, ....

Workflow under Sass/Less/etc.: change css, build css, (maybe) change html, reload, change css, build css, (maybe) change html, reload, ...

> So not only are you unnecessarily adding to your tools, but also unnecessarily adding to your build steps, which costs time every time you make any sort of visual change.

Most frameworks nowadays ship with Sass/Less built-in, or at the very least make it trivial to bolt it on. Further, most frameworks nowadays fully support the ability to automatically rebuild stylesheets when regenerating the HTML, in which case it's quite literally: change CSS, reload, change CSS, reload, etc. The build times are negligible (especially if I'm using Erlang/Elixir or C# or something else that needs compilation on changes anyway).

Also, since I'm in the habit of keeping the HTML I write or generate concerned solely with describing the content rather than the appearance thereof, there's rarely (if ever) a separate "change HTML" step there; the HTML (or the templates to generate it) is already written alongside the content, and it's just a matter of adding enough CSS to make it look decent.

Importantly, since the HTML makes no assumptions about its appearance, it's straightforward to define different stylesheets for different contexts (whether interactive v. print, or reusing a given page on multiple sites/applications with very different styles, or what have you).

Reply on news.ycombinator.com