Not to mention the Tailwind classNames are compiled to CSS in a build step, where CSS is not compiled, it's written in its native form. They're clearly very different syntaxes and approaches, even though one compiles to the other.
The above example shows how convenient Tailwind can be... well if you happen to want that 10px 15px -3px, 4px 6px -4px shadow, but the moment you break out of their palette or default style setup you end up doing stuff like this:
<div className="bg-[#243c5a]" />
Either storing that color value in JavaScript, or creating a Tailwind theme for it in tailwind.config.js:
Something that could have been easily accomplished in native CSS:
:root {
--regal-blue: #243c5a;
}
div {
background-color: var(--regal-blue);
}
For most React websites, I use Tailwind by default almost always, and Tailwind UI is a great starting point for building a component library. But it still helps to support CSS for more advance styling use cases - even within Tailwind. Knowing CSS very well will make you better at Tailwind too even for common things like
<div className="w-[calc(100% - 1rem)]" />
It's kinda important to know both as separate technologies.
That's a very extreme example, and yes, I would just use the bracket syntax in Tailwind because I can see clearly that's not what I want for box-shadow.
If I didn't know how box shadow worked, Tailwind made it easier for me to decide by having defaults in the docs that map to the actual CSS.
It's not very extreme, it's literally any time you deviate from their prefab - so any truly custom UI. The size of shadow (corner radius, font-size, etc.) at different steps are hard-coded in Tailwind, if you want something else that's up to you. In terms of colors (text, background, etc.) they have a default palette, colors like "slate", etc. but anything else is up to you. So - most brands.
> Tailwind makes box shadow easier
Easier sure: What it does is give you the abstractions "shadow-sm", "shadow-lg", "shadow-none", etc. in fact a total of SEVEN options for shadows.
That teaches you something - how to apply up to seven types of shadows! But you would be a lot more powerful of a developer if you knew how to do more than that. This doesn't teach you a foundation for understanding box-shadow or learning anything more - I think your point about learning is not valid.
I learned CSS in 2003 from Myspace profiles and Dreamweaver - visual IDEs are great for education, so don't get me wrong here, I'm a believer in what I think you're getting at, but Tailwind aint it (for that).
I meant that it's an extreme example of a tailwind utility doing a lot of settings for you. Versus, say, `italic`, which just does `font-style: italic;`. I can hardly compare that to an ORM where people can make full apps without learning SQL.
> if you want something else that's up to you
Right, just like CSS. It's a very light helper library that isn't dissimilar from CSS. That's my point.
We've been using visual generators since the introduction of the box-shadow css attribute.
Did you ever actually write them fully by hand?
I for one got better with css after using tailwindcss for a while. So Capricorn2481's statement is true at least for me.
Before I used it for a while I've always gone with component libraries, after that I very rarely did... Aside from work projects that mandate specific libraries, anyway
Of course I know CSS shorthand by memory (and most of Tailwind too), and yeah definitely googled "tailwind box shadow" more often (which one is which).
Back in my day we used Bootstrap classes but those guys put -15px margins everywhere so nobody uses their library anymore LOL
Knowing the shorthand and actually writing it are different things.
If I get a visual spec from a designer, I'm not going to try out various numbers until it fits the image. I'll either ask them for the specific attribute if their tool allows for that or replicate it with a generator.
And if I'm fully in control myself, I'm going to use a generator too as I'll want it to look a specific way, which is easier to achieve with instantaneous feedback as you get it from a generator such as https://www.cssmatic.com/box-shadow
I can't imagine how you would know the shorthand without first knowing the longer form. CSS shorthand requires that you know the original form + the order of values in shorthand, and when values can be omitted along with special formatting as in:
font: normal normal 1em/1.6em sans-serif;
CSS shorthand is - I would say - more advanced than long form.
> I'm going to ask the designer what units to use
I would never get in the habit of letting a designer tell the front-end developers how to write CSS, mainly because they work in pixels, when the developer is often using viewport units, rem for sizing, em for fonts and icons relative to an initial size and current user zoom factor, and flex gaps and alignment for spacing. That level of collaboration and specification on spacing, sizes, etc. between the developer and designer (redlining) might be part of an initial design system discussion, but the resulting component library is probably translated into a style system that works well for the engineering team.
I think it's good you're using CSS generators, I learned most of CSS that way via Dreamweaver, and have copy/pasted from CSS Tricks countless times for edge case stuff - it's a great way to learn.
Tailwind:
CSS: Not to mention the Tailwind classNames are compiled to CSS in a build step, where CSS is not compiled, it's written in its native form. They're clearly very different syntaxes and approaches, even though one compiles to the other.The above example shows how convenient Tailwind can be... well if you happen to want that 10px 15px -3px, 4px 6px -4px shadow, but the moment you break out of their palette or default style setup you end up doing stuff like this:
Either storing that color value in JavaScript, or creating a Tailwind theme for it in tailwind.config.js: Something that could have been easily accomplished in native CSS: For most React websites, I use Tailwind by default almost always, and Tailwind UI is a great starting point for building a component library. But it still helps to support CSS for more advance styling use cases - even within Tailwind. Knowing CSS very well will make you better at Tailwind too even for common things like It's kinda important to know both as separate technologies.