The WebComponents era isn’t quite with us yet - the browser makers are not progressing evenly towards compatibility. You need to use some JavaScript shims to get there though ahead of schedule. In this article, I outline some experiments with composing a page of multiple Single Page Applications without IFrames.

Four identical AngularJS apps in one page

I’m using a calculator by Ashish Singh that I have used before. The whole thing (HTML, CSS, JS) can be contained within a single <DIV> so it lends itself to being inserted into a page a few times for an experiment. Pic:

I’m using html-import from HTML5 to make it happen. That is Chrome and Opera only for now - see The trouble is that IDs have to be unique, which means that some ID shenanigans are needed to make four calculators work in isolation in the same page. I also can’t import the same Angular 1.5.8 JavaScript file four times, and have it work, so that moved to the outer container. Lastly, Angular needs to have a slightly hacky ‘boot’ to the second, third and fourth calcs within the page, which I don’t fully understand.

The composed app working well enough for you to play with the four calculators here.


I’ve a fork of the same app, without the shenanigans I outlined above: See that here, or a pic of that here:

The forked app doesn’t function at all. Given any fool can muck around with html source so that it doesn’t work, take a look at the ‘calc1’ which it inserts - it does work when standalone. The same calculator in the working composed view doesn’t work standalone (the Angular import was removed) - see here.

There is the incongruity: working standalone calculators, but not composed together into a page of four calculators, VERSUS four non-working standalone calculators which work together just fine composed into a page of four.

Github allows us to compare the two repos to see the diffs between ids, js imports etc. See that compared here for the working vs non-working forks. Sorry about the confusing added/deleted thing. That’s because Github doesn’t allow you to reverse the direction of a ‘compare’, as it’s more to do with pull-requests than pure comparison.

What I really wanted

I really wanted to me able to mark a div as ‘isolated’ and to mark the division between container and contained in a way that the DOM was instructed to separate things enough. At least enough for my app to work without making its IDs unique across four calcN.html files, and allowing each calcN.html app to have it’s own Angular.js import. In fact, you can see I have put ‘isolate’ attribute in the fork above, in the way I would be wishing to use it.

We have isolation today with iFrames, but it isn’t a smooth experience deploying composed applications. The remaining complaint with a larger app made of iframes is menus/popops/overlays can’t extend outside the iframe itself, which seems like an legacy decision.

I would also like to be able to (optionally) server-side compose the same view - meaning the whole composed app streams to the browser as a single HTML file. That means I would do the modern equivalent of a Server Side Include, and avoid the appendChild+cloneNode steps in JavaScript. I mean to have the option would be nice.


Doing an experiment to ripping apart the fabric of space/time, by trying to insert an Angular2/React/EmberJS calculator into the composed view above (they’re incompatible in the same page).

Also, perhaps, playing with polyfills (via would be interesting.

blog comments powered by Disqus


November 21st, 2016