Survey - Where are you embedding SpiderMonkey?

tcampbell · April 6, 2021, 5:02pm

Embedding SpiderMonkey into a project is no easy feat, but we know there are a number of embedders out there. We are curious where and how you are using SpiderMonkey (and also if you read this discourse/mailing-list). Hopefully if we know more, we can break your use-cases less often .

A few quick questions

What is your Project? (Or Company) (Or just “private”)
What is your main version of SpiderMonkey?
What version are you currently rebasing towards?
Why SpiderMonkey?
Pick one complaint about embedding. (eg. not enough docs; Rust requirements)

EDIT: Turning this into a wiki post.

Project	Main Version	Next Version	Why
Mozilla Firefox / Gecko	central	central	An independent platform lets us influence the shape of the Web.
GJS, GNOME’s JavaScript engine	ESR 78	ESR next	In 2008 Havoc Pennington published a blog post that was influential in the GNOME community, about an architecture of C/C++ platform libraries plus a scripting language, in which he proposed SpiderMonkey as the scripting language. At the time, Node.js didn’t exist so v8 wouldn’t have been as obvious of a choice as it might be now, and the embedding API of JavaScriptCore has always been pretty minimal. Mozilla is also philosophically aligned with GNOME around openness and software freedom.
0 A.D., a FLOSS video game	ESR 78	ESR next	The adoption was IIRC decided around 2007. The question was which scripting language to accompany our C++ backend. JS was chosen over Lua on grounds, I could look back for the exact reasons, but basically it worked and did everything they wanted back then. It proved quite useful having such an ‘entry-level’/familiar language, and I doubt the 0 A.D. modding scene would be quite so lively without it.
CouchDB	ESR 68	SM 86
MongoDB	ESR 60	?	https://engineering.mongodb.com/post/code-generating-away-the-boilerplate-in-our-migration-back-to-spidermonkey
Bloomberg’s JS runtime platform (partially)	SM 5 fork	SM 13	We started using SM in early 2001, and built a server-side JS platform around it in 2005. The choice came down to JS or Lua and we chose JS. There was no other viable option than SM and we had years of embedding experience at that point.

tcampbell · March 31, 2021, 10:41pm

There was a bit of discussion of this on #spidermonkey:mozilla.org (Matrix) and we got a few examples there.

