
Node.js v7.0.0 - tmacie
https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V7.md#7.0.0
======
bit_logic
The JavaScript language has improved a lot since node.js was released
(Promises and soon async/await). However, at this point NPM has a lot of
libraries written in the old callback style and it seems even new libraries
are still doing this. There are libraries like bluebird and Q which can
"promisify" a callback style library, but I think using these is a bad
practice. It's something that works most of the time, but sometimes breaks
when the callback code isn't what the promisify function expected. Also, the
library writers are not writing the code with any guarantees that promisify
will always work. So even if it works now, it could break in the future.

The whole promisify is a good example of general node.js culture. It's
considered "good enough" and everyone just uses it. However, anyone who has
done software development in more solid languages would feel very uneasy using
something like this. It's not really the fault of the JS developers, the
dynamic nature of the language offers no other choice. For example, when Java
added lambdas, since it has static typing it could consider a certain type of
class (a single method class) as automatically a lambda. This allowed full
backwards compatibility with any old library that conformed to this (and many
libraries such as Guava did use single method class as a kind of "ugly"
lambda).

node.js has a convention for callbacks (function(err, result)), but
unfortunately it's only a convention and there's no compiler to enforce it. So
automatic promisification is not possible. That leads to the current
situation. There's all these new language features in JS, but everyone is
still sticking to the "lowest common denominator" of callbacks. There's no
path forward for existing libraries. The only way is a complete rewrite of
libraries using the new Promise/async/await style.

~~~
kemitchell
I write and prefer libraries written in error-first callback, continuation-
passing style. I also prefer `require()` to new `import`. Those choices have
rather little to do with backwards compatibility, from my point of view. I
think they are better choices, which just so happened to be the norm before
ECMAScript began to change again. Opinions differ, and will differ, forever
and ever, amen.

Maybe we can all agree that experience in other languages leaves ECMAScript
with much to be desired. Whether the changes ES6 hath wrought and ES7 and
friends portend bode ill or well is likewise up for debate. So are the one-
trueness of futures, specialized async syntax, and static typing. Those aren't
either-or kinds of debates as far as ECMAScript is concerned. ECMAScript could
be more Scheme-like, more Java-like, more ML-like. I've forgotten to mention
some other disappointed camp. Forgive me!

If specific judgments on those kinds of controversies unify a culture, there
is no unified culture of Node.js, any more than there is a unified culture of
C or Java or English punctuation. The only unity is that standards-compliant
ECMAScript runtimes are everywhere and we all want to use them. As long as
different tastes are at least sufficiently well specified, we've a fighting
chance of automating adapters. So I'd argue promisifiers and depromisifiers
might be the most important libraries of the moment, culturally speaking. But
it's too much to ask of any broad and adaptable common platform or library to
hide the fact that tastes and approaches differ.

~~~
kpil
[There are] standards-compliant ECMAScript runtimes everywhere and we all
dream that it had been scheme instead.

Fixed that for you.

~~~
kemitchell
I'd be happier with a Scheme-ier JavaScript, and I'm not alone, but that's not
everybody.

~~~
stiGGG
The other ones do not know what that means?

~~~
kpil
A [crappy] religion teacher once tried to convince me; Everyone longs for
salvation - only some does it unconsciously, without knowing it.

Maybe he was right all along, but was actually talking about scheme.

(I can't just let go that it was soooo close that we would not had to suffer
in the javascript wastelands.)

------
gedy
I realize this follows semver, but bumping major releases without major
changes is... not as fun? as the 'old days' where major versions of software
meant something less incremental :-)

Kind of wish there was yet another number prefix to semver to signify this.

~~~
Klathmon
IMO until someone can figure out a way to objectively "quantify" the size of a
change, it should stay with how semver has it.

The line of "major" is arbitrary, and changes per person. It's basically
useless information to everyone but the person/people actually making the
version change. Having it there can just lead to anger when something that you
would consider "major" doesn't make the cut, or when the "major" bump doesn't
have anything you care about.

Semver is in no way the end-all-be-all of versioning schemes, but at least
it's pretty objective for the most part in the sense that it can prevent
bikeshedding about version numbers, while still giving some useful information
to the users.

