And it's not even about what the developers want to do, often it's about what the clients want to hear. I believe in "boring tech" and I'm a late adopter as well, but many clients think of old, dated, outdated, deprecated, unperformant when they hear about a take like this. Often we need to do React just because that's what many clients think the modern UI does. And, in a way, there is a grain of truth to it: since it's also cool with many developers, it's easier to find developers on the market for it, should the project need new people.

With that said, your premise is correct. Prevention is uncool, and safety seems overbearing, preparation is met with "YAGNI". Until people need it.

Hmm, I’ve always considered tailwind like the spice to make css actually usable, kinda like elixir is to erlang, typescript is to javascript or C is to machine code. Its still CSS just the stuff that you _actually_ want to build is pre-packaged and thought out for the use case.

And I’m not dissing on CSS - just those tools try to solve different problems.

CSS is the ground truth, and it kinda has to support all the weird edge cases and uses that tailwind doesn’t.

Tailwind is like usability overhaul of css, but still allows you to “drop down to css” everywhere you want to.

It can compose like css, but it also constraints you to what you can do. It also gives you tools to group, adjust, refine styles, but in a usable way.

It’s a transpiled language on top of css, but more ambiguous than sass or less.

Given enough time most projects I work with slowly gravitate towards small composable utility classes anyway, tailwind is just logical evolution of that.

And since design peojects usually gravitate towards design systems in the long run, tailwind is really good at facilitating that.

What makes tailwind feel wrong for me is that you put the css classes everywhere exactly like you would set inline style attribute. I would prefer using the css slectors and select by an id or class name and apply a css like that. I avoid frontend but this is how I see it used in my team.

Would be nicer if you could do it like selector > color-xyz text0xyz paddifng-xyz and never add those classes inline

Oh yeah it does feel weird “dirty” somewhat.

But to your suggestion - you can! Thats what components classes do in essence. When you have a bunch of styles that _always_ go together - you bunch em up.

But in practice it is usually simpler to keep the classes and use other templating features of your platform to achieve this.

It becomes extremely nice as every time you need the question “why is my html look like this” answered, there is no hierarchy of other files to dig through - its all just there.

And as with any tool you can abuse it in ways that are not intended - seen plenty of ugly tailwind examples with tons of weird unruly code. But thats even more true for css itself. Omg the horrors I’ve seen with custom raw css cans still give me nightmares.

I know there are many tutorials doing that, but that is not how I use Tailwind. Tailwind entirely supports your own CSS files and you can use @apply to compose all of the existing classes together.

Thanks for the tips

Just because something is old doesn’t mean it’s correct, this is such a curmudgeon take. Things we have have evolved over a long time, have been started hastily (JavaScript) and there’s no reason to believe we’re not in a local minimum and something much better is out there.

I personally believe the js model is completely wrong for the browser and something like an actor model would fit much better.

I’m not saying we should jump on every hype train, and personally really dislike the react ecosystem but I also think we should encourage exploring new approaches. CSS, html and js evolution is driven by the exploration of these new frameworks and they’re very different than what they were just a few years ago

I agree, it's exciting to have the industry trying gazillion things and see the survivors that get pushed into standards. It's much less exciting to have your project tied to frameworks (generic statement, not about Tailwind) that rot, requires massive rewrites on update, are unstable and forces you into non-standard stuff that tends to not interoperate well with the external world.

I'm puzzled to see the popularity of such frameworks while boring technologies often are well documented, well tested, highly stable, provide acceptable dev efficiency, readable by any dev, and often comes with much better performance.

I'm probably just a grumpy old man yelling at clouds.

I feel we need a club for grumpy old men that yell at clouds! I'm only 34 but after 10 years doing this I now fully understand what my seniors were trying to teach me when I started.

Boring technologies that work and will continue to work with the minimum of lock-in and fuss long into the future are what get me excited now.

I’m a bit older but I’m getting progressively more annoyed by this attitude of my peers, and increasingly think it’s an excuse not to learn new things.

I know plenty people that are stuck in Python and are some middle mangers and just yell bah! at everything new.

I’ve worked through the whole stack, am now heavily in elixir, work in a cutting edge LLM company and feel I’m better than I ever was. There’s a balance.

Agreed, balance is needed in every aspect of life. The conservatism of many experienced developers is likely an over-correction and the result of some scar tissue. There's always room for growth and trying new things, but with those lessons learnt in the back of your mind still.

I've shifted career and work as a photographer now, so remain ultra-conservative in my technology choices because I know I don't want to expend the time and mental energy to adopt over-complex solutions. It's less about how old/new they are, and more using the right tool for the job.

PS: Glad to see Elixir cropping up more and more. I loved using it before I changed careers, and still keep tabs on it. I've got an idea for a small API/service that might benefit my work, and unless I stumble upon a more appropriate choice, it'll likely be based on Phoenix.

In my job I have to learn about new Frameworks, shiny new way to do things and how they break existing workflows and architectures.

I like learning new things but the industry shouldn't follow latest trends for any project. https://boringtechnology.club/

it's kind of a trope now in social media for people to look contrarian against current web tech. There are whole twitter influencers out there that are not known for any achievements but just pooh poohing popular frameworks. Just an easy way of grabbing some status, I guess. And platforms love the engagement it brings.

I can see a top tier game engine developer talking with skepticism about current web tech, but it's more often coming from something like enterprise java devs from the 2000s that used to take months fudging with class hierarchies to deliver a basic form GUI. The kind that must take any opportunity to denounce electron apps but would never give up VS Code and go back to Eclipse.

