The Good, The Bad, and The Web Components

Rate this content
Bookmark

There has been no shortage of both fair and unfair criticism toward Web Components from a wide range of folks that build for the web, including but not limited to JavaScript Framework authors in supposed competition with the platform. In this talk I'll show you how to navigate and simplify the multifaceted landscape of web components, satisfying common criticisms and showing how you can Use the Platform most effectively today.

29 min
01 Jun, 2023

AI Generated Video Summary

Web Components are a piece of reusable UI enabled by web standards and built into the web platform. They offer the potential for faster component initialization and less library overhead. Web Components can be created from scratch and utilized with existing component libraries. Shadow DOM and Declarative Shadow DOM provide benefits such as scoped CSS and server-rendered components. The tradeoff between not repeating oneself and achieving full server-side rendering support is discussed. User experience is deemed more important than developer experience.

1. Introduction to Web Components

Short description:

Today we're going to talk about web components. They're good. They're bad. Hopefully, not ugly. Here is an example of a component. Look at that. It's a button. We have our nice JavaScript up top. We have our JSX on the bottom. Some of you might be familiar with what this example comes from. It's from Vercell.js. There's a ton of component abstractions that exist in the space. But today I want to talk to you about Web Components.

How's everybody doing? Got some coffee? Bruce, I guess we're old friends. Great. That's awesome to hear. Well, you couldn't really tell by that introduction, but that's fine. Bruce and I get along really good.

All right. So today we're going to talk about web components. They're good. They're bad. Hopefully, not ugly. So, yes. Web components. Animations. Gotta love it. Web components, right? I don't have to convince you all that components are good, right? Components. Yay.

All right. Here is an example of a component. Look at that. It's a button. Woo-hoo! Thank you. That's been my time. Yeah. So we have our nice JavaScript up top. We have our JSX on the bottom. This is great. And some of you might be familiar with what this example comes from. It's from Vercell.js.

So if we look at some of the other component libraries that exist right now, there's a ton of them, right? There's a ton of component abstractions that exist in the space. But today I want to talk to you about Web Components.

2. Web Components and Design Systems

Short description:

Web Components are a piece of reusable UI enabled by web standards and built into the web platform. They offer the potential for faster component initialization and less library overhead. Examples of Web Components in use include MSN, material design, and Adobe Photoshop on the web. According to Google Chrome's Web Statistics, nearly 19 percent of page loads in the browser utilize Web Components.

So Web Component is a piece of reusable UI, it's enabled by web standards. It's built into the web platform. It's provided to you for free by web browsers. And really the benefit here is you have the potential to initialize your components faster and run with less library overhead, which is great.

So as Bruce introduced, my name is Zach. I blog on zackleet.com. I built Eleventy, which is a static site generator. And I work at Netlify. And just to kind of convince you that Web Components are a thing that you should care about, I'm going to show you some examples. Hooray. This is peer pressure. This is social proof. And after these four or five slides, you all are going to be convinced that Web Components are amazing. So let's get into it.

Web Components, really the bread and butter of Web Components right now is design systems. People love the portability of Web Components. They love that they're built into the platform. And that's really where the most examples you'll see of them are in the wild. Microsoft built MSN with Web Components. VMware has a nice design system. Google has material design which exports to Web Components. IBM has one, Salesforce. My personal favorite, Nord Health built with 11-D is a really good example of that. GitHub uses Web Components. Adobe actually brought Photoshop to the Web with Web Components using Lit, which I think is great. And that's using Spectrum Web Components which is a wrapper around Lit. So are Web Components a thing? Look at all these logos, logos, logos, logos. We love logos. Does that really convince us that things are good? Yes, I think so. If you go out to Google Chrome's Web Statistics, they have as of April of this year, measured that 18, almost 19 percent of page loads in the Google Chrome Web Browser are properties using Web Components.

3. Introduction to Creating Web Components

Short description:

