I'm always open for critique, as long I can give it back :)
Yes, npm has a lot of modules, but the count is not really the metric that is valuable. There are several reasons why javascript has so many packages. First of all, JS does not have a standard library. This means, features that come bundled with Haskell/C/C++/and almost every other language have to come from an external (untrusted) source. The second reason is that many modules are basicly oneliners that you would normally not put in an external dependency (left-pad?). Speed is not so much an issue, especially with npm v5.
Even with blocking IO, a server written in C++ is still faster than an async node server (This is about websockets, but a similar comparison is also available for general HTTP connections with similar result, TL;DR only Ruby on Rails is slower than Node). Also that async dependencies don't work with others is not true, I worked with Asio (async IO for C++) and it is just another library that you use, it's not something that changes the language.
The single threaded callback model of nodejs makes programming harder actually, because you can make the same synchronization related programming errors normally happening only in a multithreaded environment also in a single threaded one. Additionally, closures in Javascript are very inefficient, so having a bunch of nested callbacks using the outer scopes can cripple performance. There are two ways how you can make your life easier. First, you could use blocking IO with something like C++. You also dont have concurrency, but you also dont have callbacks everywhere. Performance should be even if not better than node. The second way is using one thread per connection, this is what you would with languages like Haskell or Erlang implementing green threads. You simply write your code per client, and the runtime system scales it across as many cores as you want without using costly system threads.
With the interpreter, I meant that you first need a C++ compiler for your target platform, so you can compile V8 on it. Then you can use Javascript. But if you already have a C++ compiler, you can also use C++ directly. In fact, you can write Cross-platform apps (natively) with C++ and libraries like Qt.
The main reason for Javascript is the community not wanting to learn one or two new languages and try to put everything in their own. Everyone hypes about functional programming in Javascript, but just using lamda expressions or array map/reduce does not make your code "functional". In fact it is impossible to do real functional programming in Javascript, because the APIs are imperative. Also not having a strong type system lessens the benefit of functional programming. This and more are all symptoms of Javscripts own core weaknesses that you just can't fix, no matter how many new ESX versions you develop or how many libraries you publish on npm.
Node js, in my option has only one valid use case: server side rendering for the browser. If I had to recommend a stack, I would use Haskell with servant for the server, as writing a server with Haskell is really easy. A lot easier than you might think. The type system and the compiler/REPL guides you very well and you end up having a lot less code than with any other language. For the browser, I would use Purescript (with purescript-bridge to share the types with the backend). For native (desktop/mobile) applications you can intially use your purescript website with electron and later on develop real native applications with C++ or Haskell.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm always open for critique, as long I can give it back :)
Yes, npm has a lot of modules, but the count is not really the metric that is valuable. There are several reasons why javascript has so many packages. First of all, JS does not have a standard library. This means, features that come bundled with Haskell/C/C++/and almost every other language have to come from an external (untrusted) source. The second reason is that many modules are basicly oneliners that you would normally not put in an external dependency (left-pad?). Speed is not so much an issue, especially with npm v5.
Even with blocking IO, a server written in C++ is still faster than an async node server (This is about websockets, but a similar comparison is also available for general HTTP connections with similar result, TL;DR only Ruby on Rails is slower than Node). Also that async dependencies don't work with others is not true, I worked with Asio (async IO for C++) and it is just another library that you use, it's not something that changes the language.
The single threaded callback model of nodejs makes programming harder actually, because you can make the same synchronization related programming errors normally happening only in a multithreaded environment also in a single threaded one. Additionally, closures in Javascript are very inefficient, so having a bunch of nested callbacks using the outer scopes can cripple performance. There are two ways how you can make your life easier. First, you could use blocking IO with something like C++. You also dont have concurrency, but you also dont have callbacks everywhere. Performance should be even if not better than node. The second way is using one thread per connection, this is what you would with languages like Haskell or Erlang implementing green threads. You simply write your code per client, and the runtime system scales it across as many cores as you want without using costly system threads.
With the interpreter, I meant that you first need a C++ compiler for your target platform, so you can compile V8 on it. Then you can use Javascript. But if you already have a C++ compiler, you can also use C++ directly. In fact, you can write Cross-platform apps (natively) with C++ and libraries like Qt.
The main reason for Javascript is the community not wanting to learn one or two new languages and try to put everything in their own. Everyone hypes about functional programming in Javascript, but just using lamda expressions or array map/reduce does not make your code "functional". In fact it is impossible to do real functional programming in Javascript, because the APIs are imperative. Also not having a strong type system lessens the benefit of functional programming. This and more are all symptoms of Javscripts own core weaknesses that you just can't fix, no matter how many new ESX versions you develop or how many libraries you publish on npm.
Node js, in my option has only one valid use case: server side rendering for the browser. If I had to recommend a stack, I would use Haskell with servant for the server, as writing a server with Haskell is really easy. A lot easier than you might think. The type system and the compiler/REPL guides you very well and you end up having a lot less code than with any other language. For the browser, I would use Purescript (with purescript-bridge to share the types with the backend). For native (desktop/mobile) applications you can intially use your purescript website with electron and later on develop real native applications with C++ or Haskell.