Survey - Where are you embedding SpiderMonkey?

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 :slight_smile:.

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.
1 Like

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

1 Like

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.

2 Likes

(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.

2 Likes
  • 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! ;))
3 Likes

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.