38. Building with Web Components

Ben: Back in high school I was very involved in cable access, and that got me involved in video. And so in college I started as... I wanted to do some 3D animation, and I kind of coupled that with some comp sci, but very late into that game I found multimedia. So just pairing computer science with actual visual graphics really got me interested in this space, much more than just coding against a terminal and watching output. So just getting all that stuff put together for me really, really created a passion around that. So very early in my career, I was doing CD-ROMs and stuff in Macromedia Director. Then I transitioned over to Flash, and then as many people's story might be, 2010, 2011 is really when I started picking up a lot more different technologies as people were pushing back against Flash.

Ben: So I mostly got into... HTML5 was the big term then. I had a bunch of previous web development experience, but that's kind of what I went all in, in addition to a few other technologies, including Android, iOS, native stuff there. And I did some C# because we had an Xbox project. So it really just kind of ballooned out from there. But I really like this idea of coding for the web, developing for the web because everybody can consume this, and it's such a short barrier to entry. So yeah, I'm a web developer now.

Jamie: It seems like throughout your career, your approach has very much been about putting tangible things on the screen and making really interactive things.

Ben: Yeah. And I think that feeds a lot into kind of what I like to do at Adobe. I'm a design prototyper at Adobe. And I've done testing before, and it's great. I've done continuous integration before, and that's great. But when we're talking about what I really enjoy doing, kind of just prototyping is so quick. You get instant results. You get to vet those instant results with people. So I really just like putting things on screen really fast, like you say. So, yeah.

Jamie: And then these days, obviously, web components are a new source of inspiration for you, but what else has got you excited in the current crop of technologies?

Ben: Well, I didn't know I was going to write this book. I was really ready to go all in on VR on the web. And that's taken some time to take off, so I'm kind of glad this book opportunity came my way to write about web components because at the end of the day that's kind of how I'm getting all my projects done. And once you get used to it, just seems like something in your tool belt that's cool to use. So I'm really excited about future-looking things like web VR, or XR, as they're calling it now, because of AR and immersive media. But that's really what I'm excited about going forward. Using web components as a tool in my tool belt to go forward with all these new exciting things is just something I want to continue doing.

Jamie: Perfect. Well, that I think leads us nicely into talking about web components themselves. So perhaps we can lay the groundwork by talking about this book, which I gather has been like a big project for you over the last couple of years. How did it come about? How did this commission start?

Ben: I want to say I've been using... I keep telling people different things, different years that I've been using web components since, but I think it's been 2012, 2013. So around then I wanted to start a new way of doing things. Angular was just... I'd been using it for a while, and then something new was coming out. So I kind of got sick of that churn. So web components seemed a great way to go forward and learn something new that might carry forward. So I started working with web components. I started talking about web components at conferences. I wrote a whole bunch of blog posts on web components. And that was kind of all I wrote about and talked about anymore. And so I was like what's my next step with this? So I decided to approach Manning and offered to write a book for them.

Ben: And at the time... I think this was... It might've been early 2017 or maybe even 2016, they had actually just kind of canceled a book on web components, and there were some books from 2015 they were on the market that were becoming dangerously outdated because standards were changing. So they said no right away to me and said thank you. But a year later, they contacted me because they saw some potential future in web components now, and they said, "How about this book? Deliver an outline. Let's see what we can do with this." So I happily said yes, and we kicked off this book.

Jamie: So I think it's fair to say that your interest in web components has been something of a long bet, but it's really paying off right now, as they're starting to be adopted en masse, and various different tools are being built atop web components to enable more developers to use. So your timing's good.

Ben: Yeah, it really is. And I might've been too early if I had gotten my way, but I'm glad it happened this way. So, yeah.

Jamie: Great. So I gather the book is for anyone from people who are absolute beginners with web components through to people who maybe have encountered previous incarnations of them. Could you talk us through the structure of the book and how people are intended to read it?

Ben: My target audience is really kind of beginner to intermediate folks who they know how to work with HTML, JavaScript, and CSS and have done maybe a few projects. Maybe they've done jQuery or tried their hand at some frameworks, and they want to know what the deal is with web components. So it kind of speaks to how I structured the book too. I'm a big fan of not just like telling people what to do. I like to let people arrive on how to do stuff by themselves almost. So what I like to do is I like to break concepts down and really tear them apart and say this is something that fails, this is why it fails, and this is something that works, and this is why it works. And we came from a point of failure, and I like learning that way, kind of that exploratory learning. So that's kind of how the book is structured.

