Jan Miksovsky’s BlogArchive AboutContact

2015

Building web components from a loose framework of mixins

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.

Composing mixins to make a solid foundation for web components

We’ve been searching for a way to quickly create web components by composing together pre-defined user interface behaviors, and we have some progress to share on that front.

Web components are a great way to package user interface behavior, but they may not be the most interesting fundamental unit of behavior. There are certain aspects of behavior which you’d like to be able to share across components: accessibility, touch gestures, selection effects, and so on. Those things aren’t top-level components in their own right; they’re abstract aspects of behavior.

This is something like saying that a chemical molecule is not the fundamental unit of physical behavior — the atoms that make up the molecule are. But you can’t generally handle solitary atoms; atoms react and organize themselves into molecules. Likewise, a browser can only handle web components, not abstract behaviors. If we imagine a web component as a molecule, what’s the equivalent of an atom? That is, can we decompose a web component into a more fundamental coding unit?

One way to answer this question is to consider a web component as a custom element class. Is there a way we can decompose a class into its fundamental abstract behavioral aspects? The usual way to compose class behavior in JavaScript is with mixins, so perhaps mixins can form the fundamental unit of user interface behavior. That is, we’d like to be able to compose mixins together to create web component classes.

For that purpose, mixins present some challenges:

We thought it would be interesting to create a general-purpose mixin architecture that’s flexible enough to serve as a foundation for creating web components in plain JavaScript. The initial result of that work is a facility we call Composable.

Composable takes the form of a general-purpose factory for composing classes and objects from mixins. The most interesting part about it is its use of composition rules that let you decide how a mixin’s properties and methods should be combined with those of the class you’re adding the mixin to.

Composable itself is entirely independent of web components, but we’ve designed it to serve as a micro-kernel for web component library or framework. An example in the Composable ReadMe illustrates how it could be used to construct web components:

// Create a general-purpose element base class that supports composition.
let ComposableElement = Composable.compose.call(HTMLElement, Composable);

// A mixin that sets an element's text content.
class HelloMixin {
  createdCallback() {
    this.textContent = "Hello, world!";
  }
}

// A sample element class that uses the above mixin.
let HelloElement = ComposableElement.compose(HelloMixin);

// Register the sample element class with the browser.
document.registerElement('hello-element', HelloElement);

// Create an instance of our new element class.
let element = document.createElement('hello-element');
document.body.appendChild(element); // "Hello, world!"

We’ll share more on this direction as we go, but for now we wanted to share this as a fundamental building block. Even if you’re not creating web components, you could use Composable to give your application or framework a flexible mixin architecture.

An evaluation of polymer-micro as a minimal web component framework

Our Basic Web Components project currently creates its components using Google's Polymer framework, but we've been evaluating the use of the smaller polymer-micro core as a replacement for full Polymer. The polymer-micro core appears to be a useful web component framework in its own right, and may provide nearly everything a component library like ours needs.

Is Polymer the best choice for our open project?

We believe that some amount of framework is necessary to create web components. For a very long time, Polymer has been the primary web component framework. We love Polymer! However, we feel that Polymer has grown to the point where writing a Polymer app feels distinctly different from writing a typical HTML app.

Polymer provides numerous helpers that reduce the amount of copy-and-paste boilerplate code required to invoke standard DOM features. In current parlance, it wants to make component code as DRY as possible. For example, Polymer provides a "listeners" key for wiring up event handlers with less code than a direct invocation of the underlying addEventListener(). Polymer's "properties" key similarly simplifies definition of component properties instead of directly defining property getter/setters on the component prototype and marshalling attributes to properties with attributeChanged().

We think Polymer's goal is commendable. If you can afford to train up a team of developers on Polymer's specific way of doing things, your team should be able to crank out web UI code very efficiently.

