Forem: Serhii Kulykov

10 years of building Web Components: the story of

Serhii Kulykov — Wed, 27 Aug 2025 16:10:00 +0000

Today marks the 10 year “birthday” of one of the most complex and sophisticated parts of Vaadin web components: the <vaadin-combo-box>. I had a chance to use this component and contribute to it before joining Vaadin. Today, I’d like to explore its story, and to illustrate how Vaadin web components evolved over time.

Building a combo-box component is quite a challenging task, but I’m not going to dig deep into technical details. There is a great blog post about this topic by Jan Miksovsky, creator of Elix library. I also recommend this article by the React Aria team about their ComboBox implementation and challenges they faced.

At Vaadin, we invested significant effort into making our combo-box both feature rich and accessible. Our component supports different ways of assigning data, lazy loading, internal and external filtering. As for accessibility, in our case it took some time to get things right — especially because of using Shadow DOM.

Over the years, our work on <vaadin-combo-box> followed the Web Components evolution. We created it using Polymer 1 at the time of the so-called “v0” proposals. Then we ported it to following Polymer versions 2 and 3. And this year, we finally migrated to Lit. But let’s take a step back to see where it all started.

First steps

The initial prototype of <vaadin-combo-box> was internally using... a single column data grid! More specifically, an early version of <vaadin-grid> — another of Vaadin components with an even more fascinating story. Both were parts of the Vaadin Elements set featured on the Polycasts episode by Rob Dodson.

During the next iteration, the combo-box was updated to use <iron-list> — a virtual scroller element by the Polymer team (which was even used by Chrome UI, especially history and downloads). Around the same time it was changed to use overlay teleportation, adopted by many other Vaadin components later.

Visually the component was designed to be aligned with a set of Paper Elements by the Polymer team. At the time, the future was looking bright: Web Components started to gain cross-browser support, the Polymer ecosystem was rapidly evolving — and Vaadin Elements team worked hard to catch up.

The first stable version of <vaadin-combo-box> was released in 2016 — that’s when I had a chance to use it in production in my previous company. In just a bit over a year, the component reached version 2.0 based on Polymer 2, with support for stable implementations of custom elements and shadow DOM.

And that's what is great about Web Components: while the implementation details change over time, ultimately it’s still standard HTML. Both <vaadin-combo-box> version 2.0 and this year's upcoming 25.0 release are based on the same standards, and provide mostly the same API: properties, attributes and events.

Early days

Starting from 2017, Vaadin Elements were undergoing a major internal overhaul related to styling. While custom elements created by the Polymer team originally were using “CSS mixins” and @apply, that proposal ended up being abandoned in favor of shadow parts, which only got implemented in browsers 2 years later.

That’s when the Vaadin Elements team came up with own future proof solution: ThemableMixin, used for style injection into shadow roots. While there was no native ::part() support yet, elements inside <vaadin-combo-box> were updated to provide part attributes (in fact, some of these parts are still there today).

Also, around this time usage of Paper Elements was replaced with new web components built by Vaadin, like <vaadin-text-field>, and provided new default styles. These changes marked version 3.0, and I had a chance to contribute to it after joining Vaadin in late 2017. But that was still only the start of the journey.

The next step of the styling update for Vaadin web components was related to theming. In version 4.0, which became part of the Vaadin platform 10, we updated <vaadin-combo-box> to use the new Lumo theme by default. Later we also added Material theme, which could be used by importing different HTML files.

Yes, back then Polymer 2 was relying on HTML imports — another proposal that didn’t reach cross-browser adoption. It was announced that the next version will move to ES modules. So in our team, we had to make adjustments to all Vaadin components in preparation for the long-awaited Polymer 3 stable release.

The road to Lit

By the end of 2018, Polymer 3.0 was released as stable… just to be effectively deprecated. Google recommended to use new libraries — lit-html and lit-element for creating Web Components. With our rapidly growing codebase, moving to new libraries would mean a significant amount of work, which we couldn't afford.

However, at this point the Polymer dependency became a technical debt, while the Lit team built new things that many developers, including myself, were eager to try. This is how Vaadin web components journey to Lit started. However, after some prototyping we were only able to ship a few incomplete alpha versions.

Then it became clear that we need to at least get the codebase to Polymer 3 first. While the main goal was to ship proper TypeScript definitions, while working on this project, I also migrated our tests to @web/test-runner, a great tool by the Modern Web team. We still use it for testing Vaadin web components today.

The next step towards Lit was moving Vaadin web components to the monorepo. Thanks to dropping bower support and significantly faster tests with the new test runner, we could finally consolidate our codebase. This also allowed us to ship internal improvements, like replacing <iron-list> with the new virtualizer.

Another milestone worth a separate blog post was improving accessibility of many components including <vaadin-combo-box> in Vaadin 22. In this version, we moved interactive elements like <input> and <label> to the light DOM. We also improved code sharing using a set of mixins and Lit reactive controllers.

Where we are today

Refactoring is hard. Especially, it's hard to justify having to spend months of work on something considered and implementation detail. So it took years for Vaadin web components to be migrated to Lit. And I’m grateful to all my colleagues from the Vaadin design system team for our joint effort to make it happen.

To make moving to Lit smoother, we created PolylitMixin, a small layer on top of LitElement bringing support for Polymer features like property observers. We also adapted our test setup to run the same set of test suites for both Lit and Polymer. Finally, for every web component we added an experimental Lit version.

This was especially tricky because of numerous cross-dependencies and certain components being tightly coupled with each other. In case of <vaadin-combo-box>, most of its logic was reused in our time-picker component. In Vaadin 23, we added a multi-select version of the combo-box, initially built as an add-on.

Finally, this year we completed the Lit migration project and removed Polymer dependency from the upcoming Vaadin 25. As for the combo-box logic, it was split it into smaller mixins used by time-picker and multi-select-combo-box components, instead of "internal" versions of combo-box in shadow DOM.

And one last important change that I’d like to highlight: after almost 10 years, we no longer use DOM teleportation for our overlays! Thanks to the native popover API landing in all modern browsers including Safari 17+, we can keep overlays in shadow DOM of their respective components and use slots for content.

What’s next

While Vaadin 25 is still in alpha and has some rough edges, you can already try new Lit based versions of Vaadin web components. I’m planning to share more updates about our progress in the upcoming months, as we approach beta and stable release. In the meantime, you can check out following resources:

Live demos of new base styles that make customizing Vaadin web components much easier and will serve as a foundation for the new Aura theme,
New API documentation built using 11ty static site generator, covering JS, CSS and TypeScript API provided by our web components.

And if you have never used Web Components yet, it’s definitely worth trying! Despite all the challenges, they eventually proved to be the right choice for Vaadin components. And by the way, the latest alpha of of the @vaadin/combo-box is almost 40% smaller than the Polymer 3 version from 5 years ago.

