Why change v8 to spidermonkey in mongodb js engine?

i need explains very much. i love nodejs, and v8. nodejs js engine is v8.

Welcome to the MongoDB Community @anlex_N!

There is a lengthy article in the MongoDB Engineer Journal which explains some of the technical reasoning: Code-generating Away the Boilerplate in Our Migration Back to Spidermonkey.

This paragraph from the article provides a nice summary:

SpiderMonkey has several qualities that make it the most suitable option for our needs. Most importantly, its process model is most like ours, with a single process for the browser and threads for tabs. This necessitates better tools for constraining memory and managing resource exhaustion. In addition, Firefox (and thereby SpiderMonkey) is available on the greatest number of platforms. In addition to its high performance JIT, it also has a baseline interpreter in C++ that ensures that any architecture capable of hosting a reasonable distribution of Linux can also run Firefox. And as icing on the cake, the Mozilla Foundation offers extended support releases of Firefox that offer security fixes for a year; annual maintenance affords us a substantially more manageable integration than the six-week fix cycles we had with V8.

From an end-user point of view, the choice of JavaScript engine affects two broad usages: client-side and server-side. The legacy mongo shell is part of the MongoDB server codebase, so a given release of MongoDB will have the same embedded JavaScript engine in both of these binaries.

Server-side JavaScript is generally discouraged (and often disabled) as there are significant security, concurrency, and performance caveats. The MongoDB query language has expanded in successive server releases to replace the majority of use cases where JavaScript would previously been required. The server-side eval command (db.eval() via the mongo shell) was deprecated in MongoDB 3.0 and removed in MongoDB 4.2. The limited contexts where server-side JavaScript can be used are not expected to support the full range of language features (or pace of change) as Node.js.

However, for the client-side use case we have introduced a new MongoDB Shell (mongosh) which is built on top of the Node.js REPL. The new MongoDB shell is designed to be embeddable and extensible. You can install mongosh as a standalone download, but you’ll also find mongosh embedded in MongoDB Compass and third party tools (for example: JetBrains: Introducing MongoDB Shell in DataGrip).

That’s a rather long explanation, but if you’re a fan of Node.js you should definitely check out mongosh and let us know if you have any feedback: How can we improve the MongoDB Shell?.


as i know, firefox is written by rust, and your new mognsh is built on top of nodejs repl, oh my god, nodejs is written by C++ mainly. i don’t want to learn rust that is very complex. i just learn and like C++. your mongo team use so many programming language, it is so wrong.

Hi @anlex_N,

Can you provide more information on the use case or issue you are trying to solve?

There is no need to learn the languages that applications or server processes are written in, unless you are planning to contribute to those software projects.

If you are developing an application that connects to MongoDB, you would use a Supported Driver/Library in your preferred language framework. This does not require learning any additional programming languages aside from the main one you are using.

If you want to explore data using a tool, you can use the new MongoDB Shell (which exposes an interactive command-line interface) or a more visual tool like MongoDB Compass. You do not need to learn Node.js to use the MongoDB Shell; that aspect is a feature for developers who want to extend functionality of their shell environment.


i am learning your mongodb source code. i think spidermonkey is not so very meaningful. i don’t want to learn another js engine. i want to contribute to you in the future.
although i can not master C++ 100%, but if i master rust, i would master c++ 100%. it wll cost me so long time. do you know?
by the way, based on your docs, your mongodb source code is written by c++ 11 syntax largely. c++ 20 is the stable release now. oh my god. your syntax is so old, and if written by latest c++ syntax, your source code can be decreased very much.

Hi @anlex_N,

The JavaScript engine is only used in limited contexts. You can learn about the server source code without ever touching the code for the embedded JavaScript engine.

If you are learning about the server source code, I would focus on a specific area or subsystem of interest. Working with the source code for a large project is more like reading short stories than sitting down with a novel where you read every chapter.

I think you may be referring to the MongoDB C++ Driver which supports C++11 or newer.

The definitive information for the server source code is on GitHub (mongodb/mongo). You can find the prerequisites (which may vary for major release branches) in docs/building.md. The current requirement is C++17, which is the most recent ISO standard before C++20.

The build requirements for a mature product with an established codebase and many supported platforms cannot change as quickly as the latest language features, but the platform team does evaluate the benefits (and risks) of upgrading to newer prerequisites at the appropriate time.

C++20 has been in development for a few years, but the language standard was only approved in Sept 2020 and published by ISO in Dec 2020. Adopting a new language standard also requires compilers with feature support, and many still only have partial/experimental C++20 support at this stage.

I wish you luck in your further studies but I believe your original question on choice of JavaScript engines has been thoroughly addressed now.


webpack is my build system, nodejs is my server code, nativescript is my mobile code, those are based on v8. i wish mongodb js engine is v8 very much. i wish all in one SOLUTION. do you know, teacher?
@Stennie, how is v8 process model? i have searched in google, but can not find some material.
chromium have 4 process models, those are not benefit for you?

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.