Here's a tip: if a lot of smart, informed people have a very positive view of a technology but it doesn't click for you, it may not be the right tool for you but it very likely is not a "sign of dementia".
Thank you, I can be wrong obviously, but your argument in light of our current times would actually indicate that a lot of smart informed people are more tending to idiotic brainless emanations than anything else.
This is of course unrelated to tailwind and the words I used there were pretty uncharitable - it's open source after all - but I have yet to see a good example of it clicking, the way I've seen it, in my assumedly small real use sample pool, doesn't seem good at all.
Good luck finding anybody with a "very positive" view of C++ other than maybe Bjarne.
People that do real work with C++ will give you an honest assessment of its strengths and weaknesses. There are good reasons it's still so widely used and it's still the right tool for some jobs. Using it for something it's not well suited for is a mistake, of course.
Of course it's also a tool with a lot of legacy cruft accumulated over decades so it's not a great analogy for Tailwind.
Slightly less typing (compared to CSS), pre-defined memorable names, good documentation and a library of examples.
It's just convenient, that's it. Ideologically I don't like it; for getting work done, it's nice.
Theoretically you could achieve much of it in a "more correct" way, but we don't have the resource to do that in our company and ultimately it wouldn't be much of a value-add. Tailwind saves time.
After years of wrestling with what the “right” UI framework was and marrying your project to the syntax and rules, Tailwind has entirely removed that concern from my life.
But honest question, wouldn't those years of wrestling with the right UI framework be better spent learning the underlying CSS rules and adopting a simple pre-processor that gives you programmatic generation for repetitive bits?
Because in the end, tailwind is better than bootstrap, but it's still the wrong way and incentivises wrong patterns.
And by making it "standard" it makes everybody new to the field start with it and use it, foregoing learning the CSS. And will be supplanted at some point, and then there'll be the dance again. And again. It's just this that I don't understand.
At the point you're customising tailwind and classes you run into the same problems as with CSS without clear guidelines/organisation. So the only way to not run into that it's to use it as inline styles but with classes...
I’d used plain CSS for years following the Zen of CSS approach which I was very fond of and I was a big fan of SASS for simplifying it too. Dealing with browser quirks got old though.
The issue is that most CSS is approached from a perspective that you’re going to reuse a specific part over and over in your HTML as a single tag.
Tailwind realizes that this happens, but simply argues that in most code it happens in templated loops instead of all over your source code. So instead it focuses on reusable parts that cover all of the browser quirks and can be easily combined.
It’s such a boost to productivity and practicality that I can’t believe it hasn’t been around forever.
I think this is an important point, good standards evolve by adopting real world proven practices. If everyone only used 'the standard', then it would never improve.
Have you tried it? I don't know what you mean by "sign of dementia", but I find the approach taken by tailwind makes me a lot more successful in applying designs. Doesn't feel like dementia to me.
What it does is force you, as other frameworks, to learn all its intricacies, design decisions, use an heavy and complex development environment (that besides that reads files it doesn't have anything to go about reading?) so that you don't need to learn the underlying language.
Then it nudges you to write a soup of classes (that you need to learn, and need to learn the config because it seems by default it has -400 but not -500, or whatever, and need to learn their priorities), that you need to keep changing and copying pasting (yes you can write classes that coalesce your styling... but that's kinda the point of CSS and/or any other pre-processor), and forget about semantically marking your html. (I'm not saying you have to write it badly, it's just that writing it poorly seems much easier - and is the same with CSS).
I just don't see the point - with the exception of the pre-processing part of course - CSS can use some little help in some places to generate programatically some things but I think those are better served by a pre-processor and not a framework as the framework tends to guide the overall design of the remaining things.
> What it does is force you, as other frameworks, to learn all its intricacies, design decisions, use an heavy and complex development environment (that besides that reads files it doesn't have anything to go about reading?) so that you don't need to learn the underlying language.
The Tailwind dev environment is literally one Javascript file with a few settings. Not that complex. Tailwind is worthless if you don't know CSS, so I'm not sure that second point works either.
> Then it nudges you to write a soup of classes (that you need to learn...
Is that bad? Not using Tailwind forces you to have a separate stylesheet that hides tag to property relationships, among other hidden abstractions. The class names barely need to be learned. With an IDE, you get class name completion, and there are only a few properties that have unexpected names.
> yes you can write classes that coalesce your styling... but that's kinda the point of CSS and/or any other pre-processor
What do you mean "the point of CSS"? Read the spec. It says nothing about the number of properties a class should contain.
> and forget about semantically marking your html.
Tailwind's reset styles mean you can use whatever "semantic" HTML5 elements you want. If you mean classnames should be higher level abstractions than CSS properties, well, that's a convention that developed during the CSS Zen Garden days. Before that we used HTML attributes for styling. Conventions come and go.
> Is that bad? Not using Tailwind forces you to have a separate stylesheet that hides tag to property relationships, among other hidden abstractions. The class names barely need to be learned. With an IDE, you get class name completion, and there are only a few properties that have unexpected names.
Well, the purpose is actually to have separate stylesheets, so that you can name them in a relevant manner, I don't know, like menus.[s]css, panels.[s]css, just like so you know where things are, and so that you can use a class to define repeating elements across a codebase. There's no abstractions in CSS that aren't present or amplified in tailwind - there's pre-processing utilities that are useful in tailwind but they're present in any pre-processor without the remaining stuff. And in fact the logical way of using CSS is by defining classes and then defining modifications to those classes, when needed, when they're part of a hierarchy of classes that requires it. They're one grep away of being discovered in all css files.
> What do you mean "the point of CSS"? Read the spec. It says nothing about the number of properties a class should contain.
Uhh. Yeah, I might one day, but I don't get what you're saying.
> If you mean classnames should be higher level abstractions than CSS properties,
A classname is a selector token, that you can place in CSS hierarchies and define a set of rules, that affect the elements using that classname. It's obviously a higher abstraction than a style rule.
I wasn't talking about semantic html5, I'm talking about semantic markup for readers of the code. If I see "t-4 h-3 w-2 mongo-xyz bg-pearl-800 flex flex-col m-4" I can understand it after reading all of those properties in tailwind, perhaps and how they all interact. But I'll need to understand that it uses relative sizes (like, why...) that m-px is one 1px, m-4 is 1rem, but what I want is fixed sizes 99% of the time. That someone might have disabled some of the sizes generation. Then I don't know, if someone asks me to change the styling now I have to go through all the codebase, searching for elements that are styled like that, because I have not way of identifying it and I have to change all their classes to the new style. Obviously, it's much harder to have it placed in a single file. Inline classes are better somehow than inline styles (although you can't know exactly what it's affecting), and there's a place for inline styles, but 99% of the time it's bad.
We're trying to find the balance between semantic classes and utilities now with @apply. I've always found layout to be easier with utility classes (regardless of Tailwind, this counts for Bootstrap 4 too).
I like "atom"-like components better with semantic classes. In BEM/ITSS I'd make a component for -everything-. But in Tailwind we'd only make one for common "atoms" such as buttons, tags, inputs etc.
Code example: write ".t-button" and then use @apply to put the classes there. Keeping the design constrained to a set of tokens.
So yeah, I agree with pre-processing utilities - but this is just the same problem as with CSS and I think the apply idea is actually pretty neat...
But... I need to know all those classes to know why the final rules are put in place, I need to know that they don't have conflicting properties, or if they have, their priorities. And when you add your own custom apply's in there, then it can also break just the same. And when you customise your tailwind classes it ends the same problem. So when you're trying to figure out why rows in a table with the same number of headers and same number of td's have different sizes because some no-breaking space class was applied, and why your a.btn isn't getting the same styling as your button.btn and etc, I always feel like I've wasted more time than I should (perhaps because I know css and used it extensively)
I might have been a bit harsh on saying "dementia" as it's disrespectful for those who've put the work in writing it and releasing. It's better than all previous frameworks - I just personally think that it's problem searching for a solution as you can't really win.
It also eliminates the possibility of using a regular preprocessor.
Using the Tailwind-defined values for font sizing, spacing and colors in SCSS is trivial.
This, combined with ITCSS and BEM becomes a huge time saver, especially if your browser-base allows for the use of CSS Grid.
Naming components is the only overhead but with a clear naming and file structure is not really an issue.
So far, writing SCSS, and much less of it (because of ITCSS), is a benefit—compared to learning a proprietary framework aiming to replace CSS at a similar enough abstraction level.
Most people don't actually do design systems, because most organizations aren't set up to make/reward systematic design approaches.
Like any system that doesn't plan/support for its own maintenance, this means that most systemic/semantic approaches break down. The larger the team/projects, the greater the entropy inputs.
Solution: don't do it. Drop your styles (or some mediated subset) directly into a component. This also "solves" the overhead of separating style from content and other ways in which CSS suffers from "everything happens somewhere else"-itis.
Personally, I think tailwind is the wrong solution to these problems and we'll see posts about how this turned out to be a local maximum at best in about 2-4 years (or, hey, recently by the author of this post), but people climb to local maxima for a reason.
This is the thing, not all projects are super giant web applications being maintained by hundreds of front-end developers. For a dummy like me who curses at the laptop every time he needs to center a div and whose style sense pretty limited, tools like tailwind are a bless. I do a small library of components, copy what people who knows more than me does (taking examples from here https://tailwindcomponents.com/) adapt them to my needs and that's it. I dont have neither the skills, nor the time or the inclination to spent time on other alternatives. I like the style (more than bootstrap) and I am willing to pay the price of a cluttered html.
I personally wouldn't trust a person who can center a div on the first try - something isn't right with them!
What makes me concerned with tailwind is that its yet another API to remember. Why would I pick it over material UI with some theming or chakraUI? Why Did you pick tailwind over material or chakra?
Having worked with Tailwind, Bootstrap, and mUI, Tailwind is by far my favorite. With bootstrap and mUI you have to work very hard to go against the grain of the design they ship with, while Tailwind forces you to make your own designs, to an extent.
Sites can _feel like_ bootstrap or mui sites, but rarely have I seen something and immediately thought “this is a Tailwind site.”
For one, Tailwind has a minimal learning curve if you already know CSS. That's a huge thing going for it.
Secondly, UI frameworks are more suitable for full-blown applications, whereas Tailwind can be used for anything—applications, Wordpress themes, static sites, etc.
Material-UI React specifically has terrible performance. It's been a known issue for a while and it's still causing problems on the latest version. One of my projects has a seemingly random 400~500ms render time on any component that uses even a single Material-UI component, which I believe to be an issue with their styling engine. It's incredibly frustrating.
Since Tailwind is literally just CSS classes, at the very least I know I won't ever run into this.
