Hacker News Reader

Comment by Etheryte | Hacker News Reader

While semantic styling has been around for quite a while in different shapes and forms, this is essentially the same as inlining all of your styles in a style attribute on every element, albeit just a bit shorter to write.

It's an interesting idea to entertain as a thought, and some utility classes certainly hold value in general, but I don't see how you would ever reasonably want to use this in a project. It has all the same drawbacks as writing inline styles on elements, not to mention the large size.

Say you have a number of views and decide (or a client decides) you want all of the buttons to have a bit more padding. If anything else happens to completely accidentally also use the same padding class you're always left with manually checking every single instance just for a small change like this.

View on HN

The first thought everyone has when seeing it is what you described, including myself.

I suggest trying it out & reading more about it. It's the only way utility CSS frameworks like this seem to click.

In my opinion, Tailwind works best when being used to create template components. In your button case you would just modify your reusable button component or the reusable base button component if you have multiple button components.

You get the best of all worlds.

* You avoid writing a lot of CSS.

* You don't have to worry about thinking of CSS class names or name pollution

* I find it faster & easier to style components with a utility CSS framework in something like Storybook than it is with CSS.

* I recommend adding a plugin to your editor to help with the names of Tailwinds classes. VS Code has a couple that will suggest the right class name based on what you type.

You get all of those benefits without any of the downsides by using any other modern styling solution, for example scoped styles and scss. The arguments against this solution far outweigh the arguments for it. You're free to disagree, of course.

Scoped styles and SCSS do not prevent you from having to come up with unnecessary names for things like utilities do. That's the main benefit in my opinion. Wasting brain cycles to name arbitrary wrapper divs that only exist to be a target for layout styles things like ".image-card-content-wrapper" is a completely unnecessary step in the UI development process.

Using utility classes to build a UI is much more like building something with SwiftUI, where no one seems to argue about this silly "separation of concerns" thing we talk about on the web.

Using SCSS and using some utility classes isn't in any way mutually exclusive. If anything, it's a lot easier to mix and match. The argument isn't against having utility classes/mixins/extensions in general, but against relying on them solely.

I'm still not convinced — using only utility classes has very clear downsides, while using what's reasonably one of the most common approaches in the industry right now avoids those downsides while also providing additional benefits.

I don't think you can "only use utility classes". I think they cover 90%+ of your CSS though. I apologize if that came across as the argument I was making.

Yes, you probably will need to create some custom classes from time to time. Ideally those might be done in a utility fashion though.

TailwindCSS can be abused to resemble inline styles, but part of TailwindCSS is the fact that you have some sort of design system you can quickly set up and build upon. For example, I could define a color called "primary" and use it anywhere without caring what the actual color is.

Furthermore, styled buttons are such a common occurrence that TailwindCSS encourages users to extract common CSS patterns into component classes[0].

0: https://tailwindcss.com/docs/extracting-components

Extracting components? You mean like writing CSS classes? I'm so glad Tailwind is here to reinvent the wheel for us.

Well, you do write CSS classes, but those classes are based on your configuration. This is not a reinvention, it's a framework addressing certain issues in a certain way. It might seem counterintuitive at first, but to me it's a tool. I prefer it over SCSS (since I often rebuild in SCSS what TailwindCSS provides)

Inline styles (AFAIK) cannot be made responsive, are a pain to override given their high precedence, and do not provide any constraints—Tailwind is a design system too.

From a size perspective, compression takes care of the repetition pretty well. Utility classes allow for better reuse, meaning the overall page often is, in fact, lighter.

Nowadays most pages are put together using some kind of components anyway, so changes are that your button is already defined in one place. Otherwise you can extract your own button class.

Also see my reply to bbmario.

Even if compression is the solution for most users, I would love to have a generator on the web site where I can click on "blue" and "orange" (because that's my color scheme and my site will never use teal), not click on "forms", "buttons" and "hover", and I get a quasi-minimal version of the CSS file.

My smallish sites don't use build pipelines and post-generators and so on, I'd just like a reasonably-sized CSS file to include.

(I realize that's a niche use of those frameworks)

Oh, and if I may dream, https://caniuse.com/#feat=css-apply-rule throughout all browsers would be great!

This spec unfortunately does not appear to be alive and well.

https://tabatkins.github.io/specs/css-apply-rule/ https://www.xanthir.com/b4o00

I’ve actually been really enjoying using Hugo with PostCSS for static sites. You can run PurgeCSS automatically and have it remove all the unused crap from a CSS framework. Suddenly, it’s only 40KB for a full design system.

It is useful for component design as it removes the need to name things and then reference them.

It is similar to inline styles in how atomic it is but provides responsive classes which adapt to screen sizes.

It also provides predefined defaults for sizes and colors to prevent codebase rot and design inconsistencies.

Allows combining framework classes into nameable classes (requires using their building tool).

As someone who uses scss and know css myself I will not use it but I can see how it can be useful for devs who don’t want to learn css.

I just can’t get over the inefficiency of learning all their styles and typing them as classes feels gross compared to BEM. But I get it.

I think you have misunderstood the implementation. If you want all buttons to have a bit more padding then you either change the padding class on each button from .p-1 to .p-2 or, more likely with something like buttons, you abstract the styles into a .button class and then you can make a singular change to the padding and it will affect all your buttons.

The first one is a find and replace nightmare on any sufficiently large project and akin to inline styling. The second negates the point of utility classes.

No, it does not. They're not exclusive. I've written large pages that pretty much only used component classes for pills and buttons, with Tailwind using @apply. All the other elements used utilities. Paired with purge-css you get small CSS bundles and really quick styling.

You'd often use something like a component based JS framework or a server rendered templating language, making it easy to contain all utilities with shared logic in one place.

I’ve seen this issue at many “engineering” focused companies where many people write their own DSLs. for CSS in particular there are many people who just hate it and come up with many ways to not write it.

CSS however is very much like drawing rather than engineering. Some aspects are just not scalable. You can draw many things in vector by conbining shapes for example but a pen or pencil is still very necessary for many parts of both exploratory creation as well as something polished.

The same goes for HTML and Javascript to an extent. While it’s great to build railroad tracks, you can’t take a train everywhere... any abstraction has to also have the ability to easily break out of it to handle edge cases. Clean and Pure abstractions almost never have the grittiness necessary to reflect a fractally complex problem.

From a performance point-of-view, it's not the same at all. Also this is a design system, not just a set of utility functions. You can also abstract common components and reuse them.

What's the most recent info on large inline css for page speed? Google used to say not to inline everything [1], for size/dupes, and CSP issues.

1: https://developers.google.com/speed/docs/insights/OptimizeCS...

Reply on news.ycombinator.com