I asked this question on SO but was suggested to try here. So here it goes:

My understanding of Javascript so far has been that it is a client-side language that capture events and makes a web-page dynamic.

But on reading the comparison between MongoDB and CouchDB I noticed that both are using Javascript. This makes me wonder the reason behind the choice of JavaScript over other conventional languages.

I guess I am trying to understand the role of JavaScript and its advantages over other languages.

Update: I am not asking about the languages / drivers supported by the two databases. The comparison says:

Both CouchDB and MongoDB make use of Javascript. CouchDB uses Javascript extensively including in the building of views.

MongoDB also supports running arbitrary javascript functions server-side and uses javascript for map/reduce operations.

My lack of understanding pertains to why is Javascript being used at all for the backend work. Why is it preferred for building views in CouchDB, or for using map/reduce operations? Why C/C++ or Java were not used? What are the advantages in using Javascript for such back-end work?

  • 3
    Javascript isn't only a browser scripting language. A few other applications embed Javascript or a similar language (e.g. ActionScript in Flash, along with Javascript for scripting a number of Adobe applications). I'm not certain, but maybe Javascript was never intended to only be embedded in web browsers. So... why not embed it in a back-end database application?
    – user8709
    Commented Nov 24, 2011 at 1:05
  • Since I've seen/read about JS running in browser, I wonder how is it run on server-side without opening a browser?
    – jeff musk
    Commented Nov 24, 2011 at 1:10
  • 1
    thanks. you are right. They are using SpiderMonkey compiler to do server-side JS part. en.wikipedia.org/wiki/SpiderMonkey_(JavaScript_engine) @Raynos pointed this out.
    – jeff musk
    Commented Nov 24, 2011 at 1:15
  • 6
    For that you'll need a javascript engine, like V8 and SpiderMonkey. There are quite a few uses for Javascript outside the browser, wikipedia has a long list.
    – yannis
    Commented Nov 24, 2011 at 1:19
  • Hmmm - my previous comment is accurate as a generalization, but for me to try to be more specific could be dangerous - I don't know anything about MongoDB or CouchDB. While there's no reason why a back-end database app. on a server can't have it's own browser-independent Javascript interpreter, I don't know whether that's how it's handled, and answers below suggest that it probably isn't.
    – user8709
    Commented Nov 24, 2011 at 1:19

6 Answers 6


Mobile code & Cross-platform

JavaScript is what called mobile code, the code is transported from the server (MongoDB and CouchDB in this case) to the client (the web browser) and executed on the client without an installation process.

JavaScript runtime environments (web browsers) are also widely available on many platforms. That makes JavaScript a good cross-platform language.

JavaScript is not used as primary back-end language

The MongoDB backend is implemented in C++ and the CouchDB is implemented in Erlang. So JavaScript is not used as the primary language for the backend for theses systems.

From mongodb.com:

Written in C++

From couchdb.apache.com:

CouchDB is written in Erlang, a robust functional programming language ideal for building concurrent distributed systems. Erlang allows for a flexible design that is easily scalable and readily extensible.

  • 1
    Thank you for your response. "CouchDB uses Javascript extensively including in the building of views". So why the client is a browser for back-end work such as building a view? For such a task, why is a browser coming into the picture.
    – jeff musk
    Commented Nov 24, 2011 at 0:51
  • @startup007: See the first part of my answer. Web-browsers are already installed on most systems today (e.g. Mac OS X, Windows, Linux, iPhone, Android), so the user doesn't need to install anything since web brosers can execute JavaScript (mobile code).
    – Jonas
    Commented Nov 24, 2011 at 0:53
  • I apologize for not getting it right away. Let me elaborate. So are these databases opening browsers on server-side to do some part of the task, and then returning JSON output?
    – jeff musk
    Commented Nov 24, 2011 at 0:56
  • 1
    Thanks Raynos! wiki on spidermonkey says- "MongoDB, another NoSQL database system uses SpiderMonkey for server-side JavaScript execution." en.wikipedia.org/wiki/SpiderMonkey_(JavaScript_engine) . hmm interesting
    – jeff musk
    Commented Nov 24, 2011 at 1:14
  • 5
    wrong, neither MongoDB nor CouchdB use the browser as a client. the database client is a library the app (commonly a webapp but could be any kind of application) uses to manage the data stored in the database. There's no browser in the picture. JavaScript is used as a data definition language (a superset of JSON), and also as the store-procedure language, it's executed in the database engine, not at the client, and certainly not in any browser.
    – Javier
    Commented Nov 24, 2011 at 2:04

Because JavaScript is a scripting language.

It's a flexible and dynamic language that's familiar to people.

The other reason JavaScript is used is because it aligns well with the JSON format that these databases use.

And finally these databases need a language that can be interpreted. Because the code for these queries is send over the network.

So you need an

  • dynamic
  • flexible
  • familiar
  • interpreted

language. I don't think JavaScript is a bad choice here. It's probably chosen for having C style syntax.

Now why JavaScript was chosen over another scripting language is a good question.

  • 3
    Now why JavaScript was chosen over another scripting language: I could speculate that it's because JavaScript is the most widely used scripting language, extremely well tested via its use on browsers, and there are quite a few excellent open source interpreter implementations. CouchDB uses uneval(), a hint that they've built their interpreter on top of SpiderMonkey.
    – yannis
    Commented Nov 24, 2011 at 1:06
  • Microsoft did support VBscript in client-side many years back but thankfully that never took off... Commented Jun 21, 2014 at 11:27

