At some point code is complicated less if you introduce a new abstract than if you continue as it was.

Some trigger should fire in a head of a programmer. Like, I was coding fine, but now I've added a few lines of code so I need to stop introducing that much complexity and incapsulate those into a new method. Programmer should complicate easy things step-by-step. Do not introduce new abstracts before they're needed.

Asyncronous modules (AMD) like RequireJS help to organize code in JavaScript. But when the trigger of introducing this abstract should fire?

  • 3
    I will repeat the question I asked on SO. Do you mean 'How do I know when to move code into a separate namespace (or module)?' Or do you mean 'How do I know when to make a function call asynchronous instead of synchronous?'. Perhaps some whiteboard code or a whiteboard interaction diagram might help clarify your question. Also, what specific problem are you facing: do you think you have too much code in modules, too much code in the main namespace, too much repetition, inconsistency, difficulty in adding new features, for example? – dcorking Sep 24 '14 at 10:08

I don't think I understood your question too well. Are you asking about some of the diagnostic aspects of your code which will signal to you that it's time to shift it to AMD?

Well at our organisation we used the most popular AMD Framework, The Dojo Toolkit. And we used it really early on, even before our code became complex.

Talking about shifting a codebase from non AMD to AMD, I have the following points:

  1. How many engineers are working together? If there are many, there is a great need to split up your large code base into multiple files where people can work in parallel.

  2. Are you building a platform first and are separate teams using that platform? Eg: A team may be working on UI Widget Controls while other teams may be requireing it. Again a perfect place to use AMD.

  3. Do you have an intelligent build tool in place? If not, your end users are not going to like the sluggishness of your AMD powered App.

  4. Most importantly, even before AMD, check if your project is using Object Oriented Practices. If it is , this is again a beautiful use case to separate out your files into classes, functions, objects etc.

  5. Is there a lot of circular or complex dependency amongst files? Well, this is what AMD was built for!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.