Evolution is very hard to beat.

CSS is not static. It has been getting better and better all the time and keeps improving.

Yes because SCSS and various other new technologies have tried stuff out and we took the best back to CSS. No reason to think tailwind won’t influence css. For me it’s an improvement upon the style attribute which we have been neglecting and have been told not to use for some reason. I think it’s great to be able to adapt a component locally without putting a one off class somewhere which we have been doing before.

there's evolution and there's insanity.

it only took ~20 years to get a working vertical align (which was available in HTML from basically day 1, might I add). similar for grid to be available and it still kinda sucks.

The multi billion dollar vitamin industry disagrees. Kidding. Only half. I dislike this saying because it doesn't mean anything and just makes some VCs think they're saying something that sounds smart.

There are frameworks that genuinenly improve the development experience for certain uses cases. As with many things, it's important to still now the basics (in this case, CSS), but why not use Tailwind if the philosophy aligns with yours and makes you more productive?

Sure, switching frameworks ever few months to try the hottest shit out there is also not great, and many people overuse frameworks (e.g., React is an overkill for many (most?) applications I have seen). But that doesn't mean there isn't merit in frameworks.

It really depends, for most simple landing pages painkillers are just fine, I've also created extensive dashboards that were used 4-6 years without much iterations, then it's a waste to think too much about css structure. And clients are happy if it looks a bit sexy.

For a long-term project that will require lots of development a more thorough approach would be justified.

I was going reply at the top-level because my opinion is vastly different to the majority of comments so far, until I found yours. Years ago I very much enjoyed finding painkillers to make my work easier. I now only take vitamins.

I'm very much in agreement with the author (regarding Tailwind, I'm Web Component-curious but yet to be convinced to the degree is obviously is...). I started with Adam Morse's "Tachyons" library which is the pre-cursor to Tailwind. Conceptually that worked for me, particularly because I was all-in on the JS ecosystem, building a startup with React and Meteor (story for another time). I wrote up my thoughts on a now-extinct blog [1].

Over time though I found JS to be a fragile and brittle ecosystem to work in; I'm sure as many others have. I not only moved away from SPAs and JS as my backend language of choice to avoid npm dependency hell, but also any JS build tools because using the latter is functionally equivalent to the former.

When my choice of language/framework at the time (Elixir & Phoenix) added support for Tailwind by default, without a JS build tool (handled by an Elixir lib) I was conflicted. I had gotten used to vanilla CSS again with all the new additions such as custom properties and wasn't convinced I needed Tailwind. Even though it didn't bring the JS build chain I hated, it still represented a hard dependency to replace down the line if required, and still required a build tool. It was potentially a decision future me would regret. These days I'm all about not snookering future-me.

I think Tailwind has it's place where you're already using a build tool that can support it (JS or otherwise) and you're working in a team that needs a design system straight out of the box. It gets you up and running quickly (particularly with their TailwindUI components and themes) and provides a point of reference for everyone working on the project without coming up with a design/token system of your own. But that can be said of the older frameworks like Bootstrap or Zurb Foundation (remember that?!).

Personally I'm very happy writing HTML, CSS & JS without any build tools, bar a bit of templating to bring in partials here and there. Admittedly I'm working on very different websites now, but I spend years thinking that the foundations of the web needed augmenting and abstracting away (they probably did at that point...), but now I'm quite happy to work with it in it's natural state.

[1]: https://github.com/jamiedumont/personal_zola/blob/main/conte...

In your analogy, wouldn't tailwind be more of a multivitamin, in that it contains a bunch CSS classes (vitamins) conveniently packaged and ready to go?

I haven't used tw yet, but I intend to because I was blown away by how much sense the authors' book Refactoring UI made.

Taking multivitamins is usually the wrong approach. So they are indeed a kind of snake oil.

Which condition do you intend to treat by taking multivitamins?

Have you looked at randomized controlled studies and found that they support your idea that taking MVs has a positive effect on that condition?

Have you got your bloodwork done? Did the doctor then suggest that based on your situation MVs are the right approach? I never have heard of such a thing happening.

So yeah, TW and MVs are similar. Both appeal to people who think "Hey, why do the work and figure things out and act appropriately? I can just swallow this magic pill!".

Tailwind provides many classes to use right out of the box, whereas vanilla CSS requires classes to be written, which takes longer.

If someone's good at, fast at, and enjoys writing vanilla css, it might be the way to go, but if they don't have a sense of design or lack skill in writing CSS, a framework allows pages to look professional quickly.

A site made with a css framework may not be as extensible as one made with vanilla css, but if there's strong enough desire it could always be taken out and swapped for vanilla CSS.

For quickly getting things done on projects where time/resources are , I'd go for a frame work (for the reasons above: I lack a sense of design and would spend an eternity tinkering and doubting my design choices).

This was my experience as well. I talked to three different doctors in two different states and they were all lukewarm at best about multivitamins when I mentioned them. "It won't hurt anything" was about the best I got from one of them.

> Taking multivitamins is usually the wrong approach. So they are indeed a kind of snake oil.

Not true at all. It ensures people get needed nutrients when they have shitty diets. It's not snakeoil at all.

CSS classes in this case are microplastics, not vitamins.

That would make Tailwind a cocktail of micro-plastics, as utility classes are just regular css classes.

As a developer from ancient times.. yes!

The vitamins vs painkillers analogy is about productivity-boosters vs problem-solvers. Using plain html/css/js is neither of those. You could say Tailwind fits both of them.