How WebComponents Make Site Upgrading Easier

Contents

• Introduction

Introduction

While we’re used to systems nowadays being distributed and running across multiple services on multiple platforms when it comes to front-end web clients many people still have a rather “monolothic” outlook on things.

Many times this is down to technology imposing restrictions on us - it’s difficult enough to make some frameworks and all their component pieces work together to deliver an app without also throwing in the challenge of making multiple different frameworks coexist (part of the problem with the rise of “frameworks” instead of libraries).

It can be particularly problematic when an aging app needs to be upgraded. You may have an Angular.JS app and be faced with the choice of whether to re-write it as an Angular v2 / v4 app or switch to using the Redux / React stack instead.

Both represent a lot of work and the difficulty making frameworks coexist can be a real challenge with any attempts at doing things incrementally. This is where WebComponents can really help.

WebComponents are far from a framework and they are not even a library (although there are some great libraries being built on them). Chrome and Safari already have native support for them and there are Polyfills for compatibility in the meantime for the vendors still working on adding it.

What makes WebComponents special is that they are just the platform. They are not restricted to running within any section of the DOM that some app framework has bootstrapped and hooked into. They are the DOM, natively, no framework required. It should be no more challenging to add a WebComponent to any existing web framework view than it is to add a table or a div element.

This provides some real value when it comes to upgrading. It means we can take an existing chunk of code such as an Angular “component” and convert it into a true WebComponent that can run anywhere, with or without any Angular framework container being bootstrapped on the page.

This is a far simpler and safer upgrade path - the majority of the app code can remain untouched while we convert pieces to run without the old framework and the pieces we convert don’t need large swathes of new framework bundles to make them work. It’s lightweight and it’s efficient and performance is great.

Of course there will be some areas that are not quite so simple but on the whole I’ve found this approach of carving off pieces and converting them to WebComponents works really well especially if you want to keep the app running while the conversion process is happening. Hey, if you want to go off for a year to do “the big re-write” then good luck - I tried converting an Angular 1 app to work with Angular 2 and it was a total disaster and waste of time, this is much easier and safer.

Now you might be thinking that this is all very well and good but going all the way down to the platform level sounds like it would be a lot of work and make development less productive. It’s not as bad as you might imagine. I think much of the adoption of web frameworks started after jQuery which itself was invented to cope with the various differences and incompatibilities between browser vendors. Times have changed and the platform now natively delivers many of the features that we might be tempted to reach to a framework for.

But if and when you need some higher level features there are libraries such as Polymer that build on top of WebComponents providing things like templating and data binding. It does require a runtime but it’s pretty compact and because it is a library and doesn’t impose the the runtime constraints of a framework it still works very well for the gradual-migration approach.

The web platform develops at a much slower pace than JS frameworks because anything that is released typically has to be supported by browser vendors for significantly longer periods of time. We couldn’t still be building websites with the same core HTML after 20+ years if they didn’t and this is why WebComponents have been so long coming - getting the standards for them designed and agreed between vendors means that they will likely be here for a long time to come and that means code that aligns closely with them will run faster (through the native implementations) and suffer far less churn in the long-term.

Some frameworks are promising new major releases every 6 months as though this is a great feature to look forward to. No thank you! I want the code I write today to be capable of running in 6 years without having to constantly be upgrading the framework, if it even still exists. WebComponents help make that possible.

It doesn’t mean we can’t use frameworks if and when we want but WebComponents mean our code doesn’t have to be shackled to any single framework and being framework-agnostic means they are reusable anywhere - a much better investment for the future.