I train enterprise node.js for a living. My recommendation is to just use songbird (which exposes the forthcoming promise API from core, built on bluebird), async/await and the async `trycatch` library so you don't have to worry about a 3rd party package's choice of asynchrony. It also comes with optional long stack traces.
>async/await in my experience, async/await is a great way to layer indirection and obfuscation over what is still callback hell. it may look better in the editor, but it's hell to debug.
After a year of using Node.js in production
41–50 of 248 posts
Re: After a year of using Node.js in production
#42Very well-designed and thought-out, fast, productive. Leans functional and immutable rather than object-oriented and mutable. It's kind of like Rails but without most of the problems.
Re: After a year of using Node.js in production
#43Re: After a year of using Node.js in production
#44We switched our backend from Python to Node almost 2 years ago now and it was a great decision for us. If you handle a code base that deals with a lot of async requests Node is definitely a top contender.
Re: After a year of using Node.js in production
#45> Coming from other languages such as Python, Ruby or PHP you’d expect throwing and catching errors, or even returning an error from a function would be a straightforward way of handling errors. Not so with Node. Instead, you get to pass your errors around in your callbacks (or promises) - thats right, no throwing of exceptions. Promises let you throw errors normally. They will propagate up the call stack in a simila…
I gave a talk about handling errors in Node a few years ago: https://github.com/pjungwir/node-errors-talk At the time the solution was "use domains", but I think domains are deprecated now. It was painful enough that I have stuck with Rails since then. I'm glad to hear that Promises are an improvement!
Re: After a year of using Node.js in production
#46For web applications, I've been very happy with the up-and-coming Phoenix[0], a framework for the Elixir language. Very well-designed and thought-out, fast, productive. Leans functional and immutable rather than object-oriented and mutable. It's kind of like Rails but without most of the problems. [0] http://www.phoenixframework.org/
Re: After a year of using Node.js in production
#47I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…
Re: After a year of using Node.js in production
#48> You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts! Although couched as a criticism this is actually the community fixing itself. The evolution from Grunt > Gulp > npm scripts is movement away from needless complexity towards simplicity. Npm scripts are effectively just Bash commands that build and manage your project, which sometimes employ small, unixy tools written in Node. This self correction…
https://twitter.com/sindresorhus/status/724259780676575232?l...
https://github.com/ReactiveX/rxjs/blob/a3ec89605a24a6f54e577...
Already people are coming up with new "solutions" to this problem that looks more like Grunt. It's a repetitive circle. Personally I just use Make.
Re: After a year of using Node.js in production
#49Re: After a year of using Node.js in production
#50I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…
Yes, I too find callbacks an obstacle to readability, among other things. If one uses mongodb (popular on node.js), and one needs multiple queries to 'join' several documents, the cascade of callbacks is an obstacle to readability, let alone debugging.
I'm not calling it a Panacea but Promises are idiomatic Node Javascript now and there's almost no reason for mutliple levels of nested callbacks anymore.