Components have become the go-to method for structuring and composing UIs on the Web. Usually this means relying on a JavaScript framework such as React, Vue, or Angular. But it turns out that there is a standard mechanism for creating components built into browsers. Ben Farrell who wrote a book on this mechanism - Web Components - joins the panel to explain what they are, how they work, and why they are a great, light-weight alternative to JavaScript frameworks.

Panel

Guest

Sponsors

Links

Picks

Special Guest: Ben Farrell.

Sponsored By:

DAN_SHAPPIR: Hello everybody and welcome to another episode of JavaScript Jabber. Today on our panel, we have Amy Knight. 

AIMEE_KNIGHT: Hello, back from national. 

DAN_SHAPPIR: Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. 

DAN_SHAPPIR: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, coming at you live from cloudy, pleasant Grove.

DAN_SHAPPIR: And our very special guest, Ben Farrell. Hi, Ben. 

BEN_FARRELL: Hello, I guess I should say where I'm from too. It's Oakland, California. Nice to meet you. 

DAN_SHAPPIR: Great to meet you as well. And I forgot to mention where I'm coming from. I'm coming from Tel Aviv, where like I said to the panel before, winter has finally arrived and it's a really cold 17 degrees here, but it is raining, so it is winter. At least it counts as winter in Tel Aviv. Anyway, so Ben. Today we want to talk with you about various things, I think, but most significantly about the components, because I believe you've written a book about it. 

BEN_FARRELL: I have. But yeah, 

DAN_SHAPPIR: before we begin about that, can you tell us a little bit about yourself? 

BEN_FARRELL: Well, let's start with this weather thing. I am a transplant to California and it's around 50 degrees here. So a little colder than Tel Aviv, but I'm totally a wimp now because I'm from the East Coast. I'm usually better in the cold weather than this and 50 degrees is nothing, but now I'm just a wimp, so I'm feeling cold. Anyway, my name is Ben Farrell. I'm a prototype red adobe. So we work in that like middle ground between design and developments know, bring designs to life and see how they fare in the, like, as an actual product. So that's what I do for a living. On the side, I explore lots of things. And lately it's just been a lot about web components. So I've been, you know, presenting on web components, blogging about them, and it culminated in me writing a book last year on like these standards that make up web components. So I'm really happy that it's in my tool belt now so I can explore like lots of different technologies, all with using you know, web components is the basis. So that's kind of where my head is right now. 

 

Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production, and you can go sign up at devchat.tv slash premium. 

 

DAN_SHAPPIR: Cool, and I've just posted the link to the book so our listeners can find it in the show notes.

BEN_FARRELL: Yeah, I should mention it's Manning Press, by the way, Manning Publications. Web Components in action. 

DAN_SHAPPIR: So yeah, Amy. 

AIMEE_KNIGHT: I'm going to say, I want to start off by asking a question because I don't know, whenever I feel like Web Components still get a bad rap and people kind of like turn their noses up. So before like before we get started and possibly lose listeners in your best 60 seconds, why should people listen to the remainder of this episode? Why? What's different about Web Components now you know, or like almost 2021 that people should be interested. 

BEN_FARRELL: Well, for me, Web Components have finally gotten to the point where it's not, it's not exciting for me anymore because it's a stable technology. Before I was excited about Web Components because they were kind of emerging, like the browsers didn't support them. You need these wacky polyfills. There was all sorts of different directions people were taking with them. And if you were developing with them, like prior to last year, maybe two years ago, it was kind of a mess. And that's just how standards work. So as things have come together, it's a lot more stable of a picture and something you can use now. So to me, it's just like web components are kind of boring now. It's, it's, it's the stuff that people are building with web components. That's exciting. So that's my take on, you know, why if you had a bad taste in your mouth about web components before you should give them a second look. 

AJ_O’NEAL: I love hearing that things are boring. That's exciting to me. 

BEN_FARRELL: I know, right? 

AJ_O’NEAL: When a technology gets boring. When commits stop going in, when the project is stale because it's complete, that's a great time. 

BEN_FARRELL: There's goodies on the horizon to enhance this thing, but I think- 

