This article is called this 1, as I use many OO languages, and do not consider an “include statement” a good way to manage dependency injection. Simple JS notes also assert that code should be manually injected with a static locked version.
This article is limited to client side JS. At point of writing this site has no good process loading JS. There was originally a small number of JS libraries, and my personal shim to fix (now historical) browser faults. I have been adding to the UX niceities, so the JS is getting heavier. I want a better solution than statically linking JS classes in the main/root template. I am writing an exploration (this text) ahead of any decisions or work.

Possible Architectures

In terms of architecture, the following approaches exist (this section doesn't mention solutions, or integration costs):

  • Correct HTTP caching per file && inpage shims
    • On the assertion that if each library is already on the client, it can be applied to a page really quickly; this is a very simple solution.
    • Use a small section of script on each page that holds configuration for each active module.
    • Requires that each page can have separate JS libraries loaded (a CMS management issue).
  • Server concatenation of JS (like a PAK file).
    • Easy to edit the JS source in separate files.
    • Would be used with gzip on the network.
    • Very easy to make.
    • Avoids many HTTP connections, but is mostly obselete due to HTTP1.1 pipelining.
    • Can be dynamically configured for each page, as the files are assembled in real time.
  • Dynamically server-side compiled buffers from separate source files (like C compilation).
    • Easy to edit the JS source in separate files.
    • The compiled form doesn't need whitespace, or to be readable (variable name replacement).
    • Can include analysis tools to report likely failures.
    • This leads to a smaller footprint but static linking.
    • When each page uses the same libraries (or SPA), this is efficient.
    • With HTTP caching, this should be efficient.
    • Due to heavier processing, may wish to build the buffer asynchronously.
  • Client side library to manage download and lazy loading.
    • Sensibly, this needs to be made with a callback system (i.e. after I have moduleX, run moduleX init function). This requires architecting from scratch. This is the actual classloading option.
    • Works better with many different pages as each JS library is only downloaded when requested, meaning the first page is displayed faster.
    • Does require an extra library on the client, but this doesn't need to be very large.
    • May make page seem slower, due to more complex model (browser parses HTML, downloads 1st JS lib, parses that, then downloads behaviour libs, then parses them)
    • Can do more behaviour on failure, than the other solutions...

Aside: AMD.

I am not the first person to think that “traditional web designers” leave something to be desired when it comes to code management. AMD has been designed as a spec to push ideas to webbrowsers, and implemented in JS as shims until the browsers are extended to included this idea. AMD is short for 'Asynchronous module definition' 2. The objective of AMD is an easier way to manage JS class loading, similar to what is used in Java, and more recent versions of Symfony2 (a project started by a Java developer). There seems to be a project root at 3, but I am unable to locate a RFC. AMD is discussed in the following articles 4 5 6 7 8 9 10 11 12 13...(presented as links as I see no value in copying the content, and google inc agrees with me in this).

Possible solutions

There is little value in writing a platform from scratch, although I can do see [1]. From a quick google search here are some options:

  • RequireJS 1, a common JS framework for dependency injection. This has integration with several JS tools such as Angular.
  • Steal 2 github docs. This is reviewed as 3, its stackexchange seems to have sensible questions.
  • Dojo toolkit 4 github This project believes in docs in word files, I link the loader 5. This is distributed with the 'new BSD' licence. An article advocating Dojo 6 although it seems to have declined popularity 7 (for the whole framework..)
  • curl.js 8. This is a good tool, but it seems the project is suspended, so its use should be considered with caution.
  • ScriptmanJS I can see notes referencing this on AMD sites. This site has an expired domain, I assume a dead project. Google doesn't return the github project either.
  • UPDATE: I need to look the tools listed in here

A while ago, there was a standards focussed group called CommonJS 9 (didn't directly make any code). This is focussed on serverside JS, and is mentioned here for completeness; and that if ignorant people are reading this “AMD like” subject, notes on what to ignore may save them time.


My actual requirements is to fix the JS HTTP headers, and give the pages a per page module load list. I don't like “manual include statements”, but this may be the most appropriate level of technology on this site. I will make/ import a minimiser, as secondary target. Don't think this is worth a github project for.

[ 1 ] I am writing a Perl unit test skeleton generator, as I am unable to find one.