Vanilla JavaScript support for Tailwind Plus

Tailwind goes into crazy extreme so people can copy paste whole complex components and they work. That’s why you can dunk on these verbose examples.

This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”. Similarly you will create button/input classes that have you basic styles.

Generally you start with just simple utility classes inside html and go from there and where it make sense or its too complex you separate to more complex class. You end up with short css file that only has these special components and none of the basic stuff.

For most elemets it ends up like “flex justify-center gap-4”. In BEM i have to invent “nav-secondary__header” put it in correct place and hate myself when i need to change it to “flex justify-beween”.

Tailwind popularised functional css but is also aimed at masses/noobs. Somehow some of those concepts also resonated with some experienced users.

> will have class “font-heading-2”

At that point, why not write these in CSS instead? There is little advantage in using the tailwind shorthand classes in your own class definitions.

- You can use plain CSS variables for theming

- You're bringing back the supposed downsides of cascading and shared classes

- simple Gzip compression will achieve similar size reduction as the utility classes

Working on your codebase now requires full knowledge of the Tailwind utilities, layers, directives, pseudo-classes, theming, and all the complexity that comes along with them.

You’re right - if you only used it for ‘font-heading-2’, you wouldn’t need it.

But like the person you’re responding to said, the ergonomics improve for the majority of cases that are just ‘flex items-center gap-2’.

And yes, you could write it all yourself but Tailwind is a good set of defaults for those classes and minimizes bike-shedding and improves consistency. These are useful things in lots of teams.

I don’t really use Tailwind on smaller personal projects because I love CSS, but in an org of mixed skill levels, it’s pretty damn useful.

(Also, Tailwind uses CSS variables. It had solid support for them in the last major and first class support for it in the current one.)

I was unclear. Yes of course you write these classes “font-heading-2” in CSS. Tailwind is essentialy big list of premade classes to dynamically pull from. I think the functional approach/structure is the interesting part why people like Tailwind. On very small projects i even make “Tailwind by hand” creating those utilites as i go.

> There is little advantage in using the tailwind shorthand classes in your own class definitions.

There are few massive advantages. I dont have to figure out how to name these classes. Other people in the team know them too. And when they see class they dont know they know its something custom probably for a reason.

> You're bringing back the supposed downsides of cascading and shared classes

I never said cascade is bad. Creating new flat class with 0-1-0 specificity doesn’t break Tailwind. I’ve been through enough of - everything has specific class that’s nested/scoped… from my experience and usecase it’s harder for little benefit except neater html.

> simple Gzip compression will achieve similar size reduction as the utility classes

I meant custom css that you write by hand and have to scroll trough. Not the result pushed to browser. With functional css you manage to do most of the work in html and what doesn’t make sense you can do traditionaly. For example i dont like doing complex hover interactions in Tailwind so the html has all the layout utilities but also custom class that only has this custom interaction behaviour.

> Working on your codebase now requires full knowledge of the Tailwind utilities, layers, directives, pseudo-classes, theming, and all the complexity that comes along with them.

Is knowing Tailwind naming conventions worse than not having any convention at all? My experience is that Tailwind are just classes that are documented. Without it we would have classes that are undocumented.

There are cases where functional css is not that beneficial. Like in long running products which have single file component workflow where css is scoped and html/css live in same file. But in work i do in small team we just found it to solve many our painpoints.

As an older dev, I think it's a great natural evolution.

We had css, then SASS/LESS/etc, now Tailwind.

In the days of just CSS people would create variables/functions for their CSS in their server side language & have the server side language create the CSS. SASS/LESS allowed us to do that in stylesheets.

Now we have Tailwind (and of course CSS variables). Tailwind (and the code editor plugin devs) have done an amazing job at making a great workflow to handle CSS, especially in component type UI designs.

* Shout out to Foundation and Bootstrap for also helping us get to where we are today. Foundation is underrated in the history.