In his last An Event Apart talk, Dave made a point that it’s really only just about right now that Web Components are becoming a practical choice for production web development. For example, it has only been about a year since Edge went Chromium. Before that, Edge didn’t support any Web Component stuff. If you were shipping them long ago, you were doing so with fairly big polyfills, or in a progressive-enhancement style, where if they failed, they did so gracefully or in a controlled environment, say, an intranet where everyone has the same computer (or in something like Electron).
In my opinion, Web Components still have a ways to go to be compelling to most developers, but they are getting there. One thing that I think will push their adoption along is the incredibly easy DX of pre-built components thanks to, in part, ES Modules and how easy it is to import JavaScript.
I’ve mentioned this one before: look how silly-easy it is to use Nolan Lawson’s emoji picker:
That’s one line of JavaScript and one line of HTML to get it working, and another one line of JavaScript to wire it up and return a JSON response of a selection.
Compelling, indeed. DX, you might call it.
Web Components like that aren’t alone, hence the title of this post. Dave put together a list of Awesome Standalones. That is, Web Components that aren’t a part of some bigger more complex system1, but are just little drop-in doodads that are useful on their own, just like the emoji picker. Dave’s repo lists about 20 of them.
Take this one from GitHub (the company), a copy-to-clipboard Web Component:
Pretty sweet for something that comes across the wire at ~3KB. The production story is whatever you want it to be. Use it off the CDN. Bundle it up with your stuff. Leave it as on-demand one-off. Whatever. It’s darn easy to use. In the case of this standalone, there isn’t even any Shadow DOM to deal with.
No shade on Shadow DOM, that’s perhaps the most useful feature of Web Components (and cannot be replicated by a library since it’s a native browser feature), but the options for styling it aren’t my favorite. And if you used three different standalone components with three different opinions on how to style through the Shadow DOM, that’s going to get annoying.
What I picture is developers dipping their toes into stuff like this, seeing the benefits, and using more and more of them in what they are building, and even building their own. Building a design system from Web Components seems like a real sweet spot to me, like many big names2 already do.
The dream is for people to actually consolidate common UI patterns. Like, even if we never get native HTML “tabs” it’s possible that a Web Component could provide them, get the UI, UX, and accessibility perfect, yet leave them style-able such that literally any website could use them. But first, that needs to exist.
- That’s a cool way to use Web Components, too, but easy gets attention, and that matters. ⮑
- People always mention Lightning Design System as a Web Components-based design system, but I’m not seeing it. For example, this accordion looks like semantic HTML with class names, not Web Components. What am I missing? ⮑
If you would have posted those examples 15 years ago with a instead of the import and a
<div>with a specific class nobody would be suprised. I really dont understand what the fuzz with web conponents is ever since the first day I heard of themSure, you could just use a
<div class=clipboard></div>. But the value of web components might be compared to the<video>tag: default display (buttons and whatnot) and interactions (play, pause, scrub, etc) are encapsulated into an HTML API.To use
<video>, just read the docs on that tag. Oh look, a whole<video>JS API!playbackRate! subtitles API!) Rad stuff! Do the basics viaHTMLandCSS, or get fancy withJS. So, just port that whole mindset to anything at all. Web components are a wonderful design for encapsulating all kinds of functionality into a form which is 100% familiar to web developers everywhere.I don’t GET it so I don’t LIKE it. ROAR!!!!
Sure but can you put that code snippet anywhere? Can you be sure none of the code and styles won’t conflict with anything else? Can it be framework agnostic? Or since you mentioned 15 years ago, does it’s jQuery conflict with my jQuery?
I hate to nitpick but the clipboard copy example isn’t working for me on Edge (v90, Win 10). It did work immediately in Chrome, however.
Teething problems most likely, but still!
Could be the iframe.
Try debug mode. https://cdpn.io/chriscoyier/debug/ZELdMvB
For some reason, it doesn’t work on CodePen. Here’s a working example: https://github.github.io/clipboard-copy-element/examples/
I am really excited about Web Components getting closer and closer to a “production-ready” state. I kept my eyes on them at least since Shadow DOM landed in Firefox a few years ago.
I think they offer great opportunities for webapps where one needs JS, in contrast to webpages, if you excuse this somewhat unrealistic black and white framing.
In the latter the proliferation of web components introduces additional complexity to progressive enhancement or – I’m afraid – means even fewer content accessible to users who are wary about running javascript – for whatever reason, security, privacy, etc.
Of course, standard HTML-Elements can be placed inside custom elements and styled with CSS to fallback on. It is possible, no doubt.
And that isn’t a problem with an emoji picker, since that is just nice to have, but when I hear my colleagues suggest rebuilding cards or even “links with that one extra functionality”, then I worry a bit. Sometimes.
Yes, that LWC “Accordion” is a lot of oldskool code.
You can create an Accordion by using standard HTML <detail> and <summary> managed by a Web Component one-liner:
Documented: https://dev.to/dannyengelman/acme-the-accordion-web-component-in-187-bytes-47ah
I wouldn’t consider that Accordion example as a Web Component. IMO, proper Web Components wouldn’t leak implementation details such as class names, or require specific HTML structure do actually work. A proper Accordion Web Component would be something like
Basically, a Web Component would be a self-contained concept, with declarative behavior definitions via attributes, and an imperative API via the its
class extends HTMLElementclass definition. (And with the possibility of requiring other Web Components as children, for complex interplays, just like<ul>requires<li>.)