Then your initial page hit requires 2 round trips... one to download the page and the javascript, another to get the ajax, and then also a javascript based rendering step.
This way, the rendering is done server side so the initial html comes with the first request, and ajax updates are still generated using the same server side code path, just sent back inside of some javascript.
It's not much work to include the "first page" of data as a JavaScript variable declaration embedded in the response to the initial page hit to avoid that second round trip.
Backbone does in the docs recommend "bootstrapping" your data to eliminate the round-trip to get the initial JSON. I personally don't usually do that myself since the call to the server for JSON doesn't have a significant visual effect (to my eyes anyway). Whereas two different ways of loading data creates more testing and maintenance (on the server as well as the client)
Something about sending Javascript from the server seems like mixing up the application layers and creating dependencies that shouldn't' be there. I can see it perhaps if the code that you "own" is 100% on the server. Maybe I'm old school and it's just something that will have to sink in a bit before it makes sense to me.
This way, the rendering is done server side so the initial html comes with the first request, and ajax updates are still generated using the same server side code path, just sent back inside of some javascript.