This article documents future directions in functionality, design, and coding practices for SpiderMonkey. It can be read as something like an "ideal future state" for the engine. That means the code as it is today won't match this document, and that's OK. Whenever practical, new code and changes should move code closer to the ideal future. And of course, the idea of the future is always evolving in time as things change and we learn more.
Concurrent and wasm GC
We are working towards a concurrent collector.
We would also like to allow WebAssembly to interact with GC-managed data.
Parallelism
Most machines that run SpiderMonkey have multiple cores, so parallelism is almost certainly part of our future. It will take some experimentation to build the right set of parallel facilities. During that experimentation, we must take care to apply parallelism with conceptual clarity and discipline.
The API
The SpiderMonkey API is C++.
For the near future, we do not intend to provide a stable API, because too many things are changing. Also, we will someday want a more modern C++ API. Going forward from now, the API will likely be semi-stable, but there is no guarantee.
The public API is gradually moving from jsapi.h and jsfriendapi.h into header files in js/public. Much more cleanup and organization is still required.
Practical coding bits
Experimental language features
New language features (ES6+) and APIs often get added to SpiderMonkey while the spec is still being drafted, or before the feature has stabilized. This is good, because it helps the spec work. For these features:
- Do not add vendor prefixes. See http://hsivonen.iki.fi/vendor-prefixes/ for an extended argument.
- Disable the feature before the Beta channel. Nightly and Aurora are the good channels for experimental work.
NSPR
The plan is to make SpiderMonkey not depend on NSPR. No fundamental blockers currently exist, but ctypes is still using NSPR's runtime library loading facilities.