Happy 10 years anniversary to <vaadin-combo-box>! It’s been a great journey.

CSS Shadow Parts are coming!

Serhii Kulykov — Tue, 07 Jan 2020 18:23:50 +0000

Firefox 72 has been released with some new APIs, and two of those are good news for the Web Components users. The first one is FormDataEvent and event-based form participation, previously only available in Chromium. But today I would like to focus on another feature, implemented behind a flag since Firefox 69: part HTML attribute and ::part pseudo-element.

CSS Shadow Parts proposal is among the most waited additions to the standard for developers who create customizable components and design systems. It is a new API for styling individual elements in Shadow DOM from outside. This lets to make a single instance of certain UI widget look slightly differently – an ability that we often need in the real world apps.

Unlike CSS Custom Properties, which only allow to configure individual values like --primary-color, a new ::part pseudo-element give us a true flexibility we have been longed for. At Vaadin, we adopted the idea of CSS Shadow Parts already in 2017 as explained in this talk on theming. And now we are happy to see that ::part finally gets cross-browser support.

History

The idea of custom pseudo-elements, also known as CSS Shadow Parts, has been discussed at least since 2015 but the agreement was reached in early 2017 when it was decided to abandon CSS mixins and @apply proposal (never released in Chrome), and to implement ::part instead. Three years after – not too long for web standards – and we are getting there in 2020.

One note for those who remember a fancy explainer by Monica Dinculescu: the spec has changed since then. There is now an updated version by Fergal Daly. Also, today I'm only talking about ::part because ::theme, another pseudo-element from the original proposal, has been postponed. There are ongoing discussions related to ::theme and its future is rather unclear.

But the status of ::part looks very promising. It is supported in Chrome since version 73 and now also in Firefox 72. Safari has already implemented CSS Shadow Parts in Technology Preview 94, and it remains to wait for a stable version to be released – same as for Chromium-based Edge. So it's already time to experiment with ::part and learn how to use it in practice.

Usage

Basic example

According to the comment by Tab Atkins, one of the spec editors, the point of ::part is to hide the internal details of the web component, and to only expose exactly the parts the component author explicitly wants to.

Let's go directly to the example. The embedded CodePen below provides an example of styling <vaadin-details> custom element using ::part. This is a simple component which exposes a few elements using part attribute.

Looks like good old vanilla CSS, doesn't it? Even if you open this demo in a browser that doesn't support ::part, nothing will explode: the component will remain fully functional with the styles that it provides out of the box.

Using CSS Shadow Parts in simple cases like this one it's cheap. In fact, you only need to add part HTML attribute on the elements you wish to expose. This leaves a component consumer to choose whether to use this API or not.

Using `::part` with pseudo-elements

As you may noticed, the above example demonstrates how the details toggle button can he styled using the ::part(toggle)::after CSS selector. We can use ::part this way in combination with any other pseudo elements, too.

As demonstrated in the CodePen above, all the browsers that implement ::part already support this feature. However, please don't expect it to work with non-standard pseudo-elements like ::-webkit-scrollbar.

Using `::part` with pseudo-classes

Another feature that is often needed for elements inside shadow tree is an ability to style certain states like :hover. We can achieve it with ::part – and that's how it naturally fits into the way of writing CSS we are used to:

While other user-action pseudo-classes like :focus are also allowed to be used with ::part, the spec clearly states that structural pseudo-classes (e. g. :first-child, :nth-of-type(), :empty and so on) are not supported.

Path forwarding with `exportparts`

In certain cases, the parts we might need to expose for styling are located in a nested component, which has its own shadow root. That isn't possible with ::part by default, as it does not recursively traverse shadow trees.

However, there is now exportparts attribute designed to handle this case. When an element in shadow tree has this attribute, its value defines what parts are "exported" from that element and can be styled with ::part:

As of today, this feature only works as a "whitelist". There was a proposal to also support forwarding with -* to have kind of "wildcard". However, it is not currently standardized and therefore not implemented in browsers.

Feature detection

In some cases you might want to detect whether a browser supports CSS Shadow Parts or not – for example, to load a different chunk or .css file with fallback styles. This can be done in JS using the following code:

'part' in HTMLElement.prototype; // true if "part" is supported

There is no cross-browser way to detect support for ::part using CSS only because @supports selector() API is currently only available in Firefox.

Limitations

While CSS Shadow Parts definitely bring us a lot of flexibility, they still has certain limitations that exist by design. The restrictions related to certain pseudo-classes that are disallowed after ::part belong to them.

Same as ::slotted() pseudo-element that is already familiar to anyone who uses Shadow DOM, ::part is disallowed to use in complex selectors so you can't use it to style a sibling or child node – only the part itself.

Another important limitation: it's not possible to use classes or attribute selectors after ::part – these are considered an implementation detail. One possible workaround for it could be to use multiple parts approach.

The :state() pseudo-class is designed to work with ::part and it should cover some use cases by allowing CSS like ::part(video):state(playing) for styling custom elements that are exposed using part attribute.

Documenting

CSS Shadow Parts can be considered public CSS API exposed by a web component. This means that they should follow semantic versioning – so removing or renaming any part attribute requires a major version bump.

The web-component-analyzer tool supports @csspart JSDoc annotation that can be used to document CSS Shadow Parts exposed by a custom element, and outputs them as part of experimental JSON format.

And with the help of the <api-viewer> element (my pet project), you can generate a web component API docs from JSON, including CSS Shadow Parts. By the way, <api-viewer> itself can be styled with ::part.

Learn more

As long as CSS Shadow Parts are relatively new API, there aren't many examples yet. Here are few places where you can see ::part in action:

Elix, a collection of web components that implement common UI patterns by Jan Miksovsky. Elix recommends styling element parts among other approaches for customizing elements appearance.
Chromium Web UI elements. These web components are in progress of being updated to using CSS Shadow Parts instead of CSS mixins. You can see them already used in several places like Chrome Settings.
Firefox UI. As mentioned in the recent blog post by Brian Grinstead, the process of re-building Firefox UI with Web Components resulted in prioritizing CSS Shadow Parts support among other related features.
The web-platform-tests suite. This project is very useful to understand how certain features are supposed to work. You can check the results to see how CSS Shadow Parts work in the latest browser builds.
Mozilla Developer Network already (MDN) provides two articles about ::part pseudo-element and part global attribute. They also have a dedicated example in the web-components-examples project.

Finally, if you want to look into questions that are still under discussion, check out the CSSWG issue tracker with the corresponding label.

Summary

CSS Shadow Parts are new API that can be already used in some projects, especially in those cases when graceful degradation approach is acceptable. So I highly recommend evaluating part and exportparts to anyone who works on a web components library, UI kit or design system.

The next generation of Vaadin web components

