531–540 of 559 posts
Earlier quoted context omitted.
I just end up context switching to their documentation website to find the syntax they used. I don't, but I've been using Tailwind for a little while. Once you grok the syntax structure it's not that different to writing CSS.
If it's not that different, then you may as well just write CSS.
Earlier quoted context omitted.
Except when using Tailwind, you're learning Tailwind nomenclature and syntax and approach - which really isn't modern CSS, at all. Today's CSS - if anyone would take the time to actually learn it as they do JavaScript - doesn't need something like Tailwind to make it powerful, scalable and manageable. I write plain CSS today, which is then scoped to components or bundles of interactivity, and all of those point to ma…
One more thing I find baffling is the preference to ignore the cascade… and seeing it as a benefit. The cascade is where the value of CSS comes from! It’s an incredibly powerful concept. I use and love the Inverted Triangle CSS (ITCSS) approach and write a fraction of the CSS code I used to. Having a few utility classes, using variables for project-specific colors, breakpoints, spacing, using fluid typography, grid,…
Tailwind styles cascade just like any other CSS rules. No one is ignoring it. The reason it might appear not to is because Tailwind uses layers (https://developer.mozilla.org/en-US/docs/Web/CSS/@layer). Technically it's a polyfill at the moment, but v4 will use the native @layer syntax.
If anything Tailwind is actually better at using the cascade than most plain CSS approaches.
Earlier quoted context omitted.
> 20 minutes is enough to use Tailwind's defaults in pure CSS not 20 minutes, more. Plus all the boilerplate around @media rules > no need to wait for implementation of new CSS features What CSS features are you waiting for with Tailwind? > better performance possibilities It's very hard to beat Tailwind's performance since it's a fixed set of css classes (and a very small set in production, since it only includes cl…
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 "g…
:root {
--gap-default: 2rem;
--gap-large: 4rem;
... 30-40 more vars ...
}
.component1 {
margin: var(--gap-default);
padding: 0 var(--gap-large);
... more styles like this ...
}
@media (min-width: 640px) {
.component1 {
padding: 0 var(--gap-default);
}
}
@media (min-width: 768px) {
.component1 {
... other overrides
}
}
/* potentially repeat for other breakpoints ...*/
/* repeat for all components */
/* repeat for some internals of some components */
> As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there.
No one stops you from using whatever CSS you need alongside with Tailwind. I do that for the excellent layout breakout I found here: https://ryanmulligan.dev/blog/layout-breakouts/
Can't see how this makes Tailwind "ant-CSS".
> As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded?
Tradeoffs.
Most existing solutions can't even detect duplicated CSS. So if your existing component already has `width: var(--some-var)`, and you load a different component with the same style... You will still load that style hidden in a different (often auto-generated unique) class name.
Meanwhile with Tailwind has a fixed number of classes that apply to all components equally.
So, if you have a complex app with multiple component variations, of course you'll need to split your CSS and only load relevant CSS for displayed components. Because your CSS grows with the amount of variations, and each of those variations becomes its own unique class.
For Tailwind though that growth slows almost immediately because... it's just a fixed set of classes.
Earlier quoted context omitted.
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 "g…
Boilerplate? What do you mean? :root { --gap-default: 2rem; --gap-large: 4rem; ... 30-40 more vars ... } .component1 { margin: var(--gap-default); padding: 0 var(--gap-large); ... more styles like this ... } @media (min-width: 640px) { .component1 { padding: 0 var(--gap-default); } } @media (min-width: 768px) { .component1 { ... other overrides } } /* potentially repeat for other breakpoints ...*/ /* repeat for all c…
Here are my thoughts:
In your code example, all that is in :root should be used from project to project. As it is Tailwind. Only values should change. Again, same as Tailwind. So I don't really see a problem.
For .component1, you would do the same in Tailwind albeit with fewer characters but as I said, your IDE should pick up the slack here.
mb --gap and it is done.
As for your duplicate width problem, it can be solved easily with a linter that prevents styling across files. I'll give you an example if you're interested. At the same time, you would be repeating "width" across components in Tailwind too.
So the duplication still exists, if I understand correctly. Same with the growth of CSS... In Tailwind you grow the HTML instead. Fixed clases or not. I don't see how it is better but, again, maybe I'm missing something.
As for the media queries, same as above: your IDE should pick up the slack.
BUT!
The thing is that by writing modern CSS, you would not need most of these media queries! Do you know "clamp()[1]"? It's magical
And unfortunately not supported in Tailwind at the moment
.component1 { clamp(var(--gap-default), 1vw, var(--gap-large)) }
the above will do what you want without media queries! clamp() solves a loooot of these use cases. Honestly I don't write much media queries anymore and yes, that's great.
And if I may, I think Tailwind here prevents you from thinking about better and simpler solutions like this one. If it ain't included in what you're using, it's normal to not think about it. But really, this is a game changer. And it's been available for certainly three years. That's a lot.
And in the end, I'd say using real CSS with Tailwind kind of defeats the purpose. You end up with different styling methods for different components. I don't think that's good. More like a "hack".
But really, your example above is right on point: by excluding new approaches, Tailwind disincentivize you from using them when they would solve many of your problems elegantly and simply.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/clamp
edit: the Tailwind example provided is bad CSS. As were the ones given in the first fundamental post by Mr Wathan. These are strawmen. If you're interested, I'll give you an example of good CSS producing the same output.
Earlier quoted context omitted.
Not really. Tailwind lets you configure your own spacing and breakpoints. You get to pick what those numbers mean.
That's just a CSS variable. You don't need Tailwind for that.
Earlier quoted context omitted.
That isn't an inconsistency, it's an intentional choice. The color of the text is an aspect of the text, not of the font. The corresponding property in CSS is color, not font-color.
> The corresponding property in CSS is color, not font-color. So why not color-{color}-{shade}?
Earlier quoted context omitted.
You don't need 5 question marks to tell us you don't know what breakpoints are.
I know what breakpoints are. As far as I'm aware, there are no standard values for them.
'sm': '640px',
// => @media (min-width: 640px) { ... }
'md': '768px',
// => @media (min-width: 768px) { ... }
'lg': '1024px',
// => @media (min-width: 1024px) { ... }
'xl': '1280px',
// => @media (min-width: 1280px) { ... }
'2xl': '1536px',
// => @media (min-width: 1536px) { ... }
If you don't want those specific breakpoints in your project, you can override the defaults in `tailwind.config.js`.
Earlier quoted context omitted.
None of this mirrors my experience whatsoever. That’s “how things are” for me. I know CSS very well and Tailwind is probably the largest productivity boost I’ve encountered since, I don’t know, learning vim? It’s way faster than SASS/SCSS which is itself way faster than raw CSS. It also yields far more self-contained and more readily composable components than any other styling mechanism. Your comment doesn’t resonat…
Agreed. I've been using CSS for over two decades now. The composibility, reusability, and maintainability benefits of CSS have just never materialized outside of some very tight scopes such as toy projects or single developer projects as far as I've seen. And we pay heavy costs having half of the context of whatever we're working on living in an entirely separate file (any generally multiple discrete areas within tha…
Earlier quoted context omitted.
Have you worked on a FE team with 5 or more people? There's a lot that is easy and shouldn't be a problem when you get to define the scope and technologies and shared conventions used.
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.
But regarding one of your specifics, for example you said "the kind of help/solution that should be implemented first" before frameworks are added.
On the teams you've been on, was it easy for a developer (especially a junior) to say "Hey, we should really be implementing X, and we should have done it before I joined the team, can we restructure at this point?"
Earlier quoted context omitted.
What are you building where CSS and the "weight" of HTML is a real performance consideration?
Well, I'm building websites and apps. And, as I'm sure you know, milliseconds are important in our craft. You can easily shave or add hundreds of milliseconds with HTML or CSS. And to be honest, I find your general line of inquiry here to be quite agressive and dismissive. I think, respectfully, a little more good faith could further our understanding of each other.
Outside of consumer apps I am struggling to imagine a case where the HTML/CSS perf delta would be more important to capture than faster development time. I suppose part of why that doesn't seem like a good faith question is because you don't believe Tailwind dev time to be faster, so the tradeoff that I'm trying to evaluate is totally inane.