Pass: 0


Ajaxify – The Ajax Plugin


For web developers

Optional visual effects

For geeks


We need your comments and feedback!! Please drop one here (see below) or in the respective sections

On which browsers does this work?

This plugin works on HTML5 browsers and gracefully degrades, if the HTML5 History API is not available.

109 thoughts on “Overview”

  1. Hi There

    I’ve been looking for a plugin like this for quite a while now – at least something that would work out of the box. I wanted to use SmartAJAX (on CodeCanyon), but I’m not in a position to be purchasing anything.

    Unfortunately, for me (and based on your installation instructions), this plugin does not work. When I click on a link, it changes the URL, it identifies the change in some inline JS, but does not actually update the block which contains the main content. Everything is being logged to the console (sans, the last entry is with regard to my inline JS, which site at the bottom of , below the call to ajaxify()).

    Any idea what could be going wrong?


    1. Not to worry – I have repaired it now. There was a problem with my custom jQuery interpreter.

      Great plugin! 🙂

      1. However, I seem to have another problem. Due to the fact that this plugin is to decrease the page-load time, why does it make two GET requests to the destination? For example, if I click on a link that takes me to ‘/members’, why does it call ‘GET /members’ twice? This doubles the load-time…

        1. Hi Michael,

          Thanks for your interest in the plugin!

          Inital page load may be minutely slower. However, on all subsequent ajaxified clicks, I can only see one GET. The plugin spares the user a full-round trip and therefore does speed up page loads…

          Regards, Arvind.

          1. Hi Arvind,

            Thanks for your response. I have just updated to the latest version of the plugin. It is no longer making multiple requests.

            I’ll let you know if I spot anything else. 🙂


  2. Hi Thinsoldier,

    I’ll update the Pronto code, as soon as Ben has.
    Do you reckon, Barz is a special case when it comes to the CSS handling (unloading / reloading)?
    Can you think of a generic workaround for history.js. I’d love to fix it?

    Thanks very much!

    1. I can’t think of anything special at all about the barz demo’s css.

      My main concert right now is why the spinners.min.js and lightview.js defined at the bottom of gallery.php don’t load when the page is accessed via ajax 🙁

      1. It’s definitely not handling any [script src=file.js] tags for me.

        If I have [script]…code…[/script] it works. But not with @src .js files.

        I’ve added 2 News pages to the first barz demo.
        Go to the home page then go to News 1. The inline javascript works.
        Go to the home page, refresh, then go to News 2. The linked .js file does not work.

  3. Where would you like the hook for the second request delay in the Pronto code? Where would you suggest it: ?

    I left a comment on Ben Plum’s github and he might change pronto’s render event happens. It currently is triggered as soon as the ajax request is made rather than after the request has finished being received.

    but you said, you experience a delay or period of flickering, where the content is rendered without style.
    I will revert my example to an earlier version where the flash of unstyled content is more clearly visible.

      This shows the flash of unstyled content issue. I doubt there’s anything that can be done about it in JS code. I already have a workaround for it by combining all css. I have another possible workaround for un-combined css that involves using css-animations to update a div off-screen, wait a quarter of a second via delay in the css animation, and then bring it into view.

  4. Hi

    I’ve updated my experiment to use the file.

    Using the requestDelay option I’ve managed to get a page fade to happen.
    But there is still a flash-of-unstyled-content issue. I’ve tried to work around it by making the fade in take a very long time so that the styles will be applied by the time the content becomes visible. See

    I don’t think there’s any way to detect when the content has finished being styled by the browser. So I don’t think there’s anything that can be done about it in history.js code. I’ll just combine all my site css into a single file and hopefully that will fix it.

    There might be an issue with history.js handling [script src] tags that are outside of the [head]. If you visit the home page of the example site and then go to the photos page, the Lightview javascript is not available.

    1. I’ve updated the site again and merged all the css into a single file. There is no longer a flash of un-styled content. I’ve been able to decrease the length of time on the fade transitions to half a second which was my original desire.

      1. Hi Thinsoldier!

        Thanks for your perseverance! But it seems you’re getting where you wanted to be after all, after asking the authors of these frameworks to add the features you want.

        I love your current call to ajaxify:

        $('#main') .ajaxify({'selector':'#header a','verbosity': 0, requestDelay:400});

        Glad you saw yesterday, that I had upgraded to Pronto 0.6.3.
        I have pushed tag 2.5.0 of to GitHub after all, because I have such a good feeling that the functional requirements it handles are much more powerful through our collaboration.

        Where would you like the hook for the second request delay in the Pronto code? Where would you suggest it: ?

        Sure, if you chuck all style into one and only CSS, that’s one (safe) way to go. I had just changed the algo in 2.5.0 to cater for even mutually exclusive CSS’s, specific to pages – but you said, you experience a delay or period of flickering, where the content is rendered without style. I can’t imagine that this period takes very long, though, as the whole purpose of history.js is to be rocket fast.

        I’ll now examine the issue with the JS not loading outside of the head and report back on it…

        1. Just tested – there are lot’s of such src=” script tags being detected on , outside of the head, that are common to the pages, in version 2.5.0. Afaik, there are no occurrences of such tags, that are unique to a page on That means the algo is working for script tags, too and as mentioned before, there is no differentiation between such tags in the head or body, so it really is strange, that your Lightview JS is not being loaded…

          1. I’ve increased the speed of page loads on the server side of
            It may have been irritating, that the page loads were so slow lately…

  5. Could you update to support the latest pronto.js? It has a requestDelay option that the pronto.js hosted here doesn’t have.

    I’ve tried change the url for pronto.js inside of your history.js but that results in an error regarding $this.pronto not being available although $().pronto() is available.

    1. Hi Thinsoldier!

      Just a quick note – I’ve been busy creating a new version at which I will tag 2.5.0. It now has sound delta-loading the way you expect it for ‘script src=’ (!) i.e. the scripts get un-loaded on page change and reloaded… As mentioned before, this works for CSS’s, too.
      Please let me know, whether you think it is sensible for style tags, as well.

      I’m glad you can understand my strategic decision to procure Pronto as my backbone. It used to be Balupton’s history.js, but as Ben Plum mentions, history.js introduces quite a few low-level bugs. I’m surprised and sorry, that the built-in Pronto events don’t suite you. At a first glance, I thought they would be handy.

      Sure, I’ll upgrade Pronto to the latest version tomorrow. Very interesting that you find the delay useful, as you say, you’d find it more useful when rendering. I’ll have a look at what Ben did tomorrow and upgrade asap.

      Feel free to testdrive, which I’m not going to push to GitHub quite yet (got to re-factor the code to make it more self-consistent, because it was written just as a sort of functional prototype for testing the new delta loading – I’ve tested it against a remote site I control that uses and it works really well)

      I hope it’ll resolve your manual work when unloading / reloading bio.css and now also scripts in the head etc. at

      Cheers and greetings from Munich

      1. Hi

        The newer pronto.js does appear to allow opportunities to control page effects as I desire thanks to its new requestDelay option. With the older version 2 of the pronto events are triggered at almost the same time. This means that if I start to fade out my #content div as soon as I click a link, the ajax request will still happen immediately so you see the content change while the div is fading out, and then the same content fades back in.

        The requestDelay option would allow me to delay the ajax request long enough for the div to fully fade out, and then fade in with the new content.

        But I do wish that ,instead of requestDelay delaying the request, that there was an option to delay the rendering. This is because some sections of my barz site actually pull content from the api which mean on the server side php sometimes takes a while to pull in the data from So I don’t wan’t to delay the ajax request (which triggers another request on the server for php to talk to wordpres) but instead just delay the rendering/switching out old content with new content.

        The site is quite out of date. I’ve been experimenting with the most recent history.js tag in a local copy of the site and it works well enough for what I need. I’ll try to update the copy on the web after I add history.js tag 2.5.0 to it.

        If you want to add support for [style] tags that would be great but it’s not a major necessity. It’s faster to keep all css in their own file for caching anyway.

    1. Thanks. is my domain.

      I’ve updated my test project to use history.js tag 2.4.0. It seems to work fine. It does not seem to remove css link as I move through pages but my css doesn’t clash so it’s not a big deal. But I wonder if 2.4.0 is not the newest version.

      I’ve been trying to add page fade-in / fade-out transitions using the pronto events but the moments when pronto triggers 2 of its events are not conducive to the way I want to fade out the page. The pronto.js that is hosted on does not have the requestDelay option that the newer pronto.js on has. I think the newer pronto.js will trigger its events (in cooperation with the requestDelay) in a way that will allow me to achieve my desired result.

      It would have been nice if the newer pronto.js also had a renderDelay option. I don’t see any reason to delay making the request, an additional option to instead delay the rendering would be better in some situations.

  6. I notice that on there is not a loading/transition notification when going between pages?

    What would I have to do to be able to fade-out a page content area, load the new content, then fade-in the content area again?

    I’ve been helping a colleague build a site using history.js… another fork of history.js, then we tried pjax, the multiple forks of pjax and pagify.js and it’s been quite a lot of trouble. He now has his site working with a version of pjax but getting things to _properly_ fade out, load, then fade in with the right timing is where he’s stuck right now.

    I’m concerned that I may find a similar problem when I get around to investigating your ajaxify again.

    1. Hey,

      no, there is no such facility at the moment, because ideally, the page load should be so fast, that there is no need for the effect. I’m trying to keep the code lean, because it’s now bigger than Pronto or Balupton’s ‘ajaxify-html5’ already.


      1. Well I wouldn’t need or even want the ajaxify to handle the transitions, just give me a hook event where I can define custom function to happen ::before:: it makes the ajax request. And then another one where I can run another function immediately ::after:: the request is done and the new content is received.

        Using my friend’s project as an example, he has a page using that does a lot of transitions. He wants when a link is clicked for the contents of the home page to fade out ::before:: the ajax request happens. Then ::after:: the request is finished he needs the content area to appear immediately without transition. This is because code on the incoming page is doing its own fancy transitions to things in the content and everything in the content is set to display:none or opacity:0 to facilitate the fancy transitions he’s doing. But also within his ::after:: function is where he needs to tell the code on the incoming page to start performing its transitions. By default the functions for the fancy greensock transitions would happen on page load or dom ready, but with ajax neither of those events happen to tell the code to start. So an ::after:: callback as part of ajaxify can be used to fill that gap.

        1. Hi there,

          just a short note concerning the Pronto events, that ought to be at your disposal in the order of firing:

          – ‘pronto-request’ (1)
          – ‘pronto-load’ (2)
          – ‘pronto-render’ (3)

          Please see:

          On my side, I’ll tweak and test the new code concerning CSS’s today or tomorrow…

          Hope that helps 🙂

          1. Done. Just for CSS’s – they should now work as you expected initially.
            I will abstract this delta-loading algorithm and apply it to script src=”
            Do you think, it also applies to style tags?

            Thanks ever so much Thinsoldier for your precious input!

    1. Hey Thinsoldier,

      the most obvious error of two IDs being inserted into the DOM has been rectified. I have also introduced a class ‘.no-ajaxy’, in which case the links are not ajaxified.

      1. Does bio.css interfere with gallery.css? You obviously expect bio.css to be unloaded on page change. I suppose I could implement that with a bit of acrobatics, if it is desired. Please drop a short notice, if you want that to be implemented…

        Also, I’m thinking of supporting the loading of style tags of the target page on page change, as you and others will expect that to happen…

        1. $(‘#main’) .ajaxify({‘selector’:’#nav a’,’verbosity’: 2})

          I’m glad you found out this use-case for yourself on your own – thanks!

          That is very powerful, generic, and yes, should be documented 🙂

          Thanks very much for all your feedback!

        2. The reason I asked about:
          $this.all(‘*.find(“.document-link, .document-script”).remove()’);
          Is because I was hoping that by adding these 2 classes to my script and link css elements that would automatically tell ajaxify that those resources are specific to only the document that introduced them. And hopefully it would be smart enough to destroy the elements when requesting a different page.

          This would work perfectly for css files. But for javascript there could still be issues. Even if a script tag is removed, the objects and event listeners it created would still be present.

          It would be necessary for the developers to customize their code to properly destroy/disable itself based on which page/state was being viewed. I think most third party scripts and jquery plugins are designed with the assumption that they would never be used in an ajax context like history.js/ajaxify and therefore lack features/hooks/custom-events necessary to easily integrate them with ajaxify.

          1. Hey Thinsoldier!

            Glad to here from you 🙂

            Those two lines are used internally by the script in within the ‘getPage’ sub-plugin. Your desire from a use-case view is that CSS’s specific to a page like bio.css get unloaded right? That’s my job, buddy!

            I’ll try to give it a go at the weekend. You mentioned it’s the only serious issue you’re still having. The other thing on my todo list is to support style tags, but you seem relaxed about that.

            Just thinking out loud it’s a bit of a head-teaser:

            1) CSS’s that the previous page and the target page have in common should not be loaded again
            2) CSS’s specific to the previous page should be unloaded
            3) CSS’s specific to the target page should be loaded dynamically / additionally.

            Would you agree on that as pseudo code?

            You’re very right, for JS, I’ll keep the current algo, I think, and will have to educate the user, that he has to refactor the code, like Pronto educates its users, too. There’s no point in ‘unloading’ JS.

            I agree, most stuff doesn’t anticipate an AJAX environment.

            Since the last versions of this plugin, I let the low-level events of Pronto thru, for the user to hook into – all this still has to be documented.

            So would your use-case be catered for by the above algo for CSS’s?
            Do you think that’s what most sites want?

            Give me a short note and if we agree on that algo, I’ll code it and test it over the weekend…


Leave a Reply

Your email address will not be published.

Show Buttons
Hide Buttons