Serhii Kulykov — Tue, 19 Nov 2019 16:36:52 +0000

Originally posted on the Vaadin blog.

The current set of Vaadin components is the result of many years of development. We invested a lot in building high-quality components that are suitable for enterprise-grade apps. Starting from Vaadin 10, every major version ships with a set of new components.

While we constantly add new features and provide long-term support, there is another important priority that is always paramount in our minds: component performance. Today’s trend is to ship lightweight, performant libraries with minimal network footprint for building faster web apps.

In this post, we would like to share our ideas on what the next generation of Vaadin components might look like. This is not a roadmap, but rather a summary of the direction that we aim to follow in the coming years, to keep up to date with the rapidly evolving frontend ecosystem.

Why the next generation?

We started building the current generation of Vaadin components in the era of Polymer 1 and HTML Imports. While we mainly considered them to be simply an implementation detail, they did to some extent affect our public API, and the architectural decisions we took along the way.

Now that all the evergreen browsers support ES modules, we can leverage this to improve our codebase a lot. Improvements include reusing and sharing logic and styles between web components in ways that make them more efficient, and easier to customize, extend, and contribute to.

We also consider the next generation a perfect opportunity to modernize our technology stack. This means that we will eventually replace the Polymer library, which is currently in maintenance mode, with a new set of libraries and tools that allow us to build fast and robust web components.

How are we going to do this?

Our plan is to gradually upgrade existing Vaadin components to be based on LitElement, a lightweight library for creating fast and modern web components built by the Polymer authors. As an additional improvement, we are looking into moving our codebase to TypeScript.

Thanks to our compliance with web standards, we can be flexible and easily mix web components built using different libraries, especially Polymer 3 and LitElement. So in practice, we will continue to build on the foundation we already have, rather than rewriting from scratch.

As long as the migration mostly targets the web components, we do not expect major changes to our Java API. We will update the server-side counterparts to ensure that Java developers benefit from a smooth transition to the upcoming next generation of Vaadin components.

How does it affect developers using Vaadin?

We are planning to retain the public API of the Vaadin components during the migration, and to avoid breaking changes (unless required), while focusing on the internal optimizations. The API surface will likely only change in a few cases, for example the <template> element usage.

One area in which we anticipate significant improvement is the performance of components that use infinite scrolling, like Combo Box, Time Picker and Grid. Another important area that we would like to cover is a more customizable form validation API for the field components.

As we follow semantic versioning, every web component updated to LitElement will be released as a new major version. On the Java side, we expect minimal changes, mostly related to improving the developer experience by making the API more flexible and easy to use.

Why LitElement?

Since their first stable releases in early 2019, lit-html and LitElement have already been adopted by the web component’s community as a solid replacement for Polymer. These libraries are powering open source UI kits and design systems built by Microsoft, SAP, and VMWare.

At Vaadin, we bet on the standards-based component model offered by custom elements and shadow DOM standards. These will remain a low-level foundation for our components. With LitElement, we can keep that foundation clean and simple — as we always fight for simplicity.

We learned a lot about web components while developing with Polymer. And what is especially great is that, according to our estimates and research, with LitElement it will be possible to reuse most of the code we already have and the knowledge we have accumulated over the years.

Why TypeScript?

Over the past 2 years, TypeScript has evolved rapidly as a language, and its adoption has grown steadily as well. As you can observe this by looking at npm downloads: TypeScript usage has doubled in 2019 from about 4 M to more than 8 M monthly npm downloads.

The biggest benefit of using TypeScript is the nice developer experience that it brings to frontend developers. We also appreciate the comprehensive type definitions for DOM APIs and the type-checking support for lit-html templates that allow us to make Vaadin components even more reliable.

From the developer’s point of view, TypeScript support is purely additive and does not require any changes to the workflow and toolchain. You can continue to write JS and get all the benefits, like better editor support and code completion, of the TS type declarations that we will ship.

How do we get there?

As of today, Vaadin has more than 40 components (including Core and Pro), Lumo and Material themes, plus a couple of internal dependencies. We expect that migrating them all will be a long process involving a number of refactorings and requiring a coordinated effort from the team.

We expect LitElement and Polymer-based components to coexist for a while. This means that new features will be implemented in both versions, as necessary, by cherry-picking the corresponding changes and shipping them as part of Vaadin 14 LTS minor releases.

The plan for the upcoming months is that we start by moving certain “leaf” components (the ones with the least dependents) to LitElement. At the same time, other components will still be based on Polymer, until we migrate them as well, during one of the iterations that follow.

What are our first steps?

Recently we released <vaadin-details> 2.0.0-alpha1, a first preview release of the LitElement-based Vaadin component. Even though it is one of the smallest components we have, while working on it, we learned a lot and tested new tools that will help us to be more productive.

These first steps may not seem valuable from an end-user point of view, but they are, in fact, the extensive groundwork that will facilitate the migration. Among the notable efforts is the fact that we keep the existing unit and visual tests almost the same to prevent occasional regressions.

We will keep you informed about our progress with the next generation. As we convert more components to LitElement, we will publish them in Vaadin Labs to ask for your feedback. And of course, the development is fully transparent on GitHub: keep a look out for “next” branches.

: document your Web Components API

Serhii Kulykov — Tue, 22 Oct 2019 13:16:27 +0000

Building Web Components is something I enjoy, and it is really easy to create one using LitElement. However, the ecosystem around LitElement is not quite mature yet, and sometimes we don't have a replacement for certain important tools we used to have while developing with Polymer.

Documenting is one such missing piece. While we can use Storybook with a preset by open-wc.org for showcasing different states of our components, there is a thing that we are lacking: a simple tool to browse the API docs. This is exactly what the component I'm sharing today is intended to be.

What?

Meet the <api-viewer> element! It is built with LitElement and TypeScript. Check out the live demo to see what kind of documentation it provides.

Note, this is just 0.1.0 release and I have a lot of ideas on how to improve the API viewer. Also, the idea behind this component is that we might use it for Vaadin components in the future, so there might be some "internal" feature requests over time, but the community feedback is always welcome.

Why?

While we can still use polymer-analyzer tool and <iron-component-page> component by the Polymer team with LitElement and document properties, methods and events, it starts getting complicated if we switch to TypeScript. Also, these components and tools are no longer actively updated.

Thankfully, there is a web-component-analyzer, a CLI tool by Rune Mehlsen. It provides the ability to extract properties, attributes, methods, events, slots and custom CSS properties of the custom elements and outputs analysis as markdown or JSON (including the format proposed by VSCode team).

I was looking for a web component compatible with the Analyzer, and I found <wc-info> by Bruce B. Anderson. While I like the general idea, the component is still not exactly what I needed. So I decided to go ahead and build the <api-viewer> from scratch, and in a few days I built an MVP.

