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.
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:
- 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
- Architecture and maintainability
- Templates and data binding
- External DSLs
- Legacy integration
- CSS and HTML Encapsulation
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…
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.