Hacker News Reader

Hacker News

Comment by lawn | Hacker News Reader

Parent Full thread

lawn

Is jumping between files supposed to be difficult or something?

View on HN

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

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

> 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:

    <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>

Ok, and how does it look when you want to read or edit the “classes”?

yeah, Tailwind feels to me like a "write-only" solution.

That’s actually disgusting.

It gets worse

Check out the Netlify admin dashboard screenshot in my blog post

https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...

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.

Tailwind is the product of its era: where even sites are composed out of components. That is, this separation of concerns: https://x.com/simonswiss/status/1664736786671869952

As a comparison, here's Youtube's expertly crafted CSS (which is actually an improvement over their original 6B file). Note how much endless repetition there is: https://www.youtube.com/s/_/ytmainappweb/_/ss/k=ytmainappweb...

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.

CSS Modules are way older than Tailwind, but alas it was not enough

Oh, great. So let’s just 2x all our files then! All for, what exactly?

It sounds like you just want to write Java.

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.

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.

Reply on news.ycombinator.com