JavaScript is a shit language: Fuck off.
Wow, good argument. BTW, my office mate was at Netscape when Javascript was created. The author of Javascript has since apologized for creating Javascript. In his defense, it was only ever intended to run one line bits of logic inside of a web page. Ideas like functions actually had to be added later as the idea of using Javascript for a general purpose language came after the language was designed, not before. See how this leads to problems?
Javascript isn't and shouldn't be used as a general purpose language, EVER! It has uses but very few in general and they probably all have to do with browsers and DOMs.
JavaScript is not strongly-typed: Since when did strongly-typed languages become "better"?
Um, since math has existed? Compilers double as automated code error checkers. Or maybe you like checking your code's syntax by hand?
JavaScript is insecure: You're doing it wrong.
Javascript forces clients to execute general logic. This is a security issue no matter what. I'm sure you have some solution to this issue, but I assure you that there are ways around your solution (and anyone else's solution).
Node.js is single-threaded: OK, were you planning on serving clients with a single server instance/process?
Javascript is single threaded, this is OK for writing web apps, sometimes. But not always and its a huge hole in a general purpose language.
A single language client- and server-side offers little to no benefits: Yeah, you're right. Why would I want to a single test suite for my client- and server-side code? Why would I want to (securely) share model definitions between the client- and server-side? Why would I want to optimise one code-base instead of two? Why would I want to debug one language instead of two?
You finally make a good point. +1 for you.
MongoDB is for people who can't/won't learn SQL/the relational model: I'll admit that SQL is not my area of expertise, but my naive understanding is this: in SQL databases, you normalise your data by default until you hit performance issues. In NoSQL databases, you denormalise it by default. The decision on which one to use should depend entirely on the data you want to store.
Take it from me, you know NOTHING about data persistence no matter how much you think you do. Relational Algebra is the basic math governing manipulating, querying and storing data as tuples. It governs MongoDB (and other NoSQL tools) too, just that the authors of those systems basically lopped off all the hard parts of the relational algebra and implemented just the easy bits. And they did those parts quite poorly when compared to traditional RDBMSes.
NoSQL was an attempt to re-invent a very complex wheel that 1) already worked, and 2) the often didn't let you do things that were bad ideas (even if you didn't realize they were bad ideas at the time). SQL isn't perfect, but more people know it than HTML and Javascript combined. And the systems that implement SQL have reputations (and a history) of not losing data (well, as long as the hardware works) and allowing very large datasets to be queried. And before someone says something dumb like "Web Scale", Sharded DBs store and query some very large datasets. Only when you have datasets the size of google's do you have to implement your own. And they made BigTable so fast by not implementing things that DBs need but they didn't (like data consistency and joins). It might be nice for a RDBMS to allow you to choose to not use table locks or do other things to make these trade-offs. But RDBMSes evolved in a world where throwing hardware at problems was always a valid strategy and it probably still is and will be into the foreseeable future.
Different problems require different solutions. In some cases, JavaScript all the way through might be a good fit. Most of the time, it won't be.
You got a point there. However, it seems that lately this rule isn't understood by those that parrot it.