Take the 2-minute tour ×

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?

share|improve this question
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? –  Steve314 Nov 24 '11 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 Nov 24 '11 at 1:10
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 Nov 24 '11 at 1:15
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 Rizos Nov 24 '11 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. –  Steve314 Nov 24 '11 at 1:19

5 Answers 5

up vote 11 down vote accepted

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:


share|improve this answer
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 Nov 24 '11 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 Nov 24 '11 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 Nov 24 '11 at 0:56
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 Nov 24 '11 at 1:14
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 Nov 24 '11 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.

share|improve this answer
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 Rizos Nov 24 '11 at 1:06
Thank you Raynos and Yannis! –  jeff musk Nov 24 '11 at 1:08
Microsoft did support VBscript in client-side many years back but thankfully that never took off... –  Mark K Cowan Jun 21 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.

I Hope that helps.

share|improve this answer
+1, good list of advantages. –  Emmad Kareem Aug 13 '12 at 23:43

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.

share|improve this answer
  • 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.

share|improve this answer

Your Answer


