TimsModuleThoughts
Here are some snippets from my own notes on these subjects, having experimented with current platforms looking for feasible common ground. These are of course my opinions, but because of limited time, I’ve expressed them as matters-of-fact and probably out of order. Thanks for bearing with me if you do.
Synchronicity
async-to-sync is apples-to-oranges. This might one day be expressed and well-maintained as two separate copies of similar functionalities (at twice the cost). Not today, not in retrospect, and not by accident.
Security
Minimally-Practical vs. Secure is also apples-to-oranges. Python’s “restricted mode” abandoned its noble efforts likely because of too many loopholes hidden by applying security in retrospect. In all practical ways, CommonJS is in retrospect here. (FWIW, I had a need to explore sharing global state between modules/contexts, and am currently using an inconspicuous security loophole across several recent proto-platforms to accomplish this).
Thought Vehicles
I see lots of bike-shaped stenciling on minivans, monster trucks, and unicycles. ‘JavaScript’ is 40% ‘Java’ in terms of surface stenciling, but…
Separation of Concerns
Very little overlap happens by random chance. How are these different needs to be managed now and in the future, both in discussion and in code? Are current specifications catering to just one or two of these?
- The CommonJS-as-a-language
- The Module Librarians
- The End-User Developers
- The Platform Builders
- The Module Authors
Going with the Flow
Current proposals, when viewed across the above concerns and across existing codebases, remain suspicious and burdensome. What other approaches might better serve to maintain inter-project rapport while revealing palatable solutions? How about an incremental approach?
(1) vanilla ES3 module concept No prescribed module identifiers or resolution mandates or paths, just an embryonic, abstract mechanism for an End-User Developer to express a need, and for a Module Author to similarly identify dependencies. This is doable in useful ways through code comments.
(2) vanilla ES3+Core concept With the addition of bare-minimum, majority concurred CommonJS APIs. Both Synchronous and Asynchronous interfaces provided (fine if emulated). Nothing dependent on any module or packaging system. The APIs expressed as superglobals, not module imports, with no choices whatsoever for the End-User Developer to make here (beyond all or nothing ES3+Core).
(3) An ES3+Core+Stdlib reference implementation Basically ES3+Core+MoreES3s, with any MoreES3s’ synchronicity support TBD. Again superglobals used to reference the larger API, and just one decision for a user to make.
(4) ??
Tangential Needs
- DISCUSSION FORUM: ES3+xAPI *
To vet some good interfaces to already-common libraries like mysql/ memcache/etc. This seems completely overlooked by CommonJS movement. It needs to be addressed quickly to re-unify current divides and to avoid new exponential divides across platforms.
- DISCUSSION FORUM: ES3+Synchronicity *
To coordinate async vs. sync standards any possible interop; to track relatable efforts w/o confusing them with module or security discussions.
Again, just some thoughts from my notes offered with a grain of salt.
Best, -Tim
Here is my wish list for a specification-backed module environment, somewhat organized by stakeholders. It contemplates several atomic needs that have been obscured by recent pushes towards a one-size-fits-most "require" construct.
1) Standard Library/Modules (ala Python) [@ CommonJS core ]
a) The CommonJS-as-a-language standard libs and APIs b) The CommonJS-candidates "de facto standard" libs and APIs c) Pseudo-standard libs (ie: verticals) d) ...generalized module reuse, packaging, repositories
2) Local Module Management [@ Sysop / Code Librarian]
a) Intrinsic modules (knowledge of globals, superglobals, "require") b) Filesystem (organized by paths) c) COM registration (ie: Components.classes["@mozilla.org/preferences-service;1"]) d) URI mappings / registrations
3) Module Binding [@ End-user developer]
a) _global_ (affects VM state) b) _static_ (deterministic / easy to lint / perhaps sync) c) _dynamic_ (non-deterministic / difficult to lint / perhaps async) d) _untrusted_ (sandboxed / preprocessed)
4) Module Loaders / Resolvers [@ VM / Platform developers]
a) Versioning (dependency tracking, sniffing) b) De-duping (ie: load into VM/context just once) c) Unloading / Reloading modules d) Synthetic modules (adapters, submodules, autoloaders, etc.) e) Serialization (ie: VM-hibernate)
5) Module XYZ [ @ Module developers ]
a) (expression of) dynamic dependencies (container agnostic) b) Static linking (for autonomy) c) Submodules (internal reuse, public/private conventions) d) etc.
