Dave Rupert:
Through stalking the #WebComponents hashtag and my Frontend Masters course, I’m privy to a lot of developers’ first experiences with web components. There’s a wide range of people digging in, but the most common first-time experience I come across is a developer coming from a classical component framework like React with JSX going straight to writing vanilla Web Components, becoming frustrated, and then deeming web components “not ready for primetime.”
The gist here is that HTML Web Components aren’t really meant to replace these frameworks at all and that’s something I really struggled with until I had my eureka moment a few months ago:
I don’t think we should see web components like the ones you might find in a huge monolithic React app: your Button or Table or Input components. Instead, I’ve started to come around and see Web Components as filling in the blanks of what we can do with hypertext: they’re really just small, reusable chunks of code that extends the language of HTML.
Scott Jehl just kickstarted his course on web components and it just sounds great:
Fortunately, we now have a standard component model built right into our browsers, and using its various technologies can help us cut delivery weight and reduce complexity. Many of the largest companies in the world have already begun transitioning their sites and design systems to use web components, and major JavaScript libraries like React have greatly improved their compatibility to work with them as well. And while web components are indeed ready for production today, in the coming months several specifications are shaping up to make them even better. This course aims to cover all of that.
Can’t wait.
Smart take here from Jeremy about composable design systems:
Colours, spacing, type; these are all building blocks that a designer can compose with. But it gets murkier after that. Pre-made form fields? Sure. Pre-made forms? No thank you!
It’s like there’s a line where a design system crosses over from being a useful toolkit into being a bureaucratic hurdle to overcome. When you hear a designer complaining that a design system is stifling their creativity, I bet it’s because that line has been crossed.
Jeremy argues that design systems should have many small pieces that can be easily reconfigured—and this happens to tie in nicely from another post of his about HTML web components:
...what if my web component needs to do two things?
I make two web components.
The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.
Yes! This is precisely why I started ranting a while back about how, whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”
HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes from: everything has one job, does it really well (ideally), which makes the possible options almost infinite.
Design systems should hope for the same.