But as with any higher-level abstraction, these helpers trade off clarity and simplicity for a certain degree of magic and complexity. Each reduction in the amount of component code a developer must write forces an increase in the arcane Polymer-specific knowledge a developer must acquire to write or even read component code. It also hides details that may complicate debugging and maintenance.

For our open source project, those second-order effects reduce the potential pool of project contributors. Our priority is not time-to-market, but rather creating code which is self-evident to our open source users and potential contributors. Although 1 line of Polymer code might do the work of 3 lines of standard web code, if those 3 lines are more understandable to a wider base of developers, we might prefer the longer, clearer version.

Carrying forward the burden of backward compatibility

Another issue we're grappling with is Polymer is very much designed for this era immediately before web components emerge with native support across all mainstream browsers. Polymer wants, quite reasonably, to accommodate browsers that don't yet support web components. At the same time, Polymer also wants to deliver decent performance, notably on Mobile Safari, which at this time does not support native Shadow DOM. Rather than use the full Shadow DOM polyfill, Polymer introduced its own Shady DOM approach for approximating Shadow DOM behavior on older browsers.

Shady DOM is an impressive technical accomplishment. But having written a great deal of Shady DOM code this year, it's our subjective opinion that Shady DOM code feels clunky. Even after months of writing Shady DOM code, wrapping DOM calls with Polymer.dom() still doesn't feel natural. And it's hard to explain to someone why they can't just call appendChild(), but have to call Polymer.dom().appendChild() instead. And while Polymer.dom() is somewhat future-proof, it doesn't feel future-facing. It erodes the original, extremely elegant vision for Polymer and the web components polyfills: to let people to write web components for future web browsers today.

The alternative to Shady DOM today is to use the full Shadow DOM polyfill. That entails slower performance and — given inevitable leaks in the abstraction — a greater potential for mysterious bugs. On the plus side, the full Shadow DOM polyfill lets one write clearer, future-facing code. With all the major browser vendors on board with Shadow DOM v1, the need to download and use the Shadow DOM polyfill on most devices should fade over the course of 2016.

We're also excited about the advent of ES6, with features like arrow functions that let code be more concise. Writing an addEventListener() call is no longer a substantial burden in ES6, or at least not enough to warrant a parallel system for event listener wiring. And using built-in ES6 classes feels better than calling a purpose-focused class factory like Polymer().

Considering polymer-micro instead of full Polymer

It turns out that, underneath all of Polymer's DRY magic, there's a very clean, simple core called polymer-micro. Polymer is helpfully constructed in three layers: full Polymer on top, a smaller polymer-mini below that, then a tiny polymer-micro at the bottom. The documentation describes polymer-micro as "bare-minimum Custom Element sugaring".

Rather than use the full Polymer framework, we've been investigating whether polymer-micro on its own could meet our needs. Building on top of polymer-micro confers a number of advantages over writing our own web component framework:

The polymer-micro layer happens to provide most of the features upon which Basic Web Components depend:

On the flip side, Basic Web Components use a number of Polymer features which polymer-micro does not provide:

  1. Shadow root Instantiation. If you use polymer-micro, you're expected to create a shadow root yourself.

  2. Templates. If you want to use the <template> element to define initial content of a component's Shadow DOM, you need to manage that yourself.

  3. Shimming for CSS styles. The full Shadow DOM polyfill requires that CSS be transformed to minimize styles leaking across a custom element boundaries. Full Polymer takes care of that for you, but using polymer-micro directly means that style shimming becomes your concern.

  4. Automatic node finding. This lets your component code refer to a sub-element <button id="foo"> with this.$.foo. Complex components need a consistent and easy way to refer to subelements within the local Shadow DOM. Polymer's this.$ syntax satisfies those criteria, although we're really torn as to whether that sugar is worth it. It saves keystrokes, but isn't a web-wide convention. It may give an unfamiliar flavor to web component code.

  5. ready() callback. Many of the Basic Web Components use Polymer's ready callback to initialize themselves. Polymer takes pains to ensure that any Polymer elements inside a component's local Shadow DOM have their own ready callback fired before the outer component's ready callback is fired.

  6. CSS mixins. This is Polymer's current answer for visual themes for components. It's based on a not-yet-standard proposal for extensions to CSS. Without full Polymer, you have to invent your own theming architecture.