How?

Here is a minimal usage example which you can run using es-dev-server:

<!DOCTYPE html>
<html>
  <head>
    <script type="module">
      import 'api-viewer-element';
    </script>
  </head>

  <body>
    <api-viewer src="./custom-elements.json"></api-viewer>
  </body>
</html>

Follow the full usage instructions to learn how to generate the JSON file. The Web Component Analyzer documentation is also worth checking.

And of course, let me know if you have any comments, feature requests or any other feedback regarding <api-viewer>. Let's make it better together!

Web Components for Enterprise. Part 2: Nuxeo, Ionic, Vaadin

Serhii Kulykov — Tue, 23 Jul 2019 20:16:49 +0000

Web Components, like almost any technology in the frontend ecosystem, have supporters and opponents. The opinion polarity is mentioned in the announcement of this year’s talk by Paul Lewis at Fronteers. By the way, I think it is symbolic that it's going to be the same conference where Web Components have been originally introduced by Alex Russell in 2011.

While I must admit that Web Components have strengths and weaknesses, I think they deserve deeper research, and in my opinion, there is a certain gap here that I am trying to fill. The observations from my experience and the community became grounding for several blog posts I wrote this year, including this “enterprise” series, and I still have something to tell.

The previous post was about enterprise-scale software companies, paying a lot of attention to ownership, making proper decisions and staying current with the web standards. But there are many corporations for which the software development is not a core domain, so they usually outsource it, especially when it comes to building web applications for internal use.

Creating this kind of enterprise-grade apps might be challenging. They are often built with a tight budget, as they don’t bring any direct revenue to the owner. At the same time, these are apps, where the users can spend their entire working day. And finally, such apps tend to have a very long lifespan, which means a years of maintenance, support and painful bug fixing.

In this blog post, I would like to describe three companies who created the UI development platforms targeting mostly corporate customers using Web Components. A necessary disclaimer: I’m a frontend developer working at Vaadin, a company listed here – so I tried to avoid being biased by providing a more or less equal representation of the compared technologies.

Nuxeo

Nuxeo is a software company offering an enterprise content management platform written in Java and developed in open source under Apache 2.0 license. Nuxeo claims “zero legacy” and investments in innovation as one of its advantages. On the front-end side, this can be confirmed by the fact that Nuxeo was among the early adopters of Web Components specifications.

In 2014, Google has implemented so-called “v0” Custom Elements and Shadow DOM proposals in Chrome and was actively advocating them. Nuxeo belongs to companies which got excited about “using the platform" approach promised by Web Components. As a result, Nuxeo considered these bleeding edge specs as a potential replacement for existing JSF stack.

The new client for Nuxeo platform called “Web UI 1.0” was presented in 2017. It was built with Web Components and Polymer 1 (which was using HTML Imports and “v0” proposals under the hood). Also, nuxeo-elements, an evolving collection of UI and data visualisation controls used for building web applications with Nuxeo, has been developed in open source.

There has been a lot of changes in Nuxeo since the decision to use Web Components. In particular, elements collection is now updated to Polymer 3 and moved to monorepo. Finally, JSF has been deprecated in LTS 2019 release with motivated explanation, and a migration tool helping to convert existing JSF-based projects to Web UI has been released in beta.

One important decision made by Nuxeo was ending support for IE11 announced in 2018. As we can understand based on the wording about “inordinate amount of time” put into fixing bugs and performance issues, it was a tough call after a lot of struggle. The reality is that IE11 needs backup solution when moving to Web Components (JSF in case of Nuxeo).

Ionic

Ionic is a software company offering an open-source MIT-licensed cross-platform UI development toolkit called Ionic framework and providing commercial services and support. Initially focused on building native-style apps for mobile devices using Cordova and Angular, Ionic eventually came up with own tool: Stencil, a compiler for Web Components and PWAs.

According to the recent tweet, core development of Ionic and Stencil is handled by 10 people, and the team on GitHub has only 15 public members. However, since its founding in 2013 Ionic has been focusing on building a product for enterprise usage. This explains the choice of AngularJS, which used to be popular before the rise of React heavily affected JS landscape.

It took nearly 2 years for Stencil alpha announced at Polymer Summit 2017 to land as 1.0.0 stable release in June 2019. Ionic team is working on new features, especially related to SSR which is usually mentioned as one of the “drawbacks” of Shadow DOM. Recently, pre-rendering and client side hydration demo was shared by Stencil team as a future improvement.

One important note about Stencil is that, although it’s based on Web Components, it treats Custom Elements as a compile target. On top of that, Stencil provides an opinionated set of features claimed as key innovations to stay competitive: TypeScript, JSX, virtual DOM, reactive data binding and asynchronous rendering (described as “similar to React Fiber”).

In the recent blog post by Max Lynch, Ionic is claimed to be “somewhere in the middle” of two competing visions about Web Components. Developer experience provided by Stencil is similar both to Angular (TypeScript, decorators) and React (lifecycle callbacks, JSX). Also, Ionic follows the trends around JS frameworks community, like building design systems.

Vaadin

Vaadin is a company offering a framework, components and tools for building web apps in Java. Historically, Vaadin has been powered with GWT and used it for UI components since 2009. Compiling from Java to JavaScript was a key feature back then, but in 2018 Vaadin has moved away from GWT and shipped version 10 with UI based on Web Components standards.

Vaadin is known as one of the pioneers in the Polymer community. Early experiments with Web Components started in 2015 with Polymer 0.8 resulted in creating Vaadin Elements: a set of components meant to be a seamless extension to the Polymer element catalog. The initial set contained 5 elements and focused on feature-rich, complex controls, like data grid.

Early versions of Vaadin Elements used to depend on Paper Elements and leveraged a lot from that, while also being an example of scaling beyond the Polymer team, mentioned by Rob Dodson in "Built with Polymer" polycast episode. However, the need for ownership and especially full control over the codebase, versioning, and appearance has become clear over time.

The ability to implement own theme, not limited to Material Design, has proven to be the essential feature for customer projects. So, we extended Vaadin components with all the primitives: buttons, text fields, overlays etc. Also, we came up with own theming approach, to get rid of the abandoned CSS mixins proposal and @apply syntax used by Paper Elements.

As of today, Vaadin components use Lumo as a default theme and provide Material version as an alternative. The component set has evolved, and we learned a lot while improving it, including contributions to the polyfills and dealing with browser bugs. Finally, our components are now integrated with Vaadin Flow, a framework bringing Web Components support to Java users.

Summary

The internal enterprise web applications form a separate world. They are well hidden under NDAs, full of legacy beasts and sometimes not really staying in touch with modern trends like tiny bundle size – who cares about downloading 500 kB of JS on desktop in fast corporate intranets? But certain products aiming to approach these apps are built with Web Components.

