And let me repeat what every Tailwind fanboy (like me) states every time this project is on HN: don't knock it till you've tried it. Look at the animated example in the front page. You'll never be able to iterate that quickly with CSS.
It's true that I haven't tried it. And I probably wouldn't, at least until someone can formulate at least a hypothetical advantage.
Not the blog post, the main landing page, ie https://tailwindcss.com/
However, there's definitely a very prominent youtube video on the linked page. https://tailwindcss.com/blog/tailwindcss-v3 That's the one I was talking about.
Maybe this shows my age, but it kinda looks like an extension of <b></b> <i></i> - you know, that stuff that we moved away from a long time ago...
Isn't this losing the point of CSS - that our "content is separate from its styling"?
I know I know, we often have to adapt our HTML to allow the styling to work properly, but this is only really true for layouts, not for colors / padding / margin / fonts etc.
I understand that we now have people writing React apps and componentising everything, but if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change next time a designer decides to give your webapp a makeover?
If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effects or abandon reuse and make another-brilliant-semantic-class.
The likely choice is the latter and so applications become masses of ad-hoc, partially finished, inherently flawed styling abstractions scattered hither and yon among directories full of redundant styling artifacts, half of it long dead. How is that a benefit to some future re-designer?
> next time a designer decides to give your webapp a makeover?
I figure the odds of one approach vs the other being the greatest benefit to some future re-designer are about even, and my guess is as good as yours.
You don't refer to bananas as "the curved sweet yellow food that grows on trees", you simply refer to a banana as a banana.
Sure, for one off items it might not make sense to name it but when you create design patterns then it's incredibly useful to be able to name things.
Yes it may be hard and require you to think, but just because that is so does not make it bad necessarily.
You have (some variety of) cavendish bananas in mind. There are red, pink and blue bananas. They're not all sweet. The plants they grow in are not always "trees" but rather large fern like plants.
And then that day arrives when you are required to style some variant of 'banana' you are forced to decide: do I break the world by messing with banana or do I make new-banana?
In CSS land however you wouldn't break the world for a different banana, you'd simply add another class for the variant and style appropriately.
.banana { // generic banana styles }
.banana.musa-velutina { color: pink; }
Of course not all decisions are going to be as straightforward, but I do think that there's a lot of value in keeping a website's items consistent.
The work upfront to name things and build out concepts will pay its dividends as you extend a site or build out new ones.
Of course, there’s no right or wrong answer here, and I suspect it very much depends on what type of web systems you are building. I feel the entire debate is basically a special case of the question “do you make websites or web apps”.
If you plan on using bananas multiple times throughout your app, aren't you going to be pulling that out into a component anyway? So define that it's curved and sweet and yellow in that one place, and then insert an instance of it wherever necessary.
So far with this plugin/extension design i've not found a way to use Tailwind and also retain nicely sized CSS.
This 3.0 release has its biggest feature be JIT. If you read the linked blog post, CSS is no longer purged but generated dynamically by reading your source files and generating the TW classes you use. It's not tree shooken anymore
Whether or not you're using Javascript doesn't matter (I guess unless you use the new CDN script which I haven't tried), but it does need to be run in a build system.
Will be interesting!
The creator of Tailwind posted a comment in this thread that the Tailwind website itself, which uses way more Tailwind classes than a normal size would use (for demoing everything), only spits out 36.9kB of CSS.
- One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes.
- Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive.
- Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways.
- You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development.
- Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while).
- There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[1] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows.
The main theme to be aware of: proponents of atomic CSS rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[2] vs hyperlocal development workflows interact with your organization's design culture.
[0] https://en.wikipedia.org/wiki/APL_(programming_language)
[1] https://www.styletron.org/
[2] https://en.wikipedia.org/wiki/Aspect-oriented_programming
Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms.
You will not iterate faster than what I am suggesting.
Edit:
The reason why we are here, why something like Tailwind and MUI exist, is mostly because we need an abstraction layer to do what a designer does on a whim. You can flick a shadow on and off on a Photoshop layer and mess with the subtlety of a drop shadow with a slider. If a designer makes a fickle change, the developer needs this abstraction to make the fickle change as fickle as the thought that made it. That’s why you have all these quick utility methods. The designer is one layer (no pun intended) removed.
In 2021 (2022 really), it’s shocking the amount of latitude we give designers to still not be able to do CSS. A half competent designer could have a modest style sheet that mostly captures their design instincts, yet here we are, unable to capture their whims and must now have an albatross utility library to have manual laborers capture the translation - all because … they still won’t learn basic shit.
And for what ultimately? These aren’t baroque art pieces, it is ultimately boxes with an aesthetic applied, all very describable with semantic HTML and CSS. But alas, our brilliant artists can’t be bothered. Here, send me your masterpiece so I can transform it for you.
Take the bootcamp on web dev. You are literally the people I want going there. Not the Classics major that needs money because they picked a stupid major. It’s you guys that need it, and deserve it.
This is why all but the very best flat designs (which does not always correlate positively with the size or reputation of the firm turning them out—looking at you, Google) look to me like something I'd have turned out for a quick feature demo circa '05, with everyone at the table agreeing that, however nice the feature, a designer definitely needed to take a pass at it before it was released.
Let designers focus on designing, developers on developing.
The words of an open mind.
Each of those adjectives are very open to disagreement.
Does nobody remember themeing forums software like vbulletin? Designers weren't allowed to touch the markup in the slightest and yet so many amazing themes were made. Why? Styling wasn't hard-coded in the markup. Hell, remember the insanely customized old.reddit subreddits?
FYI I'm a recent Tailwind convert so I agree that Tailwind is good, but your comment is like saying Tesla cars are great because they aren't horses.
I won't argue if one is better than the other.