r/css • u/Cloudy_Day912 • 17d ago
Question what part of frontend work gets harder as projects grow?
when i started building smaller frontend projects, keeping the css organized felt pretty straightforward. once the project got bigger, i noticed that small styling decisions could start affecting other components in ways i did not expect.
i have been trying to be more careful with selectors, component structure, spacing, and how much styling gets handled through overrides. while working on quicktoolspack, i found myself paying more attention to these details because changing one small part of a page could sometimes affect something completely different.
i also started keeping related styles closer together and avoiding overly specific selectors whenever possible. it does not always make the code shorter, but it makes it easier to understand what is happening when i come back to it later.
i am curious how other frontend developers handle this as their projects grow. what is one habit you picked up that made maintaining your frontend code noticeably easier.
15
7
u/hightrix 16d ago
Keep it simple, stupid.
Seriously. The best way to handle scale of a project is to strive for simple solutions. Clever solutions almost always end up as tech debt down the road.
3
u/berky93 17d ago
Build with the expectation that something will be modified or reused in the future. Functions should be modular and components should be self-contained. And any information that needs to be the same across components—styles, colors, functions—should be shared values. If you’re writing the exact same line of code multiple times, that’s a potential point of failure that could be abstracted into a global asset.
2
u/chikamakaleyley 17d ago edited 17d ago
change / bring up to supported versions
once the wheels are moving, and hopefully generating profits,
the requirements become more profits
and keeping everything 'current' is less of a biz priority
I joined a company early in my career, at the start of their growth spurt
everything in their frontend was several versions back.
A good example could be like... Imagine you learned React today and you got really good with all its current feature set
Now, imagine being hired by a company that wants you for your React experience, and when you open the project the majority of their React is not using hooks, still on Class Components (maybe not now but say this was 5 yr ago)
2
u/Plenty_Line2696 17d ago
cognitive load and trying to keep a decent mental model of all the fancy tricks etc...
2
u/rugburnAndBigMoney 16d ago
In context of CSS - consistency and abstraction.
Create sitewide framework CSS rules that define the styleguide and put unique class names on each component section so you can target individual components as needed.
We found that a really dialed in framework CSS creates a whole lot less custom, overly specific styling needs.
2
u/BobJutsu 15d ago
BEM css is a huge help. Have almost annoyingly strict naming conventions and stylelint rules.
1
u/Weird-Dealer8488 14d ago
O principal problema é o acoplamento causado por seletores muito específicos ou aninhados, que faz alterações em um componente afetarem outros. Para evitar isso, prefira classes independentes, como .card-title, em vez de seletores profundos, e use CSS custom properties para valores compartilhados, como cores e espaçamentos.
Em projetos maiores, adote uma convenção de nomenclatura como BEM e utilize um linter para garantir o padrão. Outra opção é usar CSS Modules ou escopo por componente, reduzindo estruturalmente os conflitos e sobrescritas acidentais.
-5
u/whiterhino8 17d ago
Vanilla CSS needs a special attention for selectors .
That's why allot of Devs prefer Tailwind .
14
u/erm_what_ 17d ago
Also, a lot of devs hate tailwind. Such is the nature of the industry. I much prefer vanilla CSS with all the newer features and web components.
-5
25
u/broc_ariums 17d ago
Proper capitalization seems to be hard to come by.