Hacker News Reader

Comment by manigandham | Hacker News Reader

I prefer https://tachyons.io/ as a CSS framework that avoids any pre-styled themes and just provides building blocks. Great for SPA/component UIs.

View on HN

Anyone interested in this approach may also like Tailwind https://tailwindcss.com/

Tailwind is absolutely fantastic. I can code CSS 2-3 times faster and I no longer hate doing it.

How do we classify the progression that is tachyons/tailwind? Each time I see a new CSS framework I also think, is this yet another framework for devs that can’t desigh or is someone working to move the needle beyond what tachyons/tailwind have set a new place of maintainable CSS.

> How do we classify the progression that is tachyons/tailwind? Each time I see a new CSS framework I also think, is this yet another framework for devs that can’t desigh or is someone working to move the needle beyond what tachyons/tailwind have set a new place of maintainable CSS.

AFAIK, functional CSS frameworks like Tailwind are getting relevance thanks to the recent boom of functional programming.

How is this different from inline styling ? this throws class inheritance out of the window

The intention is that for repeated styles, components are extracted: https://tailwindcss.com/docs/extracting-components

A lot of modern CSS frameworks choose to ignore the cascade.

This trend has grown in response to how difficult it is to avoid regressions at scale - large or multiple projects, lots of components, lots of independent teams, etc.

The cascade really is an elegant and efficient idea but it becomes really difficult to manage as projects grow.

The different with inline CSS is that those helpers are the building blocks — that’s where your standardize your design system metrics.

As others have pointed out this library provides a mechanism to abstract into components as well.

I really do hate to be the guy this guy, but after having to maintain a website a contractor built in Tachyons, I've hated it with a passion of [insert hyperbolic phrase here].

What do you love about it/what am I missing? For me it felt like a tutorial on the most egregious CSS/dom anti-patterns, and I haven't been able to get past it.

The patterns are easy to learn (for me) and makes building components very quick while still being very customizable without having to add a whole bunch of one-off styles. And everything is still standardized.

It also removes the need to constantly reference CSS at all, and can just stick to HTML/JSX instead. It can get very verbose though, but that's a minor trade-off I think.

+1 for the reasons to use Tachyons.

Very easy to learn and reference in future.

Documentation include examples that can be used as base for minor customisations.

From someone coming from non CSS/UI/web/design background, Tachyons is very approachable in ways others are not.

My website made with Tachyons: https://aravindh.net

It's a direct 1-to-1 mapping to inline styles so why not just use inline styles? If the answer is "standardization" then using CSS as it is normally used is the logical conclusion of that concept.

Inlines styles are verbose and hard to change. Component styles allow us to build up components and customize as needed, but the styles themselves are well defined and coherent.

For example: MA1 (margin-all-size1) and MA2 (margin-all-size2) allow me to make a component with more margin, but the margin steps are standardized so everything will follow the same sizing and fit together well, and can be changed easily in one spot later if necessary.

It really only takes a few days at most to get used to the class names, and then you can easily tell everything about the component by just looking at the HTML. We follow an internal rule to place spacing first, then borders, then text, then colors at the end.

> MA1 (margin-all-size1) and MA2 (margin-all-size2)

Honestly these aren't too bad. But all the CSS frameworks I've seen of this style instead are like MA-10 (margin all 10- pixels) and MA-20 (margin-all 20 pixels) which of course completely defeats the idea of standardized steps beyond limiting you to that subset.

I think there is some value to a few of these styles in any project but ultimately you get more standardization with semantic names. "alert-danger" instead of "alert-red" for example.

There's no reason you can't combine then, and frameworks like Tailwinds mentioned above let you make those combined styles through config automatically.

However, my point was that it's a great fit for React and other SPA frameworks, where you can just create a <DangerAlert /> component instead, and inside you can use component styles.

But whatever works for you.

But if you're isolating styles inside react components, you're back to being able to use inline-styles. You can just functions and variables if you need standardization. Something like Tailwinds adds a level of indirection not a level of abstraction.

I don't like that concept of essentially inlining styles in the class attribute. It is just a misuse of html classes.

Class names should be used sparingly and describe the semantics of an element rather than its visual appearance. It should be something like class="button submit disabled" instead of class="f6 link dim br1 ph3 pv2 mb2 dib white bg-black".

If anything these styles should be exposed as sass mix-ins that you can use in your own styles. So you have a named set of style mix-ins that do not pollute class names.

button is a tag, submit and disabled are tag attributes -- surely you don't need these classes, they're either superfluous or you're not doing semantic HTML.

I agree that you could in a lot of cases get along without these classes. But sometimes you want e.g. an anchor acting as a button in a web application. Or you want a button element with browser styles. You could argue that this is also already an anti-pattern but it does way less harm then leaking inline styles into the namespace and it is still semantic. Also this was just an example (maybe not the best one) to illustrate my point that class names should be semantic and not express solely presentational attributes. The later is what styles are there for.

Especially in a javascript driven web application you may want to select all "buttons that are disabled". But you never want to select elements that "have a rounded border of 2 px and a grey background and italic font style and....". This takes class names ad absurdum.

is selectable with

    [disabled] { }

    [disabled="disabled"] { }

And

    [disabled]:not(.greyButtonStyle) { }

does the last example if you classed that style, doesn't it? I've only done a little CSS, not very recent ... unless you're recruiting, then I'm an expert ;o).

I imagine though there are times when you want to class (some) button tags as .button.

Thanks for sharing. The documentation is holy.

Reply on news.ycombinator.com