Nuxeo, Ionic and Vaadin are companies offering such products. And they all provide long term support (LTS), either as a premium feature (Ionic), 3 years of support (Nuxeo) or 5 years of support (Vaadin). But apart from the fact that one could raise money and be safe about the web platform stability for years, let me outline a few other lessons which I think we can learn:

Flexibility. Some people who prefer functional approach have been complaining about Custom Elements being class based by design. But the fact that DOM API is using class syntax and prototype inheritance should not limit anyone from implementing own layer of abstraction: hooks, objects, or even server-side representation of the DOM tree.
Themability. Usage of Shadow DOM in combination with custom CSS properties for theming appears to be an underestimated feature of the web platform. Most of developers are stick with global CSS and class name conventions, while in theory we now have potentially more scalable and reliable solutions. “Survival of the fittest” in action?
IE11: a showstopper. Although Web Components polyfills support IE11, it is nearly impossible to ensure proper performance of the big apps running in that “compatibility solution”. Having to make an app work in IE11, which is often the case for corporate environments, in practice means a need for a separate version (YouTube has one).

There is some hope that more enterprise companies will start considering Web Components over time, especially after Firefox ESR 68 is out. At the time of writing, it is undergoing the so-called qualification and testing period. The support for Custom Elements and Shadow DOM, available since Firefox 63, will thus become available for an even wider audience.

And personally, I hope that there will be enough material for the next blog posts in this series later this year. That’s where you, the reader, could help me a lot. If your company is using Web Components, please reach me in the comments, and share what you’ve learned! And of course, feel free to also share any other feedback, I really appreciate it and it keeps me inspired.

Web Components for Enterprise. Part 1: Salesforce, Oracle, SAP

Serhii Kulykov — Tue, 02 Jul 2019 19:41:35 +0000

Web Components continue to be a subject of debates. Naturally, now when they are supported by all evergreen browsers, some people ask themselves if that should be the “new era”. Then it turns out that new standards are not a silver bullet and don't meet someone’s expectations, not all the bugs are fixed, and some parts of the web platform need further improvement.

I described few such problems in my previous blog posts (1, 2). However, certain opinion leaders having some impact on the JS ecosystem tend to criticise the idea as a whole, by claiming Web Components to be based on wrong assumptions and not practically useful. These statements have their ground, but they produce a lot of misconception among the community.

You may not yet be aware of it, but in fact Web Components are now experiencing an impressive growth in the most inert part of the industry: enterprise UI development. The big companies are interested in long term solutions, and some of them learned many painful lessons in the past. That’s why now they express strong signs of support to web standards.

In this series I will give an overview of several enterprise platforms for business web app development, adopted Web Components as part of the programming model. We will see how they introduce changes while moving towards web standards over time, what value do they bring to the open source ecosystem, and what lessons can we learn from their experience.

Salesforce

Salesforce is a software company offering a CRM platform and a suite of enterprise web applications. Many of those applications came from acquisition, which is often the case for the market expansion, and were built using different stack. At the same time, customers can build their own applications using the Salesforce platform and the tools it offers.

The case for Web Components at Salesforce was presented at Google I/O 2019 in the talk by Kevin Schaaf and Caridy Patiño. The main points of the talk are listed in the article by Arthur Evans. The reasons why Salesforce choose Web Components include the need for a common component model ensuring consistent look and feel and backwards compatibility.

However, there are other valid points in that list, which I personally think are more important – especially, concerns against proprietary solutions, risk of being stuck with legacy technologies and fear of staying in the walled garden of closed ecosystem. This is how “not invented here” symptom clearly manifests itself in a rapidly changing frontend world.

In the end of 2018, Salesforce announced the Lightning Web Components as a new component model for UI development in the platform, leveraging the benefits of the web standards. A special focus was put on the coexistence and seamless interoperability with the previous model, Aura components, with the suggestion to consider migrating to Lightning over time.

Few months after, Salesforce open sourced the Lightning Web Components framework and presented the repository licensed under MIT, new website and lwc-create-app CLI tool allowing to create a new project. Salesforce developer evangelists are also writing blog posts on the related frontend technologies, like unit testing the components with Jest and debugging.

Oracle

Oracle is a corporation which offers a wide variety of enterprise software products, including client-side web applications. Many of these apps are built with Oracle JET, or JavaScript Extension Toolkit, available under open source UPL license. Note that word “toolkit” represents and emphasises the modular structure: JET is not a framework, but rather a set of libraries.

In 2017, Oracle introduced support for Custom Elements in the 4.0 release of JET. This decision was motivated as part of effort to better align with HTML standard and modern specifications. At the same time, new architecture of JET UI components was presented to the audience of UI designers and developers as a better syntax, more intuitive and natural to work with.

Previously, until 3.2.0 release of JET, all the components were wrapped as jQuery UI widgets. New “syntax” was implemented to work side-by-side with the existing model, and migrating to it was clearly indicated as not required when upgrading to the new version. But all the new features, developer guide updates etc only targeted new web components.

Note that getting rid of jQuery was not the motivation for using Custom Elements. Two years and 3 major releases after the big change, Oracle JET is still using jQuery, as well as other not so fancy libraries like RequireJS and Knockout (there is even a “Why Knockout” section in FAQ). The transition from Sass to CSS custom properties in JET also occurs slowly.

And this is the next lesson we can learn: at enterprise scale, gradual migration is a must. Big companies can’t afford to rewrite everything from scratch, while having to maintain projects for years. Oracle JET seems to keep a reasonable balance between legacy and technology renewal, while also thinking about the ecosystem and having own vision of the future.

SAP

SAP is a corporation providing enterprise software, including ERP system. For frontend developers SAP offers OpenUI5 framework available under Apache 2.0 open source license. UI5 is positioned as enterprise-grade JavaScript toolkit for building web applications running on almost any browser, using jQuery as its foundation and following web standards.

In early 2019, SAP announced the beta of UI5 Web Components library, presented as a key pillar of the UI5 Evolution project, aiming to enable independent consumption of UI elements. As it turns out from another blog post, SAP developers evaluated Web Components starting from 2014. And now they look really optimistic: “the time has come, the web is ready!”

Few months after the initial announcement, and at the time of writing RC1 has been released just in time to be presented at UI5 Con. Apart from keeping a good pace with the actual development, SAP also published a website with interactive playground, a tutorial on how to get started, several demo apps and a newscast episode with UI5 lead architect.

One important note about UI5 Web Components is how they are positioned compared to OpenUI5 as an existing product. There is a special section describing the new components as “complementary offering”, not a successor of OpenUI5. The lesson we can learn from here is the importance of clearly formulated message alongside the architecture update.

And one more thing, related to the above point: getting rid of jQuery. Here we go again: sometimes the architects have to explain the decisions they make to the users. I strongly recommend reading this comment by Andreas Kunz from SAP to understand how carefully do big companies consider the actual value of tools they use and the impact of decisions they make.

