First, thank you very much for your comment, you have highlighted several interesting points. In response to your first argument, I do understand that, of course, other languages have package managers, libraries, and frameworks. My response to this is that while it is that even if package managers are better-integrated none of them can really compare to the number of modules/packages NPM has to offer. If the issue with NPM is speed, Yarn can fix that. With your next group of points I do admit that you are correct that NodeJS that it is single-threaded, however, I will counter with the fact that it is non-io blocking (meaning multiple actions can be going at once on a single thread). It is true that many other languages have dependencies available for this functionality, however, that in most cases make other dependencies not work. As well, I would like to mention that I do agree that JavaScript shouldn't be used for everything which is why I included my last paragraph (ex. JavaScript would be a real cruddy choice for machine learning). As far as interpreter go, #1, if you want to make one for a language that doesn't have one the learning curve is very steep. #2, even if a compiler for that language did exist, at the current time, javascript does appear to be the only language that can deploy to Android, iOS, Windows, Mac, and the web without modifying too much code, and I never mentioned anything about native running apps. Often times this option would be better as it allows small teams to easily be able to get fully functional, albeit, not native apps, based off technologies that many web developers already know. Many companies including Discord, Slack, Atom, and even Microsoft with Visual Studio Code. agree with this view as they do use non-native Electron to power their desktop apps (source). While you can do this with interpreters, it is much easier and more efficient for small teams to use Electron in many use cases. As far as your view of WebAssembly, I do agree it would be awesome to use languages other than JS for client side scripting, however, JavaScript is here to stay. With the sheer community behind it, not to mention libraries and frameworks like React.js, Vue.js, and jQuery (an old library, but very useful). These all help to make it easier and easier to make epic web apps with JavaScript. With all this in mind, I believe it is unlikely that will change.
I do apologize for the long response, however, I wanted to make sure I addressed everything that you had mentioned. Thank you again for the comment.
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.
First, thank you very much for your comment, you have highlighted several interesting points. In response to your first argument, I do understand that, of course, other languages have package managers, libraries, and frameworks. My response to this is that while it is that even if package managers are better-integrated none of them can really compare to the number of modules/packages NPM has to offer. If the issue with NPM is speed, Yarn can fix that. With your next group of points I do admit that you are correct that NodeJS that it is single-threaded, however, I will counter with the fact that it is non-io blocking (meaning multiple actions can be going at once on a single thread). It is true that many other languages have dependencies available for this functionality, however, that in most cases make other dependencies not work. As well, I would like to mention that I do agree that JavaScript shouldn't be used for everything which is why I included my last paragraph (ex. JavaScript would be a real cruddy choice for machine learning). As far as interpreter go, #1, if you want to make one for a language that doesn't have one the learning curve is very steep. #2, even if a compiler for that language did exist, at the current time, javascript does appear to be the only language that can deploy to Android, iOS, Windows, Mac, and the web without modifying too much code, and I never mentioned anything about native running apps. Often times this option would be better as it allows small teams to easily be able to get fully functional, albeit, not native apps, based off technologies that many web developers already know. Many companies including Discord, Slack, Atom, and even Microsoft with Visual Studio Code. agree with this view as they do use non-native Electron to power their desktop apps (source). While you can do this with interpreters, it is much easier and more efficient for small teams to use Electron in many use cases. As far as your view of WebAssembly, I do agree it would be awesome to use languages other than JS for client side scripting, however, JavaScript is here to stay. With the sheer community behind it, not to mention libraries and frameworks like React.js, Vue.js, and jQuery (an old library, but very useful). These all help to make it easier and easier to make epic web apps with JavaScript. With all this in mind, I believe it is unlikely that will change.
I do apologize for the long response, however, I wanted to make sure I addressed everything that you had mentioned. Thank you again for the comment.
-Matt
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.