Flustered by so much JavaScript? Concerned with all the seemingly new patterns to learn? Confused about how to organize it? You are not alone.
Many JavaScript Libraries
You may look and think, wow, there are a lot of JavaScript libraries in this project. 
The “Many” is subjective based upon your perspective. Is 3 many? Is it 10, 20, 30 ? I think it depends on who you ask. Let me put it another way: if you work on a ASP.NET MVC project take a look at all of the dll’s in your references folder. How many is too many there? I bet they don’t bother most folks. Rarely do I hear complaints about that. Is it because Microsoft put them there? Or is it because they are out of sight out of mind? Or possibly we are just used to them being there.
Now let’s take a look at the 3rd party JavaScript libraries I included in my course and in the Hot Towel SPA template.
My point is that the number of JavaScript libraries I use is dependent on the value they offer. If a library offers more value to me than me writing it, then I am fine using it.
Note that I rolled up the min versions using a feature of VS 2012. Some people remove these files, others leave them alone. Choose your own adventure :)
jquery-1.9.1.js jquery-1.9.1.js jquery-1.9.1.js
Tracking Dependencies
I had a comment recently on a discussion board for my latest SPA JumpStart course at Pluralsight. “TheWayItIs” explains
My concern comes with the many code libraries and hierarchical dependencies of your patterns upon these.This in itself seems to become spaghetti of external dependencies on your patterns.
I already know these things, and that is the heart of the problem. I’ve gone through this jungle and come out the other end. Seeing the relationships and dependencies between these libraries is clear to me now. However, that is because I now know what to look for and how they all work together. Further, the patterns I employ help clarify this for new libraries and dependencies I may add or remove in the future. Now that I have this knowledge, it is more difficult to imagine what it is like to be without the knowledge. It is like this for anyone who tries to explain something that they know to someone who doesn’t know. I have to break it back down to the time when I lacked it. This is my job: to walk through these issues and show you what to look for and how to gain this clarity.
The dependencies are handled by 2 main players: the require.js and the module pattern. The module pattern separates code into more files, where each file has one specific role. then require.js helps load those dependencies between modules in their proper order. This is over simplification, but really, that’s the key to this point: it doesn’t have to be complex.
Keep your code separated and let require.js handle dependencies.
I’ve been a .NET coder since the beginning and I use these same concepts with .NET. It all falls down to Single Responsibility Principle (SRP). Keep your code separated (and do not repeat yourself) and you gain code re-use, reduce bugs, make it easier to maintain, and can scale easier.
Production Capable?
The same person on the discussion thread at my SPA course also asks
... are you proposing your sessions as production capable patterns relying on these many libs or should we view these patterns as useful for an expiring app such as a code camp with speakers?
My answer is yes. Yes these libraries and patterns are production capable right now, today, this moment (notice the pun on moment.js). Of course patterns and libraries evolve.
Why Introduce New Libraries?
Case in point is that I knew Durandal.js and Breeze.js were being developed when I wrote my intermediate SPA course. They were not ready for apps at that time (this was last summer), so I wrote replacements by hand. This accomplished a few things. First, when you go through my intermediate course you understand the complexities of solving these problems that these 2 libraries solve for you. Why? Because I walked through how to do it all manually and it was much more work. Second, there is value in seeing how this all works so you do not have magical black boxes solving your issues. Not that you want to recreate the wheel, but its important to know how a wheel rolls. Finally, after going through that experience, you now understand and appreciate the value of Durandal and Breeze much more than if you had not seen how to do it all by hand.
Clarity
Clarity won’t come in a heartbeat, but rest assured that it will come. Just like 100’s of files in .NET appear manageable to you today, the amount of JavaScript won’t appear so daunting. You’ll see that many of the important patterns you know so well in .NET are still there in JavaScript. Organizing your code in .NET is slightly personal preference … it’s the same with JavaScript/HTML. You’ll find the arrangement that works for you and find your chi.
These were awesome questions and they deserved some time in print. I hope they help you!