Today we'll learn how to create Web Components from scratch and utilize their unique power. Component libraries are adapting to Web Components, allowing us to export to them and reuse existing patterns.

So pretty popular, amazing. That's convinced you all that they are good and should be used because they're popular, right? Component libraries are sort of adapting to Web Components as well. But today we're going to kind of go through how to create a Web Component from scratch so you know how it works, you can build it, you can utilize the unique power of them. But these component libraries, animations, some of them also include options to export to Web Components directly. And I think that's great too because we can reuse the existing patterns we have for our library and framework code and export to Web Components to use in the wild.

4. Understanding Web Components

Short description:

Web Components are custom elements that can be added to a web page. They allow for the creation of reusable UI components. When using a custom element registry, the browser enhances or hydrates the elements using web standards. Limitations include the requirement for element names to include a dash to avoid overlapping with existing HTML elements. Evaluating component load performance involves minimizing layout shift and maximizing HTML content before JavaScript initialization.

So, what are Web Components? What are they? Here is a Web Component. Woo! Just as good as that button example I showed earlier. We have the sort of a ubiquitous counter component that folks love to demo. This is called a custom element and this is what it looks like when you demo it, right? You have this lovely counter that counts up when you click the button. Incredible code. We love it.

And this is what it looks like when you add a button to the example. This is the default slot, the child component of a custom element and we just added a button here. This is called light DOM but I just call it plain HTML because we don't need fancy words for things that already exist. And this is what the JavaScript looks like for a custom element. So we have, when you use our custom element registry, we define what tag name we want to associate with that and then we pass in a class. So what happens with the custom element registry is anytime the browser encounters a my counter element on the page, it doesn't need to exist on initial page load, you can fetch it in later. Those will be enhanced or hydrated using web standards. And this is all provided to you for free by the web browser. There are some minor limitations here with custom element registries. You can't define an element name that doesn't have a dash in it. So if you have an element like this, you need to add a dash. Amazing. And the reason that limitation exists is because you don't want to overlap with existing HTML elements that exist as part of the web standard.

So to make this example a little bit more fleshed out, let's add some additional JavaScript to actually increment our button number. The number that renders on our button. That's what this looks like. So we can have any number of myCounter elements on the page, and they'll all be enhanced using this mechanism. So you click the button, and you increment the number inside of it. Amazing. So the way I like to evaluate how components load, and this really kind of dovetails with Barry's talk earlier, we really want to put as much into HTML as we can. So the thing I like to do when I'm evaluating the performance characteristics of a library or a framework, I like to look at what it can look like before JavaScript has initialized and what it looks like after JavaScript has initialized. And we kind of want to minimize the amount of layout shift that happens there. And so with this example specifically, there's no layout shift before and after because we didn't do any DOM modifications. All of the HTML that's rendered is the same as the HTML we're using in our page.

5. Web Component Patterns and ShadowDOM

Short description:

This pattern allows for server rendering without library overhead and enables progressive enhancement. Examples of web components that reuse this pattern include a details utils component and a video radio star component. Another example is the is land component, which initializes nested web components when visible to the user. However, this pattern leads to repeated content inside the web component, which can be problematic for the authoring experience. To solve this, we can use ShadowDOM, which provides a reusable template injected via JavaScript.

So in a way, this pattern is exclusively server rendered. We didn't do anything but add a few event listeners here. We're not using any library JavaScript, there's no library overhead, and we can have nice progressive enhancement without any layout shift which is great for a core web vitals as well.

So there are a few web components that I built in the wild that kind of reuse this pattern. There's a details utils component that I built to sort of add additional behaviors to your detailed summary elements on your page. And you can go and check that component out if you're interested in it. This one just adds a behavior to close the details element when you click outside of it.

In this example, I have a video radio star component that only plays a video element on the page when it's visible, which I think is a nice pattern, especially when you're you don't necessarily want to play all the way through before the user has even encountered them on the page. So we want autoplay, but only when the user scrolls to it. So in this way, we're enhancing existing HTML that is the child of our web component.

