For the longest time I avoided Tailwind because including styles right in the markup seems like insanity to me. However, after using it on a project I can't argue with the results. It's quick to use and the site does look a lot more consistent than other hobby project I've done.
To me, the main benefit of Taiwind is not choosing arbitrary values. Writing everything as classes in the markup is something I deal with. It's ocasionally really convenient, but a distraction most of the time. This seems to solve exactly that problem. I still get a reasonable consistent set of values to choose, but can still write normal CSS. I'm really looking forward to trying it out.
IMO the best part of Tailwind (and much like yourself I wasn't sold initially) is working with a bigger team or passing projects around. There's no picking through classes figuring out what's going on; we can literally pass any page to a developer, and assuming they're familiar with Tailwind, they know what's going in the CSS.
Completely. And if I'm working solo, I'm also much faster because I don't need to think about how to name classes and when to create new classes or when to re-use existing ones etc.
> I still get a reasonable consistent set of values to choose
How do you deal with one of those values needing to change? With SASS or css-in-js you can define a variable and then update it everywhere at once by changing a single line. This seems to be the biggest thing you give up with Tailwind.
Yeah, using components definitely alleviates this issue somewhat. But in our code base we have some values which are global constants. Things like padding values, colors and fonts. Seems like @apply could work. Essentially falling back to regular CSS, but only for these few global values. I might give this a try next time I start a new project.
I use Tailwind for some projects, BEM for others. For some projects we've built a rough outline using BEM (for quick everywhere changes) and then when we get to the final thing, used Tailwind.
The 'update everywhere' was the biggest hurdle for me, particularly with 'design on the fly' quick pieces. But as per the Tailwind docs, generally you're building reusable parts in Vue or whatever, and you change there. There's a page on it here: https://tailwindcss.com/docs/reusing-styles - which I appreciate is still a bit of a 'really?!' kinda thing if you're used to normal CSS.
But to quote The Office... Different drinks for different needs.
You can modify or extend defaults in your `tailwind.conf.js`, or you can use the arbitrary syntax for "one offs" (`w-[69px]`), or wrap things in components.
If you really want to define some custom "global" variables, you can do that with Tailwind. You are free to add any names to the pool of available values along with a custom value in the Tailwind config. At any point you could adjust such a value.
However, I've found such a thing mostly unnecessary. Even with Tailwind I have some abstractions at the component layer so that I don't need to change values all over the place when I want my buttons to have more padding. I'd just change `px-2` to `px-4` in that one place where I define my button styles, for example.
If you need to change values dynamically with JavaScript such as you can with CSS-in-JS, I'd typically use CSS variables.
Now of course this isn't as powerful a system as SASS variables, but it's good enough. That is to say, I have gripes with Tailwind still, but dealing with variables isn't one of them.
I don't fully understand how this is supposed to be an alternative to Tailwind while not providing utility classes out of the box? Did I miss something in the docs?
To me the biggest benefit of Tailwind, apart from the great base design system, is not needing to come up with class names for 99% of the things in the app. This is of course only possible when you have some way to abstract components out of the reused parts of your markup – e.g. you're using React.
Edit: The title was "Open Props: Tailwind Alternative from Chrome Dev Team" when I posted this comment.
I think it's being compared to Tailwind because it gives you consistent scales - your padding isn't 4px, it's --size-fluid-3.
I agree with you: half of Tailwind's value for me is the scales, and half is that I don't need to create a derivative taxonomy of my app - I just style the thing that needs styling.
It seems like this isn't a Tailwind alternative, that's something the poster made up. I think it would be best for a mod to change the title here.
However, there's a point in using something like BEM (https://getbem.com/) for your class naming scheme, and go away with the utility classes within your HTML. The utility classes from Tailwind (and Bootstrap) provide great consistency, and this seems to provide the same but from within your SCSS itself.
To me the biggest drawback of tailwind is having half my styling in HTML and the other half in CSS. This directly addresses that issue by using. CSS to include functionality rather than HTML element class names.
Tailwind had to come up with something, and that something is it's JIT compiler, because shipping 10mb to the browser in dev was untenable. Let alone the people that never setup purgecss and were shipping that in production.
I don't see how that's an alternative to tailwind. The point of tailwind is not having to constantly switch back and forth between the HTML and the CSS.
I did something like this for a side project: extracted relevant Tailwind defaults that I needed and converted them to css vars.
There are some limitations to this approach: some of the utility classes encompass several values, and you have to remember to include all of those CSS vars to replicate the class.
Posting "dang, please re-title this" doesn't do anything, you should email hn@ycombinator.com instead, as I just did. Dan or some other behind-the-scenes mod usually handle these quickly.
True, but also interesting. I'm sure dang and the mod team would have a special filter for comments mentioning "@dang" or something alike. Seems imperative and useful.
Edit: ...and if they do, I think I just tagged them unnecessarily. xD
Doesn't make sense to retitle it now because the thread is so dominated by the editorialized title. I think we need to leave it. This is why the site guidelines contain the rule: "Please use the original title, unless it is misleading or linkbait; don't editorialize."
[0] Also, because it's not murky enough, "Chrome Dev" are the DevRel people (community outreach, web.dev articles, conferences, etc), not the "developers of Chrome." https://twitter.com/ChromiumDev
So, this is interesting. A different approach, whereby you still compose your own classes, but I guess the variables are all put together ahead of time so you use the variables instead of having to remember all the different options.
And makes it easy to import into existing projects and just start using.
What are some css files that does basic skinning without JavaScript. I liked bootstrap for that reason. Specify the class name and everything is pretty
Does tailwind expose their "settings" as CSS vars / props? IMO that would make tailwind very similar to this project, as well as lets you set everything on a more granular level in CSS, rather than relying on the config files.
This is generally how I have been using CSS with my own custom framework.
The benefit for me of having everything basically be variables is you can quickly modify a site to look like a different one to save time.
I also have, which I think the Chrome people should offer with this, a visual settings editor on the front end for swapping/tweaking styles in real-time.
I think the gradient examples here are a good example of why Tailwind (and similar things) are really nice. In this you have `background-image: var(--gradient-4)`. If you look at that in your code, what does it do? How can I make it end at a slightly darker blue or change its direction? No idea. They look nice, I like the noise examples too, but at some point you're probably going to want to tweak them.
Whereas if I choose a gradient from https://hypercolor.dev and copy its tailwind code it's something like `bg-gradient-to-br from-pink-300 via-purple-300 to-indigo-400`. I can look at that in my code and form an idea in my head what it looks like, and tweak it trivially.
Wow, I could not feel more the opposite of this. Tailwind is providing an entire DSL of class names for you to learn, whereas the Open Props example is literally just writing CSS.
"How can I make it end at a slightly darker blue etc." -- you're just writing CSS, so just write the CSS you want instead. ie OpenProps is just providing you a CSS variable that expands to something like: `background: linear-gradient(blue, pink);`, and if you want to change it you can just change it.
I don't define nearly as many CSS variables, but I do find it good practice to define your colors, spacing, shadows and fonts in CSS variables. It keeps the site consistent. It is a good practice whether you use this library or not.
IMO the main value of Tailwind is that it's a step function over your units and colors, which helps bring better consistency and dev speed to UI implementation.
Tailwind's "write class names instead of CSS" approach makes sense in the component-based systems most apps are built in these days, where pretty much any repeated markup will be turned into a component. It performs better than scoped styles and is less complicated.
A CSS variable approach like Open Props or Pollen is, in my experience, better if you're not using a component-based system (ie. conventional HTML) and therefore have repeated markup patterns. Having a simple class name to apply to repeated markup is much more maintainable than trying to copy/paste a long tailwind string around.
> CSS variable approach like Open Props or Pollen is, in my experience, better if you're not using a component-based system
I see it the opposite way, Tailwind is for when you don't care about design system and would like the freedom of ad-hoc styles, that is conveniently already written.
When you do need to IMPLEMENT a design/component based system, you'd prefer css (for less indirection) and have the interface of the system be something like react props where it's more restricted, as opposed to classes like in Tailwind.
63 comments
[ 3.4 ms ] story [ 128 ms ] threadTo me, the main benefit of Taiwind is not choosing arbitrary values. Writing everything as classes in the markup is something I deal with. It's ocasionally really convenient, but a distraction most of the time. This seems to solve exactly that problem. I still get a reasonable consistent set of values to choose, but can still write normal CSS. I'm really looking forward to trying it out.
How do you deal with one of those values needing to change? With SASS or css-in-js you can define a variable and then update it everywhere at once by changing a single line. This seems to be the biggest thing you give up with Tailwind.
The 'update everywhere' was the biggest hurdle for me, particularly with 'design on the fly' quick pieces. But as per the Tailwind docs, generally you're building reusable parts in Vue or whatever, and you change there. There's a page on it here: https://tailwindcss.com/docs/reusing-styles - which I appreciate is still a bit of a 'really?!' kinda thing if you're used to normal CSS.
But to quote The Office... Different drinks for different needs.
However, I've found such a thing mostly unnecessary. Even with Tailwind I have some abstractions at the component layer so that I don't need to change values all over the place when I want my buttons to have more padding. I'd just change `px-2` to `px-4` in that one place where I define my button styles, for example.
If you need to change values dynamically with JavaScript such as you can with CSS-in-JS, I'd typically use CSS variables.
Now of course this isn't as powerful a system as SASS variables, but it's good enough. That is to say, I have gripes with Tailwind still, but dealing with variables isn't one of them.
"--radius-2": unprefixed, in global scope/namespace? I'd rather use scss variables and modules tbh.
To me the biggest benefit of Tailwind, apart from the great base design system, is not needing to come up with class names for 99% of the things in the app. This is of course only possible when you have some way to abstract components out of the reused parts of your markup – e.g. you're using React.
Edit: The title was "Open Props: Tailwind Alternative from Chrome Dev Team" when I posted this comment.
I agree with you: half of Tailwind's value for me is the scales, and half is that I don't need to create a derivative taxonomy of my app - I just style the thing that needs styling.
However, there's a point in using something like BEM (https://getbem.com/) for your class naming scheme, and go away with the utility classes within your HTML. The utility classes from Tailwind (and Bootstrap) provide great consistency, and this seems to provide the same but from within your SCSS itself.
They did make a companion JIT PostCSS plugin that likely has Tailwind as its forebear.
Tailwind had to come up with something, and that something is it's JIT compiler, because shipping 10mb to the browser in dev was untenable. Let alone the people that never setup purgecss and were shipping that in production.
So please explain what they are and why they are not overengineering?
Still, I am not sold...
There are some limitations to this approach: some of the utility classes encompass several values, and you have to remember to include all of those CSS vars to replicate the class.
However, open-props never mentions tailwind. That simple mis-title has hijacked the convo.
Edit: ...and if they do, I think I just tagged them unnecessarily. xD
https://news.ycombinator.com/newsguidelines.html
The [flagged] marker, btw, is because users flagged the submission, which they were correct to do.
[0] Also, because it's not murky enough, "Chrome Dev" are the DevRel people (community outreach, web.dev articles, conferences, etc), not the "developers of Chrome." https://twitter.com/ChromiumDev
And makes it easy to import into existing projects and just start using.
That’s interesting.
The benefit for me of having everything basically be variables is you can quickly modify a site to look like a different one to save time.
I also have, which I think the Chrome people should offer with this, a visual settings editor on the front end for swapping/tweaking styles in real-time.
https://en.m.wikipedia.org/wiki/Corporate_Memphis
You should apply to buzz feed with these skills.
- HTML
- CSS
- Clickbaiting
- Javascript
Whereas if I choose a gradient from https://hypercolor.dev and copy its tailwind code it's something like `bg-gradient-to-br from-pink-300 via-purple-300 to-indigo-400`. I can look at that in my code and form an idea in my head what it looks like, and tweak it trivially.
"How can I make it end at a slightly darker blue etc." -- you're just writing CSS, so just write the CSS you want instead. ie OpenProps is just providing you a CSS variable that expands to something like: `background: linear-gradient(blue, pink);`, and if you want to change it you can just change it.
IMO the main value of Tailwind is that it's a step function over your units and colors, which helps bring better consistency and dev speed to UI implementation.
Tailwind's "write class names instead of CSS" approach makes sense in the component-based systems most apps are built in these days, where pretty much any repeated markup will be turned into a component. It performs better than scoped styles and is less complicated.
A CSS variable approach like Open Props or Pollen is, in my experience, better if you're not using a component-based system (ie. conventional HTML) and therefore have repeated markup patterns. Having a simple class name to apply to repeated markup is much more maintainable than trying to copy/paste a long tailwind string around.
I see it the opposite way, Tailwind is for when you don't care about design system and would like the freedom of ad-hoc styles, that is conveniently already written.
When you do need to IMPLEMENT a design/component based system, you'd prefer css (for less indirection) and have the interface of the system be something like react props where it's more restricted, as opposed to classes like in Tailwind.