Coming soon: Carbon Web Components v2

tl;dr

The Carbon Design System team is pleased to announce an upcoming major release for Carbon Web Components! Our team quietly announced the official support of Web Components late last year, while beginning to look at some much needed updates to v1 of the library.

We already had alpha releases go out for the next major version, and will soon announce a regular cadence of beta and release candidates. Here are some of the bigger things coming in v2.0.0:

• Upgrade to Carbon Design System v11
• Upgrade to Lit v2
• Upgrade to Typescript v4
• Existing component baseline sync with Carbon React

Once v2.0.0 is released, the work to synchronize and achieve full parity with Carbon React will begin and will be delivered in incremental minor releases.

The Carbon Web Components package was also recently migrated into the Carbon for IBM.com monorepo, which means that the Carbon for IBM.com team (part of the wider Carbon Design System team) is officially supporting Carbon Web Components as an upstream dependency.

Any bugs, questions, or feature requests can be opened on our issue board!

A design system that started with React

Historically (and to this day), the Carbon Design System has had a dedicated team focused on delivering core elements of the IBM Design Language to digital experiences. These include fundamental open-source packages like color, grid, typography, icons, theming, and more. With this DNA, the team also builds and maintains foundational components, using React as its UI library of choice.

IBM is an incredibly large and complex company with many application teams building software in their own ways. It is difficult (daresay impossible) to mandate a single UI library. While React is the most popular JavaScript library for building UI today, we have seen community-driven initiatives within IBM that offer sibling framework solutions for Carbon Design System — most notably, for Angular, VueJS, and Svelte. This is a testament to the flexibility of a core-elements architecture, which allows for the extension of IBM’s Design Language into any UI framework or library.

This is, however, where the rubber meets the road. Maintaining feature parity between Carbon React and the other Carbon UI frameworks is a challenge. While the core Carbon team is mighty, it is not largely staffed, let alone skilled across all UI frameworks in the industry. While it is heart-warming to see the organic growth of non-React libraries take hold across IBM, contributions to these projects rely heavily on the community, which unfortunately, cannot move as fast as a dedicated team.

The Carbon ecosystem: there and back again

Since its inception, the Carbon Design System has served as the LEGO blocks for digital experiences across IBM. However, teams still need to create larger, repeatable patterns based on Carbon to fully leverage a model of reuse across multiple applications. One such area within IBM is its own digital footprint, IBM.com.

At ~24 million pages, this footprint is non-trivial.

In this footprint, there are multitudes of application teams building experiences that serve their particular corner of IBM.com — with varying technology stacks and different UI architectures (React, Angular, VueJS, etc.). Yet all of them need to adopt the Carbon Design System. Like the core Carbon team, the Carbon for IBM.com team cannot scale to support all of these frameworks, at the same time, they can’t choose a single framework and leave the other teams in the dark either.

The .com team first started to build components in React, primarily because many early adopters of Carbon were already using React. However, as they were being built, the team also explored a framework-agnostic approach to serve all IBM.com application teams. During this exploration, another community-led Carbon library surfaced: Carbon Web Components.

Embracing a new browser standard

The Carbon for IBM.com team was also the first team within IBM to boldly state that it would not support Internet Explorer 11. This decision was timely, considering new browser specifications available in all modern browsers and devices — including the custom element and shadow DOM spec as part of the Web Components API offerings. Some of the key benefits of Web Components include:

• Ability to integrate with any JavaScript framework (including React)
  This addresses the needs of the many application teams making independent decisions on their UI framework of choice.
• Ability to live in harmony with existing design systems or frameworks
  The encapsulation benefits of the shadow DOM assisted with gradual migrations from the older IBM.com design system to the Carbon Design System.
• Ability to deliver components via CDN
  In addition to their availability as NPM modules, the encapsulated custom elements can be pre-packaged and delivered through IBM’s highly available Akamai servers. This gives teams that lack front-end developer support (in IBM there are many) the ability to skin a Carbon experience with JavaScript <script> tags and basic HTML markup.

<html>
  <head>
    <title>Carbon web component CDN example</title>
    <meta charset="UTF-8" />

    <!-- Adding IBM Plex font -->
    <link
      rel="stylesheet"
      href="https://1.www.s81c.com/common/carbon-for-ibm-dotcom/tag/v1/latest/plex.css"
    />

    <!-- CDN script for a Carbon button -->
    <script
      type="module"
      src="https://1.www.s81c.com/common/carbon/web-components/tag/latest/button.min.js"
    ></script>
  </head>
  <body>
    <bx-btn href="https://www.ibm.com">Button</bx-btn>
  </body>
</html>

With the availability of the Carbon Web Components library, the Carbon for IBM.com team began its journey to leverage it as an upstream dependency. To date, they have created over 70 web components (with multiple variations) for the IBM.com experience.

Becoming part of the family

As the Carbon Web Components library became part of the Carbon for IBM.com team’s mandate, the team found it increasingly difficult to stay on top of bugs and missing features in Carbon Web Components proper. Any updates involved an update to that library, followed by a release, followed by upgrading the dependency within the Carbon for IBM.com monorepo. Because Carbon Web Components is an essential and strategic library for the Carbon for IBM.com team, and they are its most active contributor, the team decided to adopt official support for the library.

With this decision, a couple of major changes happened in order to better enable support for Carbon Web Components (and ultimately Carbon for IBM.com):

• We migrated Carbon Web Components to the Carbon for IBM.com monorepo
  This ultimately allows for synchronized code updates and releases in a single repository.
• We renamed the package
  With official support, the package name was changed from carbon-web-components to @carbon/web-components

Though it can be summarized in a couple of short bullets, it was a Herculean feat to introduce a new package to an existing monorepo. Both projects have their own set of dependancies which needed to align for the suite of packages to live together in harmony. In a number of cases, these dependencies were off by multiple major releases. The largest effort surrounded the upgrade to the latest version of Storybook, which included a rewrite of all of the stories to the newer format of Component Story Format (CSF) and Storybook Controls.

The road to Carbon v11

Migrating from Carbon v10 to Carbon v11 is a huge priority for the Carbon for IBM.com team. This means that Carbon Web Components needs to be upgraded as well. So a decision needed to be made. Would the team deliver both libraries at once, or would Carbon Web Components come first? Since both are in the same code base, the second option would involve a more intricate release management strategy, in that Carbon Web Components would be ahead major version for a given period of time. However, in order to deliver iterative value to users, the team chose the second option.

Although it’s been a long journey, the .com team’s embrace of Web Components directly supports their number-one goal of reuse, by enabling them to serve even more application teams within IBM. And the greater the scale, the greater the rewards for the business. This next chapter in Carbon will define how the design system can serve all software teams within IBM, as well as the open-source community that finds value in what our team brings to the industry — whether if it’s in the form of React or the newest family member, Carbon Web Components.