This is such a good example, a lot of people are saying bem, but they fail to realize how overcomplicated bem itself can become in large multi page sites. According to me, this approach is the best for a dev cruising through codebase.
When I started to hear this css modules. I thought that it doesn't make anysense. But talking about components and no thinking the name classes is the best part of this. Just create what really is important. And forget the names and cascade problems... 💪💪
As much as i love the content, I cannot understand why you didn't include "Part 2" in the title. It's a series however title doesn't reflect that and it's very confusing for new viewers.
The point of CSS isn't that every single bit has to be scoped. It's the exact opposite; it should enable your entire application to conform to a unified visual style. It **should** cascade. It's awesome precisely because it cascades. CSS modules make it hard or even impossible to share styles. Sure, it's all fun and roses initially when you're building from scratch, but once you start refactoring and changing components of your app, you realize how stupid this shit is. Well structured BEM CSS will always be easier to work with and maintain. The only reason this scoped shit exists is because the average front-end developer doesn't understand how CSS works anymore.
You just don't know how to cook CSS modules. The best CSS modules comes served with Typescript and vscode plugin css-modules-typed. You will never miss if some className was removed by accident, instead of getting ` in production. Best dead code elimination of unused classes in CSS I ever had. No more bloated css sources! Maintainability and durability is rocking solid.
@@justfly1984 if a class breaks something visually, that should be spotted by a test. If you're strict about naming conventions, you never have to doubt anything about what some class will do or where in the node's tree it needs to be applied to. You only get that if you have BEM names. Modules will make devs write crappy names that are hard to humanly parse especially when they vary from file to file. Also CSS realistically doesn't map well 1:1 to components. Often you need to change the style based on where a component is used or what set of children it has. When the app grows, maintenance becomes a PITA. The CSS codebase will be multiple times larger than it needs to be. Like I said, this is fun only as long as you're not forced to make a global change.
@@RmNrIHRoZSBDQ1AK BEM is designed to make your CSS modular and reusable. It does that via prescribing naming conventions to ensure there's no conflict with other class names. IMO CSS Modules removes the human element of BEM - remembering the naming conventions and patterns - and lets Webpack and code do it for you. There's no restriction to having one button.css CSS Module and reusing that across multiple pages and components. Usually you don't want to do that anyways. Also the hardest thing to reason about with purely global CSS is knowing what class names are being used or not used anymore. By default the coupling between CSS and HTML is implicit and near impossible to automate with code. Using CSS Modules makes that coupling explicit and reduces the complexity of finding where CSS is being used in HTML. Also...if you like CSS more than CSS Modules - that's fine! If you're happy with that, then keep doing it! I do think CSS at scale, for a large team and application, does start to fall apart. There's only so much you can rely on human effort to maintain it before you need to start relying on computers. But I love the debate! Thanks for raising it!
@@hswolff I think the use case of one component being used within different components where it has to look just slightly different is way too common for purely scoped CSS to be viable. You could do extenders (e.g. in Sass you have a separate CSS base file you import into each component's CSS), but how is that different than a global CSS? Any kind of modification to a child's CSS has to be hacked around with JS sending down props or such. Lastly, just finding things is hard. If I use normal CSS, I can inspect the DOM and I'll know exactly what file to look for. No need for grep-ing the source. The only benefit to CSS modules is machine optimization, but I'll take readability and maintainability over that any day. I do think global CSS is more maintainable because it's more readable, but I accept that developers who haven't got a strong background in CSS would think otherwise.
I think your argument holds pretty solid. The Benefit of modules really seems to be able to import components from libs and not include a css file to make it work which might have undesirable side effects. But I totally agree that cascading is important and better than exclusive modules. Though I don’t know that I agree they are easier to find.
Rename the file App.css to App.module.css. Next, rename the import from import './App.css' to import styles from './App.modules.css. Finally, anywhere that you use a className, be sure to access the styles. So instead of writing className="App" you would write className={styles['App']}
@@berlino5563 100% correct! In that example you could even write className={styles.App}. I wanted to show that using that file extension wasn't required by CSS Modules - just by create-react-app.
css rules still apply, so inline styles take precedent, but I personally recommend swapping out classes instead of injecting direct styles to the element.
This is such a good example, a lot of people are saying bem, but they fail to realize how overcomplicated bem itself can become in large multi page sites. According to me, this approach is the best for a dev cruising through codebase.
When I started to hear this css modules. I thought that it doesn't make anysense. But talking about components and no thinking the name classes is the best part of this. Just create what really is important. And forget the names and cascade problems... 💪💪
As much as i love the content, I cannot understand why you didn't include "Part 2" in the title. It's a series however title doesn't reflect that and it's very confusing for new viewers.
This overview saved me. I was going crazy trying to change CSS.
I'm so glad it helped! Let CSS be!
Very very nice explanation like always, so much value in your videos, is bananas !!! This is one of the best frontend channels
When do you think we can / need to use CSS modules?
Amazing explanation! Thanks.
Love these videos! Thanks for the content.
Thanks for watching!
If I would have seen this video 2 days ago. It would have saved me 2 days of debugging 😂
Nice Explanation Thanks a Lot !
The point of CSS isn't that every single bit has to be scoped. It's the exact opposite; it should enable your entire application to conform to a unified visual style. It **should** cascade. It's awesome precisely because it cascades.
CSS modules make it hard or even impossible to share styles. Sure, it's all fun and roses initially when you're building from scratch, but once you start refactoring and changing components of your app, you realize how stupid this shit is. Well structured BEM CSS will always be easier to work with and maintain. The only reason this scoped shit exists is because the average front-end developer doesn't understand how CSS works anymore.
You just don't know how to cook CSS modules. The best CSS modules comes served with Typescript and vscode plugin css-modules-typed. You will never miss if some className was removed by accident, instead of getting ` in production. Best dead code elimination of unused classes in CSS I ever had. No more bloated css sources! Maintainability and durability is rocking solid.
@@justfly1984 if a class breaks something visually, that should be spotted by a test. If you're strict about naming conventions, you never have to doubt anything about what some class will do or where in the node's tree it needs to be applied to. You only get that if you have BEM names. Modules will make devs write crappy names that are hard to humanly parse especially when they vary from file to file. Also CSS realistically doesn't map well 1:1 to components. Often you need to change the style based on where a component is used or what set of children it has. When the app grows, maintenance becomes a PITA. The CSS codebase will be multiple times larger than it needs to be. Like I said, this is fun only as long as you're not forced to make a global change.
@@RmNrIHRoZSBDQ1AK BEM is designed to make your CSS modular and reusable. It does that via prescribing naming conventions to ensure there's no conflict with other class names. IMO CSS Modules removes the human element of BEM - remembering the naming conventions and patterns - and lets Webpack and code do it for you.
There's no restriction to having one button.css CSS Module and reusing that across multiple pages and components. Usually you don't want to do that anyways.
Also the hardest thing to reason about with purely global CSS is knowing what class names are being used or not used anymore. By default the coupling between CSS and HTML is implicit and near impossible to automate with code. Using CSS Modules makes that coupling explicit and reduces the complexity of finding where CSS is being used in HTML.
Also...if you like CSS more than CSS Modules - that's fine! If you're happy with that, then keep doing it! I do think CSS at scale, for a large team and application, does start to fall apart. There's only so much you can rely on human effort to maintain it before you need to start relying on computers.
But I love the debate! Thanks for raising it!
@@hswolff I think the use case of one component being used within different components where it has to look just slightly different is way too common for purely scoped CSS to be viable.
You could do extenders (e.g. in Sass you have a separate CSS base file you import into each component's CSS), but how is that different than a global CSS? Any kind of modification to a child's CSS has to be hacked around with JS sending down props or such.
Lastly, just finding things is hard. If I use normal CSS, I can inspect the DOM and I'll know exactly what file to look for. No need for grep-ing the source.
The only benefit to CSS modules is machine optimization, but I'll take readability and maintainability over that any day. I do think global CSS is more maintainable because it's more readable, but I accept that developers who haven't got a strong background in CSS would think otherwise.
I think your argument holds pretty solid. The Benefit of modules really seems to be able to import components from libs and not include a css file to make it work which might have undesirable side effects. But I totally agree that cascading is important and better than exclusive modules. Though I don’t know that I agree they are easier to find.
You can pass css variables via the style attribute.
Styled Components > CSS Modules
Can we just follow a naming convention or this approach is better?
Any idea how I can use global SCSS variables, in `module.scss` files?
import with @use 'global-sheet-dir-here' at the top of module file.
Doesn't `--my-custom-css-property: #FFF` work in modules?
So you don't work with css modules anymore for production websites?
Personally, no
@@hswolff Then what do you use now?
Nice video Harry !!! Is there a way to use css modules in create react app without ejecting ?
Rename the file App.css to App.module.css. Next, rename the import from import './App.css' to import styles from './App.modules.css. Finally, anywhere that you use a className, be sure to access the styles. So instead of writing className="App" you would write className={styles['App']}
@@berlino5563 100% correct! In that example you could even write className={styles.App}.
I wanted to show that using that file extension wasn't required by CSS Modules - just by create-react-app.
Hello I got a question :
Can you overwrite these styles with javascript?
Thank you
css rules still apply, so inline styles take precedent, but I personally recommend swapping out classes instead of injecting direct styles to the element.
LESSJS yo!
Good video! But I much prefer css-in-js tho :3
Hehe, so do I! Stay tuned :D
Хороший контент
Never underestimate an engineers ability to over complicate the simplest things lol
This css-modules, is a disaster waiting to happens.