GNOME Shell uses SpiderMonkey via it’s gjs embedding (https://github.com/GNOME/gjs). They largely follow the latest ESR builds.

CouchDB has long used SpiderMonkey and just recently got SM86 support working (https://github.com/apache/couchdb/pull/3421).

MongoDB has gone back and forth on using SpiderMonkey and is currently using ESR-60. They talk about some of their reasoning in this post: https://engineering.mongodb.com/post/code-generating-away-the-boilerplate-in-our-migration-back-to-spidermonkey

ptomato · April 1, 2021, 4:12am

I’m happy to supply more information!

Project: GJS, GNOME’s JavaScript engine
GJS is SpiderMonkey plus bindings for all of GNOME’s platform libraries. It’s used for scripting the desktop UI in GNOME Shell (plus the large ecosystem of plugins), as well as for several prominent core GNOME apps such as GNOME’s IRC client Polari and GNOME Weather. For a while it was designated GNOME’s official development language, but that proved controversial and was later reversed. Due to its use in GNOME Shell and apps, it also turns up elsewhere in the ecosystem of Linux desktop apps, such as the ebook reader Foliate and in Endless OS’s offline content framework.
Main version: ESR 78
Next version: ESR 91
Why SpiderMonkey?
In 2008 Havoc Pennington published a blog post that was influential in the GNOME community, about an architecture of C/C++ platform libraries plus a scripting language, in which he proposed SpiderMonkey as the scripting language. At the time, Node.js didn’t exist so v8 wouldn’t have been as obvious of a choice as it might be now, and the embedding API of JavaScriptCore has always been pretty minimal. Mozilla is also philosophically aligned with GNOME around openness and software freedom.
One complaint: Lack of “Mozilla-blessed”, standalone, SpiderMonkey release tarballs.

wraitii · April 6, 2021, 1:27pm

(Randomly noticed this on chat.mozilla.org)
Project: 0 A.D., which I am going to boldly claim is amongst the more well known FLOSS video games. An RTS in the Age-like/Starcraft-like style.
Main Version: recently updated to ESR78
Next Version: we follow LTS, so likely 91 too.
Why: The adoption was IIRC decided around 2007. The question was which scripting language to accompany our C++ backend. JS was chosen over Lua on grounds, I could look back for the exact reasons, but basically it worked and did everything they wanted back then.
It proved quite useful having such an ‘entry-level’/familiar language, and I doubt the 0 A.D. modding scene would be quite so lively without it.
Feedback: I think my 2 biggest complaints are the documentation being sometimes unreliable & the installation process cumbersome - we have to compile from source, and the mozilla build system does not make it easy, particularly on windows. I have to say though that I didn’t have too many difficulties upgrading from ESR45 to ESR78.

apaprocki · April 6, 2021, 4:41pm

Who: Bloomberg embeds SpiderMonkey as a critical piece of our JS runtime platform. (In addition to Chromium, v8, etc. — it’s complicated.) We have a fairly large amount of C++ built around JSAPI and native classes, bridging script to our native services and databases. We have ballpark “tens of millions” of lines of JS running through SM.
What: The current engine was forked from the FF5 release and contains fixes and customizations on top of that, but remains ES5.1 at this time. We do not rely on or use JIT and run the interpreter on 3 different OS/CPU architectures at this time. We currently use the latest TS version and downlevel to ES5.1 output to bridge a lot of the gap in native runtime support.
Towards: A few projects are in flight, but currently targeting FF13 as a stepping stone because it is prior to some of the more drastic internal changes that occurred later. It is a lot of intricate work to port from conservative scanning GC to moving GC with exact rooting (much like what FF went through).
Why: We started using SM in early 2001, and built a server-side JS platform around it in 2005. The choice came down to JS or Lua and we chose JS. There was no other viable option than SM and we had years of embedding experience at that point.
Complaints: Mercurial and not moving SM out of tree as a separate project. Due to living in tree, there were a large number of changes from version to version with no eye on the upgrade “process” because the FF usage was updated in-place as it evolved. To outside users it wasn’t always clear what sharp corners to avoid to make upgrading to planned changes easier. The ages old decision to enable SM-only features by default came back to bite us a bit. (Yay, E4X) We basically have to reverse engineer a bit what changed in the API and runtime semantics and why and then come up with a plan to migrate existing native code to be compatible. There’s very little, if any, documentation associated with these big historical JSAPI semantic changes. (We’re always looking for ex-SM hackers if anyone comes across this and is looking! ;))

Redfire · April 11, 2021, 7:43am

Project: Spiderfire(Name is still TBD)
Current Version: SM 87 (Via Servo’s rust-mozjs)
Next Version: Inline with Firefox Releases (SM 88)
Why: All the current major server-side JS runtimes use V8 as their JS Engine(Node.js & Deno). I wanted to disrupt this ecosystem and bring forth a new runtime, based on SpiderMonkey(SM). I decided to use Rust for embedding SM due to my relatively higher experience with it (than C++) and the fact that it was originally incubated by Mozilla.
Complaints: Because most of SpiderMonkey is still written in C++ and JSAPI is made primarily for rust, embedding in Rust results in a lot of unsafe blocks.

piers · May 21, 2021, 10:53pm

Project: Flow

Main version: ESR 68

Next version: ESR 91

Why: Chose SpiderMonkey back in 2006 for an earlier project (SVG engine), primarily because is supported a wide range of CPU architectures, and has a suitable licence. When we started Flow it seemed sensible to continue with the JS engine we knew. Internally we still compile and test with various versions (SM1.8.5, SM53, SM68) using veneer functions to bring all versions up to the latest API. This covers both garbage collection models — the different algorithms help ensure we don’t have bugs in our APIs.

kimman · June 9, 2021, 9:48am

What : Enterprise workflow application of Extrieve Technologies
Current Version : 1.6 (when it was still in C)
Rebasing to : ESR 78 (but now maybe 91)
Why SpiderMonkey: when we started embedding it was the only engine around; and when V8 came along looked at it but the per-instance process was not feasible and their embedding template code is way too complicated for a C shop. We built a simple program that took an ini-like file as input and produced boiler plate code for native objects - been used for ocr, barcode, image processing, http, zip/unzip and workflow client extension.
We’ve never got a window to upgrade to the newer versions - the old one works fine except for one bug in the Netscape Runtime that surfaced only on one not-very-heavy-traffic application. But now we have to upgrade to support the newer aspects of ECMA scripts.
My colleague posted a problem of building a project with VC2019 today - thats the first steps to the upgrade.
Complaints : When I started embedding js with v1.4 a friend said, “this is a bit of a dark art” … guess it remains a bit so though there is more available now than there was earlier.

TheQwertiest · July 2, 2021, 2:28pm

Project: Spider Monkey Panel, component for foobar2000 player.
Current Version: ESR68
Next Version: ESR91
Why: V8 was not suitable for project needs: RAM consumption was too high for a 32-bit app (at least at the time). And google support is well-known for being… well… its infamous self.
Complaints:

Default GC behaviour and settings are really unsuitable for anything with decent load and it took a lot of time to understand how to (re)implement it properly.
It’s not obvious which parts of JS are available by default and which must be implemented by embedding (e.g. promises, timers, modules).
SM is much less popular than V8 and it’s docs are kinda bare-bones, so the only way to find relevant information was to bug SM devs (which are awesome though <3)

Kent_Williams · September 2, 2021, 8:35pm

PROJECT: Courseleaf
Current Version: 1.8.5 & ESR60
Next Version: ESR78
Why: We started using server-side Javascript over 20 years ago before there as anything like Node around.
Complaints:

Every time we update to a newer version there are breaking API changes. The devs are very helpful on chat.
There used to be API documentation that was (more or less) maintained, but now that’s been scrubbed from mozilla.org, and we have to reference archive.org cached version, or just figure out what we need from jsapi.h.

Wes_Garland1 · July 10, 2023, 12:08pm

What is your Project? (Or Company)
We (Distributive Corp) are embedding SpiderMonkey into Python, so that JS and Python types can share backing stores, interact natively with object and function automatic wrappers, etc. The source code for PythonMonkey project homepage is at https://pythonmonkey.io/ and it is MIT-licensed. The source code is at https://github.com/Distributive-Network/PythonMonkey.

The Python VM provides the “host environment” for the JS VM and implements the event loop. Event handlers, Promises, etc interoperate between the two VMs. A CommonJS module system can load modules written in either JavaScript or Python. We plan to make ESM and Python modules transparently compatible with each other. A node-like shell called pmjs includes a REPL and can run JS programs which can call into Python.

What is your main version of SpiderMonkey?
esr102

What version are you currently rebasing towards?
mozilla-central tip, currently 116 or so.

Why SpiderMonkey?
I have extensive experience embedding SpiderMonkey versions 1.7 through 1.8.5 and understand how the jsapi team works. Given that, I figured it was my best chance of guiding my team toward getting the Python GC and SpiderMonkey GC playing nice with the same memory.

Also, there are enough V8 projects and we believe that monocultures are harmful.

Pick one complaint about embedding.
No transition guide beyond esr102