Hacker News Reader

Comment by ilaksh | Hacker News Reader

I feel like this would make the most sense presented in the context of frames.

Why are portals better than frames? How are they different? On the surface it seems like they must have similar functions.

View on HN

Found some context: https://github.com/WICG/portals

I think this proposal is a better starting point for readers than an API spec.

Goals, taken directly from the proposal:

- Enable seamless navigations from a page showing a portal, to the portaled page

- Enable seamless navigations between pages of a portal-aware website

- Avoid the characteristics of iframes which have negative impacts on security, privacy, and performance

Also: https://github.com/WICG/portals#summary-of-differences-betwe...

Well damn, that is much more understandable and super interesting. Thank you!

It seems to be some sort of in-page browser tab? Let's see what that brings. (besides interactive advertising, obviously)

It's closer to Android Activities rather than tabs since you only have one you can interact with at a time and you can send and receive data from it.

Why bother with that limitation?

You'll be able to implement more SPA-like instant navigation with preloading, etc.

See the list of use cases [0] for more

[0]: https://github.com/WICG/portals#use-cases

from the explainer [0]: Portals enable seamless navigations between pages. In particular, we propose a new <portal> HTML element which enables a page to show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.

Portals encompass some of the use cases that iframes currently do, but with better security, privacy, and ergonomics properties. And via the activation operation, they enable new use cases like preloading or navigation transitions.

[0]: https://github.com/WICG/portals#readme

The Portals API enables making multiple websites work together by allowing seamless handovers between each website, in a UNIXy way (each site does something narrow and specific).

In short, the main thing Portals have over iframes is the ability to promote an iframe to become the top level website, and go back the other way around.

You also get new APIs aiming at making the transition between two websites more seamless visually, and easier to integrate the functionality between the two.

Check out the link I shared in the other comment for videos and further context.

I feel like this would make the most sense if it was presented with any context at all. Reading a low level and detailed spec is much easier if you have some higher level understanding of what they're talking about at all.

Why do we need a new spec for this though? It seems like these are just better iframes, why not just extend the iframe spec?

See https://github.com/WICG/portals#a-new-attribute-on-an-existi...

The link from szhu clarifies the purpose for me: Single Page App (SPA) like behavior via IFrame-like syntax.

Reply on news.ycombinator.com