Episode 1 of a 2-parter conversation about Web Components. In this epidose I chat with Chris Holt and Rob Eisenberg, UX experts from Microsoft. They're both part of the FAST team pushing forward the web components standards.
Get in touch with Chris:
Get in touch with Rob:
Learn more about FAST:
Don't forget to leave a review of the episode or the entire podcast on Podchasers!
Meet our host, OpenReplay:
OpenReplay is an open-source session replay suite, built for developers and self-hosted for full control over your customer data. If you're looking for a way to understand how your users interact with your application, check out OpenReplay.
Web components. Isn't just one thing. It's really a collection of technologies that are part of the native web now. A collection of web standards. So for example, in HTML, now we have the ability to create new HTML tags, new custom elements, and there's an API for that, that lets us define the tag name and provide a class.Fernando Doglio:
Um, my name is Chris Holt. I'm a UX engineering manager at Microsoft, and a maintainer of fastRob Eisenberg:
Wow. All right. So definitely more complex than I thought it was, but that kind of robust API, like you said, uh, that's not something that comes out that is created or developed quickly. So, um, from what I've seen from what I've read, web components have been around since 2011, something like that. Uh, so Why are we not all using what components? And I know that kind of question was going towards, um, why are we using React or Vue? And I know these libraries and frameworks are not exactly like web components. They, the, I, from what you tell me, web components seems like, the building blocks, you will use to create something like that, but why are they not the actual building blocks for React or Vue or, or any other libraries? You know, built on top of them instead, uh, they go on a completely different direction. What what's missing or, you know, what's the problem or what has been the historic problem with the components. Put it that way.Rob Eisenberg:
Well, I think one thing is while there's a history that may go back to 2011, it wasn't till 2020, that all the major browsers had implemented the standards. So prior to, um, the chromium based edge lunch Uh, in January of 2020, you had to poly fill a large number of these standards, um, uh, on, on edge or I E different, you know, different things like that. So, uh, and I think, you know, a lot of people weren't willing to sort of pay the polyfill cost in order to adopt those standards for those number of years. Now, if you go back even farther than that, Uh, in the early days of web components, the specifications are actually quite different and where, um, largely, uh, the work of Google and there was not agreement in the beginning, uh, on those API APIs. And so, you know, part of that process, just, it just took time to work out. It took time for all the different browser vendors to kind of weigh in with their concerns and to define. The version of the standards that we have today. So like back in 2011, or I, I started working with them, I think around 2013, um, those versions of the specs were what we would call like the V zero web component, uh, specs at the time. And they're a good bit different than what we have today. And so it was a number of years that it really just took to stabilize, um, what those standards were. To get agreement. And then, and then there was a period of time where that implementation had to happen and where there were only polyfills. And it was really quite recently, like I said, um, in 2020 where we have finally, every browser has now implemented these, and now you can build these components without any sort of polyfill whatsoever. Uh, and I think since then there's been a huge uptick. Uh, in web components, that was kind of the edge was kind of the final piece of the puzzle when edge shipped, that really changed the landscape in terms of web components. And we've seen huge growth. Uh, obviously we're working at Microsoft and there's a ton of web components stuff happening at Microsoft. But if you look across the industry as well, Google heavily invested. I mean, they were from the beginning, but they're continuing their investment, their Adobe massive, uh, investment from Adobe. There are new photos. Uh, for the browser is being built with web components, Salesforce, their entire platform is basically web components base. They've been in this for awhile and on and on. So there's a lot of, a lot of companies that are, uh, that are shifting this way. And it's much more viable solution since 2020 than, than it was prior to that. And so I think that combination of factors was the reason why we didn't really see huge adoption. Until that point in time and all the other libraries and frameworks that you mentioned, uh, you know, we're all sort of created prior to that point in time, really, to feel, to feel what was a gap. Because there, for so many years on the web, there was no standard for building components. There was a, there was a, there was just no way to do it. Right. And so we had what we call user land solutions. Um, for many years and, you know, you can go back to the early days of even Scriptaculous and prototype and MooTools and jQuery all these different widget libraries and they evolved then angular JS, and then you got your reacts and your views and in different things like this, but all of them were trying to kind of fill this gap in the platform. Um, and finally that gap has been filled by the, by the platform, but it's actually very, very recent. Um, that it's natively implemented everywhereChris Holt:
and it takes time too. You can't blame, you can't blame all 11 years or whatnot on, on standards, but standards take time to evolve. Right? And it's not just getting agreement on broad strokes. You're talking about like the nitty gritty, how these things will work and how they will scale. You know well beyond what we can consider and see. So, you know, I think that's one thing that tends to get forgotten as well, is that, you know, the sheer volume of working on the standard side, you're not creating something that a subset of people will use. You're creating something that lives in the browser and that is the, the model. Um, and so I think it's taken time for that to evolve. And in that time, yeah, there's been a lot of awesome solution and innovation that I think has led to even better innovation on the browser.Fernando Doglio:
All right. So let me turn the question around, uh, because as you say, there are a lot of companies, big companies that are investing a lot of money and time on, on these, call it new to English now because it's somebody said, why are they what's the, um, upside of what components that is making them invest so much time and money when these other solutions came and feel that. Years ago.Rob Eisenberg:
think there's so, as Rob mentioned, like there's a lot of universal application for this, right? There's a lot of conversation that's taking place more recently on different social media sites with web components, can't scale, which, you know, um, Adobe has proven outright that that's not true by building Photoshop 100% using, you know, not just web tech or web components. Um, and they did a fantastic job on it. I think out of, out of the gate. If I were to say, um, you know, what did I offer that nothing else can, I think that they solve a problem that none of these other frameworks can, which is interoperability with any of those frameworks. And so, you know, the place that I would say there is immediate application solving a problem that others can't is component libraries at scale. Right. Um, especially at large companies, right? As you said, one of the reasons that you're starting to see more adoption. You know, large companies can't really, or don't often centralize on a single tech stack. I mean, it's very, very hard to do. Requirements. Just tend not to line up that way across business groups. Uh, and so you have a universal design language for instance, and you want a universal component library and you want to have reuse for a number of reasons, but mostly so that our users get consistency. They get, you know, the same experience, no matter where they're at and what product they're in. Up until now. Like if you pick to build your component library on react or on angular, right. It is a high cost to try and create interoperability on there. There's a high cost performance wise. There's a high cost in terms of engineering efforts. Uh, and then there's what do you do when you need to pivot or change web components solves that problem. Like, like nothing that's come before. Because it is, it is part of the platform you are creating essentially native elements that work and act and behave like native elements. And so at this point now I think we have every major framework that is offering, whether it's behind a flag or natively support for that interoperability. There's no more framework lock-in when it comes to leaf nodes. Uh, and truthfully from, from a performance standpoint, I think that. You know, pick whatever framework you want. You know, I, I'm a big fan of pick the right tools for the job at this point in time, I cannot see why anybody would be building like their UI layer, their, their component library on anything about web components, because as far as scale goes, like it's, it's really what it really brings to the table in my mind.Rob Eisenberg:
Interesting. Um, and, uh, are they up to that point already? Uh, the web components where you say, because I've seen like what components.org marketplaces, where you can just browse whatever you need. And in theory, you download it added to your app and then it just works. But are they at that level that. Plugin, and plug&play, let's put it that way.Rob Eisenberg:
the, what the goal is, right. I mean, I'm a, my hammer is, you know, like what are the requirements? Right. Build to the requirements. And so sometimes, you know, sometimes it is that somebody wants something like super customizable for a reason. Um, For the most part. Yeah. I mean, I think if, if you want to build something that is out of the box plug and play, it's absolutely doable. Um, You know, there's, there's several libraries or individual components that folks that built and publish out there, um, to, to play with. And, uh, you know, anyone listening, who's interested, I'd encourage you to, to go and grab something and play with it and look at trying to build something, you know.Fernando Doglio:
Interesting. All right. I didn't know about web components. It's definitely sad that that's the case because when you don't know better and you start Googling for it. That's one of the first results that you get? Uh, it has a great SEO. Yeah.Rob Eisenberg:
And that's why the group is looking very much into making that a better place to land. In fact, I think we have a meeting, uh, either this week or next week to circle back around on, on that.Chris Holt:
Well, and not only do you get that, I'm sure that you get a number of blogs from, you know, the mid 2010s with, you know, opinion. And that certainly doesn't help either.Fernando Doglio:
Yeah. Yeah. When I, when I started research for these, uh, I had to like filter because anything that was like 15, 12, 13, it was"why I are web components bad?". Well, you know, what's the problem with web components and, uh, up to 2021 is when you start seeing. People actually mentioning good things about them and, and, and use cases. And so on uh, it, yeah, it's not easy to find information about them.Rob Eisenberg:
Well, I think this comes back to something very interesting about the web and the web versus libraries and frameworks, which is. Libraries and frameworks typically tend to have sort of their own little marketing engines around them. Right. There's hype people get out there at the conferences. There's branding, there's a cultural personality around various frameworks and libraries. And what, what does the web have? You know, the web doesn't really have its own marketing engine and it doesn't really have, uh, quite the same thing. So I think. Uh, you know, it's quite interesting that sometimes there's more hype around something non-standard than, than something standard, which is, which may be technically better. Um, and it's simply just because of, you know, how people in communities and, uh, you know, conferences and hype and Twitter and all these other things work. Um, the web doesn't really have, you know, a have a PR firm that's out there, you know, you know, I'm doing all this cool stuff to get people excited about the actual standards that, you know, that gets shipped. And so hopefully web components that org is something that we can kind of repurpose reinvent to start to help with that side of things. A little bit, at least for web components, because I think we, everyone that's invested in web components, we see the. Transformative power for the entire web, I think, for this technology. And so we want to help people to, uh, you know, to see that and understand it and to be able to leverage, uh, those capabilities.Fernando Doglio:
Right. All right. Before we get into the, the brushes that you've been mentioning, I want to get a little bit, a little bit more technical, uh, because we don't have a lot of time to cause, and I guess we could spend hours talking about this, but you mentioned Rob, uh, at the start, when you say. Well components being an umbrella term. Uh, you said custom elements, a CSS attribute. I think you said, and shadow DOM. Can you elaborate a bit more on each, on these and what kind of capabilities they give you? I mean, cause some elements, I guess is the common one and most people. That have read anything about what components would identify them, but, um, what are the other two?Rob Eisenberg:
Yeah. That's the ones that you're thinking of.Rob Eisenberg:
And that's it for today's episode tune in next week to listen to the second and final part of our web components conversation. I'll leave you with a preview though, catch you next week.Chris Holt:
I have conversations with junior developers or folks who are looking to break into the tech industry, just because of my background. Often a lot of times, you know, based on whatever folks are hiring for, that's what they lean towards. They're like, oh, I got to go learn this framework, or I'm going to go learn that you will not become a better. X framework developer by focusing.