I wouldn’t dream of accusing you of using JSON to transfer markup. I agree HTML should be transported as is.

Some browsers do support XSLT natively http://www.w3schools.com/XSL/xsl_browsers.asp and you can always check which ones do and transform clientside or serverside where appropriate.

However I want to try out other ways of templating and HandlebarJS will be at the top of my list. It looks very neat.

Clarification: nowhere do I suggest that JSON is the proper format for transferring markup from server to client. In fact, I’d argue quite the opposite. Check out mpAjax (multi-part Ajax Responses) for an approach (which will probably make it into HandlebarJS/BikechainJS eventually) to handling different kinds of data in their native formats.

In HandlebarJS, JSON is used for DATA that will populate a template, not the markup that eventually gets wrapped around the data. The same would be true if that data were being exchanged between two processes on the server, or if it were being sent over the wire to the browser. In my opinion, JSON will always be the superior format for data exchange.

Conversely, I’d argue that HTML should be transported as HTML (not as JSON or as XML), mostly for efficiency reasons. The exception I’d make is if the HTML was in a HandlebarJS template that was pre-compiled (like at build-time), in which case what would transfer over the wire would be a snippet of executable JavaScript instead. This is a case where the run-time to compile it on-the-fly in the browser would be avoided in favor of compiling the templates ahead of time on the server, which comes at the “expense” of transferring the markup in less than ideal format in exchange for faster rendering times in the client.

And yes, HandlebarJS and BikechainJS are clearly intended (though not required) to work together.

I guess I’ll need to try it out before commenting further. If I were to use in anger I’d definitely need to be running it on the server (for SEO reasons). I suppose if like you say, we now have a ‘middle end’ – it deserves it’s own environment. This sounds like where BikechainJS comes in.

Cheers

I had an ‘iframe’ parallel loading implementation but it’s not working for the damn IE, so not usable on more than the 60% of browsers around

Your solution is quite appealing since it seems easy to implement on most sites and working cross-browser. My compliments.

It’s just $(document).ready(…) usage is so common with jQuery pages that it’s easier to assume it is being used and be cautionary, than to assume the opposite and have lots of weird race-condition gotchas.