As we just learned in the previous topic SOOJS embraces strong file separation. This is something that many projects forgo because of the deployment difficulties around multiple source files and JavaScript. I have been in that camp for a while. If you’ve ever managed a medium sized JavaScript project you know the headaches of code merging, minification, and lazy loading. These are not trivial problems and deserve attention.

But allowing implementation to affect development is simply a terrible idea. It’s not a worthwhile tradeoff to pile everything into a few files so that you won’t have to deal with a loader or merge issues later. Applications are already far too delicate to support poor architectures. Our goal is to write clean, clear code that anyone can understand and edit. We also need to support change control for the future. If I made the one logout() change mentioned in the last section then all that needs to be tested in the class I changed. Since the files are all clearly separated we can see what files were changed for any given effort and focus our testing efforts accordingly. If things are piled on top of one another — something that is the case in a vast majority of JavaScript projects — then it takes a sophisticated code review to verify that nothing else in there was accidentally bumped out of alignment.

I will leave it at that, but understand that creating individual files for each and every class will quickly reduce the complexity of maintaining your application. The examples you will see going forward will all use this concept very heavily.

Series Navigation<< Core Concepts: MaintainabilityCore Concepts: Simple JavaScript >>