So tailwind at this point is basically just a bunch of custom CSS classes which are granular to the point of single CSS properties?
How is that better, than just writing custom CSS classes for components + having some util CSS classes?
How is that better, than just writing custom CSS classes for components + having some util CSS classes?
1) it is more standardised (since it is written in html rather than custom classes) which means you can pretty much copy a component from one project to another without worrying that maybe the css naming overlaps etc. It just works.
2) it limits the decisions you need to make. No need to decide exactly how many pixels the padding should be. Just pick p-4. And if that is too much take p-3.
3) You dont need to worry that something in a totally different part of the app will break if you change the css to change the styling of a component
4) It is just faster to write and in my opinion easier to reason about (im sure this is personal) since I can see directly in the html what styling is applied and i dont need to go and dig in different stylesheets to find out what "custom-button-large" does
Not bashing Tailwind. It’s amazing. But I found myself making thatsamefuckingwebsite.com again and god damn if I didn’t want something to look different.
And as soon as you’re writing your own CSS, you might as well just write your own CSS.
Like literally the first time you write your own particularly uniquely styled component and have to mash your own classes in with Tailwind’s you think, hang on, why don’t I just…
Edit: like this site. Just found it via elsewhere. https://www.usebubbles.com/ First thought: justanotherfuckingtailwindwebsite.com
It's definitely worth building a few small projects - it looks and feels bad at first, but once you get used to using it, it's really hard to go back to anything else.
I think the ability to mix up things like that is what makes it quite powerful. You don't have to go digging through your sources to find all instances of '.my-one-off-class-that-some-random-dev-also-used'.
Tailwind together with view components has changed how I structure my code and it creates quite a bit less work than my company's old more BEM centric approach where we would create lots of tightly coupled CSS code controlled by variables and such. I find it easier to grok as well, because I don't need to reference SCSS files to determine the implications of applied classes when debugging or similar.
Now most of the component requirements can be codified in a few classes in our view component instead. Does it look kinda ugly, yeah sure. But I'm sure it has saved quite a few hours for me since I switched over.
This might just be because old process was even worse, regardless it has been a very positive change for me personally.
You don't have to remember whether you had a 4px or 0.5rem or 4% border radius on your buttons, you just have to remember sm, base, lg, xl, or full. You don't have to remember the scaling of your fonts, you just use the same nomenclature.
This:
1. Creates a more cohesive codebase where most everything is using the same units (I've never worked on a project where there wasn't a rampant intermixed use of em, rems, px, and vw/vh -- except on tailwind projects)
2. Creates a more structured component feeling -- you don't ever run into the cases where border radius is off by 1 pixel or widths are using different units
3. Creates a more cohesive design feeling -- text sizes are balanced with eachother, widths are balanced nicely, colors grade smoothly, etc
I was a long holdout on tailwind. I always say it as just another way to write css except on one line (css golfing). Either I was ignorant in the beginning, or it changed along the way, but by the time I started using it around v3 I couldn't believe I was holding onto CSS for so long.
Because the classes are shared to begin, there is less redundancy in the final CSS than using custom classes, perhaps with mixins to do standard flex or positioning patterns. So the resulting CSS file is typically relatively small and kept small by the dead code elimination. You can ship the entire CSS file to any page or on the initial page load for a SPA and not worry about code splitting your CSS, which can be troublesome in some builds.
It pretty much always were?
> How is that better, than just writing custom CSS classes for components + having some util CSS classes?
1) colocation of style and layout in the code (no separate file, no "dead-code" CSS classes) 2) isolation of styling rules (this style applies ONLY to this HTML component) 3) Built-in standardization across the codebase (spacing, colors, etc)
Only works well in component-based web development (ie React, Svelte, Vue, etc) as opposed to inheritance-based styling (old school CSS+HTML)
You can get a lot of the benefits of tailwind using other tools like CSS modules (isolation) or colocation (styled-components), or with plain CSS features (CSS variables for standardization). But tailwind has a major benefit of introducing almost-zero runtime impact (vs styled-components) and having everything already built-in (vs css-modules. There is very little the user of the lib needs to think about architecture-wise when using tailwind
Funny how that's not how it's advertised on the landing page. The first animation of its use is just basically plaintext HTML document.
I can't imagine using it for that.
That may sound absurd given tailwind classes represent single CSS property value assertions. But you can pretend and say "look we're using a preprocessor and pipeline step for our CSS" all the while you're hand-crafting your CSS like in days past, making tailwind act like a no-op submarine, and without the bad looks of inline styles.
The benefit is that you don't have to create a badass taxonomy for your frontend classes (that might or might not evolve well) just because CSS is there, especially if you're using CSS-in-JS anyway and might prefer relying on code organization via JS (that you're using anyway).
CSS rules are just a redundant syntax for markup attributes anyway.
But the advantages out-weigh the disadvantages, IMO:
- provides a simpler, thoughtful, more logically organized version of CSS (with nice ways to extend it and escape hatches if you need them). - the “CSS” —- meaning the CSS-like classes — live right on the HTML elements they style.
It makes it feasible to directly style HTML using CSS-like classes, rather than having to build and, importantly, maintain separate CSS and your own abstractions mapping classes and element types to styles.
However, I use it in my day job, and here it is useful to us as a team. The variables combined with the tooling ensures we write consistent styles across our site. The color names and text sizes also correspond to what our design team uses in Figma, making implementing and updating designs quick.
That said, I still find it a pain to read, and we could probably have set up something very similar with CSS Custom Properties.
You could import your favourite design framework (say, bootstrap) as SCSS, change its variables to suit your design, and create any custom components using @extend:
.custom-component {
@extend .some-bootstrap-class
}
Just keep it first-order, as SCSS functions cannot return new functions.
One of the big reason to not do that in the past was in order to disconnect the presentation from the page structure, but if you have individual classes for each individual css property, you're back at tying the two together.
What am I misunderstanding here?
Re: separating presentation from page structure, Tailwind is designed around the opinion that that whole idea was mostly wrong, similar to how frameworks like React brought back the `onClick=` attribute when everyone was saying “unobtrusive JavaScript” was the best practice
Wrote about this in depth a few years ago shortly before releasing Tailwind, can read here:
https://adamwathan.me/css-utility-classes-and-separation-of-...
For example, if you define class `.myclass { @apply bg-red-100 hover:bg-red-50 active:bg-red-200 p-2 md:p-3 xl:p-4 animate-pulse; }`, tailwind will generate quite a big css ruleset, with @keyframes and @media-rules. And all of these media-rules are extensible, so if you want a different size for "md" or new suffix, just define it once in config and use everywhere.
2. grouping css classes is also hard
3. having some unified naming for all utilities for all developers in your team is much easier to understand and maintain?
4. you reduce 3 steps from creating css file -> writing css class -> re-write them back in the html, vs writing classnames
5. you can have unified styling with color, spacing etc instead of rogue assignment
I'm a tailwind convert from bootstrap but it's definitely worth it after trying. Have created 15+ project with tailwind ever since
Tailwind is just a CSS design token and utility class library at its core. It’s the Bootstrap of the 2020’s.
Regarding design tokens, they are taking notes from 1996, and they realized that it is much more computational efficient to describe your component visually with inline styles compared to loading separate style sheets.
Tailwind and CSS design tokens in general make it easier to make smart, efficient choices from curated palettes. Design tokens also create a common language for everyone who uses Tailwind - both across teams and across projects, which can break down communication barriers in large scale projects.