Summary

Web Components have reached the broad browser support quite recently: Custom Elements and Shadow DOM shipped in Firefox 63 in October 2018, and Edge based on Chromium is now available in canary and dev channel. Nevertheless, certain enterprise companies have already chosen Web Components as a foundation for their UI development platforms.

Salesforce, Oracle and SAP are examples of such companies. Their frontend solutions are created using different approaches, and they are all at different stages of adoption of new component models. Comparison of those is not the primary goal of this blog post, so let me outline and briefly formulate the lessons which I think we should learn from their achievements:

Ownership. Preferring web standards over proprietary solutions is driven by the aim to avoid vendor lock-in or being stuck in closed ecosystem. Focus on web standards allows to reduce the barrier to entry for new developers, while also providing full control over the technology stack and promoting the internal competence growth.
Gradual migration. Being able to combine Web Components with other libraries is a key to ensure the smooth transition between two development models. A new approach, initially introduced either as “complementary solution” or “alternative syntax”, has to evolve and stand the test of time to finally supersede an old model.
Impact of decisions. Big companies carefully evaluate the choice they make when it comes to upgrading the technology stack, and this is especially relevant for rapidly evolving JavaScript ecosystem. In enterprise UI development, any new feature goes through a long validation phase, this is where the web standards come into play.

In the second part of the series, I will continue the overview of frontend toolkits built with Web Component from a slightly different angle. We will explore three different open source platforms which are in themselves provided as products, accompanied with the commercial services – and will hopefully learn a few other lessons from them. Stay tuned!

The Web Components journey: wrong ways, lacking parts and promising paths

Serhii Kulykov — Tue, 16 Apr 2019 19:16:04 +0000

In my previous blog post about Web Components, I described several challenging problems still unsolved as of today. The feedback I received was surprisingly warm, and I was feeling excited to be mentioned by Alex Russell, one of the authors of the initial proposals. Some people called my notes a bit of an eye opener, while others mentioned even more problems.

Taking pink glasses off wasn’t the only goal I wanted to achieve though. My criticism was aiming to identify the pain points, and remind about the importance of consensus. The recent blog post by Jan Miksovsky about the history of HTML <slot> element is a great illustration of the dead end where we could get same as 5 years ago, by pushing the proposals again.

Today I would like to expand my vision further and approach the same topic from a slightly different angle, by exploring the path of Web Components towards the wider adoption so far and in the foreseeable future. Same as before, I rely on my personal experience and observations, so feel free to add your own notes, and correct me if you think I’m missing something crucial.

One more thing from the previous post I would like to remind you about is the upcoming “Face to face” (F2F) meeting regarding Web Components, with the participation of spec authors, browser vendors and users. Yes, there is a slot in the agenda dedicated to the real use cases. That’s good news, and I’m looking forward to see the meeting notes once they are published.

The wrong ways

In early 2016, when I was making first steps with Web Components, there wasn’t that much examples. For me, the only source of inspiration at that time was Polymer Starter Kit. It has been changed a lot since then, and was replaced with the LitElement-based successor, PWA Starter Kit. But in a nutshell, they do the same: place <my-app> component in index.html.

Wrapping a whole SPA into web component is the point where some people start to dream about throwing the frameworks away. At this very moment, in my opinion, they start falling into the pit of using improper patterns. Here I share the concern raised by Mattia Astorino. And from my previous post you already know how overusing Shadow DOM might strike back.

Taking the story further, the common feature every SPA needs is a client-side routing. And yes, people have been using Web Components for routing, too. In my former team, we were using <app-router>, a vanilla v0 custom element from 2014 – and one of the first open source projects I ever have contributed to. At that time, I really liked its way of declarative routing.

But today it sounds ridiculous to me: first we run JS while registering a custom element, then each time user navigates we search matching routes from the DOM and run JS again. Am I wrong or is there an extra link in the chain? Declarativity is good per se, but trying to use HTML anywhere you need it, or in a way other people use JSX, is again a serious mistake.

The next framework-specific wheel we had to reinvent was a set of tools for loading data and managing application state. There has been a lack of best practices in this area in Polymer community. In short, we were supposed to use <iron-ajax> to trigger API requests from the DOM, and then store the data again in the DOM – just to completely mess things up.

Someone would say, once you get locked into a web components collection, the tendency is to push it as far as you can. It can be explained by the fact that Polymer was heavily limited by HTML Imports (thanks to Mozilla for dropping them), and based on some assumptions from the “model driven views” concept, inspired by the dream about "declarative renaissance".

Talking about HTML, there is still a chance that HTML modules proposal will improve our developer experience and allow to use <template> more. This is one of the areas where the Edge team is doing contributions to Chromium. While this could help creating Web Components in a better way, we shouldn't take those wrong ways of using them anymore.

The lacking parts

Back to 2019, what are the better use cases for Web Components today? The first one you probably thought about are UI components, especially complex form controls. Surprisingly, Custom Elements are not currently designed to be picked up when submitting the standard <form> HTML element. The form participation API proposal by Chrome team is expected to fix that.

When looking at the list of proposed updates to Custom Elements API, it seems to be a lot of work for browser vendors to agree and implement. Until then, we are unable use HTML form validation and submission without workarounds like <iron-form> element. In my opinion, Web Components could reach a lot more audience once this issue is finally solved.

There are few other problems related to using Web Components in forms. One of those is broken form autofill for form elements within shadow trees in Safari. Another issue is that password managers like LastPass or 1Password do not support <input> elements in Shadow DOM, as they presumably rely on global API, like document.querySelector().

One more Shadow DOM concern we need to keep in mind is how it affects accessibility. This was described by Rob Dodson, but let me repeat in two words: shadow trees introduce the boundaries for IDs in the document, which affects ARIA attributes, like aria-labelledby. That can sometimes make it harder to make the components both accessible and granular.

The similar issue with the IDs breaks the internal references in SVG, when using it inside Shadow DOM. As an example, <use> element doesn’t work because of how href references are resolved. Good news is that at least Safari has a solution supposed to fix that particular bug – which still has to be adopted by all the other browser vendors and then reflected in standards.

As you can see, at least two seemingly perfect cases to be solved with Web Components – namely, form elements and icons – have been more or less blocked for a while. In my opinion, having such lacking parts not covered for years (including the issues I already mentioned in my previous post) hurts the expansion of the new standards more than anything else.

The promising paths

So how could Web Components eventually reach the adoption? The browser support (at least, for basics) is now good. What we really lack today are real examples of using the native component model in production – preferably, in the big projects – and the best practices as a logical outcome of those. This in turn leads to a lack of trust to Web Components, and so on in a circle.

