Over at the JS Party podcast:
[Kend C. Dodds]: […] ask anybody who’s done regular, old CSS and they’ll tell you that “I don’t know if it’s okay for me to change this, so I’m gonna duplicate it.” And now we’ve got – at PayPal (this is not made up) we had 90% unused CSS on the project I was using, because everybody was afraid to touch the old stuff. So we just duplicated something new and called it something else. And you might just say that we’re bad at CSS, but maybe CSS was bad at us, I don’t know… [laughter]
[Emma Bostain]: Well, that’s why styled-components and CSS-in-JS was so pivotal; it was like “Oh, hey, we can actually encapsulate all of this logic inside the component that it’s touching and don’t have to worry about bleeding code anymore.” It’s so much easier to delete things, and add things, and all of those things.
[Kend C. Dodds]: Yeah, you’re precisely right. That was the problem that those things were made to solve.
Audio clip:
I’ve heard this exact story before several times, usually from large companies. Lots of developers, typical developer turnover… nobody knows what CSS is actually used and what isn’t because that is a very hard problem.
That’s one of the reasons I sometimes like component-based-styling solutions (CSS-in-JS, if you’re nasty). Not because I love complex tooling. Not because I like JavaScript syntax better than CSS. Because of the co-location of styles and componentry. Because nobody is afraid of the styles anymore — they are tightly coupled to what they are styling. It’s not needed on every project, but if you’re building with components anyway (an awfully nice way to architect front-ends that doesn’t require JavaScript), you might as well style this way.
For this reason, I’m excited that “scoped styles” are making a bit of a comeback in standards discussions.
I remember an ancient idea (that maybe even shipped in browsers for a minute?) where you’d just chuck a <style scoped>
block right in the HTML and whatever the parent was, the styles were scoped to that parent. That was so cool, I wish we could have that again.
But it seems like the newer stuff (here’s Miriam’s original proposal) has some more clever stuff that that basic concept doesn’t cover — like being able to set a lower-boundary in addition to an upper-boundary, making it possible to scope “donut-shaped” styles in the DOM (a Nicole Sullivan term). Whatever happens, shadow DOM-free scoped styles with zero tooling is huge.
Eh? Did I miss something? I thought the only way to accomplish HTML components was to use JS to define it…?
I mean you can author in JavaScript components and yield static HTML output (like Astro).
You can build plain components html components with templating languages. Like twig or handlebars
Reading the article made me wonder why wouldn’t it be enough to keep component files in the same directory, named after the component. By using some class, we effectively tie & scope our styles/scripts to our component, right ?
I know it’s not as foolproof as a full-fledged js component system, but at the same time, do we want in our team developers unable to follow such simple procedures ?
I mean, am I missing something here ? Couldn’t we not effectively “scope” our resources as mentioned above, without any tooling at all ?
I suppose. But zero enforcement means… zero enforcement. I don’t think teams will see nearly the benefit without tooling (or native support) for real scoping.
This is exactly what we do. One folder for every component with its template, css file and controller / backend code. The template is always wrapped in a single element with a class name same as the folder name. Can’t have two folders with the same name so styles are scoped that way.
Sounds like a very common problem that could be solved with wide spread web component framework adoption.
Let’s hope this heads there
Our production react application “scopes” css to a particular page by wrapping the entire page with a div with id=pageName. Then our scss files are named after the page they style and everything is inside a giant #pageName { block }. All page-specific components get styled there, and any shared components get styled in a global components.scss.
Vue developer:
¯_(ツ)_/¯
Sounds like a good job for an intern/student, remove css stylings and see how it affect the projects, try to see how its working and let us know which parts you think aren’t doing anything
modular css? why should I lose time naming things like: main-section, details, etc if I can use modular classes describing them?