And there is nothing to stop me from using class names that was designed for the home page.
CSSModules or BEM, as just a "more safe way to name things" could save the day. But CSSModules would be enough.
Is there anything, that CSS-in-js could improve? No.
2. CSS problem #2: Implicit dependencies
BEM, SMACSS, SUITCSS, Atomic, Nonetheless, each of these solutions are just a quick patch solution.
In short - you are wrong. This is not quick patch solutions, and BEM/Atomic approach(even if there is no similarity between then) could be used with "CSS-in-JS". You just don't get the point - they are about "structuring" the rules, not writing/naming them
Is there anything, that CSS-in-js could improve? No. The problem is perpendicular.
3. CSS problem #3: Dead code elimination
CSS in JS can dynamically clean up CSS code that is not being used.
How? Probably you might just delete it?
What if you have a one style file per component? - You probably might just delete it. Or not import it if you didn't use component.
Is there anything, that CSS-in-js could improve? No. It's the same.
4. CSS problem #4: Minification
For big applications unminified CSS code can get fairly big, especially with crazy amount of white space (indentation) we add to the stylesheet. Which just creates another dependency your CSS.
Miniwhatthing? How you think CSS-in-JS "minifies" their code? It does NOT do it. Instead of it you have to download some(a huge amount) of JS to parse, prefix and apply your styles in runtime.
CSS-in-JS usually consumes more space.
Is there anything, that CSS-in-js could improve? No. They even much worse.
5. CSS problem #5: Sharing constants
CSS supports a sharing constants with their built-in function called var().
constants are supported by SASS or LESS. Supported perfectly, and you can build bridges between JS and CSS using webpack loaders.
The problem is with variables, which you might not need.
Is there anything, that CSS-in-js could improve? Yes. The only thing CSS-in-JS can rule.
Total
Generates minimum CSS requires? NO.
Good runtime performance?RUNTIME? CSS does not require any runtime, and vanilla CSS parsers are much faster than js parsers. Keep CSS as CSS if you need "speed".
Supports dynamic styling? Yes, but do you need it really?
Easy to pre-render important CSS? And inline it into HTML? What are you doing?
Zero-runtime
If you like "CSS-in-JS" - use "zero-runtime" CSS-in-JS libraries. They produce CSS, while being "JS" for you
Those are nice libraries that I've never seen until now. I'll have to do a deep dive on them.
Overall, I don't believe traditional CSS architecture belongs in a 2019 (mid to big size) application.
We're moving towards a componentize architecture and traditional CSS structure doesn't work because of the problems I've mentioned above.
With that said, CSS modules I have heard of and I think it's great but it adds more dependencies to an application and more knowledge about Webpack configuration that an engineer needs to know.
I don't think there is a good enough reason to why need to add all that complexity or even know it.
Writing CSS in a JS file does solve the problems above, and you honestly don't need a library to do so. You can inject it inline.
Now you might say, INLINE CODE IS THE WORST!
It was horrible before because you had to write it manually, but now you can just have a style object and inject into the style attribute. You may also move the style object to it's own file for "separation of concerns".
You're still writing CSS, but just doing it through JavaScript.
We're moving towards a componentize architecture and traditional CSS structure doesn't work because of the problems I've mentioned above.
Probably the problem is with traditional CSS structure.
With that said, CSS modules I have heard of and I think it's great but it adds more dependencies to an application and more knowledge about Webpack configuration that an engineer needs to know.
It's one line. And even CRA supports it. So - there is no complexity.
Writing CSS in a JS file does solve the problems above
The problems are solved by a specialized library, not CSS-in-JS as technology itself
you honestly don't need a library to do so. You can inject it inline. Now you might say, INLINE CODE IS THE WORST!
I would say - INLINE CODE IS THE WORST!!! You got me :P
There is one, a single one reason not to use inline css - meta selectors.
Meta selectors give you the ability to:
target :hover, :focused, :active states, which you still could emulate with a pure js, but better dont
target different medias, which enables responsive and fluid designs. You still can use window.matchMedia, and produce the right styles for a current media, but it's not quite maintainable (and SSR/cache friendly)
use pseudo selectors, like :before or :after, which could simplify your html and make code cleaner. It's still possible to just add mode nodes to the markup, and joggling everything with javascript. But there are situations, when you have to use all features listed above simultaneously, like add :after element for :hover state on some @media, and CSS code shall be preferred.
And every time, when you are writing MORE CSS code than JS code, and that could be a thing, if you really use all possibilities of CSS - you might prefer CSS-in-CSS, not in JS.
It seems to me - you are underusing CSS features. And, actually, shall not have any issues in this case - CSS problems are problems of a scale.
1. CSS problem #1: Global namespace
CSSModules or BEM, as just a "more safe way to name things" could save the day. But CSSModules would be enough.
Is there anything, that CSS-in-js could improve? No.
2. CSS problem #2: Implicit dependencies
In short - you are wrong. This is not quick patch solutions, and BEM/Atomic approach(even if there is no similarity between then) could be used with "CSS-in-JS". You just don't get the point - they are about "structuring" the rules, not writing/naming them
Is there anything, that CSS-in-js could improve? No. The problem is perpendicular.
3. CSS problem #3: Dead code elimination
How? Probably you might just delete it?
What if you have a one style file per component? - You probably might just delete it. Or not import it if you didn't use component.
Is there anything, that CSS-in-js could improve? No. It's the same.
4. CSS problem #4: Minification
Miniwhatthing? How you think CSS-in-JS "minifies" their code? It does NOT do it. Instead of it you have to download some(a huge amount) of JS to parse, prefix and apply your styles in runtime.
CSS-in-JS usually consumes more space.
Is there anything, that CSS-in-js could improve? No. They even much worse.
5. CSS problem #5: Sharing constants
constants are supported by SASS or LESS. Supported perfectly, and you can build bridges between JS and CSS using webpack loaders.
The problem is with variables, which you might not need.
Is there anything, that CSS-in-js could improve? Yes. The only thing CSS-in-JS can rule.
Total
Zero-runtime
If you like "CSS-in-JS" - use "zero-runtime" CSS-in-JS libraries. They produce CSS, while being "JS" for you
Styled-Components? All the reasons you listed - are falsy. Believe the old pirate.
Those are nice libraries that I've never seen until now. I'll have to do a deep dive on them.
Overall, I don't believe traditional CSS architecture belongs in a 2019 (mid to big size) application.
We're moving towards a componentize architecture and traditional CSS structure doesn't work because of the problems I've mentioned above.
With that said, CSS modules I have heard of and I think it's great but it adds more dependencies to an application and more knowledge about Webpack configuration that an engineer needs to know.
I don't think there is a good enough reason to why need to add all that complexity or even know it.
Writing CSS in a JS file does solve the problems above, and you honestly don't need a library to do so. You can inject it inline.
Now you might say, INLINE CODE IS THE WORST!
It was horrible before because you had to write it manually, but now you can just have a style object and inject into the style attribute. You may also move the style object to it's own file for "separation of concerns".
You're still writing CSS, but just doing it through JavaScript.
Probably the problem is with traditional CSS structure.
It's one line. And even CRA supports it. So - there is no complexity.
The problems are solved by a specialized library, not CSS-in-JS as technology itself
I would say - INLINE CODE IS THE WORST!!! You got me :P
There is one, a single one reason not to use inline css - meta selectors.
Meta selectors give you the ability to:
:hover
,:focused
,:active
states, which you still could emulate with a pure js, but better dont:before
or:after
, which could simplify your html and make code cleaner. It's still possible to just add mode nodes to the markup, and joggling everything with javascript. But there are situations, when you have to use all features listed above simultaneously, like add:after
element for:hover
state on some@media
, and CSS code shall be preferred.And every time, when you are writing MORE CSS code than JS code, and that could be a thing, if you really use all possibilities of CSS - you might prefer CSS-in-CSS, not in JS.
It seems to me - you are underusing CSS features. And, actually, shall not have any issues in this case - CSS problems are problems of a scale.
Agree. CSS module system is the best
import styles from './App.module.scss';
which can be use after as
<div className={styles.App}>
...
</div>