There is of course an example of YouTube, which is again a full SPA built with Polymer. But so far we observed mostly complaints about it being slow in Firefox and Edge and causing the decision to postpone the removal of V0 specs until Chrome 75. Finally, YouTube still doesn’t use native Shadow DOM, but a polyfill (and will most likely continue doing that in future).

Another case I would like to highlight is GitHub, which switched to using Custom Elements as part of the effort related to moving away from jQuery. What is especially great is how well Custom Elements fit the idea of keeping the content in HTML and progressive enhancement. See details-dialog and details-menu elements as really good examples of that philosophy.

Moving forward in search for the hype train where Web Components could in theory jump in, it appears that the today's motto are design systems. Reusability and being framework agnostic are the strengths we shouldn’t underestimate; that’s why Tesla has chosen Web Components. We shall see over time how much people consider making the same bet.

Enterprise companies are potentially the strongest audience for Web Components, and that’s what we see from State of JS 2018 survey – check the numbers for Polymer. Let me mention ING and its team of open source enthusiasts who created open-wc, and Red Hat sponsoring the PatternFly elements library among the examples of such big companies.

One of the promising paths would be using Web Components to build an architecture and to embed parts of the application. This concept is known under the name of Micro Frontends. It can be questionable to what extent should we use Custom Elements as “spicy iframes”. But at least it’s good to keep in mind that DOM and CSS aren’t necessarily global anymore.

What's next?

Back to where we started, let me again emphasize that Web Components are not a silver bullet. They will not replace JS frameworks, despite some people claim the opposite, or even start saying bye to React. In fact, such biased statements usually hurt more than help. That's why I wanted to add my 5 cents to the ongoing discussion and drive it in the right direction.

The Web Components are safe to use today, regardless of all the unsolved issues requiring further standardization, which I have tried to systematize. Forewarned is forearmed, and I hope you are brave enough to not even fear the Chrome crashes or rendering issues, which have affected few stable versions. Some things need to stabilise, but it’s not that scary after all.

The lack of expertise among the developers, admitted by David Flanagan during the recent holy war regarding the MDN web docs page header being rewritten in React, doesn’t sound a really valid excuse to me either. As long as most of frontend teams stick to well known stack, how would we adopt for example CSS grid layout, or ES modules supported natively as well?

So let’s accept the challenge and take it as a chance to be a pioneer, building completely new things with the native component model which the web platform offers. Now in 2019, it’s time to give a try to Custom Elements and Shadow DOM. They might not be “the next big thing” by themselves, but rather solid foundation the next big thing could be built upon.

I recommend considering Custom Elements, Shadow DOM or both, depending on the actual needs, when starting a new project or refactoring the existing one, to anyone interested in the long-term solution. Also, I would love to hear about the lessons you learned with Web Components – including your own pain points, as I realise that it’s not all roses.

Finally, I would like to encourage anyone to contribute to the “awesome” list named Web Components: the right way. As I previously announced, I’m the maintainer of that project and try to do my best in order to make it a more or less full and up-to-date knowledge base. And, as usual, I’m very grateful to hear your feedback and any comments regarding this blog post.

Beyond the polyfills: how Web Components affect us today?

Serhii Kulykov — Tue, 09 Apr 2019 20:59:15 +0000

After the recent public announcement of Chromium-based Edge canary builds, there has been a lot of excitement on Twitter because of the Web Components finally getting closer to land in all evergreen browsers. The Polymer community has been waiting for it so many years, and I share that feeling. Web Components are here... but I would still say it very carefully.

Let’s assume we don’t have to support IE11 or any other legacy browsers. So, evergreen browsers with native support for both Custom Elements and Shadow DOM. The good news is that we can forget about polyfills. The bad news is that “zero polyfills” doesn’t really mean “zero bugs”. Today, I would like to share my pain and talk about the problems that still exist.

The blog post is written based on 3 years of commercial experience with all the Polymer versions since 0.5 (yes, I still remember a weirdness of multiple shadow roots in the same component). During that period, I have been working both on the quite complex production application and a web component library, so my opinion is based on the actual background.

I’m writing this now also because of the upcoming “face to face” (F2F) meeting regarding the progress on Web Components implementation. Both the browser vendors and the representatives of the companies like GitHub and Salesforce are planning to attend it. The topics to be discussed include the future, which seems bright and shiny, as usual. But today I‘m going to focus more on the present, as there are still issues unlikely to be ever fixed.

The first one (you guessed) is about extending built-in HTML elements. Let’s say we want to implement our own anchor and use it for routing, which is a common practice for SPA. I was using such a web component at the times of Custom Elements V0 and it worked nicely. But Safari refused to implement “is” attribute, as they didn’t want to change HTML parser.

So, one can not simply extend the anchor (or button, or anything else like that) in Safari. And that’s very unlikely to change, even the corresponding issue has been closed long ago. It’s not even covered by the “official” polyfill by Google. Of course, there is a community polyfill for it. But does anyone really want to use it and monkey patch the browser internals forever?

Another problem where consensus with Safari wasn’t met is related to styling Shadow DOM. Specifically, it’s about :host-context CSS selector, designed to change a web component's styles based on its parent. This kind of inversion of control is not supported anywhere else in CSS. And Safari refused to implement :host-context and requested to remove it from the specification. So far, it only works in Chrome. Sounds familiar, doesn’t it?

The reason why :host-context is so important is that it’s the only way for the web component to adjust styles based on its parent. As an example, in some CSS frameworks, the <button> placed inside disabled <fieldset> should look disabled. We can achieve it with global CSS, but with Shadow DOM we can not. The only thing we can really do is... to change our mind.

One more thing which Shadow DOM affects is handling the focus, especially navigation order when tabbing to any focusable element, like <input>, inside the shadow root. This again works in Chrome only, with the flag called “delegatesFocus” passed to attachShadow() call. One line is expected to do a lot of magic and save us a lot of time once all browsers support it. Until then, we have to use temporary workarounds.

Did I say “temporary”? At the time of writing, the state of things sounds like this: nobody has done the work to refactor and integrate the feature into the HTML specification. And the developer from Chrome, who had been assigned to work on that long ago, has since left the team. So there hasn’t been any progress for almost 3 years. I really hope to see it after F2F meeting.

Moving forward, we stumble on yet another shadow DOM related thing. So now, a few words about CSS shadow parts. They have been recently shipped in Chrome and there has been some interest from Firefox, which is migrating its internals to Custom Elements. But again, no update on WebKit tracking issue for more than a year. As a result, yet another Chrome-only feature.

Unlike the examples above, missing support for CSS shadow parts doesn’t break anything… except that it completely breaks developer experience. In the real world, style encapsulation can be an evil for the users – especially when a web component has a lot of customisable internals, it is hard to provide a flexible architecture using only custom CSS properties.

