Episode 006: Custom Elements aka Web Components

Web Components are all the rage. Claire answers Steph's questions about them in this episode.

Released: Jan 27, 2021 • Length: 15:49

Also available on Google Podcasts and Amazon Music

In our first episode of 2021, we decided to do a bit of a different episode. In this episode, we talk about web components. Claire has some answers (be sure to check the notes!) and Steph has some questions. Do you have questions? Let us know.

Check out the Episode 006 Notes

Support Word Wrap

Interested in sponsoring the show? Get in touch on our sponsorship form.

You can also become a patron with a small monthly contribution which will help us pay for necessary services to keep a podcast running. Thanks for your support!

Support Word Wrap on Patreon







I'm Claire


and I'm Steph.


And this is Word Wrap.


On today's episode, we're going to talk about web components. Um, I am inspired by this because, uh, there were some hot and spicy Twitter topics lately, uh, talking about certain things that may not be compatible with web components and some that are, and anyway, we don't have to get to that.

Um, but web components are really cool and they essentially brings something that we take for granted in a lot of JavaScript frameworks and they bring them to an HTML and JavaScript spec, um, which is really cool. Now I will say that I am not an authoritative source on what components. I am just speaking based upon my experience. I may get some things wrong and I will clarify them in the notes later if necessary. But Steph is kind of new to web components. And so what she's going to do is she's going to ask me some real questions and I'm going to answer them as best as I can. So Steph, without any further ado.


So Claire, um, how did you, what first attracted you to web components and how did you kind of get started with them?


Well, my first real usage of web components came in my current job, which is a Rails backend front end. Well, if you're familiar with Rails, Rails likes to control everything. Um, the backend and the front end, it's kind of its selling point. And it doesn't really leave a lot of room for JavaScript.

Obviously you can do JavaScript in different ways with Rails. You can make an API with it and stuff, but if you're using Rails to build its views and stuff like that, there's not a lot of room for JavaScript. Um, so you can use a framework called Stimulus, which is kind of like a - like a sugar-y like, you know, put JavaScript sugar on the HTML. That didn't really do it for me.

So I wanted to componentize, um, certain things, uh, certain parts of user interactivity, like a modal or like an auto-complete or stuff like that. And so I came across the project, uh, light element. It might be light element. It might be lit element. I still haven't figured out the pronunciation of it, but it is a project from the Polymer project, which is from Google.

And, something that I read. And again, I will correct myself later on in the, in the notes, but, um, I believe that the web component spec can be used on its own and I've used it on its own, but it is also, uh, thought of as like, you know, it's supposed to be a starting point for a, you know, a small library to like jump off of and, and, um, and extend. So by a roundabout way of saying it's supposed to be extendable.

Anyway. So LitElement is really nice and small, and it takes things that I love from Angular, such as, uh, using decorators and TypeScript. Just like, you know, it's like @property and then you give it like a name and then that's like, like essentially a prop from React.

It would, it maps to an attribute on an HTML element. So you can be like, my-element ID, not you wouldn't actually use ID cause ID is an actual HTML attribute, but, um, I dunno, let's say I wanted to name an attribute Stephanie, it would be @property stephanie, and then I could use that in the component.

So it's a very lightweight way to, essentially add, reusable like React or Angular or, you know, style components that have lifecycle hooks into your project without having to take over the entire DOM. Um, which is something you would probably do in Angular. I've personally never worked with Vue. Um, but it's, it's one of those things where it's like, you don't want to add a bunch of JavaScript to the page.

So, um, that's really how I got started. It was more of a necessity kind of thing since I couldn't really reinvent the wheel right. When I came to my current job and yeah, it, uh, it kind of just blossomed from there.


Cool. So it sounds like you're mostly using it within a framework, but one of my kind of beginner questions when I was trying to just learn more about them and work through creating my own, which I'm sure didn't quite hit all the marks on best practices. But I was finding it hard to piece together, like even from tutorials, like what's all involved with making a web component. And how, how do you make a system of them? How do you make more than one and add it to your project?


