Building web components from a loose framework of mixins

By Jan Miksovsky on December 7, 2015

We think it’s generally necessary to use some sort of framework to develop web components, but that framework may not have to be monolithic in nature. Instead, the framework might be built entirely as mixins on top of a kernel that enables mixin composition. Rather than invoking a framework’s class constructor, one would simply compose the desired mixins together to create an instantiable web component.

We’ve been prototyping a completely mixin-oriented approach to component development in a project called core-component-mixins.

Taken collectively, these core component mixins form the beginnings of a deliberately loose but useful framework for web component development. They’re still rudimentary, but they already provide much of what we need from a layer like polymer-micro. We think this strategy confers a number of advantages:

  1. This is closer to the metal. The only new thing here is the concept of a mixin. Everything else is part of the web platform. There’s no special class constructor required to perform black-box operations on a component. There’s nothing new to master (like React’s JSX or Polymer’s <dom-element>) that’s not already in the platform. There's no sugaring provided out of the box — and that’s a good thing.
  2. Each mixin can focus on doing a single task really well. For example, the TemplateStamping mixin just creates a shadow root and stamps a template into it. The only real work it’s doing is to normalize the use of native vs polyfilled Shadow DOM — that is, the work you’d need to do anyway to work on all browsers today. Given the boilerplate nature of that task, it’s reasonable to share that code with a mixin like this. Once all the browsers support Shadow DOM v1 natively, this mixin could be simplified, or dropped entirely, without needing to rearchitect everything.
  3. You can stay as close to/far from the platform as you want. Most user interface frameworks take you far away from the platform in one giant step. Here you have fine-grained control over each step you take toward a higher level of abstraction. Each mixin takes you a tiny bit further away from the platform, and in exchange for the efficiency boost the mixin provides, you have to accept some trade-offs: performance, mystery, etc. That’s an unavoidable price for sharing code, but at least this way you can decide how much you want to pay.
  4. There's a potential for cross-framework mixins. If multiple web component frameworks could agree on a mixin architecture, there’d at least be a chance we could share good solutions to common higher-level problems at the sub-component level. When Component Kitchen creates a mixin to support, say, accessibility in a list-like web component, it would be great if we could make that available to people developing list-like web components in other frameworks. While any framework could in theory adopt some other framework’s mixin format, mixins are usually intimately tied to a framework. Explicitly deciding to factor mixins into a separable concept may make cross-framework mixins more feasible.

It’s worth remembering that web components are, by their very nature, interoperable. If you decide to write a component using an approach like this, it’s still available to someone who’s using a different framework (Polymer, say). The reverse is also true. That means any team can pick the approach that works for them, while still sharing user interface elements at the component level.

As we’re experimenting with these mixin ideas in prototype form, we’re opportunistically trying some other technology choices at the same time:

This mixin-based component framework isn’t done, but feels like it’s reached the point where it’s “good enough to criticize”. Please share your feedback at; @Component or +ComponentKitchen.

Tweet

« Blog home