Ben: So we start right away with building you up with a custom element, a real simple one. And it's just a custom element. No shadow DOM, no nothing. And we do things kind of a wacky way because we haven't learned all those concepts yet. So we go from custom element to importable modules, ES6 modules, and then we take that to template literals to store your HTML and CSS. And then we build up the shadow DOM and keep exploring from there different ways to create components, including templates and building and testing. So it really builds up in that way. I like to think it really just goes deep and just explains to you. And it doesn't explain to you. It lets you experience just what doesn't work and what does.

Jamie: Right. So tell us a bit more about the process of researching this book. You obviously were involved in using web components and I guess possibly an influencing the design of them for some time. Did you find you had to do a lot more research into the stack itself to flesh out this book?

Ben: I did a lot of research. I don't know if I influenced so much of the design. I think we just converged on the same spot when the book came out and where web components were at the time. So back when I started this book, it would've probably been smart at the time to write mostly about Polymer, the Polymer library. And that's just not where we are right now. And back when I started writing, yes, we were in a place where there were three kind of standards that were rolled up in web components. There was the shadow DOM. There's custom elements, and then there was HTML imports. And HTML imports were kind of your entry point into web components. But the HTML imports have kind of fallen away. Browsers haven't picked them up. So the whole process of creating web components today have changed from where we were back then.

Ben: I kind of went with my gut and departed that way early, didn't follow Polymer, and kind of worked out my own workflow, I mean, especially with template literals to store your HTML and CSS. That's kind of where I went instead of all those places. And I was really hoping it worked out because it seemed like the best way. And then when HTML imports kind of, they decided it wasn't being supported, I was like I think I might be onto something. And then from Polymer, the Polymer team came out with lit-HTML with element, and that was kind of the convergence point where we were kind of in sync. And I didn't talk to them, but that's kind of where we landed. And I think that's kind of the future trajectory of web components.

Jamie: Could you explain what Polymer is a little bit more and then also what lit-element is?

Ben: Yeah, sure. So Polymer, when web components first started, when when Google shipped [inaudible 00:10:03] of all these standards that were... It was really geared to be experiment in Google Chrome for people to adopt these standards. And the problem was, it was they were kind of hard to work with. It wasn't easy to work with other browsers because they weren't shipping, especially the shadow DOM. It's really hard to support the shadow DOM just through a polyfill. So there needed to be a lot of work done to help people along, to support Google, to support people trying to have a say in this experiment.

Ben: So the Polymer library came along by Google, and this was around the same time as Mozilla X-tags. So the Polymer library kind of wraps up some polyfills, and they kind of said "This is where we want web components to go. We realize this isn't where we are right now, but we'll give you the tools, the Polymer tools." It's almost a framework, I guess. And that was the entry point for most people working with web components. And there was a little too long of a time there where Polymer was almost synonymous with web components. And web components are a standard, so you don't want that to happen. Polymer 1 became Polymer 2, and then Polymer 2 became 3. And now they're stopping development on Polymer, not for bug fixing and everything else. They're still supporting Polymer 3. However, what came out of that project is they scaled down Polymer a lot because we're at a place right now where the web standards are in a place where it's supported by all modern browsers. And so there's only so many things you need right now to actually get started with web components.

Ben: And lit-HTML is one of those tools. So lit-HTML supports declarative programming, kind of like the design pattern that you'd be familiar with if you are using React. So taking a model, some properties, and if anything changes in that model, you re-render the DOM. Well, you can't do that well if the DOM can't be diffed because you don't want to render the whole thing over and over and over again. You want to only render what changed. So lit-HTML helps you do that. It has some other niceties like for repeating elements from a list or something and click handlers and mouse event handlers, all within there. It's almost like working with JSX, except there's no JSX. It's all template literals and lit-html to help you out. So the rapper above that is lit-elements. So lit-element expands upon this notion of your web component extending from HTML-element, which is the core. It's the base class that you'd extend web components from if you're running web components. Lit-element extends that and kind of wraps things up in a even more easier way to use web components. So that's what the Polymer team is up to right now. And they're going to keep going along that same trajectory just to kind of make a whole bunch of things to just to help web component developers out.

Jamie: I mean, it's interesting as well that Polymer and the web components spec were evolving and changing while React was exploding in popularity and kind of changing the way people were even approaching writing components. So I guess the spec and its authors had to adapt to that changing landscape as well.

