Locker service vs cross-domain iframe

Question

In Salesforce classic, Salesforce lets you embed a Visualforce page into their page layouts. This page is in a cross-domain iframe, and therefore completely isolated from the containing page layout. With lightning components though, your code is actually running on the same window as all the other components in the application, and it is the Locker Service that prevents components from interacting with components from different namespaces.

Considering the complexity of the locker service and the resources Salesforce must have spent to create it, I imagine that there must have been some specific benefits that they had in mind to decide to move away from the simpler existing policy of keeping customer code separated with an iframe.

What does a Lightning Component with the Locker Service allow you to do that can't be done with a Visualforce Page in an iframe?

Answer 1

There are several reasons behind this choice, and most of them have been enumerated. Martin is correct, the native browser compartment mechanism is the iframe, but it doesn't solve all use cases. We have created Locker Service to act as a virtual iframe to provide the same DOM, data and code isolation as the native iframe without the drawbacks reported by Mohith and sfdcfox.

On the resource sharing alone, native iframes (if used with the security features enabled) impose on you to bootstrap a separate JavaScript and CSS framework in each one.

On the visual aspects, native iframes cause a hard clipping of their content, and it's not always possible to display a drop-down menu, a tooltip, or a CSS shadow.

Locker Service is working hard to solve these limitations and provide fine-grained security adapted to components and modern UI: for example, a Salesforce application can host a panel developed by a customer that uses a mix of widgets from Salesforce and form third party vendors, and the confinement of all namespaces will be preserved while sharing resources and allowing a rich UI.

Answer 2

First of all, using iframes causes the browser to use more resources (memory, threads, etc) than living in one DOM. Second, sandboxing was too extreme, and yet dependent on browser security rules (and therefore inconsistent).

Lightning allows limited, controlled, consistent access across namespace domains. For example, Package A can access whatever Package B exposes globally, but can't modify internal structures or override code, all while using fewer resources.

Answer 3

Better UX

One huge benefit that I see is the flexibility with the UX.With iframes there was never ending scrolling.

It was very difficult for an ISV application layout to coexist with the current layout .

You had only two options in classic layout .Either you had to iframe within the layout that adds to scrolling or the other option was to ask the user to click a button to launch the custom UI .

What lightning components allows is coexistence of ISV applications within the standard layout with a better user experience .There are multiple options to put your component , lightning utility bar , lightning tab , lightning accordian are few to name them .

Data Communication

Only possible options to communicate with the standard layout was via the apex controller .This required refresh browser to see new data changes on the UI .

Lightning Components use events for commuication making it easier to talk with standard components.