Splitting the JavaScript files down in this way has several advantages:
  1. Keeps the code organized by functional concern and helps to reduce code duplication.
     
  2. Splitting the code into files in this way allows for easier concurrent development in a multi-developer environment. When everything is in a few files then developers have to wait until the file is checked back in by someone else.
     
  3. Reduces conceptual complexity by breaking down the functionality by area of concern. How easy is to read a 2 mile long JavaScript file?
As you can imagine the premise with this structure is that any code that is applicable to all entities should be put into the organization level file. Any code that is specific to a particular entity is put into the entity specific file and so on. The break down structure is really more of an tactical ideal than "the way" to do it. I'm not saying break all files down to the absolute bottom. It just depends on the side the problem you are trying to solve. I know in certain situations for example on the opportunity entity that there can be so much code that it made sense to break down the code into the bottom most layer of functional area.
 
JavaScript Library Organization and Standards
 
C# coding standards versus JavaScript coding standards
 
It has been very tempting to just use C# coding standards when it comes to method and variable naming. For example in JavaScript you’re your method names are supposed to start in lower case letters whereas in C# method names begin with Upper case letters. Since we are dealing with JavaScript I would say it’s best to stick with JavaScript coding practice. It doesn’t help though that when you go to add an event to a form field that the event names are camel case such as OnChange versus onchange.
 
Use of JavaScript name spaces to encapsulate solution code
 
If you look at the CRM JavaScript object model you’ll notice that the root object Xrm is actually just a JavaScript namespace. Underneath Xrm you get down to the methods that Microsoft has created to obfuscate you away from the actually code implementation. I think that it would be helpful to do the same when writing code for a solution. Instead of just having a file with a bunch of methods in it why not organize it similar to how you would in C#. This also has the added advantage of giving you the ability to use Visual Studio’s intellisense.
 
Don’t hard code everything
 
JavaScript is a pain as it is since it doesn’t have the same compile time error checking as C#. So if you’ve ever come across a large library with field names hardcoded everywhere you know what I’m talking about. I believe in keeping the same standard for your JavaScript as your C# code. Hard coded field names, option set values and form event enumerations are not very friendly to the developer that has to come in behind you to make code changes. As it is called in Agile terminology this is what is referred to as “technical debt”. There is a mess on the floor in the kitchen. Everyone can see the mess but no one want to clean it up out of fear they may break something that “already works”. Just don’t make the mess in the first place and no one has to worry about it later.
 
Summary
 
JavaScript libraries in CRM can quickly become a beast to manage. While the amount of JavaScript necessary in solution for CRM 2011 is much less than it was in CRM 4 it can still be a force to be reckoned with and shouldn’t be taken lightly. As I continue down this path of JavaScript philosophy I’ll probably post a more detailed account of actually implementing this in practice.