And another example that I have here on my Github is a is lan component. And now Astro is a very popular component framework, or a popular framework that really relies heavily on islands architecture, which is just kind of spicy, fancy, lazy loading, which I know is maybe a controversial thing to say, but I'll say it anyway. So yeah, there's an is land web component that does something very similar. So any web components that are nested inside of this is land component are only initialized when they're visible to the end user, which I think is great. And there's a bunch of different mechanisms to that, too. You can only do it when it's idle, you can do it when save data is enabled, you can do it under media queries, or only when the user has interacted with it.

Now, the problem with this pattern here is that all of the content inside of our web component is sort of repeated. So the authoring experience is not great, because we really don't want to have to nest all of this repeated HTML throughout all of our content. So my number one grievance probably with this pattern is that I do have to duplicate this HTML myself, unless I have an existing library or framework on top to do that for me. And I don't like to repeat myself. And I don't like to repeat myself. So when we have three counter instances on the page, this is kind of what the authoring experience is of what I'd expect or what I'd want to do. I want the unique things inside of the component instances. I don't want any repeated things that I have to manage myself.

So to do that, we have to graduate to a level two of Web Components and go to use ShadowDOM. So ShadowDOM is a way to have a reusable template that you can inject yourself in JavaScript. And this is what this might look like. So we have a template element on our page. We have our button inside of it. We have our slot.

6. ShadowDOM and Declarative Shadow DOM

Short description:

The default slot, or the light DOM, gets slotted into the content of our component instances. By injecting the ShadowDOM template, we avoid repeating the button element and achieve automatic slotting. However, there is a higher risk of layout shift. We can use CSS hooks to control styles before and after component initialization. Some component libraries hide the component using this mechanism, but it creates additional JavaScript dependency. Declarative Shadow DOM, a new specification, allows us to use the template and inject it into the Shadow DOM, eliminating the JavaScript dependency and providing the full benefits of Shadow DOM.

And then the default slot, or the light DOM or the plain HTML, that's nested inside of our component instances, gets slotted into that content. And so I've kind of grayed out the code from the previous example. And you can see the new code that we've added just to inject the ShadowDOM template. So it's just a couple of lines. We find the template element, we attach it, and that's kind of it.

So, in that way, we get the benefits of not having to repeat our button element in every instance of our component. And the content is slotted for us automatically. But, going back to our pre-JavaScript and post-JavaScript experience, depending on where we run that custom element registry code, this could interject some layout shift because the content that was available to the component before JavaScript was initialized was just a number. And after the component is rendered using ShadowDOM, it's a button and a number inside of it. So in that way we have a client JavaScript rendered component. The benefit here is that none of the content is repeated. And we, again, don't have any library JavaScript, that's great. We're not repeating ourself in our component instances, but we do have a higher risk of layout shift happening.

So in CSS, we actually have a hook to control styles before a component registry is available or before a component is initialized in our registry, and after. So this is a great hook to say I want to render my component a certain way before and after it's initialized. Because really, I don't want any JavaScript in my critical rendering path, I want my page to be as fast as possible. And some existing component libraries that I linked to previously in this demo, and I'm not going to necessarily name names unless you find my speaker notes here, they use this mechanism to hide the component altogether. So this still has some layout shift when you're doing content or JavaScript manipulation of the DOM, excuse me. So I wouldn't recommend sort of doing this, if we can get away with it, because, again, it creates an additional JavaScript dependency on your styles. If JavaScript fails or your JavaScript doesn't run or you get an error on your page from maybe a browser extension, your page is going to be invisible, which is not great. Here's another example from another unnamed component library in the wild with Web Components. They're just toggling opacity here. So I guess this is maybe part of my brand, if people are familiar with my extensive work on social media, very relevant work too. Just JavaScript is a grievance here. We don't necessarily want to require JavaScript to have a full rendering of our Web Component. And with Shadow DOM that is a requirement. So how do we work around this? Hey, there's a new specification, level three, declarative Shadow DOM. We can actually use the template and the browser will inject that template into the Shadow DOM for us. So this completely alleviates the JavaScript dependency that we needed from the previous example and we get the full benefits of Shadow DOM. So this is what your component instance might look like.

