This is an interesting article. I rarely use JavaScript, but this seems like one of the better reasons to use it. I have a whole bunch of questions, but if you don't mind, I would like to ask you a few high-level questions:
Do you have a working example (CodePen?) of how one might incorporate the component into HTML?
One of the things I really like about SASS/SCSS is mixins, especially for creating responsive sites (update the font, remove elements, etc.). Would this now be something you have to handle with JS logic?
Do you have thoughts on best practices for organizing these components? For example, there could be many components on the page for menus, buttons, etc. Is there a best practice for naming the files and how you might store them in folders? I'm specifically thinking about some of the loose standards proposed for CSS, like this: elad.medium.com/css-architecture-f...
How do you propose sharing these components easily? I am wondering, do you put them in Gists or package them in some way?
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...
on 3.) I'm using Svelte to write my components. There every component has it's own file, holding JS, HTML and CSS.
on 4.) In Svelte when the component bundle is build, everything is merged in a single JS file. On the target page you only need to include this file and instantiate individual components using their tag e.g.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is an interesting article. I rarely use JavaScript, but this seems like one of the better reasons to use it. I have a whole bunch of questions, but if you don't mind, I would like to ask you a few high-level questions:
Thanks again!
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!
Some thoughts from my side:
on 3.) I'm using Svelte to write my components. There every component has it's own file, holding JS, HTML and CSS.
on 4.) In Svelte when the component bundle is build, everything is merged in a single JS file. On the target page you only need to include this file and instantiate individual components using their tag e.g.