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
<Content Include="Scriptsjquery-1.9.1.js" /> <Content Include="Scriptsjquery-1.9.1.min.js"> <DependentUpon>jquery-1.9.1.js</DependentUpon> </Content> <Content Include="Scriptsjquery-1.9.1.min.map"> <DependentUpon>jquery-1.9.1.js</DependentUpon> </Content> <None Include="Scriptsjquery-1.9.1.intellisense.js"> <DependentUpon>jquery-1.9.1.js</DependentUpon> </None>
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.
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.
These were awesome questions and they deserved some time in print. I hope they help you!