Web Components - a Great Standard for a Platform Approach

Since we are always thinking about the future of the Nuxeo Platform, we got excited when we began to evaluate the Web Components standard. This new standard has several truly interesting characteristics in regard to our platform approach. We decided to start a concrete investigation and will present some of our findings in a series of blog posts. This first one introduces why we think Web Components may be a good match for the future of the Nuxeo Platform UI framework.

Components for the Web (a.k.a. Web Components)

As a platform provider, we build reusable isolated components that are framework agnostic, simple to use and can serve as building blocks for our community of developers. Thankfully we are not alone and this need has driven the W3C Web Applications Working Group to work on a specification for a component model for the Web: Web Components. Let’s start with an example that shows how web components can simplify content-based applications integration.

<div class="container" layout="" vertical="" center="">
<div class="card" layout="" horizontal="" center=""><img src="/nxthumb/default//blobholder:0/" alt="" />
<h2></h2>
</div>
</div>
<pre>

The previous snippet of HTML in Chrome (with correct imports in the page, see after) will produce the following:

A document listing generated with Nuxeo components

We will explain the new nuxeo markups in an upcoming post. For now we just wanted to put the emphasis on the simplicity of web development, with the transparent encapsulation of calls made to the Nuxeo Demo Server to fetch and display the content. This simplicity is due to the two web components that are part of the example: “nx-connection” and “nx-page-provider”. Web Components are a collection of standards which ultimately allow developers to create their own custom HTML elements, such as nx-listing or nx-page-provider seen above. Among those standards are:

Custom Elements: These custom elements can use custom tag names, attributes and events and can also expose a custom script API. Developers can even extend native HTML elements as well as other custom elements. Custom elements allow you to bring new semantics to the Web, extending the existing HTML vocabulary and promoting more meaningful structured markup and content.
Templates: The content of the custom elements can be defined by templates - chunks of markup that can be attached and activated on demand. If you have used mustache or handlebars you should be pretty familiar with the concept of templates.
Shadow DOM: Proper isolation is also a cornerstone of Web Components thanks to a new specification called Shadow DOM. It allows encapsulation and well defined boundaries within the DOM. Any HTML, CSS or JavaScript inside your custom element can be protected from the parent document allowing for more reliable composition of your user interface components.
Imports: Web Components specify the packaging and loading of your custom elements as well, thanks to Imports which provide a convention for bundling your HTML, CSS and JS into a single deliverable:[html]
[/html]

Comparing Web Components and the JSF+Seam stack

We find many similarities with the JEE JSF stack that we have integrated in the Nuxeo Platform. In particular, we find in the Web Components approach the good things we like in the JSF framework, while it also solves some of the problems we met.

Similarities with the JSF+Seam approach

Reusability: Custom elements are like JSF components: they hold their logic, their model, they can be based on custom templates and they provide data-binding. They authorize you to build advanced components with reusability in mind, which is a key point when you are building a platform.
Modularity/extensibility:
- Close to native HTML chunks, Custom Elements are compatible with templating and composition design, which is absolutely necessary for building an extensible and modular application. The facelet mechanism of JSF was really helpful for authorizing our customers to override tiny parts of the application without endangering the maintainability. We would have to select a templating framework for doing the same with Web Components - which is not a problem as there are many of them.
- Another aspect of modularity that helped us a lot with Seam/JSF was the event/observer pattern, which allowed us to deploy new SEAM components without having to strictly reference them in other components. We can use JavaScript custom events to have a similar approach with Custom Elements.
Databinding - Controler: Web Components frameworks such as Polymer have added a notion very similar to the JSF EL for having advanced data-binding in attribute values, with easy references to scripts variables and methods, a bit like the way Seam component methods can be referenced from the JSF EL. This makes it very easy to wire Web Components together and provide an easy to understand pattern for implementing what you need.

With some real advantages

Client-Side versus Server-Side: Web Components is a client side technology, while JSF happens server side. Aside from all the stateless/stateful design comparison that clearly goes in favor of stateless design, the necessity of having a complete tree representation of your page server-side added a lot of complexity in the JSF cycle and its framework apprehension. In the end people have the feeling that JSF is difficult. First experiences with the Polymer framework, provided by Google for playing with Web Components, gives a simpler feeling, especially with the notion of double way data binding. Note though, that the “Shadow DOM” part of the Web Components spec can also lead to some very tricky situations :-S
Agnosticism: JSF is a standard limited to the Java World (and even in the Java World, suffered from competitive non standard frameworks such as Spring), while Web Components are a Browser capability specification, independent from any language, even if most of the Web Components are written in JavaScript. This means that Web Components are compatible with any server-side technology, whether it’s Java, PHP, C# or Android. This is an amazing differentiator!
WYSIWYG approach: Google offers an open-source designer that allows a WYSIWYG approach for composing a dynamical HTML page using Web Components. This seems very promising, although there are still some limitations as we will see in another post of this series. Visual designers exist also in JSF world, for Eclipse or Netbeans environments, though the fact that your browser is the visualization engine makes it simpler and allows more possibilities for integration of a design interface to Nuxeo Studio in the future.

It is a bit too early to understand all of the challenges we will face using Web Components and a related framework. One thing, though, that appears quickly is that because of Web Component encapsulation, error logging is a bit surprising at first. Your page may fail silently and you don’t understand what happens at the beginning. New web components are being developed every day and one can easily plug these into our own applications. Web components will enable developers to create truly reusable UI components which is actually what the Nuxeo JSF framework is all about … but only in the JEE world!

Web Components support is growing

Below is the browser support matrix:

Browsers Web Components Compatibility Matrix

Source: http://jonrimmer.github.io/are-we-componentized-yet/ (July 28th, 2014) Fortunately, a compatibility library (a polyfill) is maintained by the two main Web components frameworks available: Polymer and X-Tags. Thanks to this polyfill, support is extended to Safari, Firefox and IE 10+, with some acceptable limitations in some cases.

What’s Next?

There are several good articles about the different bits and pieces of Web Components so we won’t be focusing much on the specification details. In the next part of this series we will take a look at the existing Web Components libraries and frameworks.

References

This blogpost was co-authored by Nelson Silva and Alain Escaffre.