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.
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 -_-
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".
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.
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.
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.
$(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 -_-
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?
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.
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/...`.
Please contribute with any sites which fastr has broken.
Also I'm assuming this works similar to the Rails gem turbolinks?
I've used the turbolinks script from that repo.
https://github.com/jajoosam/fastr/tree/master/extension