7. Repeating Templates with Declarative Shadow DOM

Short description:

Our before and after JavaScript experience here is very similar to the first level when we just did a custom element and we repeated our HTML in all of our component instances. In this case, we're only repeating our template. But I'll get to that later. With Web Components, with declarative Shadow DOM, we do get server-rendered components. We aren't using any library JavaScript here. We do get full encapsulation of our components. We get progressive enhancement without layout shift. But the only problem here is that we're repeating ourself pretty badly. It's almost worse than the first example.

And so, our before and after JavaScript experience here is very similar to the first level when we just did a custom element and we repeated our HTML in all of our component instances. In this case, we're only repeating our template. But I'll get to that later. And this is what the polyfill is for existing browsers that do not have declarative Shadow DOM, which is currently just Firefox. This is what the polyfill looks like to add support for that. Now, of course, a polyfill is just another JavaScript dependency here, which we don't necessarily want. But this will go away over time, which is great. But the sooner Firefox can add support for declarative Shadow DOM, the better off we'll So, with Web Components, with declarative Shadow DOM, we do get server-rendered components. We aren't using any library JavaScript here. The polyfill is only a couple of lines, as you see. So even in Firefox, it's still pretty small, although it is JavaScript rendered in Firefox until they add support there. We do get full encapsulation of our components. We get progressive enhancement without layout shift. But the only problem here is that we're repeating ourself pretty badly. It's almost worse than the first example. So when you have three different instances of our counter component with declarative Shadow DOM, all of this stuff is repeated. You have to repeat the templates in every instance, and that's to enable streaming behavior, because you wouldn't necessarily want the template to be not available when the component instance is.

8. Benefits of Using Shadow DOM and Web Components

Short description:

One of the easiest and most communicated benefit of using Shadow DOM is scoped CSS. Scoped CSS allows you to nest a style element inside your Shadow DOM template, ensuring that component styles are scoped to just the component. However, there is a tradeoff between not repeating yourself and achieving full server-side rendering support. JavaScript frameworks and component libraries have not fully solved the SSR problem yet. Web components offer unique benefits, such as the custom elements registry, that can be leveraged by JavaScript frameworks. Some component frameworks have compilation targets for web components, and there are also first-party web components available.

Now, the benefit... One of the easiest and most... The easiest communicated benefit of using Shadow DOM, either with a JavaScript dependency or declaratively, is that you have scoped CSS. So you can nest a style element inside of your Shadow DOM template, whether you do that declaratively or not. And all of that component styles are scoped to just the component, which is amazing. And this color blue assignment will only be scoped to our counter instance. And you have a few other CSS property... Or, excuse me, CSS pseudo classes that allow you access to those things as well. You can say, I want colon host, which gives you access to the tag name. You can put an additional selector on host, and you can add host context, which is almost like a parent selector. We're coming back to repeating ourselves over and over in these templates. We don't want to have to nest our scoped CSS in every component instance as well. That is so much worse. So in a way, there's almost this standoff between not repeating yourself and getting full server-side rendering support. And sort of the elephant in the room here, in this example, is JavaScript. We have a JavaScript dependency that gives us the ability to not repeat ourselves in all of our component instances, but if we want to remove that JavaScript dependency to get as fast of a loading experience as possible, we have to repeat ourselves and repeat those styles and templates in every component instance. So we're going to graduate to level 4, which is how to add server side rendering without repeating ourselves. And so if you look at this previous example where we had our declarative Shadow DOM nested in all of our component instances, you can kind of see that we want it to exist like this. We kind of want a reusable template that we can re-assign to a component definition, and have that handled for us by the web browser. Now there's some problems to solve with streaming there, but I think that that's a thing that is coming to the web platform and I've linked up with super tiny text there, a URL if you want to see the ongoing discussion of that. But the crux of the situation is that SSR is not really sufficiently solved by the platform yet. I think it's coming, I think we'll get there, but component frameworks have not solved this problem as well. They are sort of beholden to the same limitations as the platform. So I think the important thing I'd like to communicate here is that we shouldn't hold necessarily web components to a higher standard than our existing JavaScript frameworks and component libraries that we use today. And historically, it's sort of been very adversarial, right? JavaScript frameworks have been sort of against web components and maybe the most vocal critics of web components. But I think there's some very unique benefits that we can get from web components, specifically just the custom elements registry that can be leveraged very nicely by JavaScript frameworks. And so, just going through the framework libraries that we sort of talked, the logos that we looked at before and in the bottom left you can kind of see that what some of these component frameworks have SSR targets or excuse me, have compilation targets for web components. And then in the top right, there are sort of first party web components. So you author things and web components land and then SSR is sort of an added-on feature on top of that. And then the bottom right, there's a WebCE and enhanced.dev, those are sort of two existing frameworks.

