Object-Oriented Legos

If you are a web developer, and have not yet taken the Web Components path, I have a new year message for you: Please, do it!, the sooner, the better.

The Web Components development paradigm is a huge leap forward on how web development is done. Please do not misunderstand me, I am not just dismissing the value that countless other web technologies have delivered, they have brought us to our current state of the art and, for that, they will be fondly remembered.

These brand-spanking-new, wonderful, life-changing, seemingly almighty (and sometimes, good looking) Web Components are based on the basic JavaScript, CSS, HTML trio, so the good news is that, if you decide to start training yourself in this new way of doing things, it will be more like building upon your current skills, and less like starting from zero.

The idea behind Web Components is to allow a new level of encapsulation and interoperability only dreamed of in the good old days (2014 and back.) I like to think of Web Components as Object-Oriented Legos (Lego is a registered Trademark of The Lego Group http://www.lego.com.)

Individually, the humble lego block is a simple and kind of useless piece of plastic; but when you combine two pieces, the magic begins. With a reasonable supply of pieces, beautiful art can emerge, and if you had an unlimited supply of them, then you could create whole new universes. 

The possibilities defy imagination.

Now, let us evolve the brick concept: think of a world where you can get a basic building block from the web (or create it yourself), clone it to make as many pieces as you need, then make some of them wider, some thinner, some green and some orange; make them communicate with each other and exchange information. 

Just imagine the result. 

I present you with Web Components.

When stepping into this brave new world, there are four basic concepts you have to deal with, those are:

(quotes obtained from here and here,comments by me)

HTML Imports

HTML Imports are a way to include and reuse HTML documents in other HTML documents.

For a long time, including fragments of code in an HTML page could be done using a server side mechanism such as jsp, asp, aspx, php or any number of other server side technologies; on the client side, this could be accomplished using JavaScript to import the fragment via ajax and then injecting it into the DOM tree, or via the tried and not so docile iFrame mechanism. All but one of the mentioned methods and technologies have a common element: none of them involves, other than the actual HTML being imported, any HTML in the process, relying on some plug in, server side technology or external process via scripting to accomplish something that should have been a part of the HTML definition all along. A HTML import looks like this:

    <link rel="import" href="my-brick.html">

With HTML imports you can forget about what server side technology you are using, you simply import the needed fragments into your page from the client side, in the Web Components context, these are like Java import statements or #include C statements.

Shadow DOM

This specification describes a method of combining multiple DOM trees into one hierarchy and how these trees interact with each other within a document, thus enabling better composition of the DOM

Shadow DOM implements a nice encapsulation mechanism for Javascript variables and CSS tags, so no more CSS or Javascript name conflicts between your includes and that jQuery extension you are craving to use in your project. With Shadow DOM, all variables are scoped within the component. And components can still interact with other components and other elements of the DOM tree.

Templates

The template element is used to declare fragments of HTML that can be cloned and inserted in the document by scrip.

Although template mechanisms have been with us for a while, the existing template mechanisms require some sort of server side framework or library to actually be useful. Web Component Templates behave more in the lines of a normal object oriented language class, they encapsulate the actual markup and CSS that determine how the component shall look like when cloned, they also contain the Javascript code to implement the promised functionality, so, Templates are more like classes in a Object-Oriented HTML. I say Classes because the actual Template, just like its Object Oriented counterpart, is completely inert until it is cloned (instantiated).

Custom Elements

This specification describes the method for enabling the author to define and use new types of DOM elements in a document.

HTML Includes allows the insertion of HTML files that will likely contain your Web Components, Templates offer a much needed modularity for Web Components so they can be cloned as many times as necessary without causing any conflict, Shadow DOM provides the encapsulation and scoping magic that will save you gazillion hours of sweet debugging time by making Javascript name and CSS selector conflicts a thing of the distant past (2014 and back ;-).)

Now it is the turn of the Custom Element: It allows the insertion of any well formed Web Component in the markup as a valid HTML element, as in:

    <body>

        <my-brick>

            <!-- Anything my-brick needs to include -->

        </my-brick>

    </body>

Where the my-brick element is a component imported via a HTML Import as shown earlier. Elements declared in Web Components can be cloned, configured and inserted in the DOM tree either explicitly in your markup or via Javascript.

But...

The ugly truth is that we are not quite at a point where we can jump ship and live happily ever after. Just not yet. For the time being, Web Components come with a big price tag: PERFORMANCE.

Although tremendous progress has been made in the quest to bring us this game changing technology, as of today (January, 2015,) not all mainstream browsers offer native support for it, not yet, see [http://caniuse.com/#search=components].

But while we wait for full support to happen, polyfills are here to save the day. With polyfills, all browsers are compliant, some would be lacking in speed, but are, nevertheless, compliant.

Despite the relative immaturity of the current support for Web Components, I encourage you to start this fascinating journey as soon as you are able and not fall behind, the revolution is already happening and it is building momentum.

Your bottomless bags of Object-Oriented Legos are waiting you at:

• Polymer Project: https://www.polymer-project.org/
• X-Tags: http://x-tags.org/
• Bosonic: http://bosonic.github.io/
• Custom Elements: http://customelements.io/
• Component Kitchen: http://component.kitchen/components

These are but a few of the web sites that can help you get started.

What are you planning on "componentizing"?

 A quiet autumn day at the port of Santa Cruz de Tenerife

Photo credits: Paulo E. Márquez H.