That's exactly what it is.
But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remember what you called them. Hopefully you're good at that and you can remember, else you'll duplicate things. Hopefully your entire team are aligned on the same naming conventions, or your project's styles will be a total mess.
Maybe you'll use styled-components or another CSS-in-JS solution, which helps a bit by making your styles scoped to components so they don't interfere with things outside of where they should, but then you'll have to keep a set of constants to use across all of them anyway, which puts you back at the same problem as plain CSS - you need to remember what's been set, and not duplicate things.
Ultimately, Tailwind is a really well designed abstraction of inline styles that means you don't have to worry about inconsistency and duplication of things any more. It's another thing to learn but because it's so similar to raw CSS it's not actually a lot of effort. It works well.
This is true. But if we better taught the cascade and promoted the idea of global styles rather than pretending it's a problem then more people would be better at this and the problems would gently recede.
We (the high-end front-end dev community) have fallen into the habit of using class names where we really wanted IDs and using components when we really wanted global styles. I feel we have been pushed in this direction by developers who didn't understand the technology properly. The Tailwind author clearly understands it, so I'm not targeting them... but they are supporting the people who don't see why the cascade is useful.
We have megabytes of code to create the impression of global consistency (components, style libraries, CSS-modules...) shipped to millions of users every hour. Browsers do that for us already. Embrace the simplicity of
button { border: foo; color: bar; } .callout button { color: aux; }
It's so clear, so elegant. The obsession with modularising everything, and then applying a DSL to get between the modules, makes the language's inherent convenience, elegance and clarity so much harder to work with that it boggles my mind.
The thesis of Tailwind is that the cascade actually becomes very unclear and inelegant at scale, and I would say the reason it's so popular is that many devs share that experience.
But the opposite is largely true for UI elements. For one, I’m probably using some external templating or component framework to repeat them, because they mostly likely have behaviour attached and HTML by itself has no good story for that. For two, I pretty much never want their styling to be modified by the context in which they’re used.
But that’s what you’re doing when you use scoped styles, components, Tailwind etc.
Just set it once, on body and forget about it for the lifetime of your app.
> I pretty much never want their styling to be modified by the context in which they’re used.
I guess we have worked on different projects. To me this sounds like the edge case. Most projects I’ve worked on want all the components/widgets/thingies in one consistent style that works together for a cohesive overall experience. For such situations (which to me feel like the majority case) the cascade is the simplest tool.
This is the distinction to me. New methods in composing a page approach this differently: style consistency is maintained through dependencies and a build process rather than relying on context. To understand the styling I'm applying to a given HTML elemnt, I can look to the packages going into the build (just as a I do with other aspects of the code) rather than needing to understand every context my component could possibly be invoked within.
<Button class=`border text-gray ${override}`/>
<CalloutButton /> extends <Button override="text-blue" />
I'd argue you have less markup to write overall if you are modularizing component logic/styling
for example if the corresponding css file is this: .text-blue { color: blue; } .text-gray { color: gray; }
Then in your above example, both Button and CalloutButton will have gray text because .test-gray has higher specificity than .text-blue
- CSS classes can be named on a per-component basis, according to one of the well-established naming conventions (BEM, SMACSS, or whatever). This does not require remembering the names of other classes.
- With the arrival of web components, styles can be scoped within the shadow DOM; and the name collision becomes a non-issue; as well as keeping track of _all_ the CSS that's written in the project. If CSS classes don't leak, you can focus your attention only on a given component and ignore the rest.
- Instead of CSS-in-JS, one could use CSS modules, which are just regular CSS with a build step. The relevant project-level (site-level, page-level) constants can be defined as CSS constants on the root element.I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible.
How do you deal with side effects for example I think bg-red is the brand red but some one has modified that class so it now has a border. You could prevent this with convention but then you have the same issues as using css with specificity and people not understanding the conventions around it.
I think its easier for every one to just force your frontend developers to just learn CSS and use it.
The biggest advantage over inline styles is that you are constrained. The idea is that you set up the primitives for your application's styling system: which colors are in use, which font weights, all the way to things like which border radii are valid. Your devs can then only use those.
You are correct that theoretically you can modify them to do anything, but in practice I find that people are extremely unlikely to violate the scheme (in ways like you described, adding a border to bg-red).
As for abbreviations? I think that's probably just eye of the beholder. Since you tend to add a lot of these to your HTML it helps it not get too ridiculously out of hand.
I spent years working with more traditional CSS schemes (including my all time least favorite, BEM), and it was pretty consistently a nightmare within the context of component driven applications. For a while now I've worked with tailwind and it feels like a massive step in the right direction.
I think it's one of those things that really doesn't make sense until you try it and feel the difference for yourself.
Really? I'm not sure I could take someone seriously if they called themselves a frontend developer and did not understand CSS specificity.
A program can read what looks like inline css and produce class names for youand put those in class files.
When developing your see "height 20px" In your app its compiled to "h-20" with a css file "h-20: height 20"
This is better because you don't have to learn another way to express the same logic.
Which is why this is basically reinventing inline styles. With some shorthand.
How did we go from removing <u> and <b> to calling it <div class="bold" an improvement?
You could do it with a cascading approach, but if you're building a component based application (this is what Tailwind is really for) then you already have an abstraction for re-usability. Trying to layer another one on top usually results in a really difficult to reason about mess of interlacing components and style classes.
In short it's a way to use an inline-type styling approach, which is suitable for component based apps, without giving up the ability to constrain developers to a limited design language.
There are a TON of other benefits for utility classes over inline, but I think what I described is the biggest one (media queries, pseudo selectors, stylesheet caching for reduced page load, etc.)
> How did we go from removing <u> and <b> to calling it <div class="bold" an improvement?
You can still use <u> and <b> if you want to. Adding a utility bold class also works fine.
<submit-button>Submit</submit-button> using whatever tooling you prefer.
If you don't use this style, maybe you won't like it.
I've found it's a waste of time to extract classes for items that are not repeated. And putting utilities in components lightens your "master" CSS file and makes it a lot easier to work with CSS.
I've found that the "cascading" part of style sheets almost always breaks down in larger projects. Small components seem to avoid those breakdowns while allowing for reusability.
Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you. You're making the DOM MUCH MUCH heavier than it needs to be and ignoring the rendering engine that's optimised to handle this role. It seems wasteful all 'round. I confess I'm guessing here, and haven't tested it, but I suspect a simple, axiomic CSS file and simpler HTML file would produce faster rendering than Tailwind, and travel over the network faster.
Tailwind improves the developer experience at the expense of badly optimised code bloating and slowing the user experience. The developer experience benefits are debatable, too: I freaking hate using CSS toolkits and would much rather just write CSS or SASS bespoke to my apps. I have more control and can tailor a solution for the problem.
Maybe you shouldn't make unsubstantiated claims like this then?
> Tailwind improves the developer experience at the expense of badly optimised code bloating and slowing the user experience.
I only say this because if your claims about performance are wrong, your comment seems to boil down to "I don't like CSS frameworks," which is fine, nobody's forcing you to use Tailwind.
Things like ads or heavy images actually slow the user experience. This type of thing isn't worth worrying about.
The crazy repetition of classes gzips away though so there really isn’t any extra overhead.
People that haven't used Tailwind come along and say, "this is silly, just use css". The people who have used it say, "you should try it, it's not what you think."
There are a bunch of subtle differences with Tailwind that make it quite a different experience.
Really, it's closer to inline-styles++ than anything else. The style only applies to the element you're styling. This is by design as it means you can change that one style without wondering what else you've broken across your app.
But you get variations that inline styles can't do (and aren't fun to do in css either): `text-green hover:text-red dark:hover:text-white` (interaction states, light/dark mode, responsive etc etc). This makes a huge difference when you're actually building this stuff.
Personally, from a DX point of view, I really like it. I find it faster than anything else when I'm building and it's easy to debug too; no need to fish for the styles, they're inline on the element I'm styling.
The biggest wart is the inability to functionally build up styles. For example, you have a bunch of js and you need to flip between several different colour states (say for an input that has "disabled | errored | valid | pristene"). There's no great way to force one of your classes to "win" because they're all just classes and the way they were added to the page will determine which border colour wins, for example.
Combined with either Flexbox or CSS Grid, the speed with which you can put together a good looking web page is crazy fast.
Took a little bit to get the hang of, but once I did I was working WAY faster without the mental overhead of having to cross reference 2 text files (HTML + CSS) to build the same UI, keep them in sync, come up with names, etc. I iterate so much quicker, refactoring is so much faster cause you can literally just cut and paste a block of elements, throw them somewhere else, and they just render properly cause you brought the styles along with them. Screen size breakpoints make it so much easier to make responsive UIs. You get a free, built-in layout and color system.
It eliminated basically all the major painpoints of building UIs that I had before. I use it in all my personal projects now.
No, I still know CSS but I can’t imagine coming up with class names for everything then going to a different file to define rules. Feels so long winded and hard to keep on top of.
Like others have said, the selector logic is top-notch and not having to build your own styles is great as they are pre-defined. You can always modify the styles any way you want and add your own custom ones too.
It looks "gross", but it's very practical. If you follow the best standards for component sizing, you should never really have much of a problem with the styling getting in the way.
This phenomenon encourages me to try something out before forming an opinion.
You get fast iterations without ever having to leave your markup to hunt down to find all the classes elements are using which uses their own structure & nomenclature, esp. if you need to support responsive layouts which every project implements differently that usually grows into some unmaintainable mess. With tailwind's utility classes it's all right there on the element, using intuitive prefixes and shorthand class names derived from the CSS properties it uses.
It's also the only framework I've used where you can copy markup from a number of different sources and it will look exactly the same as the preview where you got it from without it being distorted by the websites leaking cascading CSS styles.
A few of the other advantages of Tailwind: - reduced noise in the markup compared to raw inline styles, with the underlying styles getting cached by the browser - utility classes can contain multiple properties that should always go together - media queries!
You should learn what CSS is actually doing as well, but realistically Tailwind is, like you said, a pretty thin wrapper on CSS. Learning Tailwind usually just means learning CSS, with some different property names.
My lived approach to inline vs. not-inline is: why not both? Inline is great for prototyping, and for edge cases, like specific margins for wrapper divs. Where CSS classes really shine is when it comes to mature / often used components.
In all fairness, I've never actually tried it.
I was of your opinion until I tried it. Been using it for over a year on my current project, now.
I recently built a little prototype without using Tailwind, and man… I didn’t realize how big a quality of life improvement Tailwind is until I stopped using it. It’s really hard to imagine going back.
Edit: I’ve been building websites since 2000, and know CSS quite well, and hope to never write much CSS again.
That's what you're missing. Try it.
I get that it is aesthetically ugly, but if you can stop caring about that then you might find that it’s better on most other dimensions.
In my experience, tailwind is pretty close to the real CSS properties. What I found to be wonderful and freeing about it is that it stops the middle step of engineering and naming classes and naming elements with class names and let's you just do styling. There's also a really great plugin for VS code that adds intellisense. Personally I found the modifiers that allow you to target pseudo selectors like :hover to be a superpower. I totally understand the other side of the argument though. It's a lot.
This is not how you use Tailwind. Back then there was no such concept as component, so people need to write CSS classes to encapsulate and reuse styles.
Now Components are everywhere, and when you write components and CSS classes at the same time, you're non-obviously duplicating structures (Write components, then write classes corresponding that component).
In essence, Tailwind (or styled components and such) makes component mechanic as your single source of abstraction.
But the experience while writing the code is pretty excellent. It made me realize that what I really want (personally) is to have my css inlined in my editor when writing / editing it, and otherwise remain out of the way in my css file.
Would be interesting to see what an experience of being able to toggle between classless and class-only jsx looked like.
"Add the option to hide class attribute in vscode plugin" https://github.com/tailwindlabs/tailwindcss/discussions/7922
I haven't found a convincing explanation of why exactly this is better until I've used it in a project, and since then I'm completely sold. The semantic CSS concern separation pipe dream has always been snake oil in real projects.
Long live Tailwind.
The browser's built-in CSS support is the framework, I don't understand why people try to build things like this on top of it unless they're adding real value.
Aside from creating a standard naming scheme for your style guide, they also simplify specific CSS tag features by ensuring they can be consistent across browsers without you having to tweak each style.
Outside of that, they acknowledge that you're not going to use custom CSS tags that often because 9 times out of 10 you're going to style something in one place in a template and your programming language will repeat it for you...so there's no real value to creating a dedicated class.
Another that I've found over the lifecycle of a project is that developers forget what CSS is where and end up simply creating new classes for things that they need rather than trying to reuse existing ones...which leads to your CSS growing constantly over time. With Tailwind I rebuilt my entire personal site, brightball.com and ended up with 20 lines of custom CSS. This after restyling the entire site and making it responsive. And I was able to do all of it in an afternoon without ever having even made a responsive site before.
What they've done is created "Rails for Style Guides" and it works beautifully. The Refactoring UI book (fast read) from the authors of Tailwind goes into the importance and reasoning for everything they do and it makes absolutely perfect sense.
It's a design system as well as a set of utility classes. Consider the difference between
<span style="color: #cccccc">Gray text</span> and <span class="text-gray-700">Gray text</span>
In the former, you can't just redefine what gray means. You've hard set it to a value you need to keep track of and keep consistent. On the right, you can configure what "700" means, switch between a cool gray or a blue gray, etc.
<span style=“color: var(--text-gray-700)”>Gray text</span>
Here's how to make a div have 0.5rem of left/right padding on mobile, and 2rem on any screen larger:
<div class="px-2 sm:px-8">
I disagree with your preference; all the classnames are not easily parseable and obscure the markup, and I much prefer the CSS media query syntax. But that’s, like, just my opinion, man. If you like it better, don’t let me stop you!
How?
<style>@media (min-width: 100px) {}</style>https://tailwindcss.com/docs/customizing-colors#color-object...
Utility CSS is by far my favorite way to write CSS, especially in teams. It allows you to extract out multiple classnames that encapsulate all styles into a single classname.
Why would you use Sass when plain CSS does the job better? Tailwind is just normal CSS, all the build steps are ways of making your stylesheets more efficient and removing dead code but it's all still CSS no preprocessor necessary.
Everyone that complains about tailwind is because they didn't use it yet.
Yes, looks weird at first. That's not everything that matters.
If you don't don't get it, either try it out or move on.
These comments add no value to the conversation.