IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace.
My preferred solution are CSS Modules[1], Vue's scoped styling[2] or something similar.
What amazes me is how violently the run-of-the-mill programmer hates namespaces. Despite the fact that managing namespace collision is important for composability (either deliberate or accidental) and code generation.
This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other programming languages it seems the opposite:
(i) half of the software managers in the world are driven nuts because their team is screwing around with Vagrant instead of working
(ii) it seems no programming task is too boring if you do it in rust or go.
That reminds me of a colleague complaining about a recent cohort of about 60 webdev graduates. Not a single one wanted to learn perl, but were quite happy to get stuck into anything Javascript preferably react!
learning backwards can be good too.... i know a guy making $200k+ managing some old AS400s, part time, and he is too young to have grown up working on them. old school skills are worth money, and the unwillingness of new entrants to learn them just makes them that much more valuable.
I've worked in enough Perl at one point to actually like it but I would never recommend anyone learn it unless they absolute have to. At this point it's effectively a dead ended language. It's also a terribly difficult language to learn.
I don't particularly like the Javascriptification of every technology but these webdev graduates have the right idea.
i didn't find perl terribly difficult to learn at all, but then again i learned it 12-15 years ago and maybe it was more on par with other languages at that time. don't think i would want to learn it now though, still have a strong appreciation for it though.
Perl is full of strange grammatical rules and even stranger conventions that it's one of the few languages I learned 15 years ago that I can't just pick up and use. I've forgotten basically everything I ever knew about it and yet other languages from the time period, even some odd ones, I can still grasp enough to restart the process.
CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.
Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.
With sourcemaps you can get close, but it still shows the "mangled" class name in the HTML.
But with a dev/prod environment, you can have your cake and eat it too (for the most part). In dev we have our classnames be in the format of `[classname]---[file-path]---[filename]---[partial-hash]` So one of my classnames from a current project is `.container` in the file, but shows up as `.container---src-components-scanner----styles---1446d`. And in production shows up as `._1533JgnvGu096C2bCAkrxT`.
It looks like CSS modules is meaningfully different from being just a naming convention.
With a naming convention, if you want to use work from two different packages and they happen to use the same names, you need to edit one of them. People come up with conventions to try to avoid this, like prefixing everything with the package name, but that doesn't fundamentally fix the problem. If two packages have the same name, they clash again. You have a fundamental tradeoff between short prefixes which are easy to work with, and long ones which are less likely to clash.
In other systems, when you use a package, you choose the prefix. If two packages use the same names, you just give them different prefixes. Short prefixes are fine, because they don't need to be globally unique.
It looks like CSS Modules works the second way, and that's an improvement over just being a naming convention.
Perhaps I wasn't clear - of course you should be careful about naming things well (one of the hardest problems in CS, right? :P), but using consistent terms, case and the like is one thing.
A large part of CSS naming conventions is doing more convoluted stuff such as business-page__contact-form__submit--disabled, just because there are other submit buttons on your website and you don't want some styles to clash. This is the part that is abstracted away by automatic solutions.
If your favorite programming language scoped all variables globally, no matter where you defined them, sure you could prefix them with the name of the current function to solve your problem, but it'd be painful and error prone.
> CSS Modules is still a "naming convention," just one that is auto-generated for you.
Yes, that's true, but your use of the word "just" implies that auto-generation is a detail. It's not. It's the the big win. At root, everything is machine code, which also has a flat namespace. Having that flat-namespace code auto-generated is a huge lever.
And it fixes a few other unexpected problems as well.
We use SHA1 hashes of the CSS classes' contents as it's name when using CSS modules. This has the cool side effect of making any 2 classes that do the same thing to have the same name, and get de-duped in the final output, regardless of where they originated in the application.
When I saw it happen the first time, it really kind of cemented in the idea that this combined with a way to "punch through" the modularity to combine and extend "base" classes and include global colors (for us it's SASS imports) has pretty much "solved" CSS for me.
That's a nice trick -- thanks for sharing! Am I write in understanding that implementing this within webpack is simply using only [hash] as the localIdent configuration property for css-loader?
yeah, specifically [hash:base64] because [hash] will print the hex of the hash which is a bit more verbose. I think it's actually the default for css-loader if you don't set localIdentName
During development we have it set to `[local]---[path]---[name]---[hash:base64:5]` which gives massive verbose class names but lets me pinpoint exactly where they came from.
There's also one step that I left out that helps, which is to have something like csscomb[0] to order the properties of each class into a set order. It really lets this optimization shine by ensuring that different property-order won't cause different hashes.
Neat trick, but SHA1 is serious overkill for this. Even MD5 would be overkill. You don't need a cryptographically secure hash if you aren't dealing with inputs controlled by an adversary.
This problem has, for instance, dogged RDF. All the time I hear about programmers who "don't want to learn SPARQL" and I think the heavy use of namespaces is one of the impediments. For most other programming languages it seems the opposite:
(i) half of the software managers in the world are driven nuts because their team is screwing around with Vagrant instead of working (ii) it seems no programming task is too boring if you do it in rust or go.