emmacharp

mt-100 vs. margin-top: var(--100);

And the IDE will help you autocomplete it all. The same is true for all the other properties you enumerated. If it's a Tailwind design token, it can be a pure CSS design token. No "whack-a-mole" needed here.

Still, you're right about having documentation. And there has been a loooot of these kinds of doc (BEM, SMACSS, ITCSS, etc.) in the last 15 years. Nonetheless, a more modern-oriented one is indeed needed. And that's why I'm working on something like this.

As for the "15 seconds", I mean, really? If so, I beg to disagree. There is a lot to take in. And that is why numerous colleagues still have to open the Tailwind docs to know how to write a class that's not 1:1 CSS.

And lucky you if you haven't had any update and dependency issues in the medium to long term. But I know we had.

> Or just use the extremely complete, well-considered, well-defaulted, well-documented, well-supported, always-improving set "of CSS features".

The sentence above is every bit as true as yours. Add a beautiful design language and you are in business.

I understand this perfectly and is maybe the argument I have the most sympathy for.

And, because you are absolutely right, I'm working right now on something like what you propose.

The only way to convince people that CSS is a better (as in lighter, simpler, more efficient, etc.) solution than a framework like this, is to show and prove that it is. Arguments can only go so far...

So, as the saying goes, I'll be putting my money where my mouth is. Hehe.

As I said below, I don't understand how the number of team members can impede our capacity to activate source maps. Again, I may be wrong so go ahead and tell me if that's the case.

Yes, I have. And I don't see how it can impact the feasibility and easiness of activating source maps.

I may be wrong, though. Don't hesitate to correct me if that's the case.

Boilerplate? What do you mean?

Any IDE can autocomplete 90% of any media query. And, on a sidenote, I was only talking about using Tailwind's default aesthetics in pure CSS, here. That's what the 20 minutes refers to. And I think it was a conservative estimate.

As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. It took years for Tailwind to support "group hovers". And I can give even more examples if you're still not convinced. Or you can have a look at the changelog.

As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? And that's not even considering the weight difference between the "tailwinded" HTML and the one needed to support pure CSS. These things matter if performance is a goal (as it should be).

If I'm missing something, go ahead and tell me, I'll be reading with great interest!

How is that different than writing "bg-color-blue-500" in every component that needs it?

As for the class, it's the name of the component, the same name you give to the component file. Does it really add that much work?

Correct me if I'm wrong but as I see it, that's literally a couple of seconds of "work".

I'm not sure what you mean about "Stylelint having a problem".

There's a default config, with only base rules, without the more opinionated ones. Then you configure/extend it as you would with almost any other tool. Isn't it the way most tools of this kind work?

Or am I missing something?

But can you split the Tailwind styles in multiple files so that only what is now displayed in the browser is loaded?

That's the part I'm not sure of.

I'm not sure you understood correctly what I meant. Or maybe is it me. Hehe.

To reiterate: you can link and load CSS for a component just when this component is used instead of loading everything at first. So the first load of the page is faster. Same thing with media queries in link tags. Isn't that something Tailwind can't do? Tailwind will load every style, every time, right?

As for your example, I get your pain. I' ve experienced it too. But it isn't a reason for completely pushing aside CSS in favor of a framework and all that it entails. It is a reason to have good linting.

For example, no component should ever influence the "outside world". So no margins on components. Rhythm (gaps or margins) is better taken care of by the parent (a grid, a list, etc.). This is a simple linting rule in Stylelint that will prevent this development behavior.

As for the rest of your problem, I'd say the "mixin" approach is of disservice here. That and, the way you implement the filters.

Are filters to be arbitrarily applied on the whims of the designer? Creating filter classes to be applied in a singular way then may be a good approach.

Are there rules governing the usage of the filters? Then a systemic approach could be a winner, especially if you can talk with the designer.

There are simple ways of managing these issues/problems with native technology and a little linting.

PS: Sometimes the problem IS the design. If the design is irrational, the real, efficient solution is not to implement these irrational patterns but to talk with the designer and find a rational solution. I know this isn't always easy but that is the problem resolution we should strive for as it is the most efficient one.

I'm talking about the design aesthetics included in Tailwind as default. Keep the values and the names if you want. Like this, for example:

"blue-500" becomes --blue-500. That's it.

This is a far cry from using Tailwind as a whole while keeping the good-looking aesthetics.

This is easy and should not be a problem.

It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.

