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:
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.