9. Web Components SSR and WebC

Short description:

I work on WebCE, enhanced.dev is another one that I've really tried to make the SSR story and web components SSR first rather than a bolted-on feature later. SSR sort of supported for web components with these component frameworks that have web components first, your authoring and web components, Lit and Stencil are two examples of that. And Enhance and WebC are sort of taking a different approach. We want the SSR experience to happen first. So I am just going to go through a super quick example of WebC component. Using ssrfirst component libraries, we do get the benefit of server-rendered, streaming-friendly HTML. We don't have any library JavaScript. There's no sort of extra JavaScript library overhead there. We can encapsulation, we don't repeat ourselves, and we get good progress enhancement. If you want to try out WebC, there's a good starter project on my GitHub, on the 11 GitHub to do that. But really, the main thing that I think Barry really drove home today is that if you can do it in HTML, it will be faster than JavaScript. And I think that has really proven itself true if you've tried to use CSS and JavaScript libraries in the last couple of years.

I work on WebCE, enhanced.dev is another one that I've really tried to make the SSR story and web components SSR first rather than a bolted-on feature later. And if you want to sort of check out the compatibility with existing component frameworks and web standards, you can check out customelements everywhere.com with dashes in between the names. The spoiler alert, React is the only one that's being actively maintained that has failures on these tests which is unfortunate. Hopefully, it will come in React 19 but I am not holding my breath.

Okay. So, again, SSR sort of supported for web components with these component frameworks that have web components first, your authoring and web components, Lit and Stencil are two examples of that. And Enhance and WebC are sort of taking a different approach. We want the SSR experience to happen first. So I am just going to go through a super quick example of WebC component. This is what the authoring experience looks like in your template. And then you have a component definition on the right. And so we don't have to repeat ourselves but we still get the full benefit of declarative shadow DOM and it will render the output to you. We'll repeat it in this way, but you don't necessarily have to do that in your authoring experience. You still get a nice authoring experience. And there's another way to do it in WebC as well. You can sort of compile to regular HTML. So you can sort of compile to level one of the examples that we showed today. And this is the output you'll get from that example. So in this demo it's very svelte-esque in the compiler output. So using ssrfirst component libraries, we do get the benefit of server-rendered, streaming-friendly HTML. We don't have any library JavaScript. There's no sort of extra JavaScript library overhead there. We can encapsulation, we don't repeat ourselves, and we get good progress enhancement. If you want to try out WebC, there's a good starter project on my GitHub, on the 11 GitHub to do that. But really, the main thing that I think Barry really drove home today is that if you can do it in HTML, it will be faster than JavaScript. And I think that has really proven itself true if you've tried to use CSS and JavaScript libraries in the last couple of years. So thanks for listening.

