Post History

I think a lot of the bad press about iframes stems from W3C deprecating them in HTML 4 strict mode, which caused the herd of web developers to internalize that iframes a bad and should be avoided. 

However, this deprecation was due to accessibility concerns that have long since been resolved, and HTML 5 restored the iframe to good standing. Unfortunately, news of this reversal was less widely shared than the original deprecation notice, so many people still vaguely remember that something is wrong with the iframe (and make up all sorts of stories why this is so ...)

With that out of the way, let's tackle some of the misconceptions you found:

> If you create an iframe, your site becomes vulnerable to cross-site attacks.

Nonsense. iframes are subject to the same origin policy, and communication between them can only happen if both browsing contexts cooperate. 

> It tends to break the browsers' "Back" button.

What? A back button works just fine on all browsers I ever tested. 

> It confuses visually impaired visitors, using screen readers.

That [stopped being true](https://webaim.org/techniques/frames/#iframe) over a decade ago. 

> It confuses users, suddenly opening the iframe content in a new browser window.

I have never seen that happen. And I have used iframes in an app used by tens of thousands of people, so if that was a problem, some users would have reported that.

> Content within the iframe doesn't fit in and looks odd.

That depends on how that content is styled. Sure, you don't get visual consistency for free, but if you use the same styles inside and out, users won't notice a difference.

**Actual problems**

The only problem I actually had with iframes was sizing: The size of iframes is determined by their enclosing document, not the document they contain. Relatedly, iframes have their own scroll bar if their content overflows, rather than being scrolled with their parent document. This may or may not be a problem in your case. 

**iframes for migration to SPAs**

We also used iframes for an incremental migration, and it worked well. However, we preferred embedding server generated documents into the SPA rather than the SPA into server generated documents, because the latter causes reinitialization of the SPA framework upon every page navigation. 

That is, we preferred to migrate from the outside in, rather than the inside out, by first migrating the global nav to angular and its router. To ensure deep linking capability, we made the angular view include the corresponding server side view, and notified the angular router about server side navigation events by means on an onload script in the server side template.