Web Components for Enterprise. Part 2: Nuxeo, Ionic, Vaadin  
Tags: webcomponents, customelements, javascript, html
Published: 2019-07-23 20:16:49

---
title: Web Components for Enterprise. Part 2: Nuxeo, Ionic, Vaadin  
published: true
description: Overview of the UI development platforms targeting enterprise companies and built with Web Components.
tags: webcomponents,customelements,javascript,html
cover_image: https://thepracticaldev.s3.amazonaws.com/i/o658f3h5cu720yy8w48x.png
---

Web Components, like almost any technology in the frontend ecosystem, have supporters and opponents. The opinion polarity is mentioned in the [announcement](https://twitter.com/FronteersConf/status/1146751390078918656) 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](https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell) 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](https://dev.to/webpadawan/web-components-for-enterprise-part-1-salesforce-oracle-sap-e70) 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](https://www.nuxeo.com) is a software company offering an enterprise content management [platform](https://github.com/nuxeo/nuxeo) 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](https://www.nuxeo.com/blog/web-components-a-great-standard-for-a-platform-approach/) 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](https://www.nuxeo.com/blog/everything-you-need-to-know-about-web-ui/) 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](https://www.webcomponents.org/author/nuxeo), 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](https://github.com/nuxeo/nuxeo-elements). Finally, JSF has been [deprecated](https://www.nuxeo.com/blog/jsf-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](https://www.nuxeo.com/blog/nuxeo-web-ui-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](https://ionicframework.com) is a software company offering an open-source MIT-licensed cross-platform UI development toolkit called [Ionic framework](https://github.com/ionic-team/ionic) 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](https://github.com/ionic-team/stencil), a compiler for Web Components and PWAs.

According to the recent [tweet](https://twitter.com/manucorporat/status/1147438907342118912), core development of Ionic and Stencil is handled by 10 people, and the [team on GitHub](https://github.com/orgs/ionic-team/people) 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](https://www.youtube.com/watch?v=UfD-k7aHkQE) at Polymer Summit 2017 to land as [1.0.0](https://github.com/ionic-team/stencil/blob/master/CHANGELOG.md#️-100-2019-06-01) 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](https://twitter.com/adamdbradley/status/1143554342122938368) 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](https://dev.to/ionic/why-we-use-web-components-2c1i) 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](https://blog.ionicframework.com/build-your-next-design-system-with-web-components/).

## Vaadin

[Vaadin](https://vaadin.com) 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](https://vaadin.com/blog/but-why-web-components-) 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](https://vaadin.com/blog/building-components-on-top-of-polymer): 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](https://vaadin.com/blog/reinventing-the-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](https://youtu.be/945pO9Yn1ns?t=408)" 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](https://youtu.be/xSnG-mNWhqI), to get rid of the abandoned CSS mixins proposal and `@apply` syntax used by Paper Elements.

As of today, Vaadin components use [Lumo](https://demo.vaadin.com/lumo-editor/) 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](https://vaadin.com/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](https://ionicframework.com/docs/intro/support#long-term-support-premium-)), 3 years of support ([Nuxeo](https://doc.nuxeo.com/nuxeo-release-cycle/)) or 5 years of support ([Vaadin](https://vaadin.com/roadmap)). 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:

1. **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](https://css-tricks.com/haunted-hooks-for-web-components/), objects, or even server-side representation of the DOM tree.
 
2. **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?

3. **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](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/The-perils-of-using-Internet-Explorer-as-your-default-browser/ba-p/331732)”. 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](https://www.mozilla.org/en-US/firefox/organizations/) 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.