Hacker News new | comments | ask | show | jobs | submit login
Show HN: Fastr – Reload Optimizing Chrome Extension (github.com)
67 points by jajoosam 10 months ago | hide | past | web | favorite | 19 comments

Compatibility aside, how in the world can fetching a page then rendering it be faster than “a full page load”? That’s the definition of a full page load! Are we assuming heavy JS in the <head>, and that it’s also present on the current page?

I haven't touched Turbolinks since the the first version(at one point there was a rewrite if I recall), but I'm pretty sure it would only replace the body and not reinsert the head content, thus meaning that the existing scripts continue to run without being "rebooted" or downloaded again. Plus there's a slight benefit from not building a new DOM.

The downside is that all your scripts can't depend directly on 'DOMContentLoaded' or jQuery.ready. This isn't much of a problem if you're using a framework where navigation is abstracted away anyway, but third-party software can still get messed up.

I was surprised that the extension didn't interfere with my Ember.js app, but then disappointed when it prevented Leaflet from working across navigations. I honestly don't know why that would be the case since my app already does its own navigation without page reloads.

Yeah this will break a lot of webpages. If all you are doing is inserting turbolinks, and the scripts on the page are not expecting turbolinks, then you will definitely run into cases where scripts depending on events associated with the page loading lifecycle are never triggered correctly.

I imagine this would break many JS-y websites? Since just swapping in the body means that you'll lose assertions about init code only running once

From a background using turbolinks extensively, if you do:

$(document).on('turbolinks:load', insertFunctionHere);

Then you should be good to go in terms of loading functions after the trubolink(s). There should be a way to reverse this for this application. I personally, don't know -_-

Okay, how do we protect against this problem?

It would be nice to have a piece of code that detects the problem and shows a message "Hey, you have a browser extension that is not playing nice with this website; please turn the extension off".

What would that piece of code look like?

I don't think we should do anything. As a front-end guy myself, it's silly to have to add a bunch of code to check for all the nonsensical browser extensions that could break my page. If a user wants to use a broken extension, please be my guest, but don't think I'm going to go out of my way (and increase my bundle size) to warn you that you've got your footgun locked and loaded.

Hell, there are already enough problems with working around naive ad blockers (images being blocked because they have their dimensions listed in the file name, `class="ad"` being hard blocked, etc). At least those extensions are popular enough to matter and break fairly infrequently.

Reminds me of when I was generating uuids for user-uploaded avatars and putting them in url buckets like `/fc/cdcabe...`.

Of course, I would eventually have to track down why some images weren't loading for a lot of users. Took me a moment to notice the `/ad/...`.

I've started work on a blacklist- https://github.com/jajoosam/fastr/issues/3

Please contribute with any sites which fastr has broken.

Why is there no unminified source code? We only have fastr/turbolinks.js.

Also I'm assuming this works similar to the Rails gem turbolinks?

Yes, it uses the turbolinks.js - https://github.com/turbolinks/turbolinks

I've used the turbolinks script from that repo.

Thought this was about https://github.com/oracle/fastr

I've never used Turbolinks and have no prejudice, but it seems slow after working with prefetched links in Next.js and Gatsby.

How come the demo animation uses Safari

Because it's from this page https://github.com/turbolinks/turbolinks

What's the point of putting this on Github when there's no source code available? Many people won't trust arbitrary code from a random user enough to run it on their machines.

I think the extension literally drops turbolinks into each page you visit. That’s it. So the source in the repository is the source of the extension - check manifest.json.

Yup - that's pretty much it!

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