Web Components Can't Save Us. But You Can! with SCOTT JEHL — SmashingConf New York 2024
Life Is A Mystery Scott Jehl VITALY: And I'm just really, really happy to have a good friend, an incredibly nice person, a knowledgeable person, a smart person, who can write JavaScript without an Internet connection in the middle of the Amazon. So, please welcome, Scott Jehl. Scott, bring it on. SCOTT: Thanks, Vitaly. Good morning, New York! Can we make up a little code this morning? All right. So, I am here to talk about why web components can't save us. But maybe you can. And that web components might help you do that. Maybe you're thinking, save us from what? I'll talk about that first. So, here's a mystery. Talking about mysteries at this conference.
Why do we still have performance problems in 2024? It's kind of weird, right? Like everything is good now. It's supposed to be good now. We have 5G, we have evergreen browsers, we have AI that tells the truth sometimes. I think that's true. For a lot of us, most of the time things are pretty good now. But to borrow a famous quote: While the future is here, it's not always very evenly distributed. The way people experience the web today is very highly dependent on their circumstances. Why? Well,
part of that is due to the devices that we have access to. This chart shows a speed benchmark comparison for popular mobile devices across the last decade. Ten years ago, most of the devices that we had access to were pretty close in performance. That's changed a lot. The performance of high-end devices today and budget and low-end devices today have grown really far apart. The iPhone 15 is like five times faster, at least, than some popular Android
devices that people are using today and buying today. And that's faster at churning our website's code when we deliver it to them. Networks play a part too. Networks are getting faster, but again, unevenly., so the 5G rollout has been going on. But it still doesn't reach into a lot of the rural areas of the US, let alone the rest of the world. And it's taking a really long time, I think,
to build faster networks here and abroad. I'm not really sure why that is, but sometimes I wonder if it's because they spend so much time making our networks look like trees. And don't get me wrong, like, it's impressive with a they do, right? Like if I didn't know what coconuts look like... like
that's -- that's pretty convincing. It just seems like this is a really high priority for them. So, maybe that's part of the reason? Are cactuses trees? I'm not sure. Next slide. Anyway, networks are getting better. 5G is growing. But even in areas with 5G service, not everyone can use it,
right? Older devices, budget devices, don't have the hardware to connect to those towers so they're stuck on slow phones and slow connections. Doubly penalized. Now, we web designers and developers, we tend to have access to nicer devices and fast connections. Experiencing our own websites day-to-day on the connection that is we have and those ideal sort of conditions can sometimes skew our perspective of how people are actually receiving our work. In this chart, I've really carelessly just reduced the entire history of web performance into two phases. The early days of the web. You know, in those days, it was hard to deliver fast websites because everything was slow.
Like the conditions were outside of our control. Right? Networks and devices were not fast. So, we had to optimize everything, make it small, make fewer requests. Sometime around 2013, things were getting a lot better. And a lot of us started to experience a web with reduced constraints. And that should have fixed our performance problems that we had leading up to that point. But instead we saw that we had more bandwidth, right? And we just poured JavaScript all over it. And this is not mine, by the way. Credit to Andy Bell, a good friend who made that meme. React came out in 2013.
And even though React was meant to build real-time UIs, like Facebook, people just started using it to build every website. Even blogs. The performance impact of delivering websites this way, you know, like -- and like let it assemble on the other end. It's well-documented. Ten years ago my colleague at Filament Group wrote this post surveying the speed of just like getting a Hello World in the browser using popular frameworks at the time. It was taking too long. And later, Tim Kadlec, who is here somewhere, followed up with more details and confirmation that the problem was getting worse. So, treating websites like exe, executable files that we download causes different
experiences for people. Thankfully, this pattern was becoming, as it was becoming more common, the performance community was standardizing on metrics that help us measure it. And these are some of them. Delivery metrics like LCP, for example, which measures paint timing. Like how quickly
you see pixels on the screen. That really helps us figure out how quickly the page appearance. CLS is another metric. Stands for cumulative layout shift. Hardest one to say. This one is about how much the page jumps around while it's loading. And lastly, INP is a really new one to Core Web Vitals
this year. And it's really helpful for identifying how long it takes for the browser to respond to user interactions. Particularly when a lot of JavaScript gets in the way. So, for a while now, many sites built on modern JavaScript frameworks struggled to hit those early delivery metrics, and that's because JavaScript was in the way of generating the HTML. So, this is from an experiment I did a couple years back. These are recordings on a low-end Android device, recording it loading Elon Musk's blog. And on the right, we have the live Twitter site. Which is a
client-rendered React site, at least at the time. I haven't been back in a couple years. But on the left, the same site is delivered intercepted halfway to the device with the final HTML that it needs. So, the browser receives HTML first. And you can see the difference that it makes, right? Browsers are meant to receive HTML and render it quickly. And the practice of generating sites that way when they land on the device and then generate the HTML, it's still a problem. But I do to want say that finally things are starting to get a little better and I want to give credit to that. So, frameworks are starting to prioritize delivering HTML,
even if it's a React side. Next.js is one of those examples. They render React sites on the server, deliver HTML to the browser. That's really good. It took a long time for frameworks to come around to this. It's really frustrating. But it's good to see that we're working on
this but we're not out of the woods yet, even with those sites, even if it's HTML up front, they tend to deliver a big payload of JavaScript that follows the HTML to sort of re-hydrate it and make it into a single-page app again. Because we all want to do that. So, how do we know how this is impacting performance if we don't have a budget phone in our pocket? There are great tools for this. These are some of them. SpeedCurve, Caliber, WebPageTest, DebugBear. These are great. Some tools let you see how people are experiencing your site in real-time on their own devices. So, CrUX is one of those service which is stands for Chrome User Experience Report which I don't want to dwell on it. But like that's not how acronyms work. But anyway, Chrome, you know, collects
information about performance information, anonymous information, about users to websites and exposes them on this site. You can go to it and see how long it takes to access Walmart.com or whatever you're trying to measure. I'd recommend checking it out. We can test directly too. So, this is from a test that I ran in WebPageTest recently on a server-rendered single-page app kind of site. To see how it's impacting performance on two different devices. This was a fast device. So,
like a high-end Android. And you can see first contentful paint there, LCP is green, those are delivery metrics, look good, right? This one's red, total blocking time. That's because this site happened to deliver HTML up front -- so, it rendered quickly -- but something happened to cause the device to be blocked up. The main thread was halted and couldn't receive interactivity just for two seconds. Which is, you know, not long. But it's weird for a high-end device. So, if you look into that, we can see the culprit, right? A megabyte and a half of JavaScript. That's
compressed. When it expands on the device in the memory, 6.5 megabytes. That's a lot for any device to handle. And this is not a lot compared to most popular websites today. Like a meg and a half, a lot of the sites we're using are delivering more than that. This is very common now. Here's that same test run on a low-end device. Once again, slow device, but it renders quickly. First contentful paint, still under 3 seconds. Looking good. You know, it's orange, but that's okay. This is a low-end Android. But here, look at what happened to the blocking time. We've moved to
almost 12 seconds where the phone is just frozen. Can't respond to your interactivity. The page looks ready, but you can't use it. That's bad. We need to work on JavaScript. We're doing better, but we need to work on it. How? I was saying this talk would be about web components. Let's talk about them. Perhaps you tuned out on web components for a little while. I did,
admittedly. The early versions were a little rocky, browser support wasn't good, polyfill was required, standard fills were changing. Things are better now. And a lot of the big companies have adopted web components in recent years. Adobe, for example, has standardized on web components. And have an open source library built on them called Spectrum. It drives a lot of the air flagship now. When Adobe uses web components, like they built Photoshop on them.
Like the real Photoshop. This is the latest version of Photoshop. It runs in the browser and it's built on web components. This is actually a live video of me using it recently. And it works just like you'd expect Photoshop to work, as you can see. Graphic design is my passion. In the browser, you can open up DevTools and see what's under-the-hood, right? And all these little elements have weird names on them. Those are web components. So, they're really -- they're really bought into there. Apple is another web components fan. You can see it on the Apple Pay button that you can embed into your websites. SpaceX. Perhaps you were thinking web components
sound pretty good, but they certainly don't work in space. Guess what, haters? They work in space! The UI of the Crew Dragon spaceship runs web components. So, you can put space on your browser support matrix. Another small company, Microsoft, using web components. They standardized, similar to Adobe recently, of a lot of frameworks on them. Even rebuilt Edge browser, like the Chrome browser itself in web components recently. Used to be built in React and they
reported pretty big performance gains from that. GitHub, another one. See that little relative time element in there? That's a web component. And it just converts timestamps into a nice, friendly date. Last one, Wordle. Originally built on web components, at least. So, let's talk about
what they are. First thing to know about web components is that they're not any one thing. They're a series of standards that are -- that can be used alone in isolation or together to produce reusable component patterns. And they're built into the browser. These are custom elements, HTML templates and shadow DOM and slots. Which is four, but we're gonna say three. So, let's dig into custom elements first. This is my favorite part of all the web component specs,
this is the one I use the most. This is a my element-element. If you know HTML, you know that's not a standard built-in element called my-element. That's what I just made up. That's what you do with custom web elements. The way to see if it's a custom element and not a standard one, a UIL, the name will have one dash in it. They're little imposter elements that are made out of dash-separated characters like little squirrels in a trench coat trying to be HTML. In fact... thanks to Unicode and flexible naming rules of custom elements, this is totally valid.
So, you can make three little squirrels. It can't just be those squirrels, though. Which is something I never thought I'd say on a web stage. But it has to have a letter that starts. So, you see that X in there. It could be any letter. But you can still do squirrels. So,
there are a few other rules. These are all valid, again, they have to start with a letter. Have at least one dash. They don't need anything after the first dash. So, A dash is valid. I didn't know that until recently. They can use other characters after that first dash too, underscore,
period, numbers, and squirrels. Custom elements, they always need to be closed. You can't have a self-closing tag. How do we use these things you can just use them like any HTML element, right? Alongside the other ones. Or wrap them around HTML. This is the way I like to do it. Of course, since they're real HTML, we need to follow HTML rules. So, for example, some elements only allow
certain kinds of elements inside them, right? Like a UL only allows LIs inside it. Web components use real HTML so we have to work with that. And this trips people up, I think, if they come from React, for example. Because the idea of components in a framework world is often more of like an include
sort of mental model. Where the tag you put in there doesn't necessarily stay. Web components are just HTML so they stay. So, you have to -- you have to work with HTML. So, you drop it into a page. At that point, it's like a diverse span. Maybe that's useful to you. You could style
it at that point. It doesn't mean much to the browser at that point. It's not interesting for accessibility. But sometimes that's all you need. So, you could add ARIA to make it more meaningful at that point if it made sense. But usually we want to do more when we use them. For that, we use the custom elements life cycle and that's how we extend meaning and behavior of the element.
So, with the lifecycle talks about key moments in a web component's life. So, to gain access to the lifecycle, we have to teach the browser about our element. So, we need to define it or register it. That's that one line of JavaScript right there. We're passing in the element name, my element.
And then we're gonna say, we're gonna define it by extending this other class that's built into the browser. And that other class is the HTML element class which is the one that drives every default HTML element to start. A lot of native elements extend this one further, right? So, we're doing that too. We're actually working like the browser does, with building real elements. So, HTML element class, that's what gives elements things like offset top or inner HTML. That's what
defines all that. So, we're gonna extend that. And we do that by putting inside the curly braces. Now, I don't have to use an unnamed class like that, I could name it as well. You'll see this often too. So, my element extends HTML element and then I could pass that variable name in. And this is good. It's a common pattern for good reason because once you do that, you can export your component. And then other components could import your component. And that's how you can sort of compose them together if you want to. But whether you export it or not, you can also just pull it
in with a script tag. And I'd advise if you do that, add that type equals module attribute. I don't have time to explain why, it will just work better. So now we have a script that's ready to define some behavior. But it doesn't do anything interesting yet. So, that's when we go inside the curly braces and add some things. We have life cycle, constructer, connectedCallback, I'm gonna
talk about a couple. First, connectedCallback, remember we had a listener that waited for the DOM to be ready and then the HTML. We don't have to do that because connectedCallback does that and does it better on not only when it's found in the DOM, the page is delivered to the browser. Or maybe when you add HTML to the browser, to the page, sorry. It -- it doesn't have to wait for the whole page, in other words. So, it does both of those moments. And here I'm logging that moment when the browser notices my custom element in the DOM. So, also, another lifecycle moment,
this is probably the most code I'll show. Sorry about that. Wake up. Like any HTML element, you can use attributes on your web components and actually that you can use any attribute you make up. They can be custom. So, here I'm adding one called greeting. I just made it up. And you can observe changes on that attribute. And this is how you can like start to build some reactivity in web components. There are other moments that I mentioned earlier. I can't cover them all. I recommend checking them out. I'm gonna move on to the second ingredient, that's templates. If
you're coming from another templating language, lower your expectations. These are not what you're hoping. But I'll show you what they do. They just give you a way to deliver some HTML that doesn't render the user so you can reuse it and like populate it, append it to the DOM efficiently. So, that's pretty much the template element. Third component of web components is shadow DOM. And slots are part of that as well. Shadow DOM. The name implies there's a light DOM, right? A lot of people have been calling the regular DOM the light DOM. That's just the regular DOM. So, HTML
on the side there and we've got a programmatic representation of it on the right. That's the DOM. We're all used to that. It gives us tools like querying for a selector. And we can find an element in there. So, that's light DOM. It just found an H1 in the page. To contrast that, shadow DOM is a relatively new thing to web developers, but it's been around for a while so if you go into Chrome settings, you can check this little box for user agent shadow DOM. And then you can start to see it just show up in native elements. Like a select. So, there's a select element HTML, how it renders. And look at that. Shadow route. They use shadow DOM inside. A lot of form controls. And
what it is is like this little encapsulated, protected segment of the DOM that can't be interfered with as easily with JavaScript and CSS that's in the page. And sometimes that's good. Why would you want this? We can use it too. So, why would you want this? I would say that most of the time, I don't. That's a little controversial. But you know, a lot of the times you don't need
it. But it's useful in some cases. One use case, I think, is that it's really nice for embedding code on other websites like a third-party embed where you want total control over the HTML appearing the way and behaving the way you want. Like a video player. Or a -- that Apple -- Apple Pay button, for example. So, this is their configurater tool for the Apple Pay button and you can see it's
entirely shadow DOM. So, the markup they give you is just an empty element and their script controls everything. You can add some attributes to sort of change the settings for it but, you know, you can't change the Apple logo. They did this on purpose, right? So, it's useful in some of those
ways. One thing that's kind of neat about shadow DOM in general. They give you some CSS custom properties from the Apple Pay button that you can customize it. These actually pass through the shadow DOM. Most CSS doesn't, some does. Really complicated. These do. So, they're like power tools for configuring layout inside it. If you want to expose some of the layout to others. So,
how do we make it? There are a couple ways. I talked about the template tag, it was a little boring. You could actually use it to make shadow DOM now. So, what you do is add an attribute. So, shadow route mode can be open or closed. Once you add that, this is called declarative shadow DOM and it lets me make a shadow route. It's like a boundary around that paragraph now. That paragraph is protected from interference. If I wanted, I could produce that same markup without the
declarative approach. It's a little longer. But I'm attaching a shadow. I set the mode to closed. And then I appended some HTML to it. So, two ways to get the same thing. However you make it, it's encapsulated from JavaScript accidently messing with it. So, I've got DevTools open here. Query selector for a paragraph. It can't find it because it's in that shadow route, right? So, it's encapsulated. And that's the benefit of it. And I made it closed so I can't find it. On the other hand, if you set that mode to open, you can make it findable, at least. Not by accident,
only on purpose. So, if I want to find that div element and then get it shadow route and it's open, then I have a property exposed that I can talk to. And it's called shadow route. So, you can see that here. Query selector if the div, shadow route, and then I can go inside that query selector for more elements inside it. I mentioned slots before. Slots are like the best part of shadow DOM, I think, because they're light DOM. It's really confusing. Slots are elements inside the shadow DOM that expose or reveal light DOM elements that are next to it. Next to the shadow
route. And they're actually still light DOM. They receive styles from the page. So, they're like a window into the light DOM from the shadow DOM. And they're -- the reasons you might want to do that, maybe you have like some boilerplate HTML and then you want the user to be able to -- the developer user to pass in a little HTML that drops into that spot. You could do it that way. So, it would say look in the window and it's rendered in the browser. And then they could change it to something like look in the mirror, whatever. And it would just pass in, you know, a different -- a
different thing into the slot. If this was an all day workshop, I would cover CSS with shadow DOM. But it's not. It's really complicated. I would recommend reading up about it because you'll learn so much about CSS if you're not familiar with how these interact. I did. It taught me just in general a lot of CSS things I didn't really know. Also, I want to emphasize: Shadow DOM adds complexity. It adds -- it makes things more complicated. It doesn't add problems that aren't solvable. But you have to be aware of what you're doing. So, I would say just use it when it's
needed. So, that was like a bird eye view of web component standards. There's a lot more you could say. But there's a native component model built into the browser now. Maybe it will help us reduce our JavaScript reliance, right? But web components won't save us automatically, right? For that, we need changes to our practices and patterns. One particular pattern that's resonated with me for a while now is this one Jeremy Keith calls HTML web components. The idea is to build web components as wrappers that go around functional HTML that works without JavaScript, right? You sort of use it as a progressive enhancement sort of model. Here's one of those. This is HTML web component
by Cloud 4. It lets you compare two images, pretty slick. And the cool thing is the HTML behind it, it's just two images, right? If something failed, if that failed to load or had an error, you could still look at the two images and kind of compare them. You'll find a lot more examples of those in Jeremy's article. But backing up here, before we reach to, you know, elegant patterns at all, I think we need to be exhausting all opportunities to just use what's built into the browser. We might not need web components at all. HTML and CSS is really good now. A lot has added to browsers that allow us to delete a lot of JavaScript. Have you seen popover yet? This is
a popover. It requires no JavaScript, you can wire two elements together and get interactivity. It works across browsers, it's beautiful. Use these, delete JavaScript. It was mentioned yesterday, but we're getting styleable select elements too. Huge. Designers are so excited about this. They can put
icons in the menu. It's been a big problem. It's not here yet, but keep an eye on this because we can start using them and delete some JavaScript. Often a lot. We can do transitions natively in browsers now. Support is growing. Right? We used to use frameworks just for this effect. A whole JavaScript framework just to get this thing that's now like three lines of code. So, use view transitions and delete some JavaScript. Responsive video works in browsers again. This is a pet favorite of mine. So, for local video files, you can negotiate between different sizes, deliver
the right one to a small device or a large device. I was able to help land the commits in Firefox for this feature last fall. It's -- I think it's really good. It needs more use. And lastly, CSS is just wildly popular now. This is a little experiment I did to just see how much of Wordle's
interactivity I could get to with just HTML and CSS. No JavaScript at all. I got pretty close, right? Like, you know, forms are kind of binary. yo don't have that middle state where it's like, yeah, you got the right letter and it's somewhere else in the row. But it's pretty close. You get greens at least. To do this, I'm using a pattern attributes on HTML input elements. And some CSS validation. I'll show you how that looks. It's kind of cool. It actually delays the validation effect to make you're done with the row. TR -- that's the table. TR that doesn't have it shown,
it's unfocused, and it's invalid, color it gray. And this one is kind of the same, but it's valid. Color it green. So, web components are not going to get us to this place this is more like, we need to re-evaluate how we're using our tools and think, can we use CSS? Do we need JavaScript? But when you need to enhance parts of the page, maybe you want to integrate web components into your page and there are great ways to transition. I think transitional approaches to web components are one of their best features. So, like if you have a single page app, you can start to build the little components in that app with web components, but still keep the wrapper in React or whatever the framework is. And slowly maybe ten years down the line,
React isn't gonna be the framework we're using anymore possibly. But the web components will live on. They're standard. When you need high-level orchestration and you're starting fresh, there are frameworks that are actually designed to work really well with web components now. So, enhance, I'm a really big fan of that one. It's so good. Enhance.dev, check it out. Webc, also a big fan of this one. This one is more for static generated sites like Eleventy, and Lit is a power tool like
a React sort of model. It drives Photoshop. It's the core layer that they built Spectrum on top of. So, great options. Also, great community around web components. This is the community group, you should check it out. They have regular meetings, they want people to give them feedback. Tune in. It's -- there's a lot going on. A lot of stuff is about to land in browsers. So, to wrap up,
web performance varies a lot today. Depending on browser conditions, right? I think web components offer some nice new standards that could help us reduce our overreliance on JavaScript, but they will not fix our problems automatically. What they can do is give us an opportunity to rethink how we can deliver websites more resiliency. And that's where you come in. Thank, if you're interested in learning more about web components, I've got a course. There's a little coupon code for Smashing. And thanks so much. VITALY: And fantastic. Thanks,
Scott. Join us for a conversation. SCOTT: Which chair do you like? VITALY: Left one, I'll go with left one. Well, interesting. It's interesting for me to see, we have been kind of -- I don't know why -- but over the last five, ten years, kind of going into camps. We have the web components camp. We have the React camp and then, of course, in the, you know, we have the Vue camp and all that have. And I'm wondering why are we so possessed by tool something SCOTT: Sorry? VITALY: We're kind of possessed by tooling. Going all in. It's really rare at least in my experience to see
somebody who is comfortable in web components and also in React. Like really being in both worlds. How do you think we can actually bridge that? SCOTT: Yeah, well, support for web components within frameworks has been a priority of all the major frameworks for a couple years now. Or maybe more than that. Several years now. And React was lagging a little bit. But the latest version, at least -- I don't know if it's stable yet, but React 19 has better support for web components. It comes down to attributes being strings and the way, you know, in HTML, they're always strings. React uses attributes to pass data, right? So, as props and that was, you
know, that was a -- I think that they had to adapt React to work better with. And I think there are more complexities with, you know, shadow DOM and things like that, that frankly a lot of us didn't see coming. Like it's -- it breaks the mental model of how the DOM is supposed to work. And so, you know, there are work arounds that were needed. But across the board now, if you count the new version of React that I'm not sure when it will be released, but maybe someone in the audience knows, supports good. I feel like you can use both and frameworks are very friendly with it.
VITALY: There was a question that came very quickly from Jon about performance. Any time to optimize it on Squarespace and WordPress? My company is all in on both sides of being in one environment or the other. And it's kind of the question of why haven't we -- I think we did bake in a lot of optimization efforts within WordPress and Wix and Squarespace and so on. But it still feels like -- especially in terms of accessibility, you see this weird thing. Like there are a lot of popular accessibility plugins for WordPress. And again, I know it's accessibility. But the only thing they do is to change the alt tag,
not with a descriptive description of an image, but just the file name. To, you know, "Comply." SCOTT: Yeah. VITALY: Yeah, performance, I feel like it's maybe the same story. We do a little bit, but it's not like a -- oh, you're going to be fast, right? WordPress is gonna be fast out of the box. So, what do you think? What do you think on that?
SCOTT: Yeah. So, a couple parts to this answer, I guess. First of all, I feel like those examples and several others sort of like never adopted the single-page app model for delivering websites. And now that new metrics are coming into sorts of penalize over-reliance on JavaScript, those approaches are starting to show up as like a good idea all along. WordPress is an example that can be fast. Not a lot in the way of delivering HTML. As far as Squarespace goes and similar tools like it, I know in that case I work on the performance team and this is our focus right now. I think, you know, it's -- it's an ongoing process. And we're -- we're auditing and looking for opportunities to improve all the time. But generally, you know, you get a
good experience out of the box. I would say that about, you know, broadly about CMSs like that. VITALY: Okay. I'm still hopeful that much of the work that must be done in terms of accessibility and performance will be kind of happening under-the-hood. I don't mean it in way of let's just give it all to AI. That's not the point. The point is to make sure we have good
defaults. Good process, good something that you can really comfortably, reliably build upon. SCOTT: I didn't cover it much in this talk. Typically performance talks when I did this sort of progression. I talk a lot about render blocking resources and that tends to be the problem on websites that are, you know, more like statically generated and have style sheets. The way you optimize the stylesheets matter when the browser is waiting before it can render the page visibly.
I would say in those sorts of environments that's the key thing to be keeping an eye on. And, you know, something we're looking at, certainly. VITALY: Now, a few questions here. One from Sara -- what are the accessibility implications for custom web components? Question. SCOTT: Right. I would say broadly, it's the same -- the same sort of implications that you would have with any HTML elements. You know, they -- if you think about it like a div, like that's
sort of what you're starting with. With the web component or a custom element. And then, you know, I would say beyond that, shadow DOM is when things start to get complicated with accessibility. To give you an example: If you were to have a label element that pairs with an input element and the input is inside a shadow DOM node, but the label is outside it, they can't talk to each other, right? So, this is like a well known and also like a problem that people are focusing on fixing. VITALY: Sure, yep. SCOTT: And that might have already happened by now. Like I haven't checked in the last
week. It moves really quickly. But ARIA has similar relationship problems between shadow and light DOM. That's just some of 'em. Shadow DOM form elements, you know, if they're in a shadow route, they don't submit with a form. You have to actually like communicate
out the state to the top of the component so that the form knows it's there and can submit normally when you -- when you submit without JavaScript. The tools are there to do that. But that's what I mean by like it adds -- VITALY: Complications? SCOTT: Yeah, that you have to know what you're doing. And I think shadow DOM is one of those power tools where like once you start with it, you need to consider a lot of factors of how it impacts. VITALY: Yeah. Brad Frost -- hm... Brad is wondering when should we not use web components? SCOTT: I mean, first of all, I think, you know, I was trying to say that there's often an HTML element that we could choose first, right? Or like CSS that we could use to pull off whatever we're trying to do. So, I would not reach for web components until I wanted to apply some sort of enhancement to the page that I couldn't pull off with all of the many new features that are landing in browsers so frequently lately. VITALY: Some of the conversations we have been having, some people get confused. Why web components when we could just have better HTML elements?
SCOTT: I think that's happening, right? You know, it's sort of like paving with the cow paths that happens continuously in web standards. You know? Like I used to be on the jQuery team and the whole idea of the framework, like, from the start, was to make itself obsolete, right? That was the goal. And it worked, right? Like we have query selector all, built into the browser now. And hopefully jQuery's deleted from your sites and you're using that instead. So, you know,
that's a process and I think that's gonna happen as people start using patterns over and over. And like Brad showed some of the groups that are working on building reusable components that we can use, you know, across different projects. VITALY: David is wondering, why do we need a framework like enhanced to use web components? Should we use them to build design systems? SCOTT: Yeah, so, I think they add a lot of value in a really lightweight way. So, enhance is
particularly neat because it assumes that you're not delivering JavaScript to the browser in the first place. You have to opt into that part. But it gives you this -- this model for using custom elements on the server side for composition. So, it's a lot like any component framework in that way. You're defining your header here and then you've got your menu that goes in the header. And you use on the -- in the template side of things, you compile them that way and it ships HTML to the browser. Enhance makes that really smooth because there's a nice handoff when you want to
take it further. Like it can pick up where the server left off, use the same template that you used to generate it. So, I particularly like that approach. Yeah. There are different -- different ways. I would say, you know, Lit is really broadly adopted for, you know,
highly-functional kind of app use cases. It's really battle tested, you know, Photoshop. Like, yeah. Can't really argue with that. It works. VITALY: I think also like this is also a question from here, we have been living in this world for first we said, let's go all in, like as you mentioned on the client, no, that's not good enough. Go all the way, somewhere closer to the server. And then in between, and then you have Next.js where you have the sort of pre-building and you have this sort of server side component part to it. And then so, what about static site generation then in general? Like at which point? And this is a question from MR, is still static site generation still something that we should be pushing for a lot? Because it doesn't require a ton of -- if it doesn't require a ton of interactivity? Or can we rely on Next.js and
others to do this partially for -- SCOTT: Yeah, totally. I'm a huge -- do we have any Eleventy fans in here? Eleventy is awesome. VITALY: Three of us! ha! Three and a half, I think. SCOTT: Yeah. Stat
sick like the ideal if you can get there, right? It will be the fastest way to return something from the server to the browser. So, if you can do that, and you can provide a service that is not fragile and too over-reliant on taking that static thing and changing it a lot after delivery, that's beautiful. I mean, that's the goal. Yeah. VITALY: Fantastic. So, just a final question to wrap up. So, what will you be writing the next million of JavaScript lines next? SCOTT: I think... I haven't gotten there yet. But I feel like the value of a developer is in how many lines you delete. VITALY: I like that. That's a good answer. SCOTT: All right. VITALY: So, I'm looking forward to you
deleting the million lines of JavaScript. SCOTT: Keep the good ones. VITALY: All right. Excellent. Thank you so much, Scott. SCOTT: Thanks so much. VITALY: Thank you.
2024-12-20 10:29
