4 ms·
I've found Tailwind to be great for getting a project going quickly. It's pleasant to use when you get started, but it can become a pain later on when you have
by jbaczuk 4y ago
I've found Tailwind to be great for getting a project going quickly. It's pleasant to use when you get started, but it can become a pain later on when you have a lot of styles to maintain. I've been using it everyday at work for a year and a half, and wished I would have known a few things before I started using it. Here are a few:
1 - It encourages styling on the fly. Because it is faster initially, you don't have to constantly switch between a CSS file and your markup, it feels good to style it as you go, and gives you an initial productivity boost. But it can cost you in technical debt later, so be careful.
2 - It makes your markup really messy. You end up repeating the same utility classes over and over. Then you can forget which utility class you used for things that should be defined globally like spacing or colors, and have components with different styles and not one place where you can change it.
3 - It makes debugging styles in the browser difficult (you change the style of one class, it affects everything, not just the tag/component you are working on. Having component-based classes allows you to debug styling on individual components much easier. I find myself debugging by actually adding the utility classes to the markup.
4 - You have to memorize another name for every many css properties (e.g. line-height => leading), or just be constantly in the docs. VSCode extensions are helpful, but it does not always detect that you are trying to type a Tailwind class, esp. if it's dynamically generated classnames. It can also make VSCode run slower.
5 - Some CSS properties are missing values as options, so you have to customize it out of the gate (e.g. min-height) or use the custom m-h-[value] syntax, but why not make all of tailwind like this?
6 - Trying to sync Tailwind configurations between projects (e.g. between a component library and an application) can become tedious.
Like anything, I think good styling is probably a combination of global styles, utility classes, and component classes. Something like Tailwind + Bootstrap + SASS on top of your own custom classes might make for a good tool, IMO.
- jozzy-james 4y ago1. Being able to run a dev build (with no PurgeCSS) and use the .cls area of dev tools to quickly throw together TW classes to get stuff sorted, then carry over to the final resting place is wonderful. Compared to manually typing each property and value on the element and then copypasta'ing from there. 2. If you need to use the same group of utility classes over and over, extract to a class - either with @apply (if you want to keep the flexibility of config updates) or vanilla. 3. I'm not sure I'm following here - if you're changing the value of a tailwind class, you should do that via the config 4. I've found the naming differences easy enough to follow - line-height vs leading makes sense if you come from a design background. I think the biggest gotcha I had early on was everything is mobile first by default - so sm:* is actually _larger_ than the default. 5. the JIT is a wonderful addition, but does come with overhead currently - so that's why it (i assume) isn't just the default way of doing things. 6. not a problem i've run across, but why would a component config supersede an app config? to your last point, we use tailwind in conjunction with a fair amount of legacy sass to do what we need (many small nuances, spread across 4 different sites, that are otherwise the same) - I would urge against mixing tailwind and SASS if only for the build speed, PostCSS should be able to do everything you need there and it'll just make the builds a bit faster. tho I feel like what myself and my team works on is a far cry from your standard HN web app - so my experiences are probably very different.