But you really don't have to do that. Naming components only (as you already are) really is sufficient. And yes, specificity and flexibility can easily be managed/included with CSS, particularly now, with all the new widely supported features/selectors.

These solutions to an old "problem" are lighter, simpler and easier to maintain in the long run.

If you're curious, I'll be pleased to give you more concrete examples!

If you give me a couple of examples, I can give you Stylelint rules to prevent them. At least I think so... eheh.

And now that I think about it, that would be a great exercise in fact! Yes, I'd really appreciate it if you have some in mind and would post them here.

I'm all ears (eyes)!

If the Tailind defaults are used in a design language file, wouldn't it be simpler? If it's only a problem of "aesthetics", 20 minutes is enough to use Tailwind's defaults in pure CSS. No need for calling a designer here either.

Side benefits include that there is then no need to update any dependencies or library, no need to run a JIT server, no need for a new syntax, no need to wait for implementation of new CSS features, better performance possibilities, etc.

Well, that is not using Stylelint I'd say. Within half a day of configuring, you can prevent almost all of the problems denounced in this thread.

Ultimately, it really is "a couple hours of thinking/configuring a linter vs. multiple layers of abstraction, complexity and dependencies added to the codebase."

Maybe I'm missing something (and be my guest if I do!) but there is an objectively better choice here.

Food for thought:

https://csswizardry.com/2018/11/css-and-network-performance/

Progressive rendering of CSS is a great boost in performance. Tailwind can't benefit from this technique I think and as such, imposes an added cost on our users.

Correct me if I'm wrong!

Well, this is bad CSS indeed. But it does not have to be that way. A little linting with Stylelint can make sure this does not happen. As an added bonus there are less dependencies and complexity.

(Almost certainly) worse? Haha. Why would it be?

If you really want to, you can even use Tailwind's naming for you language file. The thing is, you add complexity to do a job that could be done in the same way without adding complexity and dependencies.

Shouldn't we try to justify added complexity through added value?

Why not use the devtools "to see how the button both looks and works"?

You really don't have to do that. It is a pseudo-problem. Specificity and flexibility can also be managed easily in CSS only. Without naming everything. Linting can be used to enforce real good practices. Without any overhead costs.

But these are self-inflicted wounds. Having standards and validation for CSS is easy. No need for all of this. No need for SASS either. Install Stylelint and there you are.

You absolutely don't have to name everything in CSS. Naming components is sufficient. And you already need to do that. Using good HTML markup provides you with 80% of the styling hooks you need in a component. Specificity management and flexibility can be baked in too.

As for the media queries being hard/tiresome to write, don't we have IDE auto-completion for this exact purpose?

But you don't need Tailwind for that. A "designsystem.css" file with custom properties would do the trick. Without any added third party tech.

I never got how is "context switching" such a problem. I mean, can't you have like, two files opened side-by-side in different IDE panels? Is it really that hard to "look jump" from one another? This justifies the amount of overhead added by a library like this?

If I can be blunt: I find this "argument" to be lazy as **. Sorry but "context switching" is just a fancy name for "having two files opened at the same time", which shouldn't be a problem, no?

PS: And almost all the other stated advantages of this approach seem to be as low value as this one considering the implied costs.

Every time I stumble upon a thread like this one, multiple posters react with "but everybody will stop working!". I always find this reaction to be curious.

Why are we working now if, only by not being afraid of starvation and homelessness, we shall stop doing so? It seems to me only two conclusions follow:

1. It means that the actual labor market isn't free since we are essentially coerced into exchanging by fear of being destitute.

2. It means that the free market does not operate properly since if it was, the price of labor would adjust to find a new equilibrium where employers and employees satisfied by the exchange.

UBI would not induce mass idleness. It would rebalance labor relations.

How is it different than any other political initiative? There several ways to objectively/scientifically establish an amount that matches the poverty threshold.

That doesn't strike me as inevitable.

Your comment infers that the great majority of citizens will just stop working altogether. But that's a wrong assumption. Multiple studies (and even logic) shows that the average person does not want to keep idle. You want to contribute to something.

So, why would they stop working if the pay's good? Or, what does it say about our current system if everybody stops working if you get bare subsistence for free?

Well, don't you already name component file after it? Maybe I still misunderstand...

Easier, like in less characters? Because I wouldn't say using CSS media queries is hard.

It can be, yes. But I was talking more about "right" for the end user which should be less subjective (I think).