I get the benefit of PJAX when you're replacing part of a page. If you're replacing the whole page, how does this beat a real browser load of the exact same data in the same number of hits?
(Is it simply that it saves you the effort of setting your caching headers for inline resources properly?)
Awful mistake, sorry, completely forgot about that issue. Will be fixed ASAP. However, there is "new" event, which gets fired on every new page. You can listen to it using $.joconut.on, see Readme in GitHub repository at https://github.com/vdemedes/joconut.
One thought came to mind for a potential leaky abstraction: unlike HTML and CSS that can be "undone" and are idempotent, JS has side effects that can't be undone, and isn't always idempotent. Are there JS patterns we need to embrace or avoid to ensure Joconut always "just works"?
Loads pages via AJAX and updates the browser history using `pushState`. This is an alternative to the PJAX library: https://github.com/defunkt/jquery-pjax
Use either if you have an irrational aversion to page reloads.
Snark aside - jQuery Mobile uses a similar technique to cache entire pages in the DOM and for page transitions.
It allows loading pages without refreshing browser window. User will not notice any loading indicator/progress, pages will instantly "replace" each other.
> User will not notice any loading indicator/progress, pages will instantly "replace" each other
Um, no. The pages won't "instantly" load - the browser still has to make a round trip to load the page content.
A loading or progress indicator should still be shown letting the user know that this round trip is taking place - especially important if you're on a slow US cell network. If a user is on a slow connection and no visual feedback is given they may end up mashing a link, making the load time worse - or, worse yet, assume the site is broken.
(Is it simply that it saves you the effort of setting your caching headers for inline resources properly?)