All the above features are provided at the levels above polymer-micro: either polymer-mini or full Polymer. However, those upper levels bring along a number of features we don't use, or would be happy to drop. Those features include:

These features all have some appeal, but in our estimation may add more complexity than they're worth to an open source project aiming for a general developer audience.

Lastly, there are a few higher-level Polymer features we have to use, but wish we didn't have to:

Prototyping a minimal component framework on top of polymer-micro

With the above motivation, we considered the question: What is the smallest amount of code that must be added to polymer-micro to create a web component framework that meets our project's needs?

This experiment entailed a fair amount of spelunking in the Polymer codebase. That exploration informed the creation of a little prototype web component framework called polymer-micro-test that uses only polymer-micro as its base. In this prototype framework, we wrote a small amount of code (minimalComponent.js) to implement the 5 numbered features above which we want but are missing in polymer-micro.

We then used the prototype framework to create a couple of sample components, such as a sample test-element component. A live demo of a simple page shows the test-element component in use. By virtue of using the full polyfills, components created in this prototype framework can run in all mainstream browsers.

Overall, the results of this experiment were fairly positive. Looking at each feature in turn:

  1. Creating a shadow root yourself is easy. This is only necessary for components with templates (next point).

  2. Stamping out a template is easy. The smallest amount of code we could envision for this is for a component to declare a "template" property. This can be used in conjunction with HTML Imports for a fairly clean connection between the script and the template:

    <template id="test-element">
      ... template goes here ...
    </template>
    
    

    <script> Polymer({ is: 'test-element', template: currentImport.querySelector('#test-element') }); </script>

    Aside: we really like being able to use a plain template to define component content. It turns out that you can actually do this in full Polymer today, although it's something of a trick that depends upon your component defining an undocumented _template variable. See this gist, which works in full Polymer.

  3. Shimming CSS styles took a little investigation, but it turns out the full Shadow DOM polyfill exposes its CSS-shimming code as ShadowCSS. The first time this test framework is going to stamp a template, it just invokes ShadowCSS to shim any <style> elements found in the template. It then saves the shimmed result for subsequent stamping into the shadow root.

  4. Automatic node finding. If we conclude we really need this feature, it's not that hard to implement ourselves. Right after the test framework stamps a template, it queries for all the elements in the shadow tree that have an id attribute, then adds those elements to this.$. This gives us a type of automatic node finding that meets our needs. Polymer's own implementation of the same feature is much more complex. It appears to do a lot of tree-parsing so in preparation for data binding, but since we don't need data binding, we don't need to do that work.

  5. The ready() method is a bit of a puzzle to us. The Shadow DOM spec already defines two callbacks, createdCallback() and attachedCallback(), that can cover most of what we're currently doing in ready(). One issue is that createdCallback() and attachedCallback() are synchronous, while the Polymer ready() code takes enormous pains to handle asynchronous calls. That is likely necessary to support their asynchronous data binding model. That is, if your component has a sub-component with data bindings, you want all those asynchronous data bindings to settle down first before your top-level component does its own initialization. Since we're not interested in data binding, however, it's not clear whether we need ready(). Our sample element just uses the standard callbacks.

  6. CSS mixins. This remains an open question for us. It's hard to imagine what we could do to allow component users to theme our components. At the same time, we're not convinced that the not-yet-standard CSS mixins are going to actually become a standard. The troubled history of vendor-prefixed CSS feature experiments suggests that one company's early interpretation of a hypothetical, future CSS mixin "standard" might significantly complicate things down the road when a real standard is finally established.

This small prototype framework delivers most of the features required by Basic Web Components. The main exception is that it offers no facility for component theming (point #6 above).

Some other notes:

Conclusions

While this is just an experiment, it's intriguing to consider using polymer-micro as the basis for a minimalist web component framework.

Despite these advantages, we're not yet ready to say that we're actually going to use this prototype to create components. As noted above, our goal is to foster a codebase that can be readily comprehensible to a wide audience of web developers. Using a proprietary framework, even a tiny one, impedes that goal. (Basic Web Components traces its ancestry to an earlier component library called QuickUI which never gained critical mass, in part because it was built on a proprietary framework.)

Using polymer-micro as the basis for a proprietary framework would be better than writing a framework from scratch, but every bit of code added on top of polymer-micro runs the risk of producing a framework in its own right — one distinct and unfamiliar to our developer audience.

A minimalist strategy like this would only have meaning to us if it's shared by other people. To that end, we've begun talking with other web component organizations to explore this idea a bit further. We're not sure where that discussion will go, but it's interesting, and might bear fruit in the form of a new, minimalist web component framework. If you'd be interested in participating in that discussion, please ping us at @ComponentK.

Nobody writes production web components in vanilla JS — so using a framework makes total sense

You may hear someone say they avoid using React, Polymer, Angular, or some other framework du jour, and that they prefer to write their front end code in vanilla JavaScript instead. But when it comes to writing web components, it seems everybody ends up writing atop a framework — even if it's a tiny framework of their own devising. Production web components written in vanilla JS appear to be very rare.

It seems there's just a bit too much work involved to meet even baseline expectations for a custom element. To handle instantiation, for example, you might need to:

  1. Create a shadow root on the new instance.

  2. Stamp a template into the shadow root.

  3. Marshall any attributes from the element root to the corresponding component properties. This process breaks down into more work, such as:

    • Loop over the set of attributes on the element.
    • For each attribute, see if the component defines a corresponding property. If you want to support conventionally hyphenated attribute names ("foo-bar"), you'll want to first map those attribute names to conventionally camel-cased property names (fooBar).
    • If the type of a target property is numeric or boolean, parse the string-valued attribute to convert it to a value of the desired type.
    • Set the property to the value.

Given this amount of work to simply instantiate the component, it's easy to see why most efforts to create interesting components typically end up relying on shared code. You might write a single web component in vanilla JS, but as soon as you start your second component, you'll be dying to factor the boilerplate into shared code… And now you're constructing a framework.

That's not necessarily a bad thing. It only means that, when you hear someone say that they want to write a component-based app, but don't want to use any framework at all, you have to take that with a grain of salt. It's possible the person has — perhaps unintentionally — ended up building the foundations of their own web component framework.

Does it matter whether that code is called a framework? Wikipedia enumerates these software framework hallmarks:

Given this definition, it seems hard to conclude that frameworks are bad per se. Surely there are good frameworks as well as bad frameworks.

Perhaps one reason people shy away from the concept of a framework is that, as a framework achieves higher levels of abstraction, it becomes something tantamount to a domain-specific language. If you and I both thoroughly understand JavaScript, but we are using different JavaScript frameworks, then in practice we may not find each other's code mutually intelligible.

Since the term "framework" can provoke strong negative reactions, authors of such code may actually care whether their code is labeled a framework or not. Google, for example, seems to take great pains to avoid describing its own Polymer project as a framework. They call it a "library", which sounds perhaps smaller or less threatening. But Polymer easily meets all of the above framework criteria. For example, Polymer's internal asynchronous task-scheduling infrastructure establishes the flow of control in a Polymer application, determining when to invoke component lifecycle callbacks and property observers.

Whether you like the idea of a framework or not, when it comes to web components, the DOM API is so rudimentary that, in practice, that API alone does not provide a sufficient framework for web component development. As long as that remains the case, the use of a JavaScript web component frameworks seems unavoidable. If you really, really want to avoid writing or using code that meets the above definition of "framework", perhaps you can do so and still be productive, but that seems like a hard way to go.

For our own work, we want to be using a popular web component framework, be it Polymer or something else. If our alternative were to write a proprietary, ad hoc framework of our own, which was shared by no one else, we would likely waste a lot of time solving problems others have already solved.

We’re shutting down our web component catalog

We launched this Component Kitchen site in April 2014 with a web component catalog as its centerpiece. Today we're shutting down that catalog so we can focus on web component consulting and our open web components projects, including the Gold Standard Checklist for Web Components and the general-purpose Basic Web Components library.

Running the component catalog was a great way to learn about building production applications using web components and Google's Polymer library. But we've come to feel that the catalog's utility is limited, and it no longer makes economic sense to continue it.

Retiring the catalog lets us invest more time in the projects that we think matter more. People who want a component catalog can use customelements.io, which has seen many improvements lately. Also, as a service to people who have made deep links to our catalog's component pages, for the indefinite future we will continue to serve up tombstone pages at those URLs that offer a link to the corresponding repository on GitHub.

When we started our catalog, there were only about 40 publicly registered web components — now the number is in the thousands. We really appreciate all of the people who visited our catalog in the last year and a half, who built a great component we could feature, and who took the time to give us feedback or a shout-out on social sites. We're still excited to be working in this transformative web components space, and look forward to sharing our ongoing work here soon.

The Gold Standard checklist for web components

For the last few months, we’ve been excited to help a new open project get off the ground: the Gold Standard checklist for web components. The checklist’s goal is to define a consistent, high quality bar for web components.

We believe web components should be every bit as predictable, flexible, reliable, and useful as standard HTML elements. When someone is working in HTML, they should be able to work as if all elements work the same. They shouldn’t need to learn a special set of constraints or limitations that apply to specific custom elements. They already know how standard HTML elements behave; new custom elements should behave just like that.

The standard HTML elements establish an incredibly high bar for quality. For example, you can use the standard elements in any combination, and they’ll not only work, the result is usually predictable and reasonable. But, without a great deal of care, custom elements don’t support that same degree of flexibility by default. It’s all too easy to create a custom element that only works when it’s used in a very particular way.

The project began by defining what it is that makes a standard HTML element feel like a standard HTML element. It seems no one before ever wrote down all the criteria that govern the expected behavior of a new standard HTML element. We all generally know how HTML elements should behave, and through careful design and testing, new standard elements eventually measure up to our expectations.

You can think of this as a Turing Test for elements: if you were to encounter an unfamiliar element in HTML, could you tell whether it was a new standard element or a custom element? For most custom elements today, it wouldn’t take too long to discover some unexpected quirk or limitation in the element that would reveal its custom element nature. This is not for lack of dedication on the component author’s part. It could simply be the case that they hadn’t considered some aspect of standard element behavior.

To address that, the Gold Standard checklist captures the expected behavior of a standard HTML element in a form that can guide the creation of new custom elements. The checklist covers a wide range of topics, from accessibility to performance to visual presentation. A component that meets that quality bar should be able to generally satisfy all the expectations of people using that component. This will greatly facilitating the component’s adoption and use.

A variety of people, particularly from Google, have already contributed to the Gold Standard checklist in its draft stages, and continue to make contributions to the checklist in its new wiki form. The initial focus of the project has been to develop a solid set of top-level checklist items. It’s the hope of the project contributors that every item on the list will be backed by a detailed explanation of the checklist item: why it’s important, examples of what to do or not to do, sample source code, and other resources.

If you’re interested in creating or using high-quality components, please take a look at the checklist. The project welcomes comments and suggestions as issues, or direct contributions through pull requests.

Try our interactive web components tutorial

We’ve just posted an interactive web components tutorial that teaches the basic concepts with editable live demos. We hope you’ll find that this tutorial:

Please check it out, share it, and let us know what you think!