Choosing a web component Model

If you are trying to decide which web framework to use for your next project, I would suggest that you first consider a related question:

Which web component model to use?

The world has pretty much decided that it is a good idea to componentize software and this includes the UI layer of your app.

General-purpose programming languages, like JavaScript ES 6, have many wonderful mechanisms for organizing, modularizing and encapsulating your code: functions, objects, classes, modules, etc. These features provide everything one needs to properly componentize a JavaScript app. But here is the rub:

Modern web UI’s are not written in JavaScript.

They are written in JavaScript + HTML + CSS. AKA The Web Platform.

And historically, there has been no real component model for the web platform. No mechanism to provide encapsulation and modularity. HTML id’s are global. CSS is global. Traditionally, there has been no convenient mechanism to bundle up some JavaScript, HTML and CSS into an easy-to-use, reusable component.

Thus there is a ton of effort going on to solve this problem.

Moving forward, we have two prevailing approaches for how to componentize your web apps:

1. Abstract the Platform. Avoid HTML, CSS and DOM as much as possible. Write everything in JavaScript. Then use all of the wonderful features of JavaScript, mentioned above, to componentize your app. This is the approach championed by Facebook, React and it’s ilk. This is a very successful approach and is widely used today.
2. Embrace the Platform. Utilize the recently added componentization features of the web platform itself. This is what the W3C Web Components spec is all about. Polymer (and Angular 2 ??) is based upon Web Components.

These two approaches are radically different and mostly incompatible. Thus, which choice you make will have powerful ramifications down the line. It is worth noting that there are strong opinions on either side of this debate. For example, Facebook, the creators of React openly state that they have no intention of ever moving toward Web Components.

Here I will describe and compare each of these two approaches. And how they attempt to solve the problems of web components.

Points of comparison.

• Ecosystem and supply of high quality components
• Ease of creating a component
• MVC-ish
• Performance
• Architecture and maintainability
• Templates and data binding
• External DSLs
• Legacy integration
• Interoperability
• CSS and HTML Encapsulation
• Theming

MVC-ish

I am using the term MVC generally here, in it’s broadest sense. This includes all of the MVC variants, including (and especially) React.

It is generally considered a best practice to create your UI as a function (or projection) of some model. Then, when the UI needs to change we don’t update the UI directly. Instead, we update the model. And then re-render all or some of the UI.

I am calling this MVC. The pattern was born 30 years ago in Small Talk and has stood the test of time. The details change but the key principle is the same.

Geeks like me can debate for hours over which variant of MVC is best and how best to implement it and how model changes should be propagated back to the view (change listeners, dirty checking, virtual DOM, explicit programmer refresh, etc.). But in my opinion:

The MVC pattern in general (regardless of what you call it) is essential to building complex UIs.

Web Components offer nothing specifically to address the general pattern of MVC. There is nothing in any of the web component specs to address or even acknowledge MVC. Thus MVC functionality is left up to the individual developer or to the framework developers. Polymer and Angular 2 provide templates and 2 way bindings on top of Web Components.

In the React component model, MVC is not an after thought. It is the defining feature. Despite the fact that React refuses to call itself an MVC framework, React’s handling of MVC is the thing I like most about React.

To be continued…

Conclusion

As you can see there are very compelling arguments in favor of both approaches. What I would really like to see is a component model that combines the benefits of both. Until that time, it’s a tough choice.