You must log in or register to comment.
I have to disagree with this paragraph. That Tailwind enforces a design system is its biggest strength. Having a small selection of colors, font sizes, and padding to choose from is what makes a website feel much more cohesive than one where developers pick arbitrary values every time they style an element.
But you don’t need Tailwind for that; design systems are easy to implement these days using CSS custom properties.
I think the author is rage baiting or doesn’t appreciate design systems. Calling this “the death of web craftsmanship” is hyperbolic nonsense. I’ve seen mangled UIs in basically every CSS stack.
I use Tailwind as part of a design system’s component library, but I’ve done the same with many other tools before. As with all libs in a UI stack, there is hype, then there is fit with you and your project. I think we could do with less hype & gripe, and more well considered neutral discussion of ergonomics and technical pros & cons.
Can confirm, I have mangled UIs in almost every CSS framework, its a talent of mine apparently ᕕ( ᐛ )ᕗ
deleted by creator
I’ve always preferred CSS preprocessing with tools like SASS over frameworks like Tailwind.
They work extremely well with JS frameworks like React since they’re both pretty much just syntactic upgrades of existing systems rather than an obfuscation of systems that abuse modularity.
That being said, CSS frameworks are still wonderful, used right they can save a lot of time during early development by outsourcing the majority of design to the framework devs.
That being said, CSS frameworks are still wonderful, used right they can save a lot of time during early development by outsourcing the majority of design to the framework devs.
That’s actually my intent with using a CSS framework. A personal project of mine reached minimum viable product
statudstatus (phones…) recently, I included bulma, and used some of its components for stuff like menus and modals. It was definitely faster than writing everything by hand early on. But I also ended up writing my own CSS anyway, especially with the grid, which is the foundation on which my app works on (it’s a grid-based colour mixing app).I agree, I think CSS frameworks have a place for prototyping and we shouldn’t rely on them as a project moves towards a proper release 🤔
Then again, some people might think the obfuscation in 20+ classes is somehow a good thing…frankly, I think it’s worse than inline styles. It’s basically obfuscated inline styles!
Then again, some people might think the obfuscation in 20+ classes is somehow a good thing…
I’d argue that CSS is itself an obfuscation (read: abstraction), and isn’t even implemented consistently across browsers. If the abstraction results in less duplication, more consistency across the website, and higher productivity, then I don’t think that’s a bad thing. (Of course, the flip side is that if using the abstraction results in the same learning curve with less transparency, then the benefits might not outweigh the cost.)
Having never used tailwind, I can’t give a personal opinion on that, but I find it hard to work on any decently sized project without SCSS. Sure I can write pure CSS, but SCSS provides so many QoL features over raw CSS that it’s hard to pass it up, and it’s easy enough to get setup.
I mentioned some of this in another comment in this thread[1], but CSS has gotten tremendously better since Sass was first introduced in the 00s. Many features we used are now native to CSS, and can be used in your browser, today. Some of them are even better than their sass variants, or at least have special abilities sass doesn’t.
calc()comes to mind, as it can mix and match units in a way a preprocessor just cant. You can docalc(100% - 10px), which is good for all sorts of stupid corner cases.And native CSS nesting is basically 1:1 with how Sass does it:
.parent { font-weight: 600; &:hover { background: purple; } .child { font-weight: 900; } @media screen and (max-width: 800px) { display: none; } }I still use Sass or Stylus[2] on virtually all of my projects, but its nice to not have to when you just need to get something out or write a userstyle or something.
Not sure how to provide an instance agnostic link, the few things I’ve seen people attempt didn’t work, but here’s the lemdro.id link ↩︎
I’m largely giving up on Stylus, its sadly unmaintained. My favorite preprocessor though; takes
.sass(indented) style to a whole new level on what you can omit ↩︎
Wait CSS supports nesting? Since when?
Also, SASS’s mixins, variables (CSS has variables too but they work differently), and many of the other features are hard to beat, which is why I feel like it’s almost never a negative to get it up and running on any project I work on (unless the project is a tiny one-off, then it’s probably not worth it). One thing I like is that it’s close to CSS - increasing the transparency - while still providing abstractions that let you save time and increase consistency across the project.
Landed earlier this year :D
I used to really use mixins a ton, but these days I haven’t really written any in a good long time. Still useful, still something plain-ol-css can’t do, but I’ve found autoprefixer has managed to handle most of my mixin needs.
Tailwind is just shorthand inline CSS.
I mean, for me, the greatest pro I’ve heard for the usage of Tailwind is that it makes collaboration much easier. For example, a PR to add styling to a component is easy to read - you just see the new classes added. Not only that but you know that it only affects that element and that no CSS is still being kept in your CSS files that is no longer being used.
The cascade is seen by some as one of the most annoying parts of CSS at times because it can make debugging harder - and many will simply abuse
!importantas a result.I’d argue that styled components, like Vue SFCs or Surface-ui, are even better in this regard. You can see the whole component there, and all the classes along for the ride. And they’re usually written in something fairly close to “real” CSS
But I mean, if they’re gonna be component specific CSS, why even bother over just using tailwind?
Well, you get all the real advantages of real CSS. The browser tools work. Various other preprocessors work. You can use timesavers like Sass or Less or whatever else.
The biggest advantage, imo, of using a component based design, where components handle not only the styling but the entire appearance of a “thing”, is that you make the contracts for what that thing has to support explicit. If your button needs to be able to change colors, you can add a prop that exposes that ability. If it needs to change sizes, again, that can be exposed by a prop. But they aren’t by default.
You can sort of accomplish this in “real” css using attributes carefully, but its not as elegant.
Very good article imo. I didn’t disagree with anything. I especially agree with the ugliness of the many class names in my html.
My problem I guess is reconciling how much of a pleasure it’s been to use. Perhaps I, a primarily backend developer historically, embody the death of web craftsmanship, but I don’t really want to learn modern CSS if I don’t have to 😅
The easier I can get something styled and back to doing actual business logic rather than making things pretty the happier I am. I highly respect frontend styling gurus but I’m not that interested in spending time mastering true web craftsmanship, I care more about delivering the product as fast and as beautifully to the user as possible.
I’d encourage you to take a look at modern CSS with a fresh eye. It’s gotten really good. Good enough I’ve got another blog post in the works talking about how much goddamned fun its gotten. In the last few years alone, we’ve got sass-style nesting, parent selectors (!), combinator selectors (roughly like list comprehensions in their ability to fill out a matrix of potential selectables), color functions, and far more.
wholeheartedly agree! css has been my main job for going on 15 years because i’ve always enjoyed its quirks. the past 5 years or so have felt like leaps and bounds in terms of how i structure markup and styling. it’s such a fun language to learn. stuff like flex and grid make my work so much easier so i can spend more time on the fun stuff.
But can you vertically and horizontally align something that isn’t text reliably by now?
yes! flexbox is great for this.
(and grid, which is very very similar to flexbox and uses much of the same rules)
Thank you for this response. Indeed I will. And feel excited to do so :) Look forward to that blog post as well.
i think about this article a lot whenever i hear about tailwind.
https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css
… I’m very much not sure how I feel about that article. And I don’t mean that in a negative way, it’s just very… huh.
Interesting perspective. I’ve added it to the appendix at the bottom of the article
Tailwind only really makes sense in a precise use case that absolutely does not cover everything web based and I wish the makers where clearer about it.
First off, the abstraction problem: since you give up on defining custom classes at length, elements will often receive more than a dozen utility classes. This is fine IF you use a component based framework like Vue and you break down your app into components with a small granularity.
Second, the stylesheet problem: even minified and compressed, a stylesheet containing all of Tailwind’s utility classes is multiple Megabytes. The issue will not come from where you’d expect; downloading may take a while on the first page load, but all page loads will suffer from taking into account such a massive set of rules. Tree shaking makes this fine IF your content is already known at the moment of building the app.
In the end I feel that Tailwind implements ideas on top of tech it is incompatible with and the abstractions it create are seriously leaking.
Ok so use modern frameworks and tools that implement the tailwind plugin. Because if you are shipping the entire tailwind css that’s a developer problem not tailwinds. News flash: using a technology wrong doesn’t make the tech wrong.
News flash: your snark makes you an unpleasant person. Read my comment again. I said tree shaking fixes this… unless you don’t know what content you’ll display and what classes you’ll need at build time. Not all sites are static.
Unless you are going to be allowing custom html to be added the tooling is smart enough to figure out what possible classes your code can use. You’d have to do something dumb to not have the tools able to tell what components you are serving.
More generally, the more you have a flexible editor in the app, the worst it gets. This is the use case where I ran into trouble.
Make an element that is hidden that has all possible values of classes you can use. Or use normal css for that one part of your app if that isn’t possible. Lots of ways you can handle this without thinking the framework doesn’t work.
Ninja:
https://tailwindcss.com/docs/content-configuration#safelisting-classes
Tailwind actually has this use case covered already. Use the safe list functionality to always include the classes you need.
The “News Flash” bit was unnecessary. Please keep your replies to other users respectful on Beehaw.
Thanks!
— !programming@beehaw.org Moderation Team
I don’t believe anyone who uses tailwind is shipping the whole thing with all of those megabytes of classes in production. It’s actually sort of hard to even do that on accident if you’re following a tutorial or their official docs.
So glad people are catching on to this. Until like a month ago if you said anything bad about Tailwind you would literally get shadowbanned on HN.
I am not sure how other people do it but we use tailwind in SASS using the apply directive, inside a BEM-first structure. I feel like this is the best of what everything can offer.
You might consider dropping tailwind entirely then, and using something like open-props, which gives you basically all the features of apply, but in a native CSS package
deleted by creator
