Best practices and troubleshooting

In an ideal world, everybody would get to work on greenfield projects, where they can put in standards right from the get go. However, that isn't the case. Frequently, you may find yourself in a situation where you have a bunch of non-modular JavaScript code as part of a legacy system.

In these situations, it may be advantageous to simply ignore the non-modular code until there is an actual need to upgrade it. Despite the popularity of JavaScript, much of the tooling for JavaScript is still immature, making it difficult to rely on a compiler to find errors introduced by JavaScript refactoring. Automatic refactoring tools are also complicated by the dynamic nature of JavaScript. However, for new code, proper use of modular JavaScript can be very helpful to avoid namespace conflicts and improve testability.

How to arrange JavaScript is an interesting question. From a web perspective, I have taken the approach of arranging my JavaScript in line with the web pages. So each page has an associated JavaScript file, which is responsible for the functionality of that page. In addition, components which are common between pages, say a grid control, are placed into a separate file. At compile time, all the files are combined into a single JavaScript file. This helps strike a balance between having small code files to work with, and reducing the number of requests to the server from the browser.