Go Long on Web Components

The common conception is that web technologies are a volatile bunch, where nothing stays the same for years. But the core technologies are actually rather conservative. Just consider how well an old web application or a site continue to work with the latest browsers.

This is where the core technologies, HTML, CSS and JavaScript show their stability. Even though countless hacks, front end libraries, pre-processors, have been built on top of these, it’s an anomaly that something old ceases to work when you upgrade your browser version.

Over the years we’ve had countless efforts for making up for lacking browser features; custom fonts, rounded corners, video playback, just to name a few. One by one, these have fallen prey to the ever advancing enhancements in web standards and their browser implementations. These simply become non-issues over time and the workarounds become irrelevant.

However things are rarely black and white. Take jQuery, the once de-facto utility library that developers used to include by routine. jQuery skills were once listed as requirements for jobs. Nowadays it’s a curiosity to list jQuery skills as a requirement and the library is no longer the must-have it once was. This does not mean jQuery itself was a bad technology or a failure.

In fact jQuery was maybe the greatest single library in the world of JavaScript, ever. It made the browser development much more accessible with it’s easy API and brought immense productivity gains. But it was a stop-gap, whose place is now taken by native web technologies.

Standards are built to last

This brings us to the title of the post. Native Web Components have been a promising technology standard for a number of years. They initially failed to gain momentum and were eclipsed by JavaScript based component libraries such as React and Vue.js. Web Components even reached a running joke status in some camps. They were in limbo.

The history of web standards is not short of failures. There are plenty of efforts that failed to gain traction in the real world. These were standards that were designed in a lab, sucked up millions in investment, but failed because didn’t have input from the real world or were ahead of their time. You may remember such initiative like WAP, XForms and Modular XHTML.

jQuery is a great example how web standards can be built on innovation done on library level. We've had document.querySelector native in browsers for years now. During the past few years the Web Components standard has not only matured in technical implementation, but it has certainly taken quite a bit of influence from Angular, Ember, React and other innovators.

This takes me to React, which is React is now at the top of it’s hype cycle. Just like with jQuery, it popularised new concepts and deserves loads of credit for that. It’s even grown beyond the browser and now targeting VR and Mobile Operating Systems natively. It has great concepts and an accessible API, but for the browser it’s has a JavaScript polyfill for DOM manipulation.

Web Components are neutral

As of May 2017 there are over a billion devices with browsers that are Web Components capable, and the polyfill library provides a practical way forward for browsers that yet lack standards compliant implementations. All the way to the last incarnation of Internet Explorer.

The Web Components v1 spec is solid and key polyfill libraries are stable. iOS now ships with Web Components enabled browser and the rewrite of YouTube in Web Components is a living example of a large scale application in the real world. Web Components have arrived.

It's easy to hang on to your favourite JavaScript component library and dismiss the web components approach. Aside from the natural tendency to defend your investment, this juxtaposing does not make sense. Many use jQuery for AJAX calls because of the API, similarly there is no reason why Web Components wouldn't work together your favourite library.

As React and others extend beyond the browser and the DOM they will continue to be relevant, but for the browser I see that ultimately the standards based options will be most universally applicable. Despite individual JavaScript libraries being component based, mixing and matching them is hardly trivial. This is where Web Component’s neutrality comes into play.

In the not-so-distant future I imagine YouTube embeds can be done with their own Web Component. Because of it’s nature, the JavaScript libraries will work with it just like any other tag. This means that you can use the same exact component between Angular, Vue or React applications. This means more flexibility and less reliance on proprietary implementations.

Learning is an investment

There are quite a bit of parallels between the world of business and software development. For both you need to invest resources to something and over time they tend to fluctuate in value. Disposable investments, like a van, only has a limited lifetime which you need to use it efficiently. Real estate on the other hand is a fixed investment that takes time to capitalize on.

I view any given polyfills (be it related to HTML, CSS or JavaScript) as disposable investments and established Web Standards as fixed investments. Ideally you will need a mixture of both, but given that learning takes time, it's unlikely that anyone will be able to master it all.

If I had to choose a single front end technology in 2017 for a long lasting career in Web Development, I would choose Web Components.

- Jani Tarvainen, 2017/05/18