Live data from Hacker News

Node v7.5.0 Released

github.com

91–100 of 142 posts

Re: Node v7.5.0 Released

#91
post #56
post #36

Earlier quoted context omitted.

I highly recommend against using that library - it encourages a lot of callback hell we've found at my company, and it is much harder to create nice reusable functions with it vs. promises. bluebird is a wholly superior library for handling async flow.

> it encourages a lot of callback hell we've found at my company This is a very odd comment. async provides the same level of indentation as Promises does: async.waterfall([ function(){}, function(){}, ]) Here's promises doing the same thing: function() .then(function(){}) .then(function(){}) One's a list of functions to be run in order, the other uses method chaining. You may prefer one or the other but saying async…

Yea but when using promises with async/await its very beautiful.

    await asyncFuncOne();
    await asyncFuncTwo();
No more weird water-falling, and finally proper exception handling. The only gotcha is the fact that we cant awaits at the root of a module, and we need to wrap it in a async function.

Re: Node v7.5.0 Released

#92
post #86

I don't keep up with node end ES version compliance but is there a scheduled release that'll target all ES6 features?

Strictly speaking, tail call optimization is an ES6 feature. I had the impression that its implementation in V8 is on hold, so it might be a while.

Re: Node v7.5.0 Released

#93

Earlier quoted context omitted.

So much of the promise-based code I see looks almost the same as it would with plain callbacks, just with the callbacks plopped into .then(). Am I missing something? How do promises make for more reusable functions?

Chaining and returning can keep things nice and neat. Say you are following a Controller -> Service -> Repo implementation. Controller calls the service. Service returns a call to a repo with any mapping that needs to occur. Repo calls out to database or external api and returns the promise. Makes the work very boring and repetitive for the most part which is a good thing I think. function someController(req, res) {…

It's trivial to refactor that code to use only callbacks, without ending up with callback hell.

You certainly want to call UserService.getUser for many different controllers. Why manually do that for each controller? Simply make a middleware to get the user.

If you take this to its logical conclusion, you end up with small, composable middleware functions, and controllers that are pure functions.

Re: Node v7.5.0 Released

#94
post #19
post #3

There is a lot to like about Node. I had a look a couple of years ago but lack of a definitive library to handle callback hell put me off. How is the situation these days?

The Koa web framework built by the guys behind Express is pretty neat. You can do stack like calls with it, rather than callbacks, via generator functions. Not sure what the uptake is like but you can find more at http://koajs.com .

Have they fixed the middleware graveyard? When I last used it, I found it insanely difficult to pick the correct middlewares due to the changes between versions.

Re: Node v7.5.0 Released

#95

Earlier quoted context omitted.

Automatic promisification and the disposer pattern are both Bluebird-specific features that native ES6 promises don't support, so you'll have to continue using Bluebird if you rely on them. However, promises returned by Promises/A+ compliant libraries -- and this includes native ES6 promises -- are interoperable with each other. That means you can mix Bluebird promises with native promises for the most part . E.g, pa…

Native promises and bluebird use different microtask queues on Node which makes interop incorrect (which is also one of the reasons why bluebird is ES6 spec non compliant). See https://gist.github.com/anonymous/9936c695f2c29e79a0c1a0dec8... This might lead to subtle ordering bugs, I would recommend against using both together. Using bluebird and native promises together may result in slower performance because V8 has…

In what way is this incorrect? Those are three separate promises; no code can be correct that depends on whether one resolve() call finishes before an independently started resolve() call, right?

Re: Node v7.5.0 Released

#96
post #86

I don't keep up with node end ES version compliance but is there a scheduled release that'll target all ES6 features?

I don't think so. They try as hard as possible. A lot of it is directly related to V8. In Node.JS v8.0.0 nightly they currently support 70% of the ES2015 spec without flags. You can check the progress here: http://node.green/

According to the site:

Node.js ES2015 Support is at 99% for v8.0.0 nightly.

Node.js ES2017 Support is at 74% for v8.0.0 nightly.

Re: Node v7.5.0 Released

#97

Earlier quoted context omitted.

Chaining and returning can keep things nice and neat. Say you are following a Controller -> Service -> Repo implementation. Controller calls the service. Service returns a call to a repo with any mapping that needs to occur. Repo calls out to database or external api and returns the promise. Makes the work very boring and repetitive for the most part which is a good thing I think. function someController(req, res) {…

It's trivial to refactor that code to use only callbacks, without ending up with callback hell. You certainly want to call UserService.getUser for many different controllers. Why manually do that for each controller? Simply make a middleware to get the user. If you take this to its logical conclusion, you end up with small, composable middleware functions, and controllers that are pure functions.

Well sure with a single service and a single mapper etc. Once you start tacking on multiple it keeps following the pattern above with promises and just extends with `.then`'s.

Also agree middleware is a good solution which can go through and provide a user object directly onto the request or another level of abstraction created if you prefer. That was simply to show how multiple service calls could be easily tied together rather than a full and usable example.

A benefit of callbacks though, at least from my experience, is error messages when testing with mocha / chai. I only have experience with jasmine, mocha, and chai but the errors when test driving were much easier to follow with callbacks.

Re: Node v7.5.0 Released

#98
post #59
post #43

Earlier quoted context omitted.

Better than the Python story, at least ...

Yeah! Sadly, if you wanna do actual Python (3.x?) stuff on aws you're better off rolling your own or paying premium to "have it all solved" on heroku :((

I pay $16/month for Heroku. Is AWS really that much cheaper?

Re: Node v7.5.0 Released

#99
post #34
post #28

Earlier quoted context omitted.

I don't understand

"AWS Lambda supports the following runtime versions: Node.js – v4.3.2" http://docs.aws.amazon.com/lambda/latest/dg/current-supporte...

To be fair, 4.3.2 the current LTS version, but would ideally be migrated prior to April.

https://github.com/nodejs/LTS

Re: Node v7.5.0 Released

#100
post #99
post #34

Earlier quoted context omitted.

"AWS Lambda supports the following runtime versions: Node.js – v4.3.2" http://docs.aws.amazon.com/lambda/latest/dg/current-supporte...

To be fair, 4.3.2 the current LTS version, but would ideally be migrated prior to April. https://github.com/nodejs/LTS

Isn't node v6 the current LTS version? I think each even major version is LTS, and 6 is the latest one of those.
Post reply on HN