Claim: The thing doing the containing can see the thing it is containing. The latter really only suspects it is contained, and can’t casually reach back to the container, unless the container configured it to do so.
We're going to dive into an overview of container architecture and four various styles of containers, how they're used, and their limitations.
With friends, I wrote PicoContainer in 2003. It was the first constructor injection container for Java. I’d been a junior contributor to Apache’s now defunct Avalon container for a couple of years before. Avalon introduced “Inversion of Control” (IoC). I hate the word framework in conjunction with DI. That’s because you could instantiate as many wholly separate containers as needed, register components (or other containers) into them, and by default, none of those contained things had reference to the container that contained it.
Think VMWare, Amazon EC2 instances, or the equivalent Digital Ocean (etc) things. Each needs a wholly-separate operating system, and shares CPU, RAM and networking infrastructure with sibling VMs, but can’t casually discover the siblings, or reach into innards of the containing host operating system. The technology on the host that manages the guest VMs may expose file mounts, sockets servers, and graphical resources, but the directionality is clear. Each VM can host a number of processes as a normal machine installed OS would have.
Not to be confused with VMware style VMs, though they often go together. A host machine (physical or virtual) mounts a container with minimal (shared) operating system resources. It feels like a regular operating system, but conventions apply, and the contained is limited to a single application/service. Typically, that is a limit on the number of larger processes running. Say one ideally, though again, that is really only a convention. As before, the container knows about the contained, and the contained is limited in what it can connect to. Deployments focusing on this style of container always use fewer resources than deployments resting on VM solutions (above).
It is less obvious here but a visual rectangle of a UI that contains many smaller rectangles most likely guides the layout more than the contained guide the layout of the container. Maybe the container queries the contained about preferred size and all that. This is all about the ‘V’ in MVC (Model View Controller), and the M and C aspects are entirely different programmatic constructs. As you’d expect, all bets are off if there is absolute positioning going on.
There are strong component models like Java’s Swing framework (which Netscape donated to Sun in 1997 or thereabouts). The principles of containment are almost never fully realized, though, as the view assembly code can navigate casually to its own container and tinker with it, or sibling components/containers.
Even for Flash applications in web-apps (seemingly a rectangle in a rectangle), the principle of containment was weak. A technology called LiveConnect allowed the Flash doohickey to reach back out into the DOM of the container, although maybe the same origin applied. Flash is dead anyway, and nothing programmatic has assumed its place in the world of browser plugins.
The Web, Specifically
What a disaster. As with fat UIs the components in a browser tab can interfere with each other, regardless of the visual containment intentions. This is so bad today that you can’t have rectangles from modern web microframeworks (say Angular1, Angular2, EmberJS, and React) share space on the same page and have easy isolation. It just breaks, as the monkey-patching of bits of pieces of the DOM to get things working destabilizes things. Say Angular1 inadvertently disables EmberJS, or vice versa, or they each effectively kills the other. You have to revert to Iframes to guarantee isolation, and that is quite heavy with big aesthetic downsides.
I say it's a disaster because it is 2016 and we are 25+ years into the web — this should have been solved many years before. <div isolate>..</div> is what we needed, as well as a mechanism to declare inputs and outputs of the contained, and wide support for an HTML-import.
Maybe in another decade, the DOM will become a better container/contained facilitator.