In this Microsoft tutorial they implement Ajax in the final step: "Step 7. Implement Ajax"
I know it's only a tutorial so it's kept simple but I have seen this idea elsewhere too, build the app and then sprinkle ajax where appropriate.
I implement ajax as I go but I am wondering what people feel is a best practice concerning this. Is it best to throw ajax on at the end or should you be implementing it as you go? Anyone ran into trouble one way or another?
What does 'as you go' mean ? I start with a design, and so it's very clear what the final product will be. So, yes, you need to know where the ajax stuff happens right from the beginning.
The argument for doing AJAX last is that you are much more likely to develop a site that degrades gracefully if you get it working without AJAX first.
This does not matter to some people--I've seen (internal) sites designed for a specific version of a specific browser with a definite set of features turned on. But if it matters to you, it is much easier to add AJAX to a site that works well without it than it is to remove AJAX from a site that depends on it from the start.
I do it as I go, where it makes sense. It's rare that we have a complete design spec from day 1, so you have to make a descision sometimes.
Ignoring the fact that you'd expect the requirement for Ajax to fall out of the user interface specification requirements (if you have such a thing), I'd think about implementing it (or implementing the hooks) sooner rather than later.
1) retro-fitting it to something that's been architected to return complete pages will not necessarily be straightforward
2) it'll potentially impact the deployment pattern of your solution, in that it'll be serving up pages plus page fragments/objects, and those fragments will result in many more hits to your server (imagine the extra hits that your server would get if you introduced something like Google Suggest, where potentially every keypress could result in a new server request).
So you may not want to implement the Ajaxness immediately. But I would urge you to consider it (and if its required) sooner rather than later.
If your core user interactions will rely on Ajax (e.g., Google Docs), then you should implement those bits early.
Otherwise, if your core interactions rely instead on reliably storing and retrieving data, add Ajax last. This way, you force yourself and your team to test your app's behavior as if JavaScript were unavailable on your user's browser. In this instance, Ajax would be an extra layer of user interface goodness.
Another argument for implementing Ajax early is that whenever you add any capability late in a project, you often have to tear down and rebuild some existing code or design to make it work. When you plan for the feature from the beginning, there's a lot less recoding required.