Frontend Web Frameworks yesterday, today and tomorrow: Polymer, React, minions, aliens and more!

…or how to make sense of the chaotic present and future(s) of front-end-development by taking a quick glance into the still-present-past.

In the beginning, there was HTML. Soon came CSS and Javascript. Then eons passed and lots of things happened… And now we found ourselves split between the Frontend Kingdom and Backend Kingdom. Nowadays, this separation seems as natural as the sky and the stars to most of us. Now, looking at the frontenders, they are split even further:

• some tribes built themselves strong castles with Angular 1.x or Ember.js
• others kept to the primitive habits of assembling their HTML, CSS and JS “by hand”, every man in his own way, using just some simple but powerful tools like jQuery and following a set of best-practices
• other swear by lightweight micro-frameworks like Backbone.js
• others fully embraced the future where we can all share components promised by WebComponents and the usable-in-the-present Polymer
• other believe that an even better future can be built by reuniting the Frontend and Backend Kingdoms via a magic JS staiway to the cloud, and they revere the powerful gods of Meteor.js
• and others still, started bowing to a new way of doing things, brought about by the mysterious and wonderful powers of React.js, whose influence is also starting to spread into the lands of native and mobile.

So let’s take that quick glance into the past that will help us understand this chaotic present and foggy future:

0. The Origins

In the beginnings gods gave us HTML. Then other gods gave us Javascript and CSS.

And even at this early stage, web pages started becoming more than simple hyperlinked documents. They started having application-like behaviors and more and more complex code.

And people started dreaming…

I. Out of the Chaos

Then they realized what they were dreaming of: (1) clean and easy to debug code and (2) some sort of reusable “things”.

And they worked their asses off to make those dreams reality. And this is how it looked like:

Things were cleanly divided into layers:

• HTML for structure
• CSS for presentation
• JS for behaviors

…and honestly, the layers mixed all over the place, but there were some really nice cakes. And some even found some ways of slicing the cake and they hoped to reuse some slices from an old cake into a new one. And sometimes this even worked …but most of the time it did not.

II. The Castle Age aka the times of the Big Fat Frameworks

And now people dreamed of better way of slicing their cakes and recombining and reusing their slices of cakes. And their cakes grew. They grew A LOT. Actually, at this stage they started looking more like castles than cakes:

And each castle followed it’s own way of making slices. Or, in other words they embraced a framework.

And inside a castle you can usually reuse slices, or let’s call them components from now on, as we’re clearly no longer talking about cakes. Things got serious now!

But one thing you couldn’t do was mix components from different castles. It turned out that framework-castles, just like real-world castles, grew walls! And frontenders grew isolated in their own castles.

III. The Future(s)

Now we know just enough about the past. So we can use this knowledge to look at the future(s). Let’s start…

III.a. Polymer and WebComponents aka “universal wrappings for cake pieces”

What if we forgot about the castles for a while, and went back to “the cake”? Let’s see now, what holds the layers of the cake apart? Well, it’s the obvious things, that they are made of different stuff, but it’s actually about web standards.

What if we could solve the whole cake-slicing at the level of web-standards? Well first, it would be really sloooow because getting people to agree on new standards takes ages! But this is the route some people took, and they succeeded in bringing us… WebComponents!

(HTML Templates + Shadow DOM + Custom Elements + HTML Imports = Web Components)

Hooooray!! …right? …err …not really: it will still take some times untill all the technologies covered in these standards will be fully supported by all browsers, although most work well enough today. And also, like all designed-by-committee things, the API for most of these stuff is kinda… fugly!

Thankfully, some really smart guys at and around Google, came in, wrestled with the WebComponents hydra, and brought us… POLYMER!

(POLYMER = WebComponents + a much nicer API with some extra powers on top + polyfills so we can use it in today’s browsers smoothly)

Now, the magic of Polymer is actually the fact that we can truly separate things. The chocolate cream from one piece of cake no longer flows all over the whipped cream of another one. CSS styles don’t flow from the outer page into the components or the other way around (unless you explicitly say that you want this to happen). Not even the IDs of tags used inside components need to be unique because they are truly isolated from the outside world. And components can be built from other custom components and you can use them as building blocks for others and so on and on…

Just dive into the Getting Started tutorial or the Polycasts videos (watch, out as some of the older ones refer to versions older than 1.0 so the code might not apply!) and join the fun!

But it ain’t all fun and games. Working with Polymer and WebComponents feels a lot like trying to get something done by commanding an army of minions (I’m referring to the cute yellow insane creatures from the movie, btw). You have a zillion ways of doing every things and no clear “right way”. And not so much hand-holding… it’s a BYOB job most of the time! (like in Bring Your Own Brain). The docs get you to… a point. The Polymer Starter Kit… helps. But after this, you need to figure it out on you own.

When using Polymer + Bootstrap + a set of third party jQuery based components (yeah, this can be done pretty smoothly once you figure some things out …but I’ll write this up in another post), it feels a lot like this:

…which can be fun, unless you have a deadline, like we all do in real-life.

III.b Meteor.js aka “finally bridging the Frontend|Backend divide”

But even Polymer does not solve what we know to be the greatest pain of modern full-stack web-development: the front|back glue-code that grows and grows in complexity until it eats up all your nerves and brainpower an does …nothing interesting?!

What if you could just forget about all that code that endlessly serializes your frontend models into backend models and does all the security black-magic and performance voodoo tricks and just have the same code and the same objects available both in the browser and on the server… magically? Well, this is what Meteor.js is all about:

…and I hope this was enough to make you look into it yourself, because I really don’t have the time to write more about it in this tutorial! But really, if you’re also into MEAN stuff, you must look into it!

III.c React.js or “what if it could all be different and more… pure”

Now, what if all the state-change mutability, two-way-binding induced complexities, DOM-mutation abominations and their consequences of impossible-to-replicate bugs and code-that-you-simply-can’t-run-in-you-head would just disappear? What if you could live on a magical river that only flows one way: from DATA to DOM?

This is the mythical land or React.js:

Here everything flows one way. You just need to specify how to render a component from some data. Then everything else happens automagically: you change the data, and the component is re-rendered. But there is some smart “alien technology” hidden inside it that only changes the DOM nodes that need to be changed, so there are no serious performance penalties induced by re-rendering large portions of the DOM. You need something about you component to be changed: you change the data, obviously. To make things even cooler, JS and HTML can now be seamlessly united (optionally) into …JSX, a “hybrid alien language” that is pretty sweet!

This sounds a lot like taking some of the principles of functional programming and applying them to frontend web-development, like teleporting stuff from a parallel universe where the web was build in Haskell and JS and HTML were born as conjoined twins instead of step-brothers.

Except that… it really works! and it’s fast enough. and it works on older browsers too …they say.

I really need to dive deeper into React.js …and I promise I’ll also come back with a nice write up of the experience (that will also have some code)!

But until then, I still believe that Polymer’s minions will take over the world!

Or maybe there’s a way to make Polymer and React.js play nice with each other:

…definitely need to try this and write it up!