Firstly, because you said that you're feeling bad because nobody at this conference has a framed photograph of you, anonymous said, no question, just wanted to say the presentation is top-notch. Thanks, Zach. Wow, okay.

QnA

Handling Collisions and Naming Conventions

Short description:

So, yeah. Ten out of ten. We'll do business again. Yeah. A round of applause to Mrs. Leatherman for submitting that. Dip asked, how do you deal with collisions in handling multiple versions of a web component the same page? Scoped element registries was his name? Yeah, I think so. Talking of component names, tell us briefly about the hyphen in the names. What's that about? Basically the dash in the name is because the W3C and WOTWG have said that they will never invent a core HTML tag with a hyphen in its name and therefore, it won't collide. What about the attributes? What about them? Do they have hyphens in them? Oh no. You can name them whatever you want. There's an interesting question that might have actually disappeared. But it was simply, why do developers spend so much time worrying about things that are not important? I don't really have the context of this. Now, what? There's two different ways I can take that question. The first way is that the entire talk I just gave is something that's not important and we shouldn't worry about it. So I'm going to ignore that one. And assume that developers are caring a lot about things outside of the scope of my talk that aren't relevant.

So, yeah. Ten out of ten. We'll do business again. Yeah. A round of applause to Mrs. Leatherman for submitting that.

Dip asked, how do you deal with collisions in handling multiple versions of a web component the same page? Yeah, I mean, there is a coming specification that's scoped element registries and so that will be a sort of way to handle same component name on your page registered multiple times, so that is coming. Those component tag names are sort of global right now, but that's a problem that will be solved in the future. Scoped element registries was his name? Yeah, I think so. Blimey. I suspect that I haven't heard of this increasing amounts of them now.

Talking of component names, tell us briefly about the hyphen in the names. What's that about? Yeah, so you need to add a hyphen in your tag names so that it doesn't conflict with current and future additions to the HTML specification. So I think that's an important limitation because we don't necessarily want our custom elements to collide with HTML elements they add later. But I mean, additions to HTML seem to be happening pretty slowly. I think CSS right now is just incredible how things have sort of ramped up and how they're shipping things very quickly in CSS land. So hopefully more things will come to HTML as well. So basically the dash in the name is because the W3C and WOTWG have said that they will never invent a core HTML tag with a hyphen in its name and therefore, it won't collide.

What about the attributes? What about them? Do they have hyphens in them? Oh no. You can name them whatever you want. Yeah. And I don't even think they need to, if they're on a custom element, I don't think they even need to have the data prefix that is common in existing HTML patterns. So go wild on attribute names, woohoo. Go wild on attribute names, you heard it here first party people.

There's an interesting question that might have actually disappeared. But it was simply, why do developers spend so much time worrying about things that are not important? I don't really have the context of this. Now, what? There's two different ways I can take that question. The first way is that the entire talk I just gave is something that's not important and we shouldn't worry about it. So I'm going to ignore that one. And assume that developers are caring a lot about things outside of the scope of my talk that aren't relevant.

Developer Experience vs User Experience

Short description:

Developers easily get on hype trains, taking cues from others. This conference highlights the importance of web performance and accessibility. In our industry, people worry about not repeating themselves but still use excessive JavaScript. The question of developer experience versus user experience arises. User experience is more important than developer experience, according to Zach Leatherman.

I don't know. I think that's a hard question to answer. I feel like developers really get on hype trains very easily. We're social creatures and we sort of take cues from what other people are doing. And so if someone that you admire and follow is telling you to care about a certain thing, then you start to care about it as well. And so I think, yeah, I think this conference is great because we need to get more people in front of people talking about things like web performance and accessibility and, yeah, the things that maybe have been marginalized a little bit, but things that are very important nonetheless.

Although there was no context to that question, I included it because it was a genuine question from an audience member, but it did, it does gel with something that I was thinking about. Like you mentioned often about, don't repeat yourself. I get that, but we work in an industry in which people fret about not repeating themselves and yet are more than happy to squirt 48 kilotons of JavaScript down the wire rather than just write some HTML, so what's that about? That gets into the whole developer experience versus user experience question.