AJ_O’NEAL: No, no, no, no, don't ruin it for me. Don't ruin it for me. I was getting bought into the idea that this was something usable and practical. 

BEN_FARRELL: I'm just trying to have it both ways, dude. 

AJ_O’NEAL: Okay, but go ahead. What's exciting on the horizon? I'll just close my ears.

BEN_FARRELL: No, I mean, it's... I mean, LitElement is this helper library that's really taken hold of for Web Components development. So there's helper libraries, there's upcoming specs, there's adopted style sheets that are actually in Chrome now. There's HTML templating where you can... It's not HTML templating. It's basically you can put an entire shadow root in your markup without even having to write any JavaScript. So that's on the horizon as well. On the horizon as well, you should be able to import CSS as like ES modules soon. So there's a whole bunch of things to make this experience better, but I feel like it's really stable right now. 

DAN_SHAPPIR: Yeah, but we mentioned a lot of technical terms that might not be familiar to listeners who are less knowledgeable about what web components are. 

BEN_FARRELL: True, yeah. 

DAN_SHAPPIR: Maybe we can rewind a little bit, talk about web components. What is this thing? 

BEN_FARRELL: Yeah, yeah. Well, I mean, I guess riffing off my shadow root name drop. So the shadow DOM is probably my favorite web components feature. It's one of the two main ones, I think there's custom elements, which you can just say, I have, I have a JavaScript class and this class defines how I want this custom tag to work on my page. So I can make my own custom tags, drop them into HTML. And as long as like the JavaScript instantiates that tag, assigns a behavior to it, all is good. The other part of web components is this whole concept of the shadow DOM. So. The Shadow DOM is this encapsulated, you can almost think of it as an iFrame, but without the bad taste in your mouth. It's an encapsulated space where, you know, JavaScript can't easily be pierced in. So you can't come in from the outside and select DOM elements in there. Everything has to go through really a well-defined API. My favorite part about the Shadow DOM though is CSS. So CSS doesn't pierce through the Shadow DOM either. So I could have a button in my web component behind the Shadow DOM, and I could just style it with a button selector. That's all I need, because this button selector, it won't affect other buttons on my page outside the Shadow DOM. So like style is really encapsulated in this one place, and it really kind of leads you to just use simple CSS. You can use simple CSS again, without having to worry about these large like SAS and less systems, just because everything's so encapsulated and just works so well in a tiny scope like that. So those are the two main aspects of Web Components. 

DAN_SHAPPIR: Now, it seems to me that Web Components, at least in the past, I don't know, you tell me how things are exactly now, but they seem to be in competition with frameworks, with the various frameworks. So the various frameworks like React or whatever, you provide their own mechanism for defining components. You know, if you're working in React, you literally create your own quote-unquote DOM elements, which would have been either, again, also a JavaScript class or more recently just JavaScript functions using hooks. So how is our web components different or better than the componentization mechanisms introduced by various JavaScript frameworks? 

BEN_FARRELL: So it depends on who you ask. Saying they're better or worse than using a framework, I come from the place where I stopped my framework explorations with Angular because I felt I'm spending too much time learning frameworks and dealing with frameworks to get to the actual, like my actual project. And so I had this whole notion in my head, I wanna go framework lists and things were kind of a mess. So web components coming along and providing a standard way to make components without this massive framework that you need to buy into and learn, it's a huge win. But if you already know React and you already know how to get things done in there, you might say, well, I already have that. It's already good to do a lot of things I can do in React. I need to add helpers and libraries onto the basic set of web component standards. So that's why people are kind of saying, well, web components are no good. They're just, there are a couple of different technologies that might make your life easier if you don't have a framework, but I have React and it's all good. So there's a couple of different points of view coming across there. But the deal is, too, if you're a framework author, maybe React someday or maybe Vue someday. I think Angular, it's been a while since I've done anything with Angular, but I think Angular might be adopting this way of making web components because it's standard and all these other frameworks can follow. And just because you make something, a web component with these standards, instead of the React way, it doesn't it could be at the base level of your framework. And you could be using React someday far in the future and be using web components and not even knowing it just because these components are a standard, they're a standard part of the web. So yeah, two different philosophies. Like you can start with, you can, I like to start, basically I like to start small. I like to go no framework and then see where I go, build up, take in exactly all the features I need. And that might mean bringing in helper libraries like litHTML, litElements. But the other, of course, like the other one, the other way to go is React, where you have everything there for you. There's lots of documentation for it. And I think that's the kind of the difference these days. When people take a look at Web Components, they're like, I have so many options, I don't know where to begin. And I think that's a real problem. And I think we're seeing more and more things pop up, documentation, helper libraries that kind of steer you in the right direction. But that's kind of where Web Components are lacking today. 