Ben: Yeah. I'm not certain that the actual standard adapted to change with the React. It's more like you have this base set of standards, and to meet that demand that this design pattern that all React developers seem to love, you create this thin library. I don't even call it a library. It's like a utility class with very little stuff in it, and then that helps you get up to speed with the React developers. So it kind of goes in layers. And I really appreciate that approach because you can peel back the layers, lit-element to lit-HTML. You don't have to use lit-HTML. You can go to vanilla web components or even use a different ecosystem. You can go like Ionic and their stencil compiler or the Salesforce tools. So web components are kind of branching off in many different directions. And the Polymer chain is probably the most popular one of those right now.

Jamie: So, well ,it's been really interesting to deep dive for the past few minutes. But let's zoom out a little bit. And I'd like to hear a little bit about what you use web components for in your work.

Ben: Because I'm doing prototyping, I'm not necessarily shipping out anything to production right now. So at Adobe... I can't get into the specifics of what I'm working on, but I've been doing some prototypes that mix like a 3D canvas and a 2D UI. I've been working on other canvas-based things. And that kind of extends to the side projects I like to do where I really do enjoy working in 3D and just having that 3D canvas that has... I can wrap that up in a web component and make it have its own API, and then the other 2D components off of the side can all talk to that. And they work so well together. And yeah, so I mean, that's the type of things I'm passionate about right now working with.

Jamie: That's really interesting. It sounds like it's a way to give a kind of declarative API to these 3D and 2D pieces, almost like building your own toolkit up out of web components.

Ben: Yeah. It's also a way to wrap up this crazy complex functionality that maybe you just don't know. There was one project I saw... I actually don't even know his name, but halvves on Twitter. He's this author of the Shader Doodle Component. And Shader Doodle is this thing. If you're familiar with Shadertoy, you can kind of write your own shaders and enter them on this website. And people are doing some amazing things, but it's all on this website. And this person that I was working with, they wanted to create a web component that did this. And it's hard working with WebGL. Not many people know how to do it. So just encapsulating all that in one place, a web component that you could then just use and throw your own shaders at locally is something that he put out there. And I kind of helped a little bit with, but he did most of the work. And that's one of the things I really like about web components, where you might have this rocket science knowledge of things, but you don't want to expose that to people. You just want to give them an easy web component to work with. So that's basically one of the things I love about web components.

Jamie: That leads on naturally to another question I have, which is how web components have changed the way that you work with other people on your team and beyond?

Ben: It's an interesting question because as a prototyper, I don't work with many other developers, maybe one or two other developers at a time. Mainly I'm working with designers myself and putting all the pieces together. It really does change how I work with designers, I feel like, though, because when I'm working as a prototyper with a designer, the final design isn't done yet. It might not even be started yet. So we just get started on something. I'll create some components. I'll put them together on a page, and the designer might be like, "Hey, this component doesn't work well over there. It needs to go over to this other place." So it's really just a matter of moving a component over to another piece of the page. And it doesn't really take that much effort because they're so encapsulated. Normally there might be nightmares with CSS trying to move stuff, but because components are so encapsulated, if I made the job easy, my data models and stuff, it's really just easy to move a component from one place to another.

Jamie: This is a pretty key distinction. The fact that shadow DOM is now comprehensible and easy to use I think will be a really refreshing change to a lot of people not to have to worry about your styles from one place affecting a component from a completely different place.

Ben: Absolutely. And I got to say not even just styles. I feel kind of dirty about it, but I've been using ID a lot more now. And you can use an ID attribute in a component and just call everything by ID. And maybe you style them that way, but you can also query select getByID in that component, and you don't have to worry about the rest of the page. So it's really amazing.

Jamie: And how does this work with passing events around between components? Can events escape a shadow DOM?

Ben: Absolutely. Custom events. So events can escape. You need some... Let's see. They need to bubble. I think by default they don't bubble necessarily. So you need to turn bubbles true on. And there's one other flag I can't remember. It's an attribute. Buy my book, you'll know what the attribute is, but I can't remember it off the top of my head right now, but there's totally easy. You can do custom events if you're just creating your own events, and mouse events do bubble. So yeah.

Jamie: I happen to have read a bit of the book as homework. Is it the composed property?

Ben: Composed. Thank you. I was thinking components, component, no. Yes, it's composed. Thank you.

