At the end there is a TL summary; DR at the end.
I can’t actually tell you a good resource for this, since I did not find it myself. However, all is not lost. You already have experience developing large-scale applications, and using this knowledge in the browser space does not require much rethinking.
First of all, if your application is really trivial, I would not refactor the entire code base right away, because there are endless cases that you have not thought about.
Design the basic system architecture first. In your case, you probably want all your AJAX requests to go through one point. Select an XHR interface from jQuery or YUI and write a wrapper around it that uses the hash option. All the XHR calls you write for the new code go through there. This allows you to turn off the framework that makes XHR calls with a different structure or your own at any time.
Next, agree on a wire protocol. I would recommend using JSON and POST requests (POST requests have the added benefit of FORM views that they are not cached). Make a list of the different types of requests and responses you need. For each of these answers, create a JS object to encapsulate them. (For example, a form submission response is returned to the caller as a FormReponse object that has access functions for validation errors, etc.). The JS overhead for this is completely trivial and makes it easy to change the JSON protocol itself without missing your widget code to change access to the original JSON.
If you are dealing with many forms, make sure that they all have the same structure, so you can use the JS object to serialize them. Most frameworks seem to have different full-scale functions, but I would recommend reselling them so you don't have to deal with flaws.
The added value of the business at this point, of course, is zero, because all you have is the beginning of a reasonable way to do things and even more JS code to load into your application.
If you have new code to write, write it to the API you just implemented. This is a good way to make sure that you are not doing anything stupid. Stay on the other JS as it is now, but as soon as you have to fix the error or add a function there, reorganize this code to use the new APIs. Over time, you will find that important code runs on your APIs, and many other things will gradually become obsolete.
Do not cross overboard with reinventing the wheel. Keep this new structure limited for HTTP data and wire interaction and use your main JS structure to handle everything related to the DOM, browser quirks, etc.
Also configure the global log object and do not use the console directly. Ask your log object to use the console or its own DOM logger, or whatever you need in different environments. This makes it easy to collect custom log levels, log filters, etc. Obviously, you need to set up your build environment to clear this code for production builds (you have a build process for this, right?)
My personal favorite for the relatively proper layout of JS source code and namespace is the Dojo framework. The definitions of objects relative to their namespace have an obvious relationship to their location on disk, there is an assembly system for custom assemblies, third-party modules, etc. The Dojo dependency / build system depends on dojo.require and dojo.provide in the code. When run on the source, the dojo.require statement will cause the blocking load of the resource in question. For production, the build system monitors these claims and inserts the resource into the last package at this location. Documentation is a bit rare, but it is definitely a good start for inspiration.
Answer TL, DR:
- All XHR calls go through one interface
- Do not transfer the original response data to higher levels.
- Gradually refactor existing code
- Harmonize a wired protocol
- Use JS dynamic power to create lightweight proxy code
- The string structure of the code and call graphics look the same in JS, as in other languages.