Live data from Hacker News

Node.js 5.0 Released

github.com

71–80 of 132 posts

Re: Node.js 5.0 Released

#71

I'm not sure why so many people are freaking out. Looking at the changelog, it looks like they decided to commit a bunch of breaking changes that were previously marked as deprecated. If your code was running before without warnings, upgrading shouldn't have a negative impact. The pace of change is fast because node ES6 support is progressing fast enough to maintain near 1:1 feature parity with v8. A bunch of ES6 fea…

Probably because their sole research into this issue was seeing that a number went from 4 to 5.

Re: Node.js 5.0 Released

#72
This release timeframe was announced quite a while ago. As others have mentioned the quick jump from 4 to 5 was primarily due to the io.js convergence.

Expect future major releases on a 6 month cadence with LTS releases every 12 months

https://nodesource.com/blog/essential-steps-long-term-suppor...

Re: Node.js 5.0 Released

#73

Good lord people... 1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+ 2. 5.0 followed 4.0 so closely because 4.0 was the iojs/node merge and 5.0 was to correspond with the new V8 release, future major bumps will be closer to 6mo (to match V8)

If by "match V8" you mean "skip most V8 changes"? V8 revs on par with Chrome, at a pace about four times what you say.

Turns out that despite pillorying Joyent for sticking to V8 major versions, it is the only reasonably-correct thing to do for the ecosystem to remain usable.

Re: Node.js 5.0 Released

#74
post #36

There's a lot of confusion and concern in here about the release of a new major version very soon after the release of another major version (v4.0.0 was released just a month and a half ago). Please note that this is a special release prompted largely by the odd timing of a new release of Google's V8 [1]. If you're looking for solid, long term stability, you are perfectly fine sticking with v4.0.0, as its marked an "…

Re: From the linked Twitter: "Don't feed the trolls."

I personally don't have an opinion on the quick release and am happy to just use the LTS but calling the developers "trolls" seems unnecessarily harsh for people voicing a reasonable concern, even if they were just misinformed.

Re: Node.js 5.0 Released

#75
post #42
post #33

Earlier quoted context omitted.

> I ended up opting for Flask and Python 3x instead Yap good choice. Python to me is more readable (so I can understand my own code and others' better) and I find the echo system to be friendlier and more mature.

Funny how yesterday in the pypy thread it was all doom and gloom for python and yet in the real world people keep choosing it for new projects.

It's almost like there are many people doing many things in many directions all at once!

Re: Node.js 5.0 Released

#76
post #63

So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm. What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.…

hey! do you have a specific problem in mind or is this just a hypothetical musing? 'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful - npm team member

Is there / could there be an option in package.json for which Node version you support? Like, v1.0.0 of my lib supports up to and including Node 4.2.1, but v2.0.0 requires Node 5? That way people would get a working version relatively seamlessly.

I realise this makes the package.json Node-specific, which might be something you want to avoid.

EDIT: to part-answer my own question, package.json has the "engines" field. Not sure if that means it automatically installs old versions in older versions of Node, though.

Re: Node.js 5.0 Released

#77
post #7

I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausting to keep up with. For a simple microservice api you don't want to be upgrading it every 3 days. The continuous change doesn't make sense to me. Trying to get up to speed on all the Node.js ecosystem feels exhausting, only to have it change a few weeks later.…

We have apps on Node v0.10, which is over 2.5 years old and will be supported for one more year.

3.5 years for an API, that's decently long, but dependent on industry. What does your upgrade path look like? Are you basically rewriting everything into ES6, aka starting over? Three years isn't long in a corporate environment.

Re: Node.js 5.0 Released

#78
post #42
post #33

Earlier quoted context omitted.

> I ended up opting for Flask and Python 3x instead Yap good choice. Python to me is more readable (so I can understand my own code and others' better) and I find the echo system to be friendlier and more mature.

Funny how yesterday in the pypy thread it was all doom and gloom for python and yet in the real world people keep choosing it for new projects.

Why was the pypy thread "not the real world" when this thread "is the real world"?

Re: Node.js 5.0 Released

#79
post #30
post #16

Earlier quoted context omitted.

Yes, I'm very excited about the spread operator! I've been spoiled by Firefox.

Looking at documentation.. does this only work on lists (or list like object)? I.e. you can't "expand" a k:w object? Or is there another operator for this? Example: function foo(a=1, b=2, c=3) { return a * b * c;} dict = {'b': 4, 'c': 6}; foo(...dict);

You still have to simulate named arguments with an object:

    const foo = ({ a = 2, b = 2, c = 3 } = {}) => a * b * c;
    const dict = {b: 4, c: 6};

    foo(); // 12
    foo(dict); // 48

Re: Node.js 5.0 Released

#80
post #76
post #63

Earlier quoted context omitted.

hey! do you have a specific problem in mind or is this just a hypothetical musing? 'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful - npm team member

Is there / could there be an option in package.json for which Node version you support? Like, v1.0.0 of my lib supports up to and including Node 4.2.1, but v2.0.0 requires Node 5? That way people would get a working version relatively seamlessly. I realise this makes the package.json Node-specific, which might be something you want to avoid. EDIT: to part-answer my own question, package.json has the "engines" field.…

This is still current as far as I know: http://www.marcusoft.net/2015/03/packagejson-and-engines-and...

Basically, you get an error but it won't give you the proper version. If that has changed I'd love to know, however (it most certainly should install the latest version for your environment and give you a warning that it's not the latest. In my opinion anyway).

Post reply on HN