Right, the awesome part about Web Components is you use it like any other element! So just like you'd use <button>My Button</button>, you can use <my-button>My Button</my-button>. You're really making your component part of the system, rather than sitting on top of it.
Mixins are definitely where SASS is untouchable right now, and if you use them a lot, web components won't change this. That said, CSS variables help, and you can build the css with javascript, so you can do all sorts of things because you can make JS functions to return CSS. Mixins + web components is great because you can apply them at the component level specifically.
Part of why you need so much organization for CSS is because you have to be thinking cross-functionally always. I highly recommend CubeCSS for an example. Web Components help you focus on the components individually, so you don't have to be worried too much about organization past what you'd naturally do with a file-system. For me, I find an organic process works best. I start with a folder just called /components, and then when I have too many components around a specific feature, e.g. message-stream, message-post, message-item, etc. I create a folder called /components/messages.
\
A more difficult process is figuring out what should be a component and what shouldn't be, or where one component begins and one ends. That's a lot harder and really just takes experience. But that's true no matter what you build with whatever tool you use.
You can package them! The consensus seems to be monorepos with an npm package for each one. Check out material web components for an example: github.com/material-components/mat...
Right, the awesome part about Web Components is you use it like any other element! So just like you'd use
<button>My Button</button>, you can use<my-button>My Button</my-button>. You're really making your component part of the system, rather than sitting on top of it.Mixins are definitely where SASS is untouchable right now, and if you use them a lot, web components won't change this. That said, CSS variables help, and you can build the css with javascript, so you can do all sorts of things because you can make JS functions to return CSS. Mixins + web components is great because you can apply them at the component level specifically.
Part of why you need so much organization for CSS is because you have to be thinking cross-functionally always. I highly recommend CubeCSS for an example. Web Components help you focus on the components individually, so you don't have to be worried too much about organization past what you'd naturally do with a file-system. For me, I find an organic process works best. I start with a folder just called /components, and then when I have too many components around a specific feature, e.g. message-stream, message-post, message-item, etc. I create a folder called /components/messages.
\
A more difficult process is figuring out what should be a component and what shouldn't be, or where one component begins and one ends. That's a lot harder and really just takes experience. But that's true no matter what you build with whatever tool you use.
You can package them! The consensus seems to be monorepos with an npm package for each one. Check out material web components for an example: github.com/material-components/mat...
Thanks, Brantley! I’ll play with this next week!