CK Blog

I recently tried Storybook, a popular tool for browsing the demos and documentation for a UI component library. I think Storybook offers a good user experience, but its developer experience entails complexity out of proportion to its benefits. I tried creating a simpler web component library browser using web components, and am happy with the result.

I’ve read some recent back-and-forth on Twitter regarding whether “magic” in a framework or library is something to be avoided or sought. We’ve spent a fair amount of time over the past year rewriting the core of the Elix web components project to remove what we felt were magical aspects. I wanted to write down some reasoning for that, both to better understand my own instincts, and also as a way of explaining those changes in Elix.

The latest Elix 8.0 release now lets you control how the Elix components are registered as custom elements. This post provides a summary of the complex topic of registering elements, then describes how Elix 8.0 addresses those complexities.

We've made breaking changes in the new Elix 7.0.0 to solidify our component APIs. Specifically, our components no longer expose internal methods or properties with string names.

We've been looking at how to make the Elix web component library easier to use in a React application. We recently posted a React example to show using an Elix web component in a simple React app, but we can do more.

We recently released Elix 6.0. This includes a simple state-based recalc engine that lets our components know what they should update when their internal state changes.

To me, the story behind the standard HTML <slot> element illustrates the complexity of producing standards, the importance of talking with people face-to-face, and the value of compromise.

Combo boxes are hard to implement well. At the most abstract level, a combo box combines a text input with a button that can invoke a popup. The popup contains a list or other data-entry element:

We've released v2.2 of the Elix web components library, which includes some new components for menus:

While updating our Component Kitchen site to incorporate the Elix web component documentation, we replaced our server-side use of Preact with template literals for JSX. The result works well and could be applied in many situations, so we describe the solution here in case others are interested in trying it.

Two months after releasing version 1.0 of Elix, we're happy to announce version 2.0.

I built Memoui, a fast, small-payload scratch pad application with data persistence and offline support using Elix web components and mixins. Thanks to service workers and seamless Android support for adding to the device's home screen, the application has a native feel and user experience, with the benefit of installing from a URL rather than an app store.

We’ve recently been trying a new way to let devs customize complex web components: let a component accept parameters for the custom elements that should be used inside the component’s template.

We're excited to announce that the Elix project we lead has reached its v1.0.0 milestone.

Even though styling reusable components is a hard problem, the Elix project needs a solution if it's to keep moving forward. The library's goal is to provide general-purpose components that can be styled/themed to meet customers' needs. As far as we're aware, neither the web platform nor component frameworks give us the styling primitives we need. For now, Elix is tackling this styling challenge with subclassing.

The easiest way to create web components with a distinctive visual style is to bake that style directly into the components' code. Most user interface components are designed to be used solely within the company creating them, in which case baking in styles may be acceptable. But anyone aspiring to create or consume reusable general-purpose web components will have to grapple with the fact that styling components is currently an unsolved problem.

I spent the last week on my least favorite engineering task: trying to get a body of code that works on Chrome/Safari/Firefox to work on Microsoft Edge and Microsoft Internet Explorer. In this case, I've been trying to get the Elix project's unit tests and basic component set working as expected in Edge and IE 11. Such work is never fun. Lately I've been wondering whether it's worth the Elix project's time to support Microsoft's browsers.

Web components and Shadow DOM are practically synonymous, but even web components with a shadow subtree often need to render information into the light DOM. A component might need to:

Perhaps you like the benefits of functional reactive programming, but would like to create native web components with minimal overhead. This post explores a relatively simple JavaScript mixin that lets you author web components in a functional reactive programming (FRP) style modeled after React. This mixin focuses exclusively on managing state and determining when the state should be rendered. You can use this mixin with whatever DOM rendering technology you like: virtual-dom, hyperHTML, lit-html, plain old DOM API calls, etc.

Stencil.js was introduced recently at the latest Polymer Summit. Some of our partners had questions as to what exactly Stencil is, what it creates, and what are the implications of its use. We thought we'd have a look. Here's what we discovered.

Jan and I have been very busy the past several months starting up the Elix project, a library of high-quality web components designed to support the Gold Standard Checklist. Together with developers from Comcast, Vaadin, CommonTime, and Google, we participate in the Elix Core Team with Component Kitchen serving as a host organization for the project.

With Google now shipping both Shadow DOM v1 and Custom Elements v1 in Chrome, and Apple shipping Shadow DOM v1 in Safari, we’ve been upgrading the Basic Web Components library from the original v0 specs to v1. Here’s what we learned, in case you’re facing a similar upgrade of your own components, or just want to understand some ramifications of the v1 changes.

I had a thought experiment on how I might port an application I once developed for native Android to a web app, even if it were to run solely on Android devices. The application behaves like a mantle clock: every fifteen or thirty minutes, it wakes up and plays a custom chime. My son used to call it "Big Ben in Your Pocket."

