From MozillaWiki
Jump to: navigation, search


To date, client side JavaScript has generally been able to get away with something as simple as the <script> tag and no standard way to do namespaces. On the server, it's a bit different because you're more likely to use more libraries and you can potentially load up a lot of code. Having a basic system for loading code and encouraging the use of namespaces to avoid unintentional interference will underlie everything else.


Several proposals have been made. There has been convergence toward the Securable Modules proposal, with several implementations passing the unit tests.

  1. Global File Loading
  2. Global Object Loading
  3. Pythonic Modules
  4. Securable Modules

Prior Art

  • Spidermonkey (and Jaxer) and Rhino offer a load function, but does not have any specific pattern for namespacing.
  • Dojo has a complete incremental loading facility in the form of dojo.require and a standard mechanism for declaring modules. dojo.require ensures that the module is loaded only once. It also manages dependecies between modules.
  • The Jack project implements a simple "require" system.
  • Persevere uses "require" (similar to Jack) for module loading.
  • Helma NG implements a module system with per-module scopes and import, include and require functions.
  • jslibs bootstrapping jshost provides only basic code and loading module support, direct from file and either into the global namespace or a chosen namespace
  • Advanced JavaScript Importing & Loading Extension is the browser-independent extension that provides Javascript with namespace and dynamic script loading support ( )
  • modulesjs an XHR JS module loader provides module loading, singleton modules ( )
  • Synchronet provides a global load() method which allows a specified scope/sandbox object, passing arguments, and background/concurrent execution:
  • Ejscript has a loadable module mechanism based on language extensions "module" and "use module" definitions. Modules can have scope, dependencies, incremental loading and optional backing native code.
  • Torino implements a C-style "#include" preprocessor which is intended to provide a low-level loading mechanism on top of which more sophisticated module management schemes can be implemented in JavaScript.
  • Eclipse E4 is doing work using Rhino to support writing modular JavaScript bundles that can interoperate cleanly with the OSGi modularity layer used by Java plugins in the platform.

Related Discussions