Well, the web component spec on its own kind of enforces what's called a shadow DOM, which can be a little tricky, like with interacting with it, with like, you know, just normal JavaScript. But you can think of them as custom elements. That's another word for them. And with elements, you can put elements within other elements. So that's one way that they can interact. Another way is, uh, you can do some similar concepts, like, uh, introducing like a state management, like Redux and stuff and have them, uh, essentially like, you know, message between each other. Using Redux it's it would be pretty similar to how you would write React components I would assume. I've, I've personally never written, written React. I've somehow managed to stay away from that throughout my entire web web development career. That is how I would imagine you do it. So it is pretty similar in that aspect. It just has a very basic API. I believe there's like four lifecycle hooks and that's - that's about it.


Right on. So I remember when web components started to be a thing that was on my radar, I should say a couple of years ago, one of the criticisms and why I didn't look into it too deeply - because I believe the criticisms from people I trusted - was that it was difficult to make them accessible. Do you have any, like tips? Is that still a concern or what do you, what do you have for us on that?


Yeah, so that is a concern of mine. And I actually, that is one of the reasons why I was pushed towards a library instead of using the native spec, because uh LitElement in particular can do something where it essentially renders the component outside the shadow DOM, which I think most of the, the concerns with accessibility come with the shadow DOM, because the way of interacting with it is kind of like you have to like dig into the shadow DOM, and I'm not sure necessarily. And I'm going to do more research after this, this episode, just to make sure, but I'm pretty sure that it's a little harder for screen readers and accessibility software to essentially reach into that shadow DOM.

Uh, so. I think that is one area. And I, and I, I personally fixed that by removing the shadow DOM from the equation. Uh, essentially like I would, anything that I want inside the web component, it like renders literally like a child of the web, the custom element. So like, you know, I want to div inside of it it's like the direct child of the, the custom element. So that helped a bit, but I mean, everything else. No custom JavaScript. It, it, all of those, uh, all of the normal accessibility issues are, uh, still applicable.


Gotcha. So obviously my kind of thing is CSS. And so, um, I know that one kind of crazy thing about them considering its shadow DOM, is that one of the things that can pierce shadow DOM is uh CSS custom variables. Is that how you typically style things or what, what do you use to style your components?


Yeah, so I actually haven't used CSS custom variables in a like production environment, yet. Aside from like a personal project, I haven't actually used them, which is shameful, but. I, you know, the various libraries for web components allow for CSS injection. Kind of like not necessarily CSS in JS because it's like, it's literally like a template string of CSS and you put it within the JavaScript component, but you can also link to external style sheets too.

I do. I can imagine that, you know, like putting, um, variables on the root element or root, uh, in, in CSS variables would be very good because I believe they reached through the shadow DOM, but, uh, CSS in general, doesn't reach through this shadow DOM. So that can be a little weird. And then it's kind of a mental leap would be like, Why is my CSS not showing up in this thing?

Yeah. I don't usually like, you know, hawk, like using a library to utilize some native technology, but I really do think the web component spec is supposed to be used with a library of some sort. And there are plenty of them out there. It just makes it a lot easier to interact with them. And the really nice thing is that a lot of them stay very similar to the spec. So you can rip out the library, if let's say the spec gets better or at least easier to work with.


Right on.

So my single, baby web component that I have is, um... so there was a challenge on CSS Tricks [edit: CodePen] in November I think? Maybe a little bit earlier. They were kind of going through a theme of nostalgia on the web. And so one of the challenges was bringing back webrings. So my one little baby, my one little web component is a webring because that was kind of a pretty - it seemed like a good use case. Because the idea being that people can add themselves to a JSON file and in GitHub. So it can like be interactive and always updating, but it'll kind of update independently from the rest of my code base.