AIMEE_KNIGHT: So you said something that makes me want to ask a question, because what you said kind of resonates with how I like to do is just like start. I don't want to bring something in until I feel like I need it. So if I wanted to go the web components route, what's kind of like a signal that maybe it's something I want to, like what's a pain point that you've experienced that then you decide, OK, maybe I want to bring this in? 

BEN_FARRELL: I think the biggest pain point that's been solved by Google's Polymer effort with LitElement Basically, all the rage these days are declarative UIs. I'm late to the game. React kind of popularized these declarative UIs where you have a data model and you render based on that data model. With Web Components, with nothing else, you're probably doing something imperative. You're querying DOM elements and you're saying, do this. Whereas, like I said, with React, you're just rendering based on a model. So that's, and people really like that. I've really started to like that. I can't, now that I've gotten into that mode, I can't see doing anything else with my UI. That's where lit HTML comes in. It's a templating library that doesn't have the virtual DOM overhead that React does. It kind of like does this weird thing behind the scenes where it sticks comments in and into your HTML and like kind of like hand does the differences that way. It's super tiny and super fast, but does let you do this declarative UI stuff. And then of course, on top of that, if you go lit element extends the the web components API, the standard API, and does some extra things for you in terms of managing style, just controlling the lifecycle a little more. So these are the core helpers that I started using every day now just because I started writing my own helpers for this and I realized, hey, I'm just duplicating all this work that they did already and better. So why not just a dot lit element? I'm grumpy that way. I'm like, I don't want to use it. Never going to use it. And then I'd start writing my stuff and I'm like, okay. 

DAN_SHAPPIR: Well, at the end of the day, that's the purpose of frameworks to eliminate some of the boilerplate coding that we would otherwise have to do ourselves. 

BEN_FARRELL: Yeah, yeah. But it kind of starts out like you don't know what you need when you start exploring this space and you're kind of like every little paper cut you get like, I need that, I need that and then it just kind of rolls this big snowball and you're like, okay, I guess I need at least a helper library, maybe not a framework, maybe just a helper library for now.

DAN_SHAPPIR: So just to make sure that I understand, lithtml, and I also posted a link to that, that's basically sort of mini framework on top of Web Components, or is that something else? 

BEN_FARRELL: It's completely standalone from Web Components. I would call it a small utility library rather than a framework. All it does is basically you create template literal string and you can use this template literal string to assign to your divs in our HTML, your div in this case for my case is going to be a web component, but it could be anything. And so when you re-render based on changed stuff in your data model, changed variables, it will only render the differences. So it's not gonna re-render the whole world inside your inner HTML. It's just gonna render those differences. So in that, it functions a lot like React's VDOM. 

DAN_SHAPPIR: Okay, so that was what I was going to ask that it actually is a simple implementation, it sounds like, of a virtual DOM mechanism for reconciliation.

BEN_FARRELL: And I want to say like the, the, the maintainer of that, uh, library that works at Google Justin, he's always going on about how tiny it is. I think it's like something like 2k. So speed like performance and size is just what he's going for. And that's why I think like calling it a framework is a bit too much. Like, I don't think he'd ever call it a framework. He it's, it's like a utility. 

AJ_O’NEAL: So is I'm looking at the docs for this thing and I get confused. Cause when I look at like TypeScript and react script, it's just. You know, it's just confusing to me. And I, so I see this thing. It's like HTML and the back tick and then HTML inside. What the heck is that? Is that, is this like react where it's its own language and then it like spits out JavaScript and HTML, or is this like.