3 ms·

I'm using NodeJS on a pretty big project. Things I like: * Async libraries make it easy to make things high performance. * I like Sequelize as an ORM, once I

I'm using NodeJS on a pretty big project. Things I like: * Async libraries make it easy to make things high performance. * I like Sequelize as an ORM, once I figured out how the async everything works. * The testing support is pretty good, both mocha and e2e testing using selenium * The angular-fullstack generator was really helpful for getting started and setting up the deploy to Heroku. * everything is open source. If I get confused with what a library is doing while I'm debugging I can just stick a print in the lib temporarily. Things I don't like: * "undefined is not a function". When something goes wrong. This is the error I get 80% of the time. * async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere * There's a bit of a learning curve with promises. * Needs a lot more automated testing than a really strongly typed language like Scala. * Single Threaded. I know how to program using threads, so I view this as a disadvantage. * No types. I have a lot of type checking asserts at the beginning of dao functions. If I did it all again and my teammates would oblige, I would have probably chosen Play/Scala. I actually reimplemnted things from a Play/Scala project I did a while back (login/signup/forgot password/confirm account) and it took less time in Play/Scala, even without passportJS and friends. I have about a years worth of experience learning Scala before I started that project, so it would probably take longer for a new Scala developer.

rhinoceraptor 11y ago
> async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere Huh? That's not how async errors work in Node. Try/Catch is not async, the catch block will not magically transfer to your callback function. You check for the error as the first parameter in your callback, that's the standard way of error handling. Throwing errors in Node is considered by most to be an anti-pattern.
- narrator 11y ago
  That's nice in theory, but third party libraries may throw exceptions if unexpected things happen at runtime. You'd still have to put the try catch block there and call the callback in the catch block everywhere.
  - rhinoceraptor 11y ago
    That's only for non-async stuff, which is very rare. If you're using some wacky 3rd party code which throws an Error instead of the accepted convention of (err, response) callback arguments (or returning a promise), I suggest not using it.
neckro23 11y ago
> * async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere There's no need for that: process.on('unhandledRejection', err => console.trace(err))
dietrichepp 11y ago
The async stuff is not really any better performing than e.g. async in C#, which is mature, easy to debug, and has been around a while. I don't know why people keep saying node.js is "high performance", the numbers I've seen basically put it in the same ballpark as similarly architected apps in other languages, as long as the other language has a reasonably performant toolchain. Perhaps people are used to old Ruby on Rails performance problems?
spriggan3 11y ago
> * I like Sequelize as an ORM, once I figured out how the async everything works. Sequelize is painfully slow unfortunately, I don't mean a bit slow like most ORMs I mean really really slow. It shouldn't be used in production.
- bschwindHN 11y ago
  Not to mention it's flaky on even producing correct queries. Sequelize was hell for me and I'm glad to not be using it anymore.

rhinoceraptor 11y ago

> async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere Huh? That's not how async errors work in Node. Try/Catch is not async, the catch block will not magically transfer to your callback function. You check for the error as the first parameter in your callback, that's the standard way of error handling. Throwing errors in Node is considered by most to be an anti-pattern.

narrator 11y ago
That's nice in theory, but third party libraries may throw exceptions if unexpected things happen at runtime. You'd still have to put the try catch block there and call the callback in the catch block everywhere.
- rhinoceraptor 11y ago
  That's only for non-async stuff, which is very rare. If you're using some wacky 3rd party code which throws an Error instead of the accepted convention of (err, response) callback arguments (or returning a promise), I suggest not using it.

neckro23 11y ago

> * async stuff silently swallows exceptions unless I put try{} catch(err) { console.trace(err) } everywhere There's no need for that: process.on('unhandledRejection', err => console.trace(err))

dietrichepp 11y ago

The async stuff is not really any better performing than e.g. async in C#, which is mature, easy to debug, and has been around a while. I don't know why people keep saying node.js is "high performance", the numbers I've seen basically put it in the same ballpark as similarly architected apps in other languages, as long as the other language has a reasonably performant toolchain. Perhaps people are used to old Ruby on Rails performance problems?

spriggan3 11y ago

> * I like Sequelize as an ORM, once I figured out how the async everything works. Sequelize is painfully slow unfortunately, I don't mean a bit slow like most ORMs I mean really really slow. It shouldn't be used in production.

bschwindHN 11y ago
Not to mention it's flaky on even producing correct queries. Sequelize was hell for me and I'm glad to not be using it anymore.