News for hackers. Stuff that matters.
Re:Portals API by Touche on Tuesday June 30, 2020 @10:22AM (#23690286)
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.

Re:Portals API by oftenwrong on Tuesday June 30, 2020 @11:01AM (#23690741)
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.

Re:Portals API by maxfurman on Tuesday June 30, 2020 @10:34AM (#23690422)
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.
Re:Portals API by Touche on Tuesday June 30, 2020 @10:47AM (#23690564)
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?
Re:Portals API by maxfurman on Tuesday June 30, 2020 @10:58AM (#23690704)
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.

Re:Portals API by Cthulhu_ on Tuesday June 30, 2020 @10:40AM (#23690489)
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.
Re:Portals API by oneweekwonder on Tuesday June 30, 2020 @01:45PM (#23692709)
> 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).