A new release of Basic Web Components based on plain JavaScript component mixins

As discussed in this blog over the past few months, we’ve been plotting a strategy for creating web components using a library of plain JavaScript mixins instead of a monolithic component framework. We’ve just published a new 0.7 release of the basic-web-components project that represents a transition to this mixin strategy. So far, this approach appears to be working well, and meeting our expectations.

What’s changed?

1. We’ve begun rewriting all our components in ES6. So far, we’ve rewritten the basic-autosize-textarea, basic-carousel, and basic-list-box components in ES6. We transpile the ES6 source to ES5 using Babel. Developers wanting to incorporate the components into ES6 applications can consume the original source, while devs working in ES5 can still easily incorporate these components into their applications.
2. We have restructured the way we distribute these components to use npm 3 instead of Bower. The primary basic-web-components repository is now a monorepo: a single repository used to manage multiple packages separately registered with npm. This is much, much easier for us to maintain than our prior arrangement, in which Bower had forced us to maintain a constellation of separate repositories for our Bower packages. Using npm for web component distribution will likely bring its own challenges, but we’re confident the much larger npm community will address those issues over time.
3. Because we are just using JavaScript now, component files can be included with regular script tags instead of HTML Imports. That erases any concerns about cross-browser support for HTML Imports, and generally simplifies including these web components in an existing application build process. For example, instead of requiring use of a specialized tool like Vulcanize, developers can incorporate Basic Web Components into their applications using more popular tools like Browserify and WebPack.
4. We are now offering a library of web component JavaScript mixins. See this blog post for some background on that strategy. Mixins take the form of functions that can be applied to any component class without requiring a common runtime or framework. These mixins are collected in a new package, basic-component-mixins. See that package for details, including documentation our initial set of 25 web component mixins. We believe this arrangement will make it much easier for people to adopt key features of the Basic Web Components in their own components.

As we first noted when we first looked at using polymer-micro instead of full Polymer, there are some distinct downsides to moving away from full Polymer:

• We can no longer use Polymer’s Shady DOM to emulate Shadow DOM on older browsers, so anyone targeting browsers other than Google Chrome must include the full webcomponents.js polyfill. However, all four browser vendors are racing to implement native Shadow DOM v1, and it seems likely we will see all of them deliver native supoprt later this year. While using the full polyfill incurs a performance penalty today, we are very happy to be writing code that is squarely aimed at the future.
• We are left for the time being without a simple way to let developers style our components. Polymer provided a plausible styling solution, although it’s based on CSS Variables (not in all browsers yet), and relies on proprietary extensions to CSS Variables (non-standard; unlikely to appear in any browser soon). So styling remains an issue for us — but then again, it’s currently an unsolved problem for web components generally.

Overall, for our project, we think the advantages of writing in plain JavaScript outweight any disadvantages. We’re very happy to be able to write highly functional web components without having to use a monolithic framework and an accompanying required runtime. And so far, our mixin strategy is letting us maintain an elegant factoring of our component code, while avoiding the limitations of a single-inheritance class hierarchy.

That said, we think frameworks are certainly an appropriate tool for many teams. For certain projects, we enjoy working in frameworks such as Polymer and React. One of the tremendous advantages of web components is that they’re a standard. That lets us write our components in the way that makes most sense for us, while still allowing anyone to incorporate those components into applications written in other ways. In particular, Polymer remains the most active web component framework, so interop with Polymer is a critical feature for all our components. As a simple demonstration, we’ve posted a carousel-with-tabs example showing use of our basic-carousel component with Polymer’s paper-tabs component.