5 ms·

I've been using Node.js for 4 years now and it's my favourite runtime (I've been programming for 13 years). I have a broad background with experience in Java,

I've been using Node.js for 4 years now and it's my favourite runtime (I've been programming for 13 years). I have a broad background with experience in Java, C/C++, Python and I've done AVR microcontroller programming in assembly and C so I know what I'm talking about. I've found that most people who complain about Node.js tend to lack experience. I think it's one of the best runtimes/languages for building web applications - In the same league as Tornado (Python) and Go. Personally, I like it more than the others because I like JavaScript and it makes it easy to context switch between frontend and backend work. People who have a background in statically typed languages tend to dislike JavaScript because it gives you more flexibility (and more ways to introduce issues into your app if you're not careful). If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning Node.js.

kitd 10y ago
Node is ok, JS is (more or less) ok. The bit I really don't like though is NPM and the horrendous package bloat that it encourages.
- oAlbe 10y ago
  > NPM And the security risks coming with it.
mi100hael 10y ago
- Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today. - Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript. - NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline. - The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck. - A community with the attention span of a goldfish - Scaling is a pain in the ass. I've found that most people who think Node.js is a good platform lack experience. If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning literally anything other than Node.js. For a HTTP server, try Python+Flask, Ruby+Sinatra, Go+Gorilla,Gin,Goji,etc., Scala+Akka-HTTP, Java+Dropwizard, C#+Nancy, C+libonion, ...
- ralusek 10y ago
  The second anybody mentions callback hell, I know for certain that they have never come close to seriously developing in Node. Callback Hell is completely negated by using promises, which any developer who seriously works with Node is already doing. Doing a series of asynchronous tasks would at WORST look like this using promises: http://paste.ofcode.org/Nx2infQQ2aESNxxiwJC7cN http://paste.ofcode.org/Nx2infQQ2aESNxxiwJC7cN Javascript lacks static typing in the same way that Python and Ruby do. If you want static typing, TypeScript is stronger than any tool that exists for either of those languages. Good luck developing offline? What are you talking about? Over engineered UI frameworks...what does this have to do with NodeJS applications. Most server applications these days have absolutely nothing to do with the UI whatsoever. Scaling is a pain in the ass? How do you figure? The entire concept of scaling in NodeJS is based off of replication in a cluster, it could not be easier to scale. You linearly add more instances of your application to a cluster of infinite scale.
  - thinkpad20 10y ago
    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.
ben_jones 10y ago
I think the problem is with the javascript mentality and not the language or runtime. Simply put you don't put time into fully understanding the problems and implications of a particular implementation, you either download a third party library off npm with minimal inspection (which pulls in a dozen other libraries that get NO inspection) or you write a new library with what you think is a solid test suite but because it is a new library by its very virtue it is not battle tested in any way shape or form. Compounding these observations together you get an environment where you don't know what's going on which is something many developers wish to avoid at all costs when building large, complex, high-performance/scalability, systems.

kitd 10y ago

Node is ok, JS is (more or less) ok. The bit I really don't like though is NPM and the horrendous package bloat that it encourages.

oAlbe 10y ago
> NPM And the security risks coming with it.

mi100hael 10y ago

- Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today. - Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript. - NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline. - The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck. - A community with the attention span of a goldfish - Scaling is a pain in the ass. I've found that most people who think Node.js is a good platform lack experience. If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning literally anything other than Node.js. For a HTTP server, try Python+Flask, Ruby+Sinatra, Go+Gorilla,Gin,Goji,etc., Scala+Akka-HTTP, Java+Dropwizard, C#+Nancy, C+libonion, ...

ralusek 10y ago
The second anybody mentions callback hell, I know for certain that they have never come close to seriously developing in Node. Callback Hell is completely negated by using promises, which any developer who seriously works with Node is already doing. Doing a series of asynchronous tasks would at WORST look like this using promises: http://paste.ofcode.org/Nx2infQQ2aESNxxiwJC7cN http://paste.ofcode.org/Nx2infQQ2aESNxxiwJC7cN Javascript lacks static typing in the same way that Python and Ruby do. If you want static typing, TypeScript is stronger than any tool that exists for either of those languages. Good luck developing offline? What are you talking about? Over engineered UI frameworks...what does this have to do with NodeJS applications. Most server applications these days have absolutely nothing to do with the UI whatsoever. Scaling is a pain in the ass? How do you figure? The entire concept of scaling in NodeJS is based off of replication in a cluster, it could not be easier to scale. You linearly add more instances of your application to a cluster of infinite scale.
- thinkpad20 10y ago
  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.

ben_jones 10y ago

I think the problem is with the javascript mentality and not the language or runtime. Simply put you don't put time into fully understanding the problems and implications of a particular implementation, you either download a third party library off npm with minimal inspection (which pulls in a dozen other libraries that get NO inspection) or you write a new library with what you think is a solid test suite but because it is a new library by its very virtue it is not battle tested in any way shape or form. Compounding these observations together you get an environment where you don't know what's going on which is something many developers wish to avoid at all costs when building large, complex, high-performance/scalability, systems.