Hacker News new | past | comments | ask | show | jobs | submit login
Node.js 7.6 Released (nodejs.org)
74 points by wonderfuly on Feb 22, 2017 | hide | past | favorite | 17 comments



So this, having V8 5.5 means async await is now stable and available without command line flags? Awesome!


Yummy. No .then() chaining, no async.waterfall(), no pyramid. Not totally seamless as parent scope has to be run with `async` but still excellent:

    async function logFetch(url) {
      try {
        const response = await fetch(url);
        console.log(await response.text());
      } catch (err) {
        console.log('fetch failed', err);
      }
    }


Here's my attempt at a slightly less contrived example:

    router.get('/users/:id', async (ctx, next) => {
      const user = await db.getUser(ctx.params.id)
      if (!user) return ctx.send(404)
      let data
      if (user.admin) data = await api.getSomeData(user)
      return ctx.render('show_user.html', { user, data })
    })


This would quietly swallow all the errors though


That's actually one of the whole points of using promises: it doesn't swallow errors.

Errors bubble up to the top-level. It's the old callback-style that swallows errors unless you manually handle them every time. It's one of the chief advantages of promises.

In my case, errors bubble up to error-catching middleware and, at the end of the chain, into a 500 error that gets logged.


The errors won't be swallowed only in two cases: either if router.get actually supports promises (thus catches all the bubbled errors on its own) or if you have unhandledRejection global listener. Some node versions do show unhandled rejections automatically (e.g. v7.x), but that is getting deprecated soon.

So, there's quite a real risk of quiet failures in that bit of code.

Upd. Looks like even though the unhandled rejections warnings are getting deprecated, the rejections themselves will actually stop the code execution with non-zero exit code! Which means most of the issues I had with that code are gone (which is awesome)


Of course the code in my example handles promises. It's actually an example of koa code.

Not sure why that is a "real risk". You generally want to be using promises with libraries that support them. That's why I wouldn't use promises in vanilla Express as my daily driver abstraction.

Compare this to callbacks where there's an actual real risk of silent error dropping any time you forget to `next(err)` or `.catch(handleErr)`, which is something you have to carry around for the life of the project instead of my example, where you choose a framework (once) that supports them.

I'd say it's a great demo and addressed all your concerns so far since it's this kind of context where async/await really pays off compared to the logFetch example.


I really hope that this release means that koa2 will release soon.. been a little painful to determine which versions of what modules are supported. Really enjoying koa2 though.


You can keep track of the stable async/await-native koa release here: https://github.com/koajs/koa/issues/533 (scroll to the bottom).

Looks like this is the release they've been waiting for.


yeah, now I'm having trouble getting webpack + hmr working with koa2 in node 7.6... the webpack page mentions issues with v7, so trying what I had in v6, will see if I can get it working.. :-(


Fair enough!

Looks like it might be a good time to move code from v4 (that had all those swallowing issues) to v7 and just forget about that. Promises sure came a long way :D


I so much prefer promise syntax to this, I do not understand why people favor this at all.


Much easier to read and understand. Same scope. No chains and chains of nested messiness.



Thanks... may have to take the time to have a couple different webpack configs so I can target the latest chrome (and edge 15, safari 10.1, etc), separately from the es2015 builds.

It's been coming for a while, but finally getting browsers that don't need nearly as much fluffy goodness from babel, which I'm happy to see.


> fs: allow WHATWG URL objects as paths (James M Snell)

Can someone explain this to me? Does this just mean I can open files using the 'file:' syntax or can I somehow open URLs with readFile now?


The linked PR[0] says it's just using the file: syntax

[0] - https://github.com/nodejs/node/pull/10739




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: