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>
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.
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.
Colocation is a useful principle in component-based architecture.
As much hate as it gets, this is one thing I like about Angular.
imo Angular would have won had it figured out a stronger path from v1 to v2
2 replies →
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
> Any selector with the " " operator on A risk expanding to the inner A even if it was intended only for the outer.
Then <a type=b> is potentially a <c>. Consider a small refactor?
This problem was solved a long time ago with CSS Modules.
I prefer almost anything to CSS modules, so this bike shedding topic is probably very subjective.
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.
Yes.
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.
Is staying in one file supposed to be difficult or something?
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:
2 replies →
That’s actually disgusting.
3 replies →
You can literally command click a class to go into a styled components css file. I do not understand what the big issue is.
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.
Css modules gets away from the larger sins of the massive global css files.
If modules had existed much earlier it probably would’ve gotten rid of most of the awfulness.
3 replies →
What do you mean 12 files? It’s 2 files. One for your component and one for its styles module.
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.