Yesterday I wanted to complete the documentation of the animated
hamburger_icon button used in my previous post.
As often happens, documenting things will help to improve them and this will require a few last-minute changes, that in this case were about adding extra options for choosing different burger animations and colors. The result is available here.
But wait a minute... I've used this hamburger_icon button in all of the 3 example projects on Glitch and also over a couple of other projects on GitHub pages.
Does that mean I've to copy the new code all over the different projects that are using the hamburger_icon and publish all of them once again?
Luckily that's not the case since none of those projects were holding a copy of employed bits but rather a direct link to the original source of each.
This is also what we can see in the
HTML code used to implement the header bar in the last example of my previous post:
A "bit" from index.html hosted on zuix-app-3.glitch.me
data-ui-include="//zuix-app-1.glitch.me/layout/header" means that the
layout/header is fetched directly from the server hosting the first example and that consists of these two files:
But then when we look at the
header.html we see
<div class="logo"> <a href="/">app-logo</a> </div> <div data-ui-load="@lib/components/hamburger_icon" data-ui-options="options.menuButton" class="menu-button"></div>
data-ui-load="@lib/components/hamburger_icon" means that, in turn, the header will load the
@lib (which is a shortcut to the zKit components collection server).
zuix-app-3 includes the
layout/header from the
zuix-app-1 host and that also loads the hamburger_icon component from
This means that if the
layout/header is modified on the host
zuix-app-1 it will be automatically updated both on
zuix-app-3, but also means that whenever the
components/hamburger_icon is updated on zuixjs.github.io/zkit, it will be seamlessly and instantly updated on all examples hosted on Glitch!
So using an unique reference to components has obvious advantages both for productivity and creativity, either when they're hosted on the same server or over a bunch of different ones.
In order to make this work without issues we must guarantee 100% backward compatibility whenever a distributed component is updated. If this is not possible, then a new path must be assigned to the updated component.
Also we must consider that downloading resources from multiple hosts of uncertain reliability can sometime compromise performance especially in presence of network issues. That's an old lesson already taught by the use of CDNs.
So when performance is a real concern about your application, a different strategy can be adopted and this consists of downloading all of the employed resources and packing them into a single local file.
But before you start to think I'm gonna talk about build systems, package managers, web packers and such, I want to reassure you that it is not.
Well, that would also be an option, but if we don't want yet to deal with those build tools, by just using zUIx.js we can generate the application bundle directly in the browser console.
That's what I call in-browser bundling (or client-side bundling), but I'll be writing about this later.