Several proposals have been made. There has been convergence toward the Securable Modules proposal, with several implementations passing the unit tests.
- 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 http://code.google.com/p/jslibs/wiki/jshost
- modulesjs an XHR JS module loader provides module loading, singleton modules ( http://modulesjs.com/ )
- Synchronet provides a global load() method which allows a specified scope/sandbox object, passing arguments, and background/concurrent execution: http://synchro.net/docs/jsobjs.html#global
- 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.
- a module system (difficult to agree)
- Concerns about the proposed module system(s)
- do we need a Module object instead of require() function?
- Are we agreed on require, in general?
- SecurableModules question
- Do you think require() should be implemented in JS?
- Securable Modules show of hands
- Secureable Modules: "exports" vs "this"
- SecurableModules: Namespacing, version numbers
- Global Free Variable