…
I still think web components are a great foundation for a design system. No other approach gives you true cross-framework portability built on what the web platform already provides. The problem isn’t necessarily the model itself, it’s how we’ve been building them.
This is how I ended up creating Elena, a library that I’m open sourcing today. Elena starts from HTML and CSS, and stays grounded in web standards and what the web platform natively provides.
…
I love the “HTML Web Components”/”Progressive Web Components”1 development pattern. The idea is, if you’re new to it:
- Write the HTML to provide as much functionality as possible
- Wrap it in a custom element
- Use that custom element to enhance the component with anything only JS can provide
The downside is that there’s often more scaffolding than you’d like: implementing event and property change listeners (and tidying them on disconnection), batching updates to avoid flicker, and all that jazz.
Now obviously you could go with one of the big heavyweight frameworks like React, but then you’re leaning into a whole locked-in architecture that makes it harder to write progressive components and burdens your users with a ton of unnecessary code. Boo!
That’s why I love it when clever people make useful, HTML-friendly, ultra-lightweight frameworks2 like ReefJS, which I’ve talked about using before, and – now – Elena!
Elena’s a modern, simple, MIT-licensed wrapper framework for your web components, and – having perused the documentation on-and-off for the last couple of days – it’s really exciting. Perhaps not because of what it does, but because of what it doesn’t do. It’s unopinionated, well-documented, SSR-friendly3 microframework that seems to bring the absolute best in what the Web offers via web components… and makes it easier for developers without making end-users pay the price for it.
Anyway: all of which is to say: check out Elena! I’m really excited to have a play with it the next time I have a suitable web components project.
Footnotes
1 I’m with Jeremy: “Progressive Web Components” is a better name. Also: it’s it funny how changing just one word of a name can make you re-think what a thing is. The moment I refactored the way I thought about HTML Web Components into calling them Progressive Web Components was the moment I said to myself “hey, I could put an SVG into one of those… use state-managed props to set CSS variables that are available to the image… and in doing so, produce an SVG that elegantly becomes animated where JS is available…”
2 I same “frameworks”: by the time they’re this lightweight, single-purpose, and focussed on adding functionality that perhaps vanilla JS and web components should already have we might as well call them utility libraries or polyfills!
3 SSR perhaps ought not to matter for Progressive Web Components, but I can imagine situations where Elena would still be useful even for web components without a HTML fallback, at which point I suppose SSR could be a performance shortcut for some projects.