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.
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 https://code.google.com/p/jslibs/wiki/jshost
- Advanced JavaScript Importing & Loading Extension is the browser-independent extension that provides Javascript with namespace and dynamic script loading support ( https://ajile.iskitz.com/ )
- modulesjs an XHR JS module loader provides module loading, singleton modules ( https://modulesjs.com/ )
- Synchronet provides a global load() method which allows a specified scope/sandbox object, passing arguments, and background/concurrent execution: https://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.
Proposed API
P1) global file loading
The following is a simple system based on loading files by filename. This is quite Ruby-like.
//
// Evaluate the content of the fully specified file
// in the global scope.
//
load('/usr/local/lib/js/File.js')
//
// If no file extension is included '.js' is assumed
//
load('/usr/local/lib/js/File')
//
// Searching through the library path.
// Suppose the path is
// /home/peter/js:/usr/local/lib/js:/usr/lib/js
//
load('File')
//
// Use 'load' above only if this file has never been
// loaded before.
//
load.once('File')
//
// Load a file relative to the current file's path.
// '__DIR__' is a macro expanded to the file's absolute path
// before the code is evaluated. It may be that __DIR__ is
// expanded to be something like
//
// /home/peter/src/foo-project
//
// This allows for one file to load many others distributed
// in the same package.
//
// web-framework.js
// web-framework/
// routing.js
// templates.js
// orm.js
//
// This does not cross over to the browser as the browser does
// not have macros.
//
load(__DIR__+'subdir/foo'); Remark: the __DIR__ macro is not necessary: the JS intepreter can as well do a chdir() to the directory of a script being loaded, effectively setting a new base path for consecutive relative includes.
Remark: I think chdir() is not a good option here because if one module does chdir to include other modules which also do chdir(), then chdir() is required before every individual "load". Otherwise the current directory is basically unknown to any particular script. -- Peter Michaux
P2) global object loading
A system similar to the simple file loading as file content is still evaluated in the global scope; however, this system depends on a naming convention between file and object names. This makes it a bit more Java-like and is more heavily dependent on the library path. It removes the need to think about a file system and makes it possible to use the same system in the browser.
//
// Searching through the library path.
// Suppose the path is
// /home/peter/js:/usr/local/lib/js:/usr/lib/js
// Then if can evaluate the content of the file
// /usr/local/lib/js/io/File.js in the global scope
// with
load('io.File')
//
// Use 'load' above only if this file has never been
// loaded before.
//
load.once('io.File')
P3) Pythonic Modules
This is a proposal that provides protection against name collisions by isolating module scopes, while being reasonably easy to implement in a server or standalone JavaScript runtime.
P4) Securable Modules
This is a proposal that provides protection against name collisions by isolating module scopes, defaults declarations to closure private scope, and emphasizes interoperability on three dimensions: client to server, insecure to secure, and current to future.