Hi <portal>, Bye <iframe>

At Google I/O 2019 conference, Google launched portals which seamlessly enables to navigate and load web pages across the app.

<iframe> have been responsible for embedding pages for us till now, though there are many challenges associated with it mostly related to data sharing or navigating through web pages, cost associated to browser re-rendering the component again. For those who have used <iframe> a blank white screen is commonly seen, that glitch definitely do not enhance UX. Due to security reasons, iframe didn’t allow us to navigate into its content, with portals, one cannot only embed page, can also navigate to to their content.

<portal> allow users to navigate inside the content they are embedding. Portals are always created as top-level browser context, and can always be embedded into a page just like iframe. They are basically an upgrade over iframe. With portals, one can prefetch the content and create an illusion of smooth navigation when called upon. Portals can also overwrite the existing URL address bar, making it more powerful to be used for navigation.

Portal can be activated, which causes the top-level browsing context to navigate, replacing its document with the portal. The document receives an event when it is activated. It can use this event to receive data from its predecessor (the document which previously occupied the tab), and even move it into a portal context.