Hacker News Reader

Comment by bshimmin | Hacker News Reader

I think I'd have to assume anyone using that on a project I was paying them for really was trying to be funny. I mean, really, take a look at this: https://github.com/tachyons-css/tachyons-visibility

View on HN

I used and am using this in production. So are others. It works really really well.

Here's the rational: http://mrmrs.io/writing/2016/03/24/scalable-css/

In all seriousness, what advantages do you see over writing inline styles?

Better caching, smaller HTML size and the ability to use inline styles if you do need to override something

Are `class` attributes cached more efficiently than `style` attributes for some reason?

I assume he/she means that CSS is cached as an http resource and can be reused in different pages, whereas style attributes are only cached as part of the page; ie using them adds page weight.

Tachyons is based on mathematical scales: http://tachyons.io/docs/layout/spacing/

Practical example: I have a form with a header. I look at it and think "there needs to be more space below the header". So I change

  className="mt0"

  className="mt1"

It hot-reloads etc. It took me exactly two keystrokes to change this and I know that the spacing is consistent with all the other spacing in my app.

But how is that any more efficient than changing:

    style="margin-top: 1rem;"

    style="margin-top: 2rem;"

It's also two keystrokes, and is mathematically determined...

1. way less clutter and repeating, my whole style is in one line per tag.

2. the scale also has fractional rem values.

I'd rather change "f5" to "f6" for a smaller font than: "fontSize: 1rem" to "fontSize: 0.875rem".

3. the author of tachyons clearly understand design. If he improves his stylesheet, I benefit.

4. Apparently inline-styles are slower [0], but I don't count that since everything could be extracted.

[0] http://ctheu.com/2015/08/17/react-inline-styles-vs-css-stupi...

5. I thoroughly enjoy using it. :)

Perhaps I'm just a fuddy-duddy, but I rather like MDN's description of what classes used to be for: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... (The second paragraph.)

It is much faster to type and maintain, easier to read, smaller document size and faster for the browser to parse.

Is there a benchmark you can point me to for "faster for the browser to parse"?

sure, I searched for tests just before I posted my comment.

http://ctheu.com/2015/08/17/react-inline-styles-vs-css-stupi...

I use react inline styles in some situations where it's appropriate. on large tables or SVG (eg. with zillions of styled circles) there will be issues.

if you are sending HTML from a server with inline-styles then you will have much bigger problems with bandwidth.

This is where tachyon and basscss can provide a clean way for the day to day simple styling tasks like "needs more padding here" "make that title bigger there" without writing up stylesheets with repetitive margin, float, etc. for every single view in your app or every page on your website.

I've been looking at this recently. I'd really love to hear more about real-world experience using Tachyons. We're suffering from serious bloat (500KB CSS) on an old project, and are trying to figure out how best to manage CSS so it doesn't bloat over time (at least not as much).

These are valid issues, but one that has a better, actually scalable solution: CSS preprocessors.

You can name your magic numbers/RGB values. You can move your shared behaviour into mixins. You can stop using float for god's sake - it's 2016, we have flexbox now (OK, so that's not related to preprocessors, but it's still true).

Sure, if it's a quick hack or something you're throwing together for personal reasons, use whatever mixture of inline-styles, "visually semantic" classes, and table layout goes fastest for you. But if the point is "scalability" (In the sense of size of team working together), then this halfway point between semantic classes and inline styles is definitely not the right way to achieve it.

If you want a website that works on enterprise desktops, you aren't using flexbox - you're using floats.

Is that still true? I recently joined a company whose primary audience is education, and our numbers say that less than 1% of our customers use browsers that don't support flexbox.

Are public middle schools farther along the tech curve than "enterprise"?

(Legitimately curious. It'd be pretty funny if so.)

For what it’s worth my project is about 2.5% no flexbox, which is too high to move over really.

The sticking point for enterprise-y things remains IE, since it only supports flexbox (buggily) as of IE11.

Though there's polyfills like flexibility out there, of course.

According to this[0], IE10.

0. http://caniuse.com/#feat=flexbox

Sort of? I mean, note that table skips IE10 entirely.

As I understand it, IE10 implements a different, somewhat incompatible version of the flexbox spec. You can see all the changes they made for 11 here: https://msdn.microsoft.com/library/dn265027(v=vs.85).aspx

Didn't MS announce to only keep supporting the latest IE/Edge version? This should help in that class.

Yes, schools use chromebooks

I used css-preprocessors (LESS, SASS and various postcss-configurations), but now I'm glad to not have another layer of imports and logic in CSS. Especially in react-driven pages.

I wonder, though, if there could be some workflow where you write and edit with tachyons, (babel-) analyze the code, find commonly used combination and prompt to name them.

EDIT: I also usually work with only two or three people, I guess it's different if there are 20 working on the css.

But especially in teams: don't you consider it extremely valuable that one can change the style of exactly one part somewhere in the page without affecting anything else?

Reply on news.ycombinator.com