As discussed in this blog over the past few months, we've been plotting a
mixins instead of a monolithic component framework. We've just published a
new 0.7 release of the
project that represents a transition to this mixin strategy. So far, this
approach appears to be working well, and meeting our expectations.
We've begun rewriting all our components in ES6.
So far, we've rewritten the
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.
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.
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
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,
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
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
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
example showing use of our basic-carousel component with Polymer's