Jumping up and down in the file is not much better and you still need to come up with names for classes. I want to look at an element and immediately know how it's styled.
I think your point has very little to do with tailwind and everything to do with CSS. Tailwind is optimized for modification and maintainability. We could replace your example with
<div class="hero-header hero-header--large">...
but now any time we want to modify hero-header, we're trolling through the whole site to find where else these classes might be used so we know what to test to avoid breaking anything
Sure it's easy to look at the element you shared and say it's too complex (it's really not, it's very declarative), but the complexity must live somewhere, and I'd choose Tailwind over any other prevailing system because it's isolated and safe to modify
You can fold it, format it, and IDEs preview it. This is like me posting the equivalent CSS in one big line. But even without all that I still prefer this over dealing with cascading styles in stylesheets. Never again.
What stops you from doing the same thing in CSS? It is trivial to assign a specific CSS class to an element that is the root node of a "component" and scope rules under that.
Angular is pretty decent in that it gives you everything you need (the concept of a page and routing, services etc) but one thing I'll give React is the simplicity of changes to attributes just triggering updates.
From where I am standing it is mostly Angular or Next.js, both have separation of HTML and CSS by default, naturally they cannot block someone to come in and put tailwind on the project.
In my lived experience, shared components just become another problem. Especially in a fledgling company, the iteration velocity is actually negatively affected by shared libs because there's always overhead to (not) break legacy. so shared components bloat to address every evolving need.
And now with AI generated code i see so many wrapper patterns that forward endless props down, it's crazy!
TLDR: i almost always end up branching out into evergreen "reusable" components anyway.
Very unlikely the component library the CTO asked claude to DRY up the code with, is the one to rule them all.
FWIW, “colocation in component-based architecture” doesn’t necessarily mean shared code. It can just mean the one thing has all of its parts in one place, instead of having HTML in one file, CSS in another, JS in another.
You’re right about DRY and code reuse very often being a premiere (wrong) abstraction, which is usually more of a problem than a few copy/pastes, because premature wrong abstractions become entrenched and harder to displace.
Without a lot of discipline it is very easy to end up with a css with lots of unclear and hard to guess effects. Eg consider the case of <A type=1><B><A type=2></A></B></A> where A and B are complex templates. Any selector with the " " operator on A risk expanding to the inner A even if it was intended only for the outer. Similarly a :has selector might catch a descendant of the wrong element.
@scope fixes a lot of this, but it is a complex problem. With tailwind you mostly have to worry about inheritance
I find it to be more difficult. Especially if I can't pane the files in view comfortably (ie. beyond 2 or 3 it gets significantly harder to work across them).
Some frameworks or coding styles really lean into having lots of tiny files. That necessitates a more complicated directory structure for the project. Locating files eventually tends to requires search capability rather than being able to look through the tree in a sidebar.
None of this is "hard" per se but I find the opposite is nicer to work with typically.
The problem is that the styles for something can be defined in multiple places, and that makes it hard. Especially with CSS and (potentially) having specificity issues if things aren't managed well. Having them as a part of the component means that problem goes away.
this is grey text from tailwindcss.com, I wouldn't call it easy and readable.
<div class="relative before:absolute before:top-0 before:h-px before:w-[200vw] before:bg-gray-950/5 dark:before:bg-white/10 before:-left-[100vw] after:absolute after:bottom-0 after:h-px after:w-[200vw] after:bg-gray-950/5 dark:after:bg-white/10 after:-left-[100vw]"><p class="max-w-(--breakpoint-md) px-2 text-base/7 text-gray-600 max-sm:px-4 dark:text-gray-400">Because Tailwind is so low-level, it never encourages you to design the same site twice. Some of your favorite sites are built with Tailwind, and you probably had no idea.</p></div>
In my editor this looks like this, with an extension like Tailwind Fold or Inline Fold:
<div class="...">
<p class="...">
Because Tailwind is so low-level, it never encourages you to design the same site twice. Some of your favorite sites are built with Tailwind, and you probably had no idea.
</p>
</div>
There's nothing in Tailwind that makes the craftsmanship dead, and your proposed solution with scoped styles somehow a revival of said craftsmanship.
Note how your solution literally depends on a build tool (Vue) to work. Whereas Tailwind can work with no build tools (tailwind build tools removes unused classes, and that's mostly it).
And then you go:
--- start quote ---
Juniors still come along and just do margin: 13px. In tailwind, they do m-[13px]. No difference. At least with CSS its centralized.
--- end quote ---
When your scoped CSS example is literally decentralized per-file CSS that has `margin: 5px` in it. That gets compiled into a meaningless `class-678x8789g` by the build tool.
> The people I've seen who are most excited over tailwind are generally those that would view frontend as something they have to do, not something they want to do.
Cognitive load of looking at 12 open files trying to understand what’s happening. Well, in fairness some of those 12 are the same file because we have one part for the default CSS and then one for the media query that’s 900 lines further down the file.
If you have a complaint about your styles being so complicated and in a giant 900 line mega file, I don’t see how you address physical size other than breaking up the file.
Granted, nesting support was also added fairly recently in the grand scheme of things, which boggles the mind given how it was such an obvious problem and solution that CSS preprocessing came about to address it.
Also modern CSS is often written in a <style> tag either in a native web component or in a framework which supports single file component like vue or svelte.