Vanilla JavaScript support for Tailwind Plus

I've worked in many different FE codebases with a variety of CSS "strategies".

This sort of thing is objectively ugly and takes a minute to learn. The advantages of this approach I found is two-fold

1. You can be more confident that the changes you are making apply to only the elements you are interested in changing

You are modifying an element directly. Contrast with modifying some class that could be on any number of elements

2. You can change things around quite quickly

Once you're well familiar with your toolset, you know what to reach for to quickly reach a desired end state

Agree, and to add…the “component” still needs to exist somewhere in the system for tailwind to make sense.

No one is writing a long paragraph of styles for _every_ button in their app.

This is one of the least elegant ways to scope CSS though.. you may as well just write inline CSS

I like BEM personally. "navbar__item" scopes the styling to the nav item

> Once you're well familiar with your toolset, you know what to reach for to quickly reach a desired end state

This also applies to plain CSS, doesn't it?

The big value add that Tailwind brought isn't their utility classes IMO - it's their philosophy around having a design system of consistent coloring and spacing. I actually borrowed that for my own projects. It taught me to be a lot more diligent about specifying the system upfront. Put it in CSS variables and re-use those

> No one is writing a long paragraph of styles for _every_ button in their app.

Very much not true. LLMs love doing this!

1. Aren't there good tools that can list all the elements a style would be applied to so that you can pick and change only the ones affecting the element you need?

Yes, many most definitely do just that.

You can’t use inline css it’s not at all the same.

Inline css

1. Can’t use media queries (responsive design).

2. Gets you to specificity hell - you loose ability to cascade.

3. Does not follow any system or reuse of values.

4. Values can’t be centrally changed. Utility clases are still classes - when you change class value it changes everywhere where the class is used.

5. Its verbose. Utility classes can have multiple css rules.

Conceptually it might seem that inline css is similar but thats just feeling. Functional css (utility classes) are about composing classes with simpler (one purpose) behaviour together to create complex behaviour.

> Values can’t be centrally changed.

Or you end up redefining dozens of CSS variables inline :)

Why not just use the style attribute?

verbosity. Using style, "p-4" becomes padding: calc(var(--spacing)*4);

When people complain about CSS being hard I'm not sure what parts of it really? It's rarely explained further too.

As someone that did a lot of CSS like 15 years ago when fullstack was the norm, then just sporadically for various non-public tooling, is that yes, the old ways of trying to position things really sucked and had a lot of hacks and some of those trail-n-error "how-does-this-change-the-elements-position" seems to still apply, but are much rarer now with grids/flex etc. But the structure of CSS itself is very straight-forward to me and has almost always been?

Is what's really going on that when people are trying to use vanilla CSS they go overboard with keeping CSS DRY? Which ofc ends up with an interdependent mess that's becomes increasingly harder to change. Just stop that? Start namespacing and copy pasting? CSS doesn't need to be compact.

The hard part isn't just placing the correct styles, that is trivially learnable, it comes in when you have multiple people touching the same code, or even in small teams with a large enough project. In a large enough project, and IME that "large enough" point gets hit very quickly, things become messy and it becomes difficult to figure out why something is rendering in the way it is.

Every non-tailwind project I've ever worked on inevitably devolved into a mess where you have 50 billion CSS files scattered all over the place, many containing classes that contradict and override other existing classes, often in completely unclear ways as it's hard to know in which order things will get compiled ultimately. As time passes, you'll see BEM done in various ways, you'll see cursed SCSS functions that generate styles dynamicslly, you'll see a bunch of !importants, and eventually you end up in a state where making a change to a legacy page becomes an exercise in dodging specificity and ordering minefields.

Meanwhile with Tailwind, everything is localized to the element it's affecting, and very importantly the entire team has a "standard library" of properties and patterns they can pull from, so you don't end up with people in different teams naming similar UI patterns differently, and you straight up never have to think of specificity ever again (which in my view is a boon, despite what CSS purists might say). Yes, the HTML is more verbose, but this is just such a non-issue after the first 5 minutes of discomfort, plus all the other benefits.

Hot take, but the Cascading part of CSS has proven itself to be a massive drawback, and not a benefit. Tailwind obviates that completely.

This sounds like it agrees with my point of going overboard with DRY? But this is true for pretty much all languages. When people go overboard with abstractions it usually ends up bad over time and changes, as in your example as well, starts becoming a dredge. But this is solved by experience and better practices, not throwing out the baby with the bath water. Tailwind seems strangely defeatist to me - going from one extreme to another.