If you want scaling, NodeJS is probably not the best choice.

Even tho it may be based of replication in a cluster, Go and most HTTP Framework it uses are trimmed for microservice clustering, concurrency and safety.

The standard library already includes most things you need for making simple webservers, including a generic SQL interface, HTTP and HTTPS framework, cryptographic functions, inter-machine communication protocols like RPC, JSON and XML en and decode, fairly good logging framework and finally a very expressive templating system that can hold it's own against a lot of other templating systems.

Go comes with batteries included. All this compiles in under 10 seconds on my machine. It also compiles without any dependencies except the stdlibc, so it runs basically everywhere you have a target binary format for and ported the stdlibc too (and os-specific libraries if used). Thanks to newer developments it even runs on "baremetal" VMs with only a stub hypervisor kernel for management.

Bigger files for a portability that runs circles around NodeJs.

On NodeJs that's probably a couple dozen packages. I'm currently developing something using Node and I have about 570 packages (only top level) in my nodes_modules folder from a default ember.js setup. It actually breaks my system after a few minutes to use live reload due to the sheer number of files in there.

All Go libraries I have installed consume are only 9700 files, including binaries, personal pet projects and various "try-and-forget" libraries. The single nodejs app I develop has 45000 files only in the node_modules folder, and I stopped counting my project after 96000 files (after ls failed to enumerate the tmp folder within a few minutes)

Scaling? Go or Erland wins by miles with time to spare. NodeJs is struggling downhill.

Is it called node because of its inode usage?! Jokes aside, it's just crazy how big node_modules can become for a simple app! I was kind of surprise the first time I got a "no space left on device" error and df shows < 50% of usage :/

Promises introduce their own pain points. In particular, promise-laden code can be very confusing and difficult to read, especially for those who only need to look at it sometimes (like me). Error handling in promises is strange and often a promise chain will "succeed" even if an internal function failed, because the implementor forgot to put in a `.catch()`. Promise chains also make stack traces either nonexistent or illegible. Furthermore many promises are created by "promisifying" an async function with callbacks, which once again reduces readability. Also if you try to use something which isn't a promise inside of a chain, you get silly errors like ".next() is not a function" or whatever.

Python and JavaScript are both dynamically typed, but python's type system is much better thought out, easy to understand and leads itself to mostly robust code with error messages that make sense. JavaScript's type system is the Wild West with prototype inheritance, no classes (how do I tell what type this object is? Maybe I could use `typeof`, one of the most pathetic duck typing tools one can imagine...), nonsensical operators ("1" + 2, ===, etc), both "null" and "undefined" (really?). Also one of the worst design decisions, which was to have accessing a non-existent attribute just return `undefined` rather than throw an error, or that the number of function arguments isn't checked in JavaScript. These two things account for tons of "undefined is not a function" and similar errors that have probably cost developers combined centuries of time debugging.

Let's not forget that Python has a huge and incredibly useful standard library while JavaScript's is almost non-existent, which is one of the factors leading to the ballooning dependency trees for npm packages.

Advocating TypeScript is besides the point. It's a different language; you can't argue in favor of JavaScript if you're telling people to use a different language. Not to mention that TypeScript has its own issues.

I don't have many responses to the other points because I'm not familiar, but I would set myself on fire rather than write full-time in JavaScript.

I've read both sides of these arguments everywhere, leading me to believe both sides must hold some degree of truth. The problem with these "arguments" is they are mostly from experience. It's difficult to argue with experiences which are true if they happened. The bottom-line is node has the capacity to be awesome and to suck. The only option is to find out where you and your project fall after trying node for yourself, but if one thing is for certain, node will do better focusing on minimizing bad experiences no matter how they happen. Now most new frameworks recruiting users begin their pitch with promising a better experience (than node).

> Doing a series of asynchronous tasks would at WORST look like this

...that paste is still pretty close to callback hell. Spend a month working with Scala Futures and then tell me you want to go back to chaining a bunch of .then()s.

> Javascript lacks static typing in the same way that Python and Ruby do.

I'm aware of the lack of static typing in the other languages which is why I said "ignoring the fact..." The point is that JavaScript still sucks more which is why things like TypeScript and CoffeeScript even exist. There are too many gotchas even for basic operations like 'if (typeof(foo) === "undefined")' vs 'if (foo === null)' vs 'if (foo == null)'.

> Good luck developing offline? What are you talking about?

NPM was written with the assumption that the user would have an active internet connection and the application would be packaged in the same environment in which it would be run, like someone might build for a small project with a basic manual deployment. I ran into a real-world issue attempting to distribute a Node.js application to customers who would then run it in an air-gapped environment on a platform over which I had no control. (Trivial for Java, C/C++, C#, etc). There was no way to pre-package dependency sources and then run the compilation step as a part of the installation to ensure they were built for the right architecture against the available system libraries. These days there are a few tools like npmbox, but they are poor band-aids.

> Over engineered UI frameworks...what does this have to do with NodeJS applications.

Not sure why you're surprised by this. Redux and Electron are both pretty common use-cases for Node these days. It's not uncommon to be subjected to the torture of grunt/gulp/bower along with NPM.

> Scaling is a pain in the ass? How do you figure?

Scaling has gotten better recently, but servers like Unicorn/Gunicorn that don't require any code modifications or manual process management to scale worker processes on a single box are preferable IMO.

> NPM was written with the assumption that the user would have an active internet connection and the application would be packaged in the same environment in which it would be run, like someone might build for a small project with a basic manual deployment. I ran into a real-world issue attempting to distribute a Node.js application to customers who would then run it in an air-gapped environment on a platform over which I had no control. (Trivial for Java, C/C++, C#, etc). There was no way to pre-package dependency sources and then run the compilation step as a part of the installation to ensure they were built for the right architecture against the available system libraries. These days there are a few tools like npmbox, but they are poor band-aids.

You can use `file:` in your `package.json` to point to your dependencies too if you don't have Internet connection. Also, there's nothing stopping you from including `node_modules` in your project. In fact you can just copy/paste the node packages from one machine to another and have it be portable unless it's a native module.

Checking in node_modules has the same problem as copy/pasting for native modules (on which I was relying, hence the compilation issues). Using file: is a better solution that wasn't around when I first encountered this solution, but still has the problem of requiring you to manually manage every dependency (which can grow to obnoxious proportions in Node). There's no clear way to create the equivalent package of a fat shaded JAR or a statically linked binary.

>at WORST look like this using promises: http://paste.ofcode.org/Nx2infQQ2aESNxxiwJC7cN

I'm sorry but I can't see how it is good-looking code. In my opinion this piece should look like this:

    var dbResource = fetchDbResource(query);
    var serviceResponse = callSomeAsyncService();
    var otherService = callSomeOtherAsyncService();