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.
Top comments (6)
Recently I've been looking into something to replace Polymer components being used in a project I'm working on (funnily enough, we also still actively use the polymer-dependent Vaadin components along with the Polymer 2 itself). And Stencil looked very interesting, with TypeScript an other cool stuff out of the box. However, the sad part turned out to be the fact that Stencil does not allow extending existing components at any point. Inheritance from any imported class is not allowed due to some internal compiler quirks (Stencil is, in fact, a compiler). They have an actively discussed issue and the team did state that they have a good practice for this in mind, but didn't follow up for over 3 months and the decision kind of hang up.
I was looking to inheritance too when I began to play with Stencil and at first I was sad too that it wasn't possible.
Fast forward one year later, I've created multiple components and I'm even developing a full app only with it (aka "without framework") and turns out I was able to live without that pattern. Also don't feel my code is that uglier.
Just wanted to point out that according my experience, even if that would be cool, it isn't something absolutely mandatory or maybe you've got a concrete use case where inheritance is absolutely must?
I love the idea of web components, but I don't know if I need them now that the trinity of frontend frameworks exist. But then again, it would be nice not to be tied to a particular framework. Caniuse?
All major browsers support the required specs for web components since late last year, except Edge (Chromium Edge should fix that).
I've been building framework-less on Stencil for almost a year now and I have to say... It's AMAZING. I honestly believe web components are what the frameworks have been trying to give us for the last decade.
Now that they are part of the spec and relatively stable, I don't really see the point in the Frameworks anymore, other than to provide an opinionated standard, and access to all the libraries built to support them that don't work outside of their context.
re: your #1 Summary point - "Custom Elements being class based by design as a basic problem for so many people."
I still can’t figure out if this is just a dev preference, or if this spec actually prevents a migration towards the benefits of functional programming?
An example is Java, where class based code hasn’t prevented a migration to functional programming - it’s just one of many preferred options for how I write my Java code. Isn’t that same thing true within the context of WC, as it is currently spec’d?
htmlelements.com/ should be probably in this collection, too. Smart is web components framework built by jQWidgets with more than 60 web components