Jamie: So thinking more about the shadow nature of components, it seems like something that would be very well suited to a design system like a design toolkit to be consumed in other applications. Have you seen much of that out in the wild?

Ben: Yeah, it's great for design systems but it makes it a little harder upfront, for now anyway. If you think about a design system like Bootstrap. Bootstrap is this whole system, and all the CSS has started at the root of your page, and it kind of spiders up, and the CSS affects different elements on your page. And that's kind of how design systems have been. And that does really doesn't work for the shadow DOM because you're not going to be able to query select components deep into your page like that. So it kind of shuts out approaches like that. But I think that most modern design systems have moved away from that. One of those is Adobe's design system, Spectrum CSS, which it's open source right now. So I've been kind of working with that. I have an article about it.

Ben: Basically Spectrum CSS... And I'm sure a lot of other design systems that are modern, they kind of store a lot of stuff in CSS variables, which actually you can use them anywhere. Anything that you have nested, they reach beyond the shadow bounds. So you can use those. There's some efforts going on for... Because you don't want... These CSS variables, you want to wrap up bigger phrases than just little tiny CSS variables. So there are some proposals going on that Chrome will adopt part in theme. But even beyond that, right now we're kind of writing... There's some build systems that are going on to inject these CSS rules into each component. That's kind the the hacky way we're doing it right now. But these modular design systems, the way things are going right now, I feel like it makes that job a lot easier. So there's an emerging story. There wasn't a good story in the past, but I think we're moving towards something that's a little better in terms of design systems. And once we're there, it'll just be amazing, I think. And one of the Google news, I was just at a web components meet-up in San Francisco last week, and I know on Google's end, the Polymer team is going to be working a lot more closely with the material design system. So that shows promise as well. So it's a story that's ongoing.

Jamie: Interesting. So say your team had an existing CSS-based design system, and they wanted to put it to work or encapsulate it within web components. What are the ways of doing this? I've heard something about constructable stylesheets, but that's about the limit of my knowledge. Can you explain a little bit more about this side of it?

Ben: Yeah. I wrote an article about constructable stylesheets with Spectrum. Basically what's going on there is, so constructable stylesheets are a Chrome-only feature, but it is easily polyfilled. The idea there is you would load up a stylesheet as a CSS stylesheet object, and you can actually use that object and adopt it into anywhere, including your document, but most notably, your shadow DOM of any component you have. So you can just look that up, adopt it to the shadow DOM web component, and adopt that same stylesheet with the shadow DOM on another component, and you're using that same stylesheet, loading them up, repeating ties, not overloading your memory with multiple stylesheets. You're just using that same instance over and over again in multiple stylesheets. And it worked really well when I tried that out with Spectrum just because of really how modularized it was. And I expect the approach would work for other similar design systems.

Ben: And I kind of wrote a wrapper around that so that you can make that request and say hey, fetch me that stylesheet. if it's already loaded, go into my dictionary and just get the cache version of that. So there's some helper stuff I had to write around that, but going forward there's something called CSS modules. And CSS modules will let you do ES6 module importing of stylesheets. So right in your component, assuming this feature ships soon, you can just say import my CSS, use that, adopt the stylesheet, and that kind of completes that constructable stylesheet story in a big way. And I can't wait for that day to come.

Jamie: Given the spec is now stable and very approachable, given that the tooling story is making it even more approachable, it seems like we're fast approaching a point where people will be creating lots of useful web components for everybody to consume. Where do you see people sharing these? Do you think it will happen via npm? Or do you think there'll be some other approach that takes hold with web components?

Ben: I think it's a tricky thing to say because... Okay, so take a very straightforward component like Google's model-viewer component. It's a component that wraps up a 3D model and allows you to interact with that 3D model and just show it on your screen. That's something that's easily shareable because it doesn't really have a UI. So yeah, absolutely, wrap that thing up on npm, ship it. Everybody can pull it in and use it. I think that the story is a little more complicated when you talk about things that actually have a design and a UI behind them. And yes, you can wrap up a component that has a UI design, ship that on npm, and that's cool. But I feel like a lot of people would want to change up that design. So you really have to be careful about how you expose what needs to be changed or like what design elements needs to be changed of that component. So I'm not sure at anybody's solved that well in any framework really either. So yeah, I think we'll see on that.

