Re: [w3c/webcomponents] HTML Modules as a leaf node in the module graph or not? (#805)

Hi @matthewp 

Over a decade ago, we wanted to solve lots of things with iframes.  We were inspired by the [iGoogle portal](http://www.igoogleportal.com/), and in fact used some of their code (like a pub/sub library for messaging between widgets).  We are a fair size organization -- different teams working with different technology stacks, but with a need to integrate content together.  So we embarked on using iFrames to do that.  Each piece of functionality would be a small standalone widget which we could iframe in, just like the link above shows.  Users could build their own workspaces of content they needed from a [gallery](http://www.igoogleportal.com/directory/gadgets).

Issues we ran into was terrible performance, largely because everyone was using a heavy framework (extjs, Silverlight, GWT, WebLogic server-side-centric applications, etc) which we were loading over and over again into the same window, and content was confined to a rectangle.  Messaging between widgets using pub/sub was also quite limited.  So we had to scale the concept way back, and just load the main view as an iframe.  It was quite the debacle, which put me on a lookout for something better, and I've been pinning my hopes on web components ever since.  Basically, the technology limitations forced us to adopt an entirely different integration model from what we really wanted.

Even now, within that scaled back portal, we are often finding ourselves sharing content from one application into another via iframes, just because it's a lot of work to recreate the content in each application (and we don't want to give each application access to the databases, etc).

Problems it solved really well was the ability of different content providers to have their own release schedule and manage their own dependencies.  And styles from one app not affecting others.  And allowing functions with the same name not causing interference.  I.e. scope isolation.  Also great is that each team can build and test their own content in standalone windows, without having to pull down everyone else's content.  And sometimes we want users to be able to open that sub content without loading the entire portal.

Just the other day, I was talking to a group who is building a new complex application (converting over a native windows WPF application) and they want to break it down into separately hosted sub application "modules" so they could have separate release cycles.  I recommended iFrames, but said to watch the web component space (hoping that HTML Modules will help).

The key is the federated model -- although it makes sense to share common libraries via the top frame, the application code needs to be managed by the content provider, not by the top frame.   The people managing the top frame have to be *extremely* careful about making any changes.    

Hope that makes sense.  Would  leaf node HTML Modules solve our conundrum?  I don't see how, but I could be missing something.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/805#issuecomment-480535898