5 ms·

Nodejs is an excellent tool for front-end integration testing and asset pipelines that depend on js(LESS,coffeescript,babel and co). On the other, on the server

by aikah 11y ago

Nodejs is an excellent tool for front-end integration testing and asset pipelines that depend on js(LESS,coffeescript,babel and co). On the other, on the server, you can read many stories of startup that started with NodeJs and ended up with Go. NodeJs doesn't have any concurrency capability. Sure you can fork, but then you need a message queue for interprocess communication. And frankly while javascript's getting better, some people are a bit sick of dynamically typed languages and prefer static typed languages. How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable.

LocalPCGuy 11y ago
> How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable. If written correctly, neither of those questions should be an issue. 1) JS devs shouldn't have "large" JavaScript source files, like most good programs, they should be broken into small, concise pieces. 2) JS devs shouldn't use "ninja tricks" or other BS, they should write for the next person that reads the code, again, like any language. Yes, a lot of people still write bad JavaScript, but that is on them, not the language. It is pretty simple to write bery readable JavaScript if you so choose.
- WorldWideWayne 11y ago
  The language and the environment are certainly at fault to a high degree due to the lack of standards. 1) Breaking JS up into small files actually makes it less readable because then you have to guess at the context that the JS is running in. Without static typing, it's impossible to reason about certain blocks of code without going to find blocks of code that exist in other files and so on... 2) JS devs have to use ninja tricks because without a strong standard library they have to keep reinventing the wheels that should have been included. There is no standard for how to write readable Javascript and there is too much flexibility. Isaacs, of Node.js fame, writes horribly unreadable code IMO due to the fact that he does not use semi-colons and he tends to put punctuation on the left. However, he swears by the fact that it's more readable...to him.
bryanlarsen 11y ago
It is Node.js's concurrency capabilities that are one of it's core strengths. There are very few other frameworks that can handle tens of thousands of simultaneous requests as well as Node can. In other framework that's tens of thousands of threads; in Node you can have tens of thousands of requests all blocked on I/O using a single thread.
- ngrilly 11y ago
  That's absolutely not a specificity of Node.js. You can handle tens of thousands of simultaneous requests as well, and sometimes even better, in Go, Erlang, Stackless Python, Python 2 with Tornado or gevent, Python 3 with asyncio, Haskell, Java with vert.x or Quasar, nginx with Lua, and many other examples. Node.js is an interesting and useful solution to some problems, but please stop the repeating this unfounded marketing claim.

by aikah 11y ago

LocalPCGuy 11y ago

> How many people can go read a large JS source file and make sense of what is happening quickly? not a lot, in comparison, Go is easy to read,there is no "ninja trick" or metaprogramming stunts that makes code unreadable. If written correctly, neither of those questions should be an issue. 1) JS devs shouldn't have "large" JavaScript source files, like most good programs, they should be broken into small, concise pieces. 2) JS devs shouldn't use "ninja tricks" or other BS, they should write for the next person that reads the code, again, like any language. Yes, a lot of people still write bad JavaScript, but that is on them, not the language. It is pretty simple to write bery readable JavaScript if you so choose.

WorldWideWayne 11y ago
The language and the environment are certainly at fault to a high degree due to the lack of standards. 1) Breaking JS up into small files actually makes it less readable because then you have to guess at the context that the JS is running in. Without static typing, it's impossible to reason about certain blocks of code without going to find blocks of code that exist in other files and so on... 2) JS devs have to use ninja tricks because without a strong standard library they have to keep reinventing the wheels that should have been included. There is no standard for how to write readable Javascript and there is too much flexibility. Isaacs, of Node.js fame, writes horribly unreadable code IMO due to the fact that he does not use semi-colons and he tends to put punctuation on the left. However, he swears by the fact that it's more readable...to him.

bryanlarsen 11y ago

It is Node.js's concurrency capabilities that are one of it's core strengths. There are very few other frameworks that can handle tens of thousands of simultaneous requests as well as Node can. In other framework that's tens of thousands of threads; in Node you can have tens of thousands of requests all blocked on I/O using a single thread.

ngrilly 11y ago
That's absolutely not a specificity of Node.js. You can handle tens of thousands of simultaneous requests as well, and sometimes even better, in Go, Erlang, Stackless Python, Python 2 with Tornado or gevent, Python 3 with asyncio, Haskell, Java with vert.x or Quasar, nginx with Lua, and many other examples. Node.js is an interesting and useful solution to some problems, but please stop the repeating this unfounded marketing claim.