Ben: So Salesforce, I just saw a nice slide from the same meet-up I went to last week how they have 1 million web components right now. I'm not sure where... I don't know how they're delivering them, but that's a pretty interesting story as well. Yeah, I think we'll have to wait and see on that.

Jamie: Yeah, I mean, with Salesforce, the way that that works, I mean, one of the use cases for lightning web components is on the Lightning platform itself. So this is the user interface that people see when they're interacting with the Salesforce platform. And it's highly, highly extensible and customizable. And the idea in that environment is when you want a custom piece of UI, you write a lightning component using the Lightning web component's tooling, which is basically just writing a web component. And it gives you all the benefits of encapsulation with the shadow DOM, but also allows you to use the existing Lightning design system web components in there too. So I think that's what they're referring to when they talk about that. So there's a big active community of people programming their Salesforce instances today using web component technologies.

Ben: Yeah, and I think that's kind of the point I was inadvertently running into, which is each platform is going to have their own way of... If you're involved in that platform or ecosystem, they're probably going to have their own way to deliver. There's another web component ecosystem called Vaaden. And you can just go in and download Vaaden components off their page. I'm pretty sure you can get them off npm as well. But I think right now what we're seeing is very platform or ecosystem centric. It'll be interesting to see how we kind of emerge out of that into something a little more general use I guess. But I guess npm is probably the best place we have right now to ship them.

Jamie: So okay. You've given us tons of great details about the history of web components, the state of them today, the kind of cool things you can build with them. It's nice reading your book. What advice do you have for people looking to learn how to use web components?

Ben: Yeah, I mean, so my book wasn't even the first book. There's another book by Cory Rylan. I've said this before. I bought Cory's book initially just to see oh, he wrote the first book, and I didn't get to it first. So it was kind of like a little a competition in jest there, even though I never met him. But I picked up his book. I bought it, and he touches on a lot of different points than I do on books. So I think his book is a great addition as well. And it's a short, quick ebook read. So that's a great book. Another place you can go to, the Polymer Slack channel. It's Google owned, and they do talk about lit-HTML and lit-element a lot there. But it's a great resource. People are totally willing to help you out.

Ben: Google, the Polymer team specifically, is doing a great job just supporting the web proponents community. Going on the web, reading recent articles... I would say in 2019 there's been so many good web components articles, and just make sure you look at the date too because if it's from 2015, it's probably too old. Even stuff that's 2017 is probably too old at this point. The web component community has been just so amazing in just supporting each other and coming together, putting out learning material. It's been great. So I would suggest all of the above.

Jamie: Sounds great. You've already touched on this a bit, but I think an interesting way to wrap up would be to ask you where do you see web components and related technologies and related emerging specifications going in the next five years?

Ben: There's going to be a lot to that, that CSS story, that design system story going forward with the parts and the themes, constructable stylesheets, CSS modules. So that's something that you're going to hear a lot more about going forward as Chrome starts shipping features, and hopefully those features trickle to other browsers. Now, in terms of where the whole web components ecosystem is going to go, maybe this is too much of a rosy view, but again, at this web components meet-up last week, Justin, the author of lit-HTML, lit-element, he was talking about how React will... There's going to be a breaking change... If I get this right. Please... Hopefully I'm not wrong on this. There's going to be a breaking change that makes web components more easily slide into the React framework. And this is pretty significant because one of the resources you can go to right now, Custom Elements Everywhere, really defines how web components work in a variety of frameworks and a variety of situations. And the story is closing in that web components really are on the verge of being able to easily be inserted anywhere you go.

Ben: And this has major implications in that maybe we won't have framework wars anymore. Maybe a React component can work in my Angular project, an Angular project can work on my web component. We're just breaking down barriers at this point, I think, and I think this standard of web components is going to be huge to break down these barriers. And I think that's one of the major directions that we're going to see web components in the future just breaking down these barriers and going forward with all these different ecosystems like lit-element, like Ionic's web components, like Salesforce's web components. So we're going to be seeing a lot more web components and other frameworks playing on equal playing fields, I feel like. So I think that's one of the major things I'm excited about.

Jamie: Fantastic. Well, on that note, thank you so much for joining us on Codeish. And I should mention finally that we have a very special promo code for the book, so if you go to Manning's website, Manning Publications website, and use the code podish19, P-O-D-I-S-H 19, for a very lovely discount and go ahead and buy Web Components in Action by Ben Farrell. Thanks Ben.

Ben: Thank you.