JavaScript Dates – Why Does JavaScript Treat Days and Months Differently?

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.

I'm going to make an argument for ==

Douglas Crockford which you cited is known for his many and often very useful opinions. While I'm with Crockford in this particular case it's worth mentioning it is not the only opinion. There are others like language creator Brendan Eich who don't see the big problem with ==. The argument goes a little like the following:

JavaScript is a behaviorally* typed language. Things are treated based on what they can do and not their actual type. This is why you can call an array's .map method on a NodeList or on a jQuery selection set. It's also why you can do 3 - "5" and get something meaningful back - because "5" can act like a number.

When you perform a == equality you are comparing the contents of a variable rather than its type. Here are some cases where this is useful:

• Reading a number from the user - read the .value of an input element in the DOM? No problem! You don't have to start casting it or worrying about its type - you can == it right away to numbers and get something meaningful back.
• Need to check for the "existence" of a declared variable? - you can == null it since behaviorally null represents there is nothing there and undefined doesn't have anything there either.
• Need to check if you got meaningful input from a user? - check if the input is false with the == argument, it will treat cases the user has entered nothing or just white-space for you which is probably what you need.

Let's look at Crockford's examples and explain them behaviorally:

'' == '0'           // got input from user vs. didn't get input - so false
0 == ''             // number representing empty and string representing empty - so true
0 == '0'            // these both behave as the number 0 when added to numbers - so true    
false == 'false'    // false vs got input from user which is truthy - so false
false == '0'        // both can substitute for 0 as numbers - so again true

false == undefined  // having nothing is not the same as having a false value - so false
false == null       // having empty is not the same as having a false value - so false
null == undefined   // both don't represent a value - so true

' \t\r\n ' == 0     // didn't get meaningful input from user vs falsey number - true 

Basically, == is designed to work based on how primitives behave in JavaScript, not based on what they are. While I don't personally agree with this point of view there is definitely merit in doing it - especially if you take this paradigm of treating types based on behavior language-wide.

^{* some might prefer the name structural typing which is more common but there is a difference - not really interested in discussing the difference here.}