We believe in progressive web applications as a strong alternative to native mobile applications. Along with small experimental projects we conduct on the side, we intend to improve our web site over time with new techniques and patterns, both to educate ourselves as well as to demonstrate the worth of these browser improvements. Our latest improvement makes use of Service Workers. You can now view most of the Component Kitchen website offline, courtesy of the power of Service Workers.

We’ve rewritten the component.kitchen backend server to rip out a popular templating language and replace it with plain JavaScript functions. Recent language improvements in ES2015 have, in our opinion, made it a sufficiently capable general-purpose language that we’ve dropped use of a special-purpose template language. As we began a rewrite of our site, we were inspired by our recent work using plain JavaScript functions to create web components and decided to apply the same philosophy to our backend as well.

The rising interest in React inspired us to try implementing web components that use a reactive approach to rendering. As an experiment, we’ve redone a React tutorial in web components, using Redux for predictive state management, JSX for rendering state, and virtual-dom for comparative DOM updating. Essentially, we treat each web component as if it were a reactive application in its own right. Our goal isn't to push an agenda, but to learn what the reactive web component patterns might look like.

What if you want to create a web component that extends the behavior of a standard HTML element like a link? An early draft of the Custom Elements specification allowed you to do this with a special syntax, but the fate of that syntax is in doubt. We've been trying to create custom variations of standard elements without that support, and wanted to share our progress. Our results are mixed: more positive than we expected, but with some downsides.

An interesting point of backward compatibility came up as we were recently porting our own Component Kitchen site to plain JavaScript web components. The main goal of the port was to be able to write our own site in plain ES6, with less abstraction between us and the platform. We've also reaped some other benefits: our site is now simpler to build, and much faster to load on older polyfilled browsers like Apple Safari and Internet Explorer.

Basic Web Components (BWC) is a project containing multiple, often-related Web Components along with support code implemented as mixins. As we have migrated the implementation of BWC from Polymer components to a plain JavaScript approach, we’ve also revisited the way we organize the project to support the following goals:

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.

In response to our last post on building components from a loose collection of mixins, a helpful commenter referred us to another mixin library he had released called mixwith.js. That library treats mixins more as a pattern than a thing. In that pattern, a mixin is simply a function that takes a base class and returns a subclass of that base class with the desired new features.

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 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.

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.

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.

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.

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'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:

If you hold or participate in project management discussions, consider printing out this handy Printable Wall Calendar that was quickly built with web components.

This review focuses not on a component, but an aspect of a component called basic-list-box. Component Kitchen released that component under the aegis of the Basic Web Components project. In our reviews, we want to avoid focusing too much on our own work, but in this case we can happily feature a small but important contribution to the project from developer Marcy Sutton, a passionate advocate for building an accessible web that can be used by everyone.

ordered-columns implements a packed column layout in the style of Pinterest. Home pages with cards or modules that vary in height often use this layout to pack the cards into columns: cards are assigned in order to whichever column is currently the shortest. Such a layout is quick to compute, produces visually engaging results, maximizes content that appears above the fold. It's a useful responsive design pattern that scales well from small displays to very large ones. Many JavaScript libraries exist to implement this pattern, but this is a great example of a pattern that can be delivered as a web component.

We love the elegant demos and documentation filaraujo is creating for his collection of web components. His akyral-modal component, for example, addresses the common need to have a modal dialog or other UI appear in front of other elements on the page. Several other modal components exist, but none so nicely documented.

Sometimes the simplest approach works best. A number of registered web components aim to handle the simple task of showing or soliciting a star rating from a user using the now-convential set of 5 stars. On its own, a 5-star rating system can present serious issues, as users tend to offer responses only at the extremes, but when managed well (adding users to add comments to explain their response, etc.), such rating systems can be useful.

The voice-elements component gives you easy access to the Web Speech API natively supported (as of this writing) only in Chrome. This lets you both read text aloud to the user, and perform basic voice recognition. Users can quickly tire of repetitive spoken prompts, but voice playback might useful for short alerts that incorporate dynamic content such as data coming from your app.

We've been eagerly tracking the state of the web components community since we started Component Kitchen earlier this year. Over that time, it's been exciting to watch the number of web components registered with Bower grow from about 40 to nearly 500 today.

There are already a number of web components that wrap existing slide-based presentation libraries; slide-page is notable for being written from the ground up with web components. The source code for the core component is little more than a wiring together of existing parts in a novel combination. That approach is, in fact, exactly right, and component writing at its best! This component mostly adds sequential arrow button navigation around Polymer's core-animated-pages component. For the buttons, it takes advantage of Google's Material Design theme, specifically the Paper floating action button.

Many companies embed a hard-coded Google Map on their site to show, for example, the location of their office. This component allows you to easily create more dynamic maps. You could, for example, combine this with geo-location to show your user's current location.

Component Kitchen founder Jan Miksovsky shares some of his recent experience creating some general-purpose components over on his user interface design/development blog at flow|state.

We recently added live demos to the Component Kitchen site for all components that define a demo. Components with demos are marked on the home page with a "DEMO" indicator, so you can check out all the demos.

Today we’re excited to publicly announce the launch of a preview edition of our site at https://component.kitchen.