Native web components are on the rise. You don't believe it? Here are some statistics to prove otherwise:
According to chromestatus.com as of January 1st, 2022 about
17.5%of web page loads made use of the CustomElementRegistryDefine feature to define custom elements. On the 1st of January 2021, that number was only about10%.According to caniuse.com the browser support for the Custom Elements (V1) spec, is at about
93.85%.
Web component flaws
So why isn't everybody switching over to web components? Well, multiple reasons. If you ever googled web components and tried to implement them, you would soon realize working with the barebones web components API is no fun. Plus there are tons of features missing that you are accustomed to from common frameworks like Vue, React or Angular. Additionally, they are overly complex, thus setting the barrier to entry unreasonably high.
There are certainly some other shortcomings but if the developer experience of the system is bad nobody will try to dig deeper.
What I noticed right off the bat is that a lot of people think they are forced to choose between a framework or native web components for their projects. But here in lies the flaw, it's not an either-or.
Thinking outside the box
Everybody had high expectations for native web components but they never lived up to the hype and faded somewhat into the background while React and Vue still remained in the spotlight.
I think that is about to change, but first, we need to reframe how we think about web components. Native web components are not here to replace common frameworks but instead should be used complementary.
The strength of web components is their universality, since they're native you can use them anywhere, which makes them perfectly suitable for design systems.
A Design System is a set of interconnected patterns and shared practices coherently organized.
This means if you are using native web components for your design system you don't have to write the same set of components for every single framework and legacy application that you are using.
After crafting a bunch of web components for multiple projects myself and fiddling with the web components API, I knew another solution would be required to make working with web components a breeze, and thus Minze was born.
Minze
What is Minze? Minze is a dead-simple framework for shareable web components. It provides an intuitive abstraction layer around the web components API for creating encapsulated, reusable, cross-framework web components.
Features
- 👶 Simple - Dive right in by scaffolding a project or using a CDN link.
- ⚡ Fast - Tiny footprint ~2KB (minified and compressed).
- 🚀 Modern - Based on the latest technologies around web components.
- 📦 Shareable - Build component libraries or design systems. Define once, use everywhere.
- 🎲 Framework Agnostic - Use Minze with any common framework - React, Vue, Angular ...
- 🔒 Typed API - Scale your component library with ease by using TypeScript.
Example
Here's what Minze looks like included via npm:
import { MinzeElement } from 'minze'
class MyElement extends MinzeElement {
html = () => `Hello Minze!`
}
MyElement.define()
<my-element></my-element>
And here's what Minze looks like included via CDN:
<html>
<head></head>
<body>
<my-element></my-element>
<script src="//unpkg.com/minze@latest" defer></script>
<script type="module">
class MyElement extends MinzeElement {
html = () => `Hello Minze!`
}
MyElement.define()
</script>
</body>
</html>
Easy, right? Feel free to share your thoughts on the web components topic in the comments below.
Find out more about Minze
Top comments (2)
Can you please make a comparison between Minze and the other 58 libraries that claim to make Web Components development easier
So is the main advantage of native web components the ability to reuse components between frameworks? Because if you still need a framework for the application layer it seems very similar to me just doing everything inside the framework with library components like Material UI. I suppose I should just dive in to try to understand the differences but am torn where to start with between Lit/native WC, Qwikjs, and architect/FWAs