Captain Codeman Captain Codeman

Polymer 2.0 - Simple and Elegant

Web client frameworks don't have to be complicated



If you’ve been involved in front-end web development for the past few years you will no doubt have come across the concept of “JavaScript Fatigue”.

It’s the result of constant and seemingly endless changes, reinventions and releases of tooling and frameworks that you feel you need to keep up with.

Often it seems like something is invented so solve one problem but brings with it more issues. And in the world of JavaScript there’s nothing that can’t be fixed by new tooling … always, oh so many tools.

But things are going to change …

The latest trend is for the JavaScript code bundling tools (think Browserify, WebPack and Rollup) to now offer “Code Splitting”. Yes, it sounds a bit crazy - first you pull all the pieces of code together and then you split them all apart. Where once you had a few simple Grunt or Gulp tasks to move a few files around and combine a few things, now you have complex build systems - more complexity to manage the complexity of the previous round of inventions.

Well, what if it didn’t have to be that way? Remember when you could just open a web page in notepad, edit it and view it in the browser? Those days are back my friends thanks to the simple elegance that is Polymer, because Polymer builds on the web platform, specifically Web Components.

Instead of trying to jam an entire applications mass of JavaScript into a single bundle before realizing that it’s way too big and trying to split it into fragments, Web Components allow you to keep things separated from the start.

Each Web Component is a neatly packaged up micro-bundle of the HTML, CSS and JavaScript required to make it work. Because they are small, they load fast. And because they are individual, they load and start working straight away so you don’t experience the “uncanny valley” of an app that appears to have rendered but it still awaiting the 4Mb of JavaScript required to make it function - as elements appear on screen (and they appear fast) they are fully functional.

With Polymer you don’t need to bundle your code, you can run it straight from the disk which does wonders for development speed and productivity. You might think that this would be slow at run time and, if you were using the web as it was 5 years ago, you’d probably be right - the cumulative latency of requesting each small piece would be prohibitive.

But it’s 2017 and the web has changed. With http/2 we now have server-push which can start dependencies downloading as the very first response is sent from the server. Think of it as bundling on the fly but unlike the old bundling, where changing one bye of one source would invalidate the entire file, this retains the advantage of being able to cache each piece separately so only what’s changed needs to be sent.

Because each component is individually packaged up, you also don’t need to bother with the other build tools invented to give the appearance of modularity. I’m talking about CSS pre-processors such as LESS and SASS. Imagine if a button in bootstrap contained the CSS for a button … why would any CSS bundling ever be necessary?

You can, if you want, bundle groups of components together if it makes sense. The Polymer team provide a great cli tool that has this option baked in. It will also transpile ES6 to ES5, minify HTML and CSS and create a service-worker file too. But these are enhancements, not necessities. You can ship the raw components if you want.

It’s this stripping away of the complexity that for some reason we’ve all grown to accept as the only way to do things that delivers an overall simple and elegant development experience. The amount of tooling and work necessary to create a fast-loading Progressive Web App with Polymer is minimal compared to most other frameworks.

Give it a go, you’ll be surprised with what can be achieved now by sticking closely to the web platform. The hardest part is unlearning some of the entrenched thinking that’s built up over the last 5-10 years. All those abstractions and frameworks and build tools that we used to need now might just be getting in the way.

There is another way …