> 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.
...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.