Hacker News new | past | comments | ask | show | jobs | submit login

Here's some context on this with illustrations and videos:

https://web.dev/hands-on-portals/




It appears that the motivation behind the concept of portals was to eliminate perceptively slow page transitions, and allow a developer to create a multi-page experience that behaves like a single-page app.

Given this motivation, portals are a single solution to two problems. In my mind, it would make more sense to divide the concept, and create two separate, complementary features:

1. A way to eliminate perceptively slow page transitions, perhaps with an approach like turbolinks: https://github.com/turbolinks/turbolinks . Require minimal changes to existing markup, and allow <a> to use the new, more-seamless page transitions.

2. A new UI element that is like a modern take on the iframe: the <portal>.


I'm trying to understand how Turbolinks makes things faster. What I'm gathering is that it's the merging of <head> that helps. Because if you have stylesheets or scripts in your head that have already ran using Turbolinks will prevent refetching and rerunning those things.

The downside to the approach is that it cannot stream the HTML response, which is what browsers do, so you wait longer for the page to complete. But if you have a fast enough server then the gains from not rerunning scripts probably helps more.


I believe you are correct about that aspect of turbolinks.

However, what I was alluding to in my comment was the background-load-and-swap approach used by turbolinks. An <a> could be enhanced to load the next page in the background, and then swap in the content. When combined with smart pre-fetching and pre-rendering, this will yield page boundaries that feel seamless.

Note that this is exactly how portals will make browsing feel faster. My abstract proposal is merely to make this a more general feature that can enhance plain links, rather than coupling it to a new UI element.


It may or may not be faster in real terms, but it _feels_ faster to users, because the browser window never blanks out between screens.


If you replace the entire body wouldn't there be a blanking that occurs regardless? Or does the browser not repaint the parts of the page that look the same in the before and after?


A regular page load will block and show a blank screen until all of the style tags, script tags, etc. have been fetched. Replacing the body does take a few ms to paint, but does not need to wait on any other fetches.

Of course there are techniques to improve page load time without turbolinks (using async script tags for example), but turbolinks predates many of those.


Yeah IIRC (from when it was introduced) it's an easy way to add SPA-like performance to your Ruby app by only re-rendering the <body> tag; no need to rebuild your server-side rendered app to a single-page application.


> no need to rebuild your server-side rendered app to a single-page application.

server-side rendered html by its nature is also more accessible then spa/vdom frameworks, that tries to be fast by skipping the dom and re-implementing it in js(suckers).


s/perceptively/perceptually/g


This does a much better job of explaining how these would work and why they might be useful.


I suspect that this will significantly cut down on the JavaScript needed to make websites feel more like a mobile app. I've had to add more complexity to the social network I'm building to make the web experience feel fluid. I'm also implementing a no-JavaScript subdomain of the website for people who hate bloat also.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: