Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm have been doing some research into making code more testable and modular, but after reading alot about AMD based JavaScript, it doesn't appear to fit the needs of a static website. Is this assumption correct? Is AMD based development geared more toward highly interactive web applications that simple websites?

share|improve this question
up vote 2 down vote accepted

For a truly static website, I'd try to get by with as little javascript as possible (or none -- you can do quite a bit with just HTML and CSS). Remember, some people browse with javascript disabled. You wouldn't want to limit your audience unnecessarily.

share|improve this answer

I've never understood the appeal of AMD loaders for the client-side web in general, although they did make some sense for mobile at one point because resource files didn't cache on Android and parsing performance wasn't great.

If you attach script files in 3 categories in the following order,

  • General 3rd party libraries
  • App-specific in-house libraries that reference the 3rd party libraries
  • Implementation code that can reference both

... where's the problem? Scripts that aren't used on a page aren't ever more than a one-time loading performance hit because they're cached. If juggling dependencies within those categories just by appending script tags in the right order has become an exceedingly difficult task, I'd call that an architecture/file-management issue that shouldn't be hard to handle with a little clean-up/consolidation.

If two functions or constructors share a dependency, it usually makes sense to have everybody in the same file and that shouldn't be hard when you've separated the code that implements, from things that are used by implementation, from 3rd party things that can be used anywhere. Within a given category don't split things into separate files if they share a common problem domain. And of course combine/minify in production.

If all you're using JS for is client-side templating, I would not expect anyone would want to use AMD. As a general rule, don't use anything that doesn't provide an obvious/immediate benefit. It's easier to add later than it is to take away.

share|improve this answer

You could see AMD loaders as the missing include of JS. Do you need a big site to start including some files in others?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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