21–30 of 44 posts
So the takeaway for me here is to avoid dogma, and if your “senior” coworkers are forcing it on you, leave asap. Oh and if you want to be productive, use Tailwind first and hand craft the small percent of CSS where that’s required later, if such a thing actually occurs. Everything else is just religion (in the emacs vs vim sense).
> use Tailwind first and hand craft the small percent of CSS where that’s required later What is the difference between Tailwind and in-line CSS?
As I commented on Mastodon: Today's "Tailwind-in-HTML" is tomorrow's tech debt on a scale we haven't seen since the AngularJS days from a decade ago. It won't be pretty. (But perhaps a future job opportunity for folks who can rebuild design systems using real CSS and web standards.)
But I might just be naive.
I've been working in CSS for over 20 years. I know it very well. Tailwind is also my absolute most favorite technology to come along in a long time. I would even argue to use it effectively you also need to understand CSS well. The smart steering analogy doesn't jive with me at all.
IMO, Tailwind is a coping strategy for people who have accepted that CSS is bad technology. The Cascade seemed like a good idea at the time, and made for some cool demos back in the "CSS Zen Garden" days, but in practice it is miserable to work with; it's even less suitable now that most websites are assembled from self-contained components. But it's what we have, and at least Tailwind makes it fast to build and modify things.
So the takeaway for me here is to avoid dogma, and if your “senior” coworkers are forcing it on you, leave asap. Oh and if you want to be productive, use Tailwind first and hand craft the small percent of CSS where that’s required later, if such a thing actually occurs. Everything else is just religion (in the emacs vs vim sense).
> use Tailwind first and hand craft the small percent of CSS where that’s required later What is the difference between Tailwind and in-line CSS?
> Often the biggest challenge when working with a framework is figuring out what you’re supposed to do when there’s something you need that the framework doesn’t handle for you.
[1] https://tailwindcss.com/docs/adding-custom-styles#using-css-...
There are two problems with tailwind; 1) https://twitter.com/dillonchanis/status/1706473840367247482/... and B) the tailwind fan boys.
Every project of any decent size needs utility classes. No reason not to use tailwind for those. But every time I head that naming things is hard, I can't take that person seriously. You're not naming a baby. and if you change your mind on .pricing__card__header, just use your editors refactoring tools to rename it.
So the takeaway for me here is to avoid dogma, and if your “senior” coworkers are forcing it on you, leave asap. Oh and if you want to be productive, use Tailwind first and hand craft the small percent of CSS where that’s required later, if such a thing actually occurs. Everything else is just religion (in the emacs vs vim sense).
> use Tailwind first and hand craft the small percent of CSS where that’s required later What is the difference between Tailwind and in-line CSS?
I think the argument about Tailwind is overblown because half the people using it should just be using a component library. Component libraries suck when you need to massage a design system into them. But at least half the arguments over Tailwind vs CSS are devs mostly doing their own thing and touting how easy it is to change X Y and Z. Similarly those same devs hate component libraries because you can't just change…
Sure. You can punch tailwind until it behaves like the formatting templates people used on PHP before CSS generalized them. This will indeed fix the problem.
The only thing I got to say is "blegh". You are adding code to get the "90's-dynamic" behavior into a framework that added code to remove the cascading behavior from the framework that came with code to emulate the "90's-dynamic" behavior with a few extra bonuses.
But yeah, it works. I have no idea why one would choose to go that way, but if one is constrained into it, that's a sound direction.
As I commented on Mastodon: Today's "Tailwind-in-HTML" is tomorrow's tech debt on a scale we haven't seen since the AngularJS days from a decade ago. It won't be pretty. (But perhaps a future job opportunity for folks who can rebuild design systems using real CSS and web standards.)
The classes are in the HTML-document regardless of Tailwind. I should think it would be possible to create a tool that removes them from the HTML and generates whatever they did in a separate CSS-file, if you wanted to move on from Tailwind. Not pretty, but wouldn't be that bad, honestly. But I might just be naive.
I'm glad the writer has actually tried Tailwind and I respect it's not really their thing, but I've got to hard disagree with the Builder vs Crafter/specialist look on it. Tailwind will only just barely save you from not knowing CSS, it's still fundamental to understand it. Also I would consider myself very well versed in CSS, but while my handcrafted css works, it cannot compare in maintainability to its tailwind eq…
I think it happens eventually with most of code, whatever language. If you don't have a clear structure or methodology at the time of writing it, it will become a mess at some point. I don't think it's a particular problem of CSS.
So that unveils me as a "crafter" - well, am a graphic designer doing CSS since 2006 or so; in fact I've thought that way about doing 'raw' CSS, that is the most "artisanal" thing one can do in the world of web dev - and whereas it is true Tailwind can save time in styling a web page or whatever, it takes away from the expresiveness of doing it "by hand". Many people even here wonder from time to time why contemporary websites pretty much look the same: many people are using frameworks to style them.
It's kind of something like doing your own furniture in a pretty artisanal way vs. getting something from Ikea. Or more like growing your own potatoes vs. buying processed potatoes at a mall. You'll end with potatoes in your stomach, but they will taste differently.