Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node v7.5.0 Released

github.com

Post reply on HN
Print view View original

131–140 of 142 posts

Re: Node v7.5.0 Released

#131

Post by kosinus »

omouse wrote: post #128

Just wanted to leave a comment about the ChangeLog which is a list of commits. It would be nice if they sat down for a day (or two) to write down proper release notes that made reference to various commits and outlined exactly what is changing, like if there are backwards compatibility issues or if there are very important bugs solved. The changelog here looks like a git log :/ I mean, I can do better on my own proje…

I actually like these release notes? The commits are an extra, and messages are always clearly worded, in my humble opinion.

I guess the commit list is the first thing that pops out when skimming, but it's less important than the notable changes.

'Notable changes' is more akin to the release notes I think you want.

As for breaking changes, Node.js follows semver. A major version lists breaking changes more clearly.

Re: Node v7.5.0 Released

#133

Post by spion »

jcheng wrote: post #87
spion wrote: post #54

Earlier quoted context omitted.

Because the standard library doesn't really have that many callback based functions. The more important issue here is that Promises are seen as fundamentally incompatible with post-mortem debugging due to their empty-the-stack requirement: https://promisesaplus.com/#point-34 If the stack is emptied when handling an exception, the context in which that exception happened is completely lost, so its not clear how to get…

Both Q and bluebird promises optionally support long stack traces, albeit at a performance hit. And in practice even old style callbacks often (usually?) empty the stack.

No, old style callbacks don't empty the stack on thrown errors - they crash.

Long stack traces are fine, but post-mortem debugging means analyzing the entire program's core dump. That includes everything that was in the heap at the time, and not just the names of the functions on the stack but also their arguments (which often point to stuff in the heap). It can be used to reproduce most of the program state at the time of the crash.

The real problem is that at some point node decided that throw = programmer errors = core dump. This is wrong and misguided, but thats another story...

Re: Node v7.5.0 Released

#134

Post by spion »

mayank wrote: post #115
sotojuan wrote: post #57

Earlier quoted context omitted.

IMO promises and Bluebird made `async` obsolete.

They certainly did not, if for nothing other than `async.auto()`, which automatically runs a dependency graph of async functions.

Here is a complex dependency graphs built with no nesting and no "special" methods, only a combination of `then` and `all`

  function test(name1, name2) {
    let user1 = User.find(name1)
    let user2 = User.find(name2)
    let post1 = user1.then(u => Posts.getLast(u.id))
    let post2 = user2.then(u => Posts.getLast(u.id))
    let comparison = Promise.all([post1, post2])
      .then(([p1, p2]) => DiffService.compare(p1, p2))
    let email1 = Promise.all([user1, comparison])
      .then(([u1, c]) => Email.send(comparison.text(), u1.email))
    let email2 = Promise.all([user2, comparison])
      .then(([u2, c]) => Email.send(comparison.text() ,u2.email))
    return Promise.all([email1, email2])
  }

Re: Node v7.5.0 Released

#135

Post by fermuch »

averageweather wrote: post #98
fb03 wrote: post #59

Earlier quoted context omitted.

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?

By far. I use lambda as a public API for my sites. One site has 4000req / h (at peeks. Not much, but it's an api after all) and I only pay some cents.

Re: Node v7.5.0 Released

#136

Post by jodoherty »

GeneralMaximus wrote: post #21
SeanDav wrote: 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?

You have a number of ways of keeping a handle on async code now. 1. Native ES6 promises will cover most of your basic needs. See https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... . In fact, unless you have very specific needs not covered by native promises, you shouldn't drop a third party library into your project. 2. For more advanced operations on promises, use Bluebird. See http://bluebirdjs.com and…

I've used the `co` library at work to extensively trim down and simplify a lot of server-side Node.js code recently. It's worked out very well compared to the very Promise heavy code we had before, especially since so many database libraries now make use of promises. I would highly recommend it if you're going to be stuck using Node v6 for the next 2-4 years.

On the front-end, we're using TypeScript 2.1.5, so we've been able to make good use of async/await there. The only tricky parts are dealing with AngularJS, due to the way it handles change detection via scope digests.

Both solutions still require the use and understanding of ES6 promises, especially when dealing with code that only works with callbacks.

Re: Node v7.5.0 Released

#137

Post by z3t4 »

always_good wrote: post #121
erikpukinskis wrote: post #113

Earlier quoted context omitted.

Yes! Callback hell is a gift that forces you to refactor code until it's easy to understand and your abstractions are correct. Promises are a band-aid that gives you shallower indentation, and then simply hides the callback complexity in invisible objects that are even harder to debug. The problem is the modern web development world is all about creating two classes of programmer: framework programmers who control th…

> Callback hell is a gift that forces you to > refactor code until it's easy to understand That doesn't sound like a gift to me. Unless you meant they are so painful as an abstraction that they gifted us with promises and then async/await. Almost everyone here has worked with callbacks and you'll be hard-pressed to find people that felt like they improved the code base. Just tiny changes to the logic, like an if-stat…

refactoring is better then an extra if and argument. and force you to understand the code and result in less bugs.

Re: Node v7.5.0 Released

#138

Post by charrondev »

wereHamster wrote: post #125
MehdiHK wrote: post #80

Earlier quoted context omitted.

You can always check here: http://node.green

I don't see ES6 modules (import/export keywords etc) in that list. Where is that feature hiding?

The loader spec hasn't been completed yet so there is no way to load properly modules in es2015, es2016, or es2017 as far as I know.

Re: Node v7.5.0 Released

#139

Post by ilaksh »

norswap wrote: post #46
SeanDav wrote: 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?

Many people are complaining that the standard library still uses callbacks and so even though you have async/await, you can't use it with the standard library. I wholeheartedly agree. I don't understand why someone hasn't build a compat library that simply promisifies all the standard library (it isn't that big), taking the edge cases into account.

There are multiple that do that. `mz` is the most popular I know of.

Re: Node v7.5.0 Released

#140

Post by h1d »

kuzmin wrote: post #108
skynode wrote: post #105

Earlier quoted context omitted.

TypeScript async/await helps a lot with this. Type safety plus async ops. Awesomeness.

I feel like it should be clarified here that async/await is not exclusive to TypeScript, but a ES7 (?) feature that is also available if you use the Babel transpiler. Having type safety is great of course, but it might be too heavy to add if you just want good async handling.

You may add types at a later time while enjoying the rest of the features.
Post reply on HN