So if you go to 11ty.rocks, then at the bottom, that webring is a web component. So theoretically, also somebody else can use that on their site. So I definitely, really, I mean, to me, the portability seems like a super strong selling point. Um, but do you still have that if you use, if you use a library, like can somebody independently... like if you're sharing it, like among an enterprise, say, can like different parts of enterprise pick up, you know, one off components? Say you figured out auto-complete can they pick that up?


Yeah, you can definitely package them in a way to where you know, that the. I mean, yes, you're right. It becomes a dependency. There are certain libraries out there that do not do that. Like I believe Stencil, um, actually compiles to an actual web component that doesn't have any dependencies.

So yes, there are methods that you can do to make it dependency free. And you can obviously also bundle the library with the web component. Granted that makes the web component a lot larger. So yeah, there are, there are methodologies to, I guess, both sides of the argument of using a library using and not using a library, but really at the end of the day, it is JavaScript and it, as long as you bundle it in a certain way, you know, you can take one JavaScript file and include it on your page and you've got it all. So yeah, I think you've just got to be mindful of exactly how you're going to be using it.

I think if you're going to be doing something like you said, with a webring, um, I don't think I would use light element or LitElement or - see again, I, I get messed up with that. I, I, you know, I would probably think twice to actually use a library outside of just the native spec.

Um, because I think that's where the, you know, being thoughtful with your actions comes in. Yeah. If you're using it in one code base and, and the dependency is always going to be there, it's a little bit less a bar, um, to make that work. So, uh, yeah,


So at my previous position, um, the company was very heavily weighted towards Angular, um, and had 30 plus different product development teams.

So one proposal, or I heard, cause I also have not written Angular. You have. Um, is that Angular now actually, I don't know if exports is the right word - compiles to? - web components. And what, and so along with that, an argument was that a web component could be used, like if we created web components - because my job was also sign system related - you know, if we created web components, then it could be used by whatever else. Your isn't your stack. Like more easily shared.


Yeah. So Angular actually, uh, allows for custom elements. Uh, just by default. You have to add them in a certain way, but essentially they get imported like any other, uh, you know, any other Angular element Angular component. Now, Angular can export web component. Like they're not necessarily web components. They're like, individualized Angular elements. They essentially come still with the Angular runtime, albeit smaller and, you know, they require Angular to run. However, I think the minimum size for them is like 200 kilobytes, which if you use like LitElement, it's like 60 kilobytes.

So like you're, you're not like totally breaking the bank, but, um, especially in an enterprise environment, like that does make sense.

Now, I'm going to have to research this afterward, but I believe React is still a little weird with web components. Um, and they have purposefully not wanted to make the, the, you know, make interoperability better between React and web components. I think it's kind of a competitiveness thing where React was kind of marketed on what web components are supposed to do. And then I see every React project I've ever seen just it turns into it... I'm not going to get into that. Um, but, uh, point is, um, yes, that is the like thought process behind it. Uh, but again, your mileage may vary and it should be very much weighted upon like who the audience is. Um, in an enterprise environment like that I think it makes sense, but you know, it's all about execution and how it works. So, cause it could also go very badly.


Nice. That's all helpful info. I was also thinking that we need to do a future episode. So, you know, usually when we see like somebody have a hot take, a bad take, like it's just a dogpile. We should do a fun episode, um, where we have friendly healthy banter because you enjoy, or at least have written, I think you enjoy it? Angular. And I have written and enjoyed React. So we should definitely do a friendly debate.


I’m looking forward to it!


Well, awesome. Well, you definitely answered some of my questions and hopefully like gave some other folks that are listening out there the - some ideas to look into it more and kind of explore the possibilities. So, yeah, that was awesome! Thank you.


Good! For more information, you can go to webcomponents.org and they have all of the different libraries, um, that do extend web components as well as how to use web components. And there's also a library of web components that everyone else has made. Um, so go there and, uh, have a ball.


Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!

Review the Episode 006 Notes

View All Episodes