OK, I'll ask the question. I don't know if we have time for that, since we have thirty seconds left, but that's maybe a whole hour. I'll ask the question which you can answer in twenty-six seconds. What's more important, developer experience or end user experience? I think user experience is so much more important than developer experience. And you heard it here, folks. Thought leader, Zach Leatherman said user experience is more important than developer experience. Yep.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Day Berlin 2022React Day Berlin 2022
34 min
It's Time to De-Fragment the Web
Over the past few years, the number of web frameworks available to us has exploded. In some ways, the breadth of choice is a clear win for our ecosystem. However, for many of us, it also comes with harsh drawbacks: - Have you ever used a popular open-sourced component built for framework A, and wished it existed in framework B? What about a design system library? - Does your company have frontends built in different frameworks, and your web teams are frustrated about the wasted hours needed to achieve a consistent design system? - Does your team build SDKs for web frameworks, and must manually re-write them for each framework? The solution to all 3 of these problems exists today. To fully understand it, we must first examine today’s web frameworks, re-think what a component should look like, and introduce a new Intermediate Representation of our components. This is what we have done at Builder.io when we created Mitosis, and we’re excited to share it with everyone.
JSNation Live 2021JSNation Live 2021
28 min
Web Components, Lit and Santa 🎅
Get started with Web Components – enabling you to define new HTML elements that work everywhere regular HTML does. This talk will focus on Lit, a suite from Google that helps you create WCs with features you'd expect like data-binding and declarative definitions. It'll also cover how we've used them to build one of the web's jolliest sites, Google's Santa Tracker 🎅
React Summit US 2023React Summit US 2023
21 min
Authoring HTML in a JavaScript World
 In this talk, Tony shows how an authoring and semantic HTML-first approach to JSX template work leads to more readable, maintainable, and accessible UI components. He demonstrates how to think through implementing a UI prototype in a semantic way, authoring HTML before visuals. He shows how accessible markup improves performance, reduces DOM size, minimizes time spent on CSS, and reduces cognitive load not only for developers, but also for all our users, no matter how they consume our sites and applications.
JSNation 2022JSNation 2022
20 min
Immutable Web Apps
Resolving dependencies when they are all bundled together is easy. Resolving dependencies when they are in being loaded via script tags is much more challenging. The goal of this talk is to explain how Meltwater handles dependency resolution when building native Web Component based applications that rely on packages published by many different teams.
JSNation 2022JSNation 2022
10 min
Web Components are awesome!
Ever wondered how by placing "video" or "audio" into your HTML, you get a media player with controls included? Or how, depending on the type attribute, "input" can be a button, a place to enter text, select a date or file, color picker and more? What if you could create your own element? The answer: Web Components! 🤯 In this talk, we’ll take a look at what Web Components are, how to make one and include it into an application.
React Advanced Conference 2021React Advanced Conference 2021
32 min
Let's talk about Web Components
Before the dawn of some of the most popular frameworks (read: React and Vue), there was Web components. Web Components take one of the best parts of these frameworks (reusable components) and combine it with the best parts of web development (native browser support and not needing to set up a build process). As if that's not enough, web components allow you use the same functions across any framework.If at this point, you're wondering "If web components are so awesome, why haven't I heard about them before?", then you're in luck because that's exactly what this talk is about.In this presentation, we'll take a look at what web components are, why web components are awesome, why web components can be a pain and how we can use web components both as a standalone tool and together with frameworks.

Workshops on related topic

JSNation Live 2021JSNation Live 2021
184 min
Web Components in Action
Workshop
The workshop extends JavaScript programming language knowledge, overviews general software design patterns. It is focused on Web Components standards and technologies built on top of them, like Lit-HTML and Lit-Element. We also practice writing Web Components both with native JavaScript and using Lit-Element. In the end we overview key tooling to develop an application - open-wc.