I'll try and clarify what I mean here. Tailwind seems to appeal to devs who feel they never fully grasped CSS + design.
Because it provides a copy-pastable subset of reliable classes where you end result will look good.
As a company we are often hired to fill a knowledge gap (exactly in design and front-end). The nature of agency work is to leave a deliverable for the client to work with.
My idea is that when the project is over and the design/front-end gap still exists in the team, perhaps it is better to leave something more manipulatable (I used the word malleable originally).
I think with the great docs that Tailwind has it might be easier for someone who is not a front-end dev to manipulate a `<div class="p-4">` to `<div class="p-3">` than to come across a BEM/ITCSS component, written in SCSS* where you have to understand much more concepts to manipulate it skillfully.
I agree, but none of those tweets were directed at the authors. They were just talking about Tailwind in general. One was a poor joke.
My 3 blog posts were a genuine attempt at trying to dissect what I didn't like about the framework. Many people wrote in to thank me for that perspective.
I find it unfair to single out two historical tweets neither of which is directed at the authors.
The context is that we're primarily a design company, the front-end is a way to express our designs.
A big reason for me is that I want the bigger group in our company to experiment with several CSS techniques to grow as front-end developers. If I (as a manager) set a constraint on one type of CSS it is difficult to learn more.
As an agency it makes sense to have broad capabilities. I think as a freelancer it's super fine to just constrain yourself to what you like, as you state there is huge demand out there.
We're trying to find the balance between semantic classes and utilities now with @apply. I've always found layout to be easier with utility classes (regardless of Tailwind, this counts for Bootstrap 4 too).
I like "atom"-like components better with semantic classes. In BEM/ITSS I'd make a component for -everything-. But in Tailwind we'd only make one for common "atoms" such as buttons, tags, inputs etc.
Code example: write ".t-button" and then use @apply to put the classes there. Keeping the design constrained to a set of tokens.
If that's really their intent why not do a layoff round with a bigger severance package for 10-20 ppl to get back to 30 people, it would be less painful than this PR disaster?
I think if 1/3 of your company leaves there is short-term morale loss for the ones that remain. But the loss of internal IP will be devastating. Especially if you are not big on docs and have that “just be smart and ship” approach that Basecamp has. Basecamp has a real problem hand here... they probably never expected this.
The founders went into a political discussion with someone on the other side of the political spectrum and got tired of it - then instituted a no-politics-and-society-discussion policy when the whole success of Basecamp is taking a societal , opionated view on software and what work should be.
I don't get why Tailwind is so hot. Do any of you actually maintain large custom design systems?
Where the same system is used across multiple code bases, with varying components, where you need to be able to accurately replace the look of a component, that might be coded in multiple dev environments (Angular, PHP, React...)?
If so, you would be running away from this approach fast. BEM/ITCSS all the way. How would you globally replace something that is marked up like this (example appears somewhere else in this thread)? How would you assert what this code means across projects?
With BEM/ITCSS, you would have a custom namespace like `auk`:
class="auk-btn auk-btn--primary"
And you can reason about it, maybe in project 2 it is
class="auk2-btn auk2-btn--primary"
So now you can refactor the old buttons out to replace the new buttons. Good luck with the mess above.
If people say: you can use `@apply`. Yeah. If you write your whole stylesheet in `@apply` logic, why are you using Tailwind at all?
Design tokens and the re-use of design variables is not a Tailwind thing by the way. Some people seem to be acting like it is. We've had variables in Sass for over since 2009. People have been doing clever things with variable maps (arrays) in Sass since forever. There's no way Tailwind can take credit for this.
I've written extensively about why Tailwind is problematic:
Most people use rem these days, but there are common browser bugs with using rems or ems in media query rules, so in the rules specifically it is common to still specify pixels, even if the rest of your stylesheet uses rems or ems.
Their marketing is good, they do a primo job at conveying the message in a nice looking way, but the end result is still HTML littered with hundreds classes, that gets hard to maintain and impossible to refactor.
Just like I, a front-end dev + designer am thankful for something like Firebase, because my backend skills are fairly nonexistent.