Abstracting the DOM
Summary: neither of these solutions can be considered performant. On the one hand, you're loading dozens of resources for shadow DOM trees; on the other, you've got an in-memory copy of the entire DOM. Both methods presume some arguably unfair minimum requirements.
As Google continues to push for the Web Components standard—even roping in its puppet-competitor Mozilla—and while Facebook's React.js continues to grow in its influence and maturity, an important question arises which will be significant in determining the likely victor between these related technologies: which is better, the shadow DOM or the virtual DOM?
It's necessary for us to first establish what each of these actually is in order to make an informed judgement on which is better. The shadow DOM is one of the concepts that is driving the push for the Web Components standard. It's not strictly necessary to use a shadow DOM for a Web Component, except that what you have then is not really a Web Component, but a
A Web Component is a set of DOM elements packed as an isolated and portable block, with its own style/script context, separate from the “true” DOM. We call this isolation of styling/scripting encapsulation and it's very attractive over the incumbent iFrame, a noted performance hog. Take out the shadow DOM, aka the diet iFrame, and you have a custom element, literally HTML elements for which you can provide custom tag names—basically, a means by which to take the notion of semantic DOM nodes to the extreme.
Sure, it's nice to have semantically-named UI components as clean blocks that you can essentially copy and paste into the
document, but the performance cost is astronomical in Safari and Firefox with all of the polyfills, and it's no spring chicken in Chrome compared to regular HTML.
The performance improvement over other frameworks results from the virtual DOM not actually being a rendering engine, it's essentially version control for the native DOM. Change something and, rather than rewrite the DOM, it tracks the changes and updates (hence the name “React” rather than “jQuery 3”) and this should, in theory, keep costly DOM manipulation to a regulated minimum.
And it's true, React is a nimple alternative to frameworks like Angular, but this is a common misinterpretation of what React is and what other frameworks are. Angular, and Polymer to an extent, are ASP.NET WebForms reimagined, while React is a diffing algorithm and an abstracted handler for UI state. You can even implement React's benefits in jQuery if you don't like how React does things, or you could roll your own framework adopting React's approach rather than getting tangled up in the React fad of using JSX, attribute styles, and so on. The core ideal of delta copying, of tracking revisions to the DOM, is (or should be) the (only) reason behind React's prevalence in recent months.
Apples and Oranges
Minimising/abstracting DOM revisions and separating the DOM into lots of sub-DOMs are different solutions to different problems. Eventually, Web Components/Polymer will probably end up taking some concepts from React on board and do away with DOMs within DOMs (seriously, they removed support
<style scoped> from Chrome due to complexity, but nesting a different DOM context for every major UI component is supposed to be simpler?
Should I be interested in any of these?
alert and these days creating modals and overlays block users from consuming content without first doing something profitable.
Even if, for the sake of good UX, you want to give some immediate (i.e. not post-
post or post-reload) feedback regarding the validity of user input, you can—and should—validate on the client side using HTML5 attributes like
required, along with
:invalid CSS3 selectors to indicate state.
The most you could possibly need on the client side for polished UX would be an
onblur handler to throw into the mix.
Why Web Components are crazy
Scope is nice and everything, but just watch the network timeline for a Polymer site. HTTP2 is coming soon, but not that soon. Sure, you can hit up the Polymer Project website and not find yourself waiting around too long, but that's probably thanks to much of the website's resources being served up by Google's CDN.
The reality is that serving up a Polymer app will incur some performance penalties on the HTTP1 spec, and they're just not worth it. Encapsulation basically enables lazier development with little to no gain for the user. There is enough front-end tooling available to trivialise the production of optimised clean, modular CSS. Write your CSS properly and you shouldn't need encapsulation.
In my opinion, the whole point of the web and the reason for its use as an app vector orthogonal to native apps is:
- The web should be light
- The web should be trustworthy
- The web should be universal/cross-platform
When you start thinking about Web Components and offline web apps, you're really not far from just installing a native app. It'll be heavier than a website should be, it'll need to essentially install itself or a copy in order for it to work offline, and the complexity of the web app itself and the development time will likely skyrocket. Plus Web Components are only natively supported in Chrome, which means that the Web just stopped being cross-platform which is its singular financial/business-translatable advantage over native apps.
Why you still shouldn't consider React
I mean, you do get something of a budget on modern smartphones, and having Chrome available on iPhone and Android is a big help, but you have to remember that just because Chrome is the rational browser choice, that does not mean that it will be the browser of choice for the majority of users. It won't be.
Oh and don't trust React's virtual DOM to save you from the performance cost of DOM manipulation. The virtual DOM isn't an infinitesimal or a nearly massless neutrino; it is part of a UI library, so add a HTTP request. Then do some intensive DOM manipulation with the virtual DOM.
(In all fairness, you can hardly blame iOS users for sticking with Safari since you cannot change the default browser, just install additional ones, making Chrome a bit of a hassle to use if you need to open a link from within an app or email.)
If somebody comes to you with some serious money, a sane deadline that permits for extensive testing and a desire for a performant web app, then you can think about React.
NB: if you must opt for an SPA, please use React and render it on the server. Angular 1.* is dead and Angular 2.* is still going to be Google WebForms. Sure, it works, but if the alternatives are lighter, cleaner, and quicker to develop (once you achieve a reasonable level of proficiency) things like Angular really start to make less sense.
Lots of developers should be thinking about these technologies and approaches to the web. Native apps are a serious threat to the future of the web and web applications need to be demonstrably equal to or better than native applications in more ways than relative cheapness. Web applications need offline support, high performance, high framerate, real-time notifications and so on. All of these are possible, but with varying degrees of success/stability.
With businesses developing mobile apps just for user engagement, without having any function or service in the app, it's clear that users just like apps and to interact. Suffice it to say that, if performant native apps were written in a common language and thus costed less to develop, the web would not have time to respond. We web developers ought to actually thank Apple, Google and Microsoft for adopting Objective-C, Java and C#.NET respectively.