In fact, users don’t really want styles to leak out the component. But at the same time, they often want certain styles to magically leak in. Yes, this has been partially covered with the Constructible Stylesheets (have you been able to guess the only browser supporting them as of today?). But we still need CSS shadow parts to replace abandoned CSS mixins and @apply.

So far so good, but it looks like I have to mention Safari once again – now because of a more advanced topic. If you have ever tried to use a rich text editor JS library like CKEditor, Quill, Prosemirror or even Trix (which is built with Custom Elements) inside a shadow root, you will understand me. And that’s again the issue to be fixed by the browser vendors.

Calling document.getSelection() in Safari doesn’t return nodes from shadow trees. Chrome, in its turn, implements this method also on shadow roots, but Safari doesn’t. There has been a rough consensus at one of the previous F2F meetings and a related issue submitted to the corresponding repo. Until this is fixed, we should consider using shadow DOM carefully.

As you might have noticed, all the issues except the first one are related to Shadow DOM. Even without the ShadyDOM shim making certain monkey-patched API slow in "good old" Edge, we still have problems to keep in mind. The declarative shadow DOM proposal (needed for server side rendering) opposed by the implementers is yet another serious challenge.

I hope it is now clear why so many people aren’t that excited about Web Components specs. They do provide a missing primitives and solve a certain amount of problems – at the cost of introducing other challenges. So, blind evangelism in support of the Web Components can actually result in backfire, as someone could call them a “broken promise” even today.

Wrapping it up, I do believe that Web Components are a big thing, and will hopefully make the architecture of our web apps more flexible, and the size of our bundles smaller. They can be compared to CSS grid or ES modules, except the fact that Web Components are coupled with all the underlying parts of the web platform: HTML, CSS, JavaScript and DOM.

And finally, as already mentioned above, I really hope to update this post in the upcoming weeks and to see at least certain of those tough questions resolved. And if you, the reader, watch as many GitHub repositories and issues as I do, you probably can give me a hand with some inside. Anyways, I would be glad to hear any valuable feedback regarding this post!

UPD: Please note, I'm not blaming neither Safari nor Chrome here, and to be honest Firefox has had a number of smaller issues too, once they rolled version 63. The point here is about how much the consensus means, and how long does it take for Web Components APIs to mature and stabilise.

Announcing Aybolit: lightweight web components library built with LitElement

Serhii Kulykov — Wed, 13 Mar 2019 09:41:40 +0000

Yesterday, I released a 0.1.0 version of Aybolit, the pet project I've been working on lately. In two words, it is about writing web components and finding "the common denominator" between popular CSS frameworks.

The problems Aybolit aims to solve are: granular DOM structure with Custom Elements, scoped CSS thanks to Shadow DOM, and flexible theming API with custom CSS properties and calc(). It also leverages the benefit of Constructible Stylesheets landing in Chrome, as the support for it is already integrated into LitElelment.

The initial release 0.1.0 only includes 5 components: button, checkbox, progress, range and switch (more to come soon). At the same time, it provides Bootstrap, Bulma and Material versions for all of those, plus "White Label" variant with bare minimum of styles, easy to override.

I appreciate any feedback and would like to make Aybolit better with the help of community. It's almost 3 years now since I started making first steps with Polymer, and I put all my experience and enthusiasm into this project.

Check it live: https://web-padawan.github.io/aybolit/

Source code: https://github.com/web-padawan/aybolit

Web Components: the Right Way. Project relaunch!

Serhii Kulykov — Tue, 04 Dec 2018 20:04:34 +0000

Web Components have been one of the most debatable sets of specifications so far. Someone called them "a broken promise", someone predicted that in 2018 they would still "lurk" waiting for interest from developers. The path of the Web Components towards the adoption was not strewn with roses.

Furthermore, this path was really long. It is now more than 7 years since the original ideas by Dimitri Glazkov and Alex Russell were demonstrated. Now, by the end of 2018, there are implementations in Chrome, Safari, and Firefox. And Microsoft, including VSCode team, is working on it too.

There has been a lot of enthusiasm from the developers excited by the ideas of the componentized future. Early adopters appearing here and there were brave enough to use Web Components in production (and to discover how deep the rabbit hole goes). They were sharing the pain and the knowledge.

It was 4 years ago, 1 December 2014, when Sindre Sorhus pushed the commit to his "Awesome" list, updating it with the new items. Among the others, there was a new list called "Web Components: the Right Way" by Mateus Ortiz, created a few months before that, in October 2014.

The wave of hype which was about to start in 2014 failed, and there was a period of disbelief. Web Components did not make it to the browsers that fast, future was unclear, React conquered the minds – dramatic story, huh. At some point, the "Right Way" list became unmaintained for a long time.

So, now what, you ask me? You got it: Web Components: the Right Way is again bright and shiny – and so Web Components are! I'm happy to announce that from now on, as a collaborator and maintainer, I will do my best keeping the list up-to-date and adding awesome content.

And now, I need your help and the power of the community to make it even better. We need a centralized knowledge base for anyone learning how to build Web Components. And we can work on it together. Right not there are already links to specs, blog posts, and tutorials – expect more to come.

Apart from the "introduction" level blog posts, which can be found easily, we need the real use cases – not in the form of marketing buzz, as it sometimes happens. Instead of digging into framework-specific details, let's collect the best practices which can be used regardless of the specific stack.

If you are looking for the place to watch for what's going on with the Web Components, without following w3c issues, this repo is a good choice. Also, feel free to submit your issues, if you have some topics to discuss or items worth including to the list. And of course, PRs are welcome!

Forem: Serhii Kulykov

10 years of building Web Components: the story of

First steps

Early days

The road to Lit

Where we are today

What’s next

CSS Shadow Parts are coming!

History

Usage

Basic example

Using ::part with pseudo-elements

Using ::part with pseudo-classes

Path forwarding with exportparts

Feature detection

Limitations

Documenting

Learn more

Summary

The next generation of Vaadin web components

Why the next generation?

How are we going to do this?

How does it affect developers using Vaadin?

Why LitElement?

Why TypeScript?

How do we get there?

What are our first steps?

: document your Web Components API

What?

Why?

How?

Web Components for Enterprise. Part 2: Nuxeo, Ionic, Vaadin

Nuxeo

Ionic

Vaadin

Summary

Web Components for Enterprise. Part 1: Salesforce, Oracle, SAP

Salesforce

Oracle

SAP

Summary

The Web Components journey: wrong ways, lacking parts and promising paths

The wrong ways

The lacking parts

The promising paths

What's next?

Beyond the polyfills: how Web Components affect us today?

Announcing Aybolit: lightweight web components library built with LitElement

Web Components: the Right Way. Project relaunch!

Using `::part` with pseudo-elements

Using `::part` with pseudo-classes

Path forwarding with `exportparts`