I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file.
If you're on the fence, try it out. I think it's the future of writing CSS.
Tailwind didn't invent utility classes. We've done this since the '90s.
> significantly easier to maintain
Disagree totally. Utility classes are good for rapid prototyping. But they clutter your code, mix semantics with presentation, and are a pain in the ass when it comes to code reuse. The cascade part of CSS is, believe it or not, actually useful for code reuse. Need to change a font deep in some nested component? Not a problem with CSS. Tailwind, you're fucked. You'll need to modify each component layer to pass down a class prop. Or do some ugly context hack.
* Tailwind doesn’t claim to have invented utility classes, nor even utility-first CSS architecture.
* HTML has always mixed semantics and presentation.
* It’s terrific for production applications because we don’t lovingly hand-craft each DOM node. Far from being an enemy of reuse, it enables refactoring at the point of HTML generation, and aligns particularly well with partials and view helper functions/objects.
* The cascade is still there; you’re not fucked. Not even if you’ve been suckered into using some react-like framework.
no, we really didn't. tho i'll agree that utility classes have been a thing for longer than tailwind/bootstrap/tachyons/pico/etc have existed
> mix semantics with presentation
there is nothing semantic about class names: nothing, zero, zilch - using IDs are even worse due to specificity, with none of the "semantic" benefit. focus on the correct top level wrappers
part of me wonders about the extent of what HN commenters actually do on the web regarding styles, or if they just slap together some homogenous web app or static site where its rather easy to not have a design team needing flexibility on every little thing.
case in point, our main "button" has about 15 different base variants (that *3 currently) depending on context, not counting the interaction states.
Okay so one huge difference between now and the late 90's is that we have several very popular ways to create "components" of HTML/JS/CSS. From react to liveview it's very popular. This is important because it's much easier to maintain.
We did back then too. In fact we had SSR. It often took the form of CGI, like PHP - which, hate the language all you want, it has a very sane and scalable model.
and bi-directional data flow was done in the form on long polling. this sounds very much like a get off my lawn argument rather than anything rooted in reality of the now.
I’m familiar with the pain point you’re describing. It’s not the cascade, it’s the ability to target a child element through a selector. (Which utility based approaches do away with)
But the thing is you can always do that if it’s needed. There’s no one forcing you to strictly adopt the utility pattern. It’s all just vanilla CSS at the end of the day. If a hybrid approach works best for your project then do that.
Personally I find the need for this to be quite rare, and there are actually some good arguments against writing too much specificity in to your css even if it’s more convenient up front.
Although Tailwind won't target those descendant elements for you, it doesn't block your ability to do so. We found that 95% of our CSS goes away, the remaining 5% is still there with complex selectors and/or CSS settings that aren't in Tailwind. That remaining small amount is far easier to deal with.
I also started out thinking the whole idea seemed backward. Now I think of it this way: it works extremely well in practice, even if in theory it won't.
To fix the css + jsx in one file, just write your styled components at the bottom of your component.
If you ever seen a react component completely riddled with Tailwind, you'll realize how messy and uncoordinated it looks.
Even I would consider switching between two files just to avoid that style of css.
Furthermore the necessity to utilize horizontal scroll because adding 10+ more rules will inevitably break your prettier printWidth rule is, by far, the most annoying aspect of Tailwind.
Consider these two snippets, after time of not looking at your css code, do you think 10+ rules on one line is maintainable?
Not even close, ask yourself to change a css property - you would have to iteratively go from left to right until you find it, whereas looking from top down you can immediately catch the css rule you want to find.
Succinct doesn't mean maintainable, and sometimes verbosity does.
Regardless of where place your tailwindcss or where you split / sort classes, reading iteratively from left to right, especially if the css rules are numerous, is not legible.
just looking at the two examples above, and already I can tell how much it would be easier to maintain verbose css.
So u cant manage the little bigger list of words? And you can manage way complex software behavior at the same time? Particularly if it lets you manage small subset of CSS ?
I wrote a “function” for this exact reason. It’ll display the classes in a much easier to read way. It also can type check to ensure that all classes are valid. I say function in quotes because it’s actually a babel macro that’s get compiled down so there’s no runtime cost! https://github.com/fleck/class-types.macro#better-prettier-f...
It's much more difficult to scan a list of classes in a single line. With CSS I can quickly scan the declarations from top to bottom until I find the thing I want.
Complex nested declarations are also super easy to scan when using SCSS. When you start adding pseudoclasses with TW it becomes a shit show.
And it really makes the markup an absolute mess for anything other than trivial examples.
People complain about not knowing where the styles are, which was a valid concern when doing old school CSS (everything in a couple of files) but I haven't had that issue since I started using SCSS in almost a decade.
When doing front end with components I store the SCSS for the component in the same directory of the component file. Eg: MyComponent.svelte and MyComponent.scss. Super easy and clear. I've also written a small VSCode extension that allows me switch between the component and its SCSS file with a shortcut. I don't even have to open the SCSS file or look for it. I configure Webpack or whatever I'm using to automatically include the .scss files in the component folders. I have all the convenience and control I want without relying on something as convoluted as TW.
I don't think the example compares. In languages like JS, double, triple or even further nested ternaries are possible. But terser isn't always better because human readability is important. I can easily understood your SASS example because I know SASS, but I'd never write it like that. If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.
The problem with Tailwind is there's nothing you can do to avoid the much more difficult to scan and understand syntax described above. I personally don't understand why people are drinking this koolaide. I really think this is a fad a lot of people are going to come to regret when they go back to maintain older projects based on it.
> If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.
a) maybe you don't really know how far up the chain that tag gets called from.
b) it creates new selectors for class1 and class1.class2, as well as class1.class2's hover
c) creates a hyper specificity
now, I'm not advocating this usage of SASS - but it can be a handy hatchet when you need to support multiple themes with minimal changes/effort, much to the chagrin of specificity and maintainability
The point I was trying to make was just because Tailwind doesn't happen to be expressive enough to get you into that particular kind of mess isn't a reason to use it. True, its fair to say you can write bad CSS or SASS, but that's the same for all programming languages. If your main goal is something foot gun free and safe for the inexperienced, might as well go all the way and recommend low/no code or even Squarespace.
I think the reason a lot of ppl think they need tailwind, is because a) they aren't familiar enough with more current CSS techniques like CSS modules and linting which can limit stuff like nested descendant selectors and/or b) they're tricked into thinking they won't have to learn as much about CSS (a dangerous fallacy unless you're sticking to the most basic of prototypes!).
I guess the point you're making is that TW prevents you from making certain errors.
Which is technically true but irrelevant. TW doesn't prevent you from understanding fundamental CSS concepts such as the box model, cascading, etc. Anyone with even basic CSS knowledge would not write this nonsensical and malicious example you just used.
You can do both of those things with Tailwind. Put the css only components at the bottom and use them in your main component if you want. Break the classes over multiple lines if you want.
The difference between your 2 examples is that TW allowed you to handle media queries seamlessly but you couldn't do that in your styles example.
In practice our "full-stack" developers are writing less and less CSS because they're just using the components that encapsulate all of this, our frontend developers get code completion for our design system tokens, and we haven't had to ship any new CSS classes in the last few months.
Our new hires are able to just use the design system tokens rather than going in and saying `padding: 5px` and `padding: 4px` because the designer didn't think it was a big deal. They just write `p-1` and that covers it.
All the components get tree-shaken and only ship the styles they need so bundle size gets reduced as well.
If I had my dream team of 10x frontend developers and a perfect design team who always follows the rules they create then yes I would use regular css with css variables, but I don't.
I am more than happy to sacrifice "separation of technologies" for a happier team, more consistent styling, and faster delivery times.
"Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider."
Not sure what you mean by that. I've been doing this since we did layouts with tables and shims in the 90s. I've found TW pretty nice to maintain myself.
"It's not that much harder", but a) it's a simple example and b) now you're going to litter your code with a load of hard coded media widths?
Let's talk about something concrete. Let's take a really simple layout that changes border and margin responsively (this, for me, is seamless).
As a side note, you can configure prettier for automatic class sorting for tailwind! It makes a huge difference in terms of code readability and maintenance.
Same. People touted semantic CSS as the future for ages, and that's what I was taught in my first role out of college. Parts of that made sense (e.g. de-noising html), so I was against tailwind, but it's has quickly become one of my favorite tools.
I am pretty conservative in terms of "use boring tech", because I see so much reinventing of the wheel and making the same mistakes, but Tailwind is not in that camp!
I was never happy with any of the CSS in JS solutions in React land – all of them felt tedious or boilerplate-heavy compared to Vue's CSS model, which is excellent. Writing css and getting component scoping for free are great.
But with tailwind I've minimized usage of Vue CSS too. I pull it in occasionally when I need specific overrides of the tailwind component lib I'm using, but other than that I don't even need to touch css.
It's really for the React generation. People used to embedding the code, markup and style all in one file.
I've tried multiple times to use it, but I always end up using something like bootstrap. Funnily enough, I paid for tailwindui and take the styles and reproduce them in bootstrap css.
Bootstrap community seems to have given up. They only want to sell templates. The default is ugly. Sometimes I think about going back to bootstrap 2.
If you're using React, check out Material UI. I was a big fan of Bootstrap, but I didn't like that there was still so much for me to build. MUI comes with components for things like user avatars out of the box. But it doesn't get in the way at all either, it's very customizable at the theme and the component level (I'm using it with styled components, and I love not having to come up with class names for everything). I've also tried Antd and it's impossible to customize.
I’m a huge fan but maintaining tailwind projects is actually a huge pain in the ass. I could maybe improve it by factoring out the classes from my html into a separate sheet using @apply when I’m “done” a project, but I don’t, and it defeats the convenience value anyway.
The markup is so overwhelming when there’s anything remotely complex. And sometimes components are almost identical but with slight variations. I miss seeing an element with a simple .classname to let me know what’s going on. Admittedly this is due to a lack of foresight on my part but moving forward I’m either re-thinking tailwind or ditching it.
I even have a pre-release 0.6v or something running on a production site I need to maintain. Which is stupid and my fault but demonstrates 1) that I’m a huge fan and have been using it forever and 2) it can suck maintaining if not thought out properly.
Don’t forget now you need to configure webpack for node sass and purge css and blah blah blah.
Tailwind is great for building something you never need to touch again.
I really like utility classes and think Tailwind is really smart for many usecases, but the drawback with Tailwind is even if you componentize, your code is sprinkled with very specific visual classes like for shadows, border radius, etc. When companies want to refresh their look and feel, it's really annoying to change everything to remove now unwanted shadows, etc. In spite of it's age, I've found Bootstrap is better for this as it uses predefined component classes that can be restyled without rewriting the app or components (but also has some handy utility classes).
I know you can define your own component classes in TW, but then you've just recreated Bootstrap/Bulma/etc, but with no 3rd party components available. (Tailwind UI is just some limited copy paste code snippets last I looked.)
There are a bunch of great 3rd party components available in tailwind now. https://daisyui.com/ is one I've been using. They're usually a tad bit lower level than typical framework component libs, but the flexibility is great.
A great thing about that is they're not React-specific, Vue-specific, etc. You can use them in everything from raw html to your JS library flavor of choice.
DaisyUI is a nice approach and hope it succeeds. We were looking to use that until we realized it's almost identical to Bootstrap, and that we were just using Tailwind as an elaborate way to make a custom Bootstrap theme at build time. Company decided to go with BS5 instead.
Have you ever had to change the company's look and feel with anything else than tailwind?
I had to do it with a BEM codebase, and I also had to do it with tailwind. The tailwind situation was by far the easiest one. And it was because I was not afraid to remove things that could break unrelated parts of the application. Not allowing developer to hand write CSS is a great restriction for a good bunch of developers. The messes out there are unbelievable.
> Have you ever had to change the company's look and feel with anything else than tailwind?
Yes, many times, with normal CSS. It's basically the point of cascading style sheets. Sticking to proper class names and elements makes reskinning a breeze.
> It's basically the point of cascading style sheets
The "cascading" part is what makes it incredibly complicated. Keeping the "cascade" in sync with the actual markup is not a trivial task in teams with many people of different skills levels.
Not everyone is a top 1% dev, so we need easier and safer tools so that everyone can work and maintain a codebase.
> Sticking to proper class names and elements makes reskinning a breeze.
This is more easily said than done. It's like saying "Just don't write bugs". Every single project I find that has been built with BEM and similar patches after a couple years are just a mess and their CSS becomes "append only", as there's no guarantee that removing something won't break in unexpected ways.
You're just shifting work though. The commit will now contain 10000 non html structure changes to an html, phtml, whatever, instead styles to a CSS sheet. Might as well go back to doing inline styles. There's a reason we don't do that anymore.
This isn't the 90s. We all use file includes now. If you're working on a view file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing.
"If you're working on a view file longer than a couple hundred lines,"
Sorry, but this might just mean one file-include per tag if you use tailwind-css. The in-line CSS exceeds the HTML content by sometimes an order of magnitude bloating the page HTML to ginormous size.
"We all use 'cascading sheets' now. If you're working on a CSS file longer than a couple hundred lines, properly formatted, you're not abstracting enough or it's a one off marketing thing."
> The commit will now contain 10000 non html structure changes to an html
It's an acceptable trade off. Nothing is perfect. In exchange you're guaranteed those changes only affect this markup, and not some other li > ul > a whatever somewhere else.
> Might as well go back to doing inline styles
No, it is not. This has been explained thousands of times anyone says "tailwind is like inline styles". You can do responsive, you're limited to a consistent subset of rules, minimal output css file, caching, etc, etc. For example, here [1] is an explanation why it is not the same, but there are thousands.
By reading your answers I deduce you've not used it yet. And this is exactly what is being discussed here. Fanatics closed inward looking people will never like it, nor anything that defies what they've been taught for years. Like religion almost. You have to try it for real to see the benefits. It is not perfect, but the net result is very positive for a lot of people as you can see from the usage statistics. Just be a bit more open minded to new tech and give it a try. At least you'll understand why it is not the same as inline styles which is a pretty basic thing you understand after 1 hour of using it.
Crazy, in my entire career I've never been involved in a redesign that didn't involve the entire layout but only changed some colors, paddings and drop shadows.
Definitely done it a bunch of times. Marketing comes out with some new web font crap they want and we need to go adjust everything. Flat face buttons become popular so we get rid of the pseudo 3d ones. They want to launch a new webstore but dont want to redesign, lets just steal one we have and reskin it a bit.
> Not allowing developer to hand write CSS is a great restriction for a good bunch of developers.
I agree, main point is that I think there are better tools for large codebases. We had a "no CSS" rule where we used bootstrap components and utility classes only.
agree. i'm a cynic turned convert as well. even told a friend it caused ugly unreadable classname soup and that zero-runtime CSS-in-JS solutions (like linaria, but even css modules) could do more with a lower learning curve (because you Actually Write CSS instead of tailwind shortcuts).
then i tried learning it and it turns out that Tailwind's constraints both help my design and help with the learning curve
If you're using a component-based architecture (e.g. when using React, Vue or Angular), otherwise it can get pretty annoying. But if you do, it's pretty great; you don't really need the abstraction of reusable classes, when you already have reusable components, and getting rid of useless abstractions makes me a happy programmer.
This isn't meant as a contradiction of your point, but there are plenty of ways to use component-based architectures with server-side rendered apps, too, like GitHub's ViewComponent gem for Rails. https://viewcomponent.org
Also, I'd go so far as to say that if you're not using a component based architecture for your web app's view layer, you're creating a ton of extra work for yourself.
I’d add you don’t even need ViewComponent. Layouts, partials, variants, and helper functions provide plenty of heavy lifting options when it comes to refactoring your HTML.
My take on ViewComponent: it’s what helper functions become when they grow up into proper objects. Great for larger projects, may be more infrastructure than necessary for smaller ones, adopt incrementally when they seem compelling.
Don't need it, but I've found ViewComponent to be a big win over partials. Being explicit with the available state instead of implicit has helped me catch plenty of bugs.
I am using it with traditional Django + Jinja2 for templating now which is working well. With {% macro %} you basically get fully reusable “components” on the backend so there’s limited copy pasting of tailwind classes.
I would add that, even for regular HTML you can write CSS using @apply and still leverage the nice structure tailwind provides while creating your component CSS classes.
I was where you were and am glad I got over my reticence because it's genuinely feels like a pleasure to use now. Another good aspect is that while you're using tailwind's custom identifiers, you still have to write real CSS and so are quite likely to end up refining your own CSS skillset in the process.
Isn't this at the cost of dramatically increasing HTML size ? I have seen tailwind littered HTML increase by 2x-3x the page size with all that extra-ordinary repetition.
PS: I agree it makes CSS coding quite faster due to less typing involved when designing something thanks to succinct atomic CSS classes. I am not sure less typing is better though, especially for maintainability and performance.
This, and the tendency towards repetition, is my biggest issue with tailwind (and I still love it).
It tends to make the code pretty ugly.
There are ways to improve things somewhat (moving "bundles" of classNames into properties of a local or global cssClasses object and adding those to your elements' className), but you lose the intellisense when editing classes and it often ends up feeling like the extra friction isn't worth it. Having the styles right there seems to be a key part of what makes using tailwind so productive.
We have enough decisions to make regarding design as it is, adding organization, naming, selection, and attempting to maintain a sensible hierarchy into the mix leads to a fog of decision fatigue that I didn't realize existed until I tried Tailwind and it lifted.
The truth about web design is there's only a few things that repeat in semantics, that's why lowest level token works. At the end of the day, web design is mostly color, space, font, barely things that are higher. If you have some buttons and form inputs pattern, your design is almost done (excluding non-ui state/behavior).
>I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file.
Same. I always said they'd pry my stylesheets from my cold dead hands. But then I tried it, and I'll never go back. I feel like it's time to let go of those last vestiges of the old "web development" paradigm, and start treating the browser as what it is; a universal VM for application development.
Color management is easy in SCSS, too, though. I just have a _colors.scss file and enforce that no color is ever used that isn't in that file.
If I'm working with a designer rather than designing my own UIs, that they have a default color palette isn't helpful, so what do I gain from Tailwind?
EDIT: Reading some other comments, I wonder if part of the reason I don't see the utility is that I use Vue, not React. It sounds like Tailwind solves a lot of the same problems that Vue+SCSS does.
One good part is the generated classes for every color. Background colors, font colors, border colors... everything in the color palette is usable as `bg-blue-500`, `text-blue-500`, `border-blue-500` etc. Could be reproduced in css for sure, but it's a great set of defaults that you can utilize cross-repo. Standardization is a powerful concept.
The killer for SASS nowadays is CI. You're either using the (ancient, slow) Ruby implementation of SASS, or node-sass which requires a native binary build and causes headaches across environments. Furthermore, with Post-CSS, the feature set of SASS has been completely subsumed by the latest CSS standard. There's really no good reason to use it anymore.
You should really be using the dart-sass[0] build (just `sass` on npm). None of the headaches of native binaries or using ruby, its pure JavaScript (its a dart codebase transpiled to JS). It is very fast.
Acronyms can make sense to switch case, but initialisms... en-pee-em... I guess it happens. I originally was introduced it as Node Package Manager, but I'm gonna make an effort to correct this now.
For large apps yes; all Sass compile options are slow with embedded Sass being the least slow BUT:
Does your tooling even support embedded Sass?! Vite does not. Our version of webpack does not.. The Cenobites would LOVE Sass; never ending performance pain.
I honestly think I'd quit my job if I had to go back to any other system. Not sure what could be next for maintaining / styling, but this is the best I've ever had it.
I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file.
If you're on the fence, try it out. I think it's the future of writing CSS.