Earlier quoted context omitted.
> "holy hell this is the worst thing I've ever seen" This is so true. All the classes in HTML source look so ugly and verbose when you first see it. At first I dismissed the framework and wondered how someone could think this was a good idea. I kept seeing it pop up, and the comments were always positive, so I put in a little more effort into understanding how it works. Eventually I decided to try it, and within 5 mi…
The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?
Tailwind: A Utility-First CSS Framework
41–50 of 106 posts
Re: Tailwind: A Utility-First CSS Framework
#42Earlier quoted context omitted.
> "holy hell this is the worst thing I've ever seen" This is so true. All the classes in HTML source look so ugly and verbose when you first see it. At first I dismissed the framework and wondered how someone could think this was a good idea. I kept seeing it pop up, and the comments were always positive, so I put in a little more effort into understanding how it works. Eventually I decided to try it, and within 5 mi…
The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?
With Tailwind, we don't try to pretend that you will never need to write any CSS, and instead embrace that fact and give you as much tooling and guidance as possible on how to extend the framework the way it was intended to be extended.
In the situation you're talking about, you would extract a "component class" using Tailwind's `@apply` directive to enforce that the component followed your design system:
https://tailwindcss.com/docs/extracting-components
Then you could update all your buttons at once by making changes to that component class.
The key with Tailwind is that it encourages a "utility-FIRST" workflow, not a "utility-ONLY" workflow. Build your UI with small primitive utility classes, and extract components only when you start to experience painful duplication problems.
Re: Tailwind: A Utility-First CSS Framework
#43Earlier quoted context omitted.
Isn't that basically the same thing as inline styles? Not quite, for a few reasons: Inline styles don't respect media queries, which basically rules out responsive design Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue) Inline styles cause specificity issues, since they trump separate stylesheets. Inline styles don't support print-specific styles. Inl…
So what happens when your design changes and suddenly all your white buttons need to be off-grey? You change the class on 700 components?
Re: Tailwind: A Utility-First CSS Framework
#44https://github.com/tachyons-css/tachyons
Its similar, but has been around since 2015.
Re: Tailwind: A Utility-First CSS Framework
#45Earlier quoted context omitted.
Isn't that basically the same thing as inline styles? Not quite, for a few reasons: Inline styles don't respect media queries, which basically rules out responsive design Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue) Inline styles cause specificity issues, since they trump separate stylesheets. Inline styles don't support print-specific styles. Inl…
So what happens when your design changes and suddenly all your white buttons need to be off-grey? You change the class on 700 components?
If you have 500 buttons using the exact same set of classes, you should of had a button class in the first place. Almost all my projects have their own button and form input classes for this exact reason!
Where utility-based CSS frameworks really start to shine is the other 75% of your codebase, where you're inventing clever class names, only to end up using them once.
This is also why Tailwind calls itself a utility-FIRST framework. Build things with utilities, and extract components to classes when the need arises. Avoiding early abstractions provides a lot of value (in any programming language for that matter). Not having to invent a name for every single piece of UI also saves a ton of headaches down the road.
Re: Tailwind: A Utility-First CSS Framework
#46Author of Tailwind here! If you haven't worked with a library like this before, I promise your gut reaction will be "holy hell this is the worst thing I've ever seen" (it was my reaction too!) You really do have to try it to shake that impression. If you need a bit more convincing before you're willing to try it, I wrote an in-depth article a while ago that documents my journey from a "semantic classes"-loving HTML/C…
.align-left {
text-align: left;
}
This is a very reusable class, of course, because it is literally just css but with a different name. But that's what always ends up happening. The lowest common denominator for reusability in css is so low, that you often end up with ridiculously simple classes like this, or close, basically re-inventing css with a different syntax. The new challenge becomes learning this new language and how to compose it.The core issue with CSS is that it has divergent architectural characteristics simultaneously. On the one hand there are usually a set of extremely re-usable primitives: btn, normal-text, overlay, card, etc. Then very quickly, we get higher-level components/styles that are extremely not re-usable: order-form, contact-page, etc. And other stuff in between. Applying the same structural models to all of it will cause sub-optimality at some level.
To address this, I've found that applying different models to different aspects of the css most beneficial. Basically having a mix of both utility css, and semantic css. Low-level, highly re-usable components are defined in a utility fashion so that font-sizes, colors and other things are consistent throughout the site. And complex, non-reusable high-level components that compose primitives, and other custom non-reusable css, to define the top-level components. When the need for sharing common css arises, those can be abstracted out into utility stuff, but part of the goal is to keep the utility part small so that people don't have to learn an entirely new language.
[1] https://adamwathan.me/css-utility-classes-and-separation-of-...
Re: Tailwind: A Utility-First CSS Framework
#47Earlier quoted context omitted.
> "holy hell this is the worst thing I've ever seen" This is so true. All the classes in HTML source look so ugly and verbose when you first see it. At first I dismissed the framework and wondered how someone could think this was a good idea. I kept seeing it pop up, and the comments were always positive, so I put in a little more effort into understanding how it works. Eventually I decided to try it, and within 5 mi…
The problem I have is: what if I want to (for example) add a style or take it away from all my buttons? It's going to be a lot of manual fiddle, or is the idea that hand written sites are wrong to start with and I should be using generated code?
.btn {
@apply .bg-grey .rounded-sm;
}Re: Tailwind: A Utility-First CSS Framework
#48Earlier quoted context omitted.
Generally you’d have your button html and classes inside a component so you’re just tweaking that one component.
Then it feels like we're just back to writing normal CSS classes.
Re: Tailwind: A Utility-First CSS Framework
#49It also means, for front-end developers like me, that I can create a company theme on Bootstrap, and get junior developers to use it can feel comfortable with being able to implement the brand design language and not have to pixel-fiddle. Not only does this strengthen the technical skillset of my team, but it also helps keep standards high when dealing with offshore resources.
We can get them to build UI for entirely separate projects, slap our branding on it, and dramatically cut down on resource allocation, time, and effort.
So, here's the thing: this is great, but Bootstrap also has utility classes these days. If I use Tailwind, or Foundation, or Bulma, I immediate lose out on developer leverage. This is so much more powerful than moving some classes around.
Approaching all of these design concerns in a slightly different way just isn't powerful enough to outweigh the leverage Bootstrap has over everything else out there.
It's just not significantly different enough. It doesn't standout to me. In fact, how it differentiates in its introduction is a _con_ to me. No, the industry doesn't need complete UI kits, design languages vary enough that this could provide additional undesired weight, however people use buttons, drop-downs, and many other common components _all the time_.
A major competitor to Bootstrap in the arena would need to do something revolutionary.