That being said, I'd love a system that lets me view changelogs by the version
"level" I want. So I can easily lookup the major changes since v6.6, and
someone else can check what has change since v4.2, etc... With Semver a lot of
my time is spent reviewing every changelog between my current version and the
one i'm bumping to, and there's no reason it needs to be that way.

~~~
gregmac
It's even more nuanced than that.

If I release 1.0, then add a couple "medium" size features and release as 1.1
a month or so later, I can keep doing this indefinitely with 1.2, 1.3, etc.
Baring some truly some new big thing or a fundamental change in functionality,
it becomes very unclear as to when to release "2.0" or what even makes it
different than the other 1.x releases.

On the other hand, if I do the exact same work of adding a couple features per
month, but don't actually release, I could then make a big splash a year later
with 2.0 that had 19 new features, and I think most people could readily agree
that qualifies as a "major" release.

From a quality point of view, release early, release often is very useful: get
feedback quickly, iterate in small chunks, minimize breakage.

However, from a marketing point of view, this is boring -- especially by the
time you're on 1.19 and your features are largely quality-of-life or only
affect a small segment of the market. A big 2.0 release that gets press
releases and such is much more exciting.

~~~
Jarwain
I've always thought of a major release as being one that isn't backwards
compatible/include breaking changes

~~~
Ajedi32
Yes, that's exactly what it means for any project using
[SemVer]([http://semver.org/](http://semver.org/)). It says nothing about how
many new features you added or anything like that, only that you introduced
breaking changes.

------
XaspR8d
This just makes me realize that it's gonna be really confusing when Node.js
_V8_ is released!

Joking aside, I wonder if there are any internal plans on keeping terminology
clear for the next version?

~~~
BurningFrog
Might as well "do a Windows" and skip to V9.

~~~
cshenoy
But odd numbered releases don't get LTS. =/

~~~
andypants
Then you can _really_ do a Windows and release Node 10.

~~~
bastawhiz
I'm partial to Node Vista.

------
emilong
Anyone have a good summary of the language feature changes & APIs (either
standards or standards track) that are in the version of V8 that ships with
Node 7 vs Node 6?

~~~
jefozabuss
From what I read in slack: Do not use async/await yet (with --harmony-async-
await flag) because it has memory leaks (V8 5.5 will fix it when it gets
added)

~~~
ilkkao
Is it known how easy it is to trigger the memory leak?

------
EugeneOZ
Dedicated blog post:
[https://nodejs.org/en/blog/release/v7.0.0/](https://nodejs.org/en/blog/release/v7.0.0/)

------
terink
node releases should ship with yarn instead of npm. Yarn is better all around
- faster, deterministic, local caching, offline mode, better licensing terms.

~~~
mattnewton
Not everyone is down to switch such a core piece of the infrastructure at the
first sign of new and shiny. I think yarn will succeed, but so did lots of
people about bower, ied, duo, etc. Give it a moment to settle. The path
forward might even be a merger instead of replacement.

~~~
terink
node developers have overwhelmingly indicated that they want to switch to yarn
and are willing to work through the short term problems until it becomes
stable. npm wouldn't be a suitable caretaker for yarn.

~~~
franciscop
I am sorry, but what? What is your source? From a new account[1] with only 3
comments overwhelmingly favoring yarn over npm it's difficult to trust this as
it just seems like SPAM. I have been developing in Node over 3 years and
trying new things constantly and no, I'm not really excited about yarn. Nor
many Node developers I know.

[1]
[https://news.ycombinator.com/threads?id=terink](https://news.ycombinator.com/threads?id=terink)

~~~
terink
Most devs on Github disagree with you:

[https://github.com/yarnpkg/yarn](https://github.com/yarnpkg/yarn) \- 17,271
stars

[https://github.com/npm/npm](https://github.com/npm/npm) \- 10,807 stars

~~~
franciscop
Ah I see, Github stars. I am not sure they are a good indication though; many
people (HN effect?) star something new and fancy when it comes out, while I
think NPM can be considered to have "grown" organically with Node.js; which in
my experience doesn't attract as many stars at all. When NPM came out the Node
community was still in its infancy, with not so many people in the ecosystem.
I haven't even _starred_ NPM while I almost starred Yarn the other day.