We will all have to eat humble-pie when we realize that JS is being used to write:

  • Databases

  • Servers

  • Operating System

  • and a myriad of libraries, frameworks, rendering engines, and compiling languages,

... because it is better.

Seriously, please... hear me out. Do not shoot the messenger.

Ask Microsoft why they are building Windows 8 with JS as a first class citizen. Or Mozilla's new mobile OS, or IBM's Rivertrail, PhoneGap, ExtJS, or WebGL.

Would any of these companies or projects have been successful if the experts did not find something better in implementation?

The answer is... They did. We did. So the theme here should be clear: there is a better way.

But, better is subjective: so we must drill-down and compare. What is better?

It started with AJAX... and it has not stopped.

  1. Non-Blocking IO. This is a really big deal and worth knowing. In JS this is the callback pattern. It turns out, using callbacks can enable a non-blocking server: Node.js ~ about 8 lines of code. setTimeout() is a callback. Single-threaded asynchronous processing.

  2. Flexibility. What? -Java and C have classes and interface, but are called object-oriented. JavaScript has only objects. But it is called ... something else.

    -Having objects-only is a nice thing for flexibility, because members and methods are fully dynamic at runtime. -Prototypal inheritance is not scary. Some experts describe it as an object-packpack. -JS is friendly on errors. -Code can mix together to result in Composite-Components, without much effort, or knowledge of... 'interfaces', 'abstraction', 'inheritance', 'encapsulation', 'polymorphism'. Good things, but like Nike, in JS; you just do it.

  3. Data-Translation. With JSON, objects can be transferred front-to-back, back-to-front. No XML data translations. JSON is clearly simple.

  4. Low learning curve. It is possible to cut and paste extremely complex code, then step-debug it into existence. I hear a colleague ... 'noobs'. But it is not just for noobs.

-It turns out that this is a really nice feature for Rapid Prototyping. And sites are popping up all over that leverage this design-in-browser thing, and more widely; runtime-prototyping. Checkout JSFiddle and CodePen, also MicroJS. GitHub.

Like Transformers, with JS, there is more than meets the eye.  

It is a big deal.

UPDATE: since this posting JavaScript is now used extensively by other languages.

In Java - check out Nashorn.
In C++ - check out Emscripten, or ASM.
And there are many more.

The big surprise since the original writing of this answer was JS cross-compilation.

It turns out that many languages can be compiled to JS.

And the community is encouraging that... CoffeeScript, Dart, etc.    

This is not my specific area of expertise, but it is going on in big ways.

Simply put, we just don't know how the dynamism of JS is going to hash out yet. 
  • Python can do all of those as well
    – Jonathan
    Commented Apr 28, 2015 at 20:23
  • @JonathanLeaders - all? :)
    – Jack Stone
    Commented Apr 29, 2015 at 20:22
  • 1
    @jonathan-leaders can Python run on a web browser?
    – Aaron C
    Commented Apr 8, 2018 at 4:21
  • You can do less with more - There are a couple schools on this. The verbosity school wants everything spelled out in super-fine detail that any idiot can understand. JS is a member of the opposite school where you can layer complexity such that it's easier to get the big picture before understanding how the finer details operate. It is much easier to write to an interface in JS than in most languages, IMO.

  • First class functions, closures, prototypal inheritance - It's a really, really flexible combo. We can imitate classes if we want. But that's seen as a somewhat pointless endeavor by those who understand JS really well. Compositing suits JS much better than chained inheritance.

  • Blocking is useful at a higher level. Yes, you heard me. It helps you keep the focus on the JS as messenger rather than the workhorse and processes pretty much queue themselves while allowing for interruptions from asynchronous behavior between function calls.

  • I would say the learning curve is actually a little bit steep for writing powerful JS but once you're there, it's a hoot. It's not at all hard to implement pre-baked stuff in JS at the lower skill level, however.


This question is a little dated but the reason to use JavaScript vs Java/C++ is that neither Java or C++ easily support code fragments.

Even if JavaScript was never invented, Java nor C++ would of been a good choice for Source Code Fragments that will execute on the server side. They would of picked another language or invented their own. Back in the day products used to create their own language, define their own production rules, AST, interpreter etc. that specialized in their domain.

But with JavaScript it is extremely easy to create a Domain Specific Language (DSL) for your product and embed the engine without having to worry about creating all the other non-domain related infrastructure.


Event driven programming model

JavaScript was created with an event driven non-shared-memory approach to computing. In UI development this is completely old hat. There is no assumption that your "application" is in control of a process. There is no process API. Nor is there a main function.

Your "application" is a collection of scripts that will be executed when a particular thing happens such as

  • the script is loaded in the browser
  • the html page loading reaches a certain point
  • on a particular user interaction with a given element

This matches quite well with the small chunks of processing logic needed for data transforms.

Scripting Language

Being able to execute without a compile stage means that processing instructions can be stored easily. You can save the script easily as text and pass it around without any special data types or knowledge.

Quite Simple, Stable and Backwards compatible

The code you write today isn't that much different from 10 years ago. Versioning isn't likely to be much of an issue for people embedding it.


There are several good open source engines out there with a ton of work put into them. It executes quite a bit faster than many alternatives.

Curly Braces

Many people are restricted in their comfort with a range of programming languages. They only know how to program Java or C# for instance. So they expect to learn JavaScript easily because it looks familiar. That is of course an illusion. When I learned Python it was at pretty much the same pace as learning JavaScript. Syntax is only emotionally significant assuming it isn't completely obscure.

Not the answer you're looking for? Browse other questions tagged or ask your own question.