
Node v4.0.0 - mmebane
https://nodejs.org/en/blog/release/v4.0.0/
======
dcwca
The io.js fork and subsequent merge back into Node.js, including the birth of
the Node Foundation, has been one of the best examples of the power of open
source I have ever seen in action.

The situation went from bad, to worse, to the best possible outcome, and
that's remarkable to say the least.

Congratulations to everyone involved and thank you for the hard work.

~~~
blowski
As somebody who uses Node only at the periphery of my role (for things like
the Zombie browser, and SASS parsing) the massive instability has put me off
from relying on it for anything core.

Documentation is quickly out of date, libraries seem to have incompatibilities
which only become obvious when they don't work, there's no 'recommended'
approach for even basic tasks.

I won't pretend I'm speaking for everyone, as clearly there are lots of people
doing great things with Node. However, it doesn't seem to be a language like
Ruby or Python where I would feel comfortable using it for a small but
important project.

I'm always grateful to everyone who works on open source projects, but I
wouldn't hold Node up as a great example of the open source community.

~~~
untog
I mean, Ruby was created in 1995, Python in 1991. Node was first released in
2009. That's not an entirely fair comparison since, of course, _JavaScript_
was created long before Node, but Node introduced the language to a new
environment, and a lot of complications needed (and in some cases, still need)
to be sorted out.

As for no recommend approach - that's deliberate. I don't think most people
working on Node _want_ a Rails equivalent.

~~~
aikah
> I don't think most people working on Node want a Rails equivalent

It wouldn't really be possible anyway. Async programming is hard and the
shortcuts one can take with synchronous Ruby are impossible with Async
Javascript. Nodejs has a "fibers" lib though , but it doesn't look like it is
widely popular, but AFAIK it is the only to truly abstract async programming.

~~~
ivank
Try bluebird's Promise.coroutine, I use it everywhere and it works great.

[https://github.com/petkaantonov/bluebird/blob/master/API.md#...](https://github.com/petkaantonov/bluebird/blob/master/API.md#promisecoroutinegeneratorfunction-
generatorfunction---function)

~~~
Dashron
Or if you want to use native promises, I threw this together

[https://github.com/Dashron/roads-coroutine](https://github.com/Dashron/roads-
coroutine)

------
AndyKelley
Alright, now everybody stare at ffmpeg and libav!

~~~
stingraycharles
Don't forget about bitcoin core and bitcoin-xt! People are screaming bloody
murder about that, it will be very, very interesting to see how it plays out.

~~~
sam_goody
There are many ways a large fork can go in an open source project. A great
description of the io.js/node split is:
[https://news.ycombinator.com/item?id=8884874](https://news.ycombinator.com/item?id=8884874)

"Lets hope the spork gets spooned so that no projects get knifed. If not then
I guess we have to hope for a knork so we don't get stuck with a couple of
chopsticks."

------
cpeterso
Here is a timeline diagram showing how the LTS and Stable branches will work:

[https://nodesource.com/assets/blog/essential-steps-
lts/nodej...](https://nodesource.com/assets/blog/essential-steps-
lts/nodejs_lts_schedule.png)

From this NodeSource post:

[https://nodesource.com/blog/essential-steps-long-term-
suppor...](https://nodesource.com/blog/essential-steps-long-term-support-for-
nodejs)

------
georgerobinson
What happened with the version numbers? I could have sworn Node was on v0.10
just a couple of months back?

~~~
bsimpson
A group of contributors got tired of Node not using semver when the rest of
the ecosystem does (among other gripes). They forked it and shipped io.js
v1.0.0. In keeping with semver, they bumped the major version number on every
breaking change. According to iojs.org, the most recent version is v3.3.0.

Joyent and the io.js team reconciled and merged their codebases, maintaining
everyone's versions. Since io.js had used versions 1 - 3, the merged version
number is 4.

~~~
ploxiln
No api stability promises before 1.0 is technically part of semver. It sounds
like io.js should have stayed below 1.0 if they broke backwards compatibility
three times in less than a year!

I always found the naming-and-proclaiming of semver in the javascript
community silly. Old style C libs have been doing what semver describes for
decades, and while the js community talks it up like crazy, the compatibility
and stability is terrible (and as a result they find the need for private
recursive sub-dependencies, and the resulting thousands of unique libs/copies
is impossible to audit or patch).

~~~
bsimpson
The Node library is massive, and tightly coupled to V8. The changes that
bumped the major version weren't major changes for most people, just for those
who happened to be using the parts of the library that changed. Maybe that's a
deficiency in semver (or the way io.js used it), but going to v4 in one year
isn't as unstable as it sounds; it's just following Chrome's example of not
caring how big the version number gets, so long as the semantics make sense.

I believe the io.js community was in the "ship or get off the pot" camp, and
found it silly that Node was a critical piece of infrastructure at firms like
PayPal while still technically not having had a GM release. By forcing the
issue, they got Joyent to commit to major version changes twice a year, which
sounds like a reasonable compromise between everything-changing-all-the-time
and we-can't-have-new-things-because-legacy.

~~~
lobster_johnson
It's a good argument for adding another level in addition to semver: A human-
oriented release number.

After all, when a project goes from 2.0 to 3.0, you expect something big to
have happened -- not just some breakage.

Some projects use release names (e.g., Ubuntu and Android), but if every
project starts using release names we'll have a lot of (mostly silly) names to
deal with on a daily basis. Plus, there's no inherent ordering in names.

------
jjcm
"In parallel, we will be branching a new Stable line of releases every 6
months, one in October and one in April each year."

Nice, they're syncing up with the ubuntu release cycle. Should make updating
servers a bit easier.

~~~
daredevildave
Presumably, this means Ubuntu will always be one release behind...

------
maga
Guys, does V8 still deoptimize on ES6 features? For example, would using say
const/lets in a function prevent V8 from optimizing it as a whole? That was
the case some time ago when these features were still under a flag.

~~~
gear54rus
Can I ask for a link on that? Thanks!

~~~
maga
The one readily available on search:
[https://github.com/petkaantonov/bluebird/wiki/Optimization-k...](https://github.com/petkaantonov/bluebird/wiki/Optimization-
killers#2-unsupported-syntax)

Otherwise the fact that engines bailout on optimizing ES6 features was kind of
common knowledge when engines started to implement them.

------
atburrow
This is great news. I'm especially excited about the new ECMA6 features
(arrows, etc.)

~~~
pfooti
Yeah, this is rad, as I imagine there's some overhead to running the
transpiled babel ES6 code compared to running the native ES6 features. At
least some things may be faster - I remember lexical block scoping (let and
fat arrow) causing perf issues in traceur.

Now I just need to be able to rely on these features being present in the
browser so I can just write native ES6 everywhere and skip that build step
entirely.

~~~
azernik
Not just performance overhead, but also the overhead of maintaining and
configuring the extra bits of toolchain.

------
mark_l_watson
ES6 support is nice, especially if there is no performance hits for using ES6
features. I slightly prefer Typescript, but the extra language features in ES6
really make JavaScript development more fun for me. Thanks to the newly re-
combined Node team!

~~~
tomphoolery
Good news for you: ES2016 will support optional type annotations, clearly
inspired by TypeScript. The idea is we shouldn't need a damn transpiler just
to get the features most people want out of a language...

~~~
Ciantic
Interesting, can you give a link? I tried to find it, it's not here
[https://github.com/tc39/ecma262](https://github.com/tc39/ecma262) Only
mention is "Typed objects" but that is not TS-like annotation.

------
msoad
When node supports `import` how you'll import node modules?

I hope it works like this

    
    
        import {readFile} from 'fs';
        import {clone} from 'lodash';
    

rather than explicitly providing "correct" URL to the modules.

EDIT: edited the syntax.

~~~
codecurve
You'll be able to achieve that behaviour when node also supports
destructuring.

    
    
        import { readFile, writeFile } from 'fs';
        import { clone } from 'lodash';

~~~
msoad
oops I forgot the braces! ok then, it's cool. I'm happy it does resolving to
node_modules and all that automatically.

~~~
pluma
It's just syntactic sugar for `require`, mostly. The import mechanism should
behave the same.

------
hamhamed
This is crazy fast shipment..almost scary that you have to start keeping up
with all the changes..

For anyone who wants to upgrade either from node 0.12 or iojs 3.30..all you
have to do is re-install it with the GUI installer and you're good to go..for
your personal computer at least!

~~~
cornedor
`nvm install v4.0.0` and you're ready to go.

~~~
ausjke
nvm install 4.0 works, do we really need the "v"?

~~~
qubyte
Since it's the first and only release so far in 4.x.y, I got away with `nvm
install 4`. ;)

~~~
srn_
Using `stable` is also another way.

    
    
      > nvm install stable
      v4.0.0 is already installed.
      Now using node v4.0.0 (npm v2.14.2)

~~~
ljharb
nvm maintainer here: this is true - but please use `node`, since the concept
of "stable" and "unstable" has died with the advent of node v4.0 using semver.

All node versions are now stable, and version numbers now communicate
breakage, not stability. As it should be.

------
jyunderwood
Excited to see this happen so soon. I was expecting it to take a bit longer.

I see it's still shipping npm v2. Any news on when npm v3 will be "production-
ready" and the default version?

~~~
M2Ys4U
npm@3 "will be leaving beta very soon!" according to the release notes for
3.3.2.

------
techman9
Does anyone have a good source of information about the major changes between
Node and IO? I haven't kept up with the community recently and I'm curious as
to what the delta really is and what merging IO back into Node will mean
practically.

~~~
steveklabnik
The largest is a pretty big update to V8, it was one of the biggest features
of iojs.

------
Cshelton
When I first saw the post about the two combining, never did I imagine it
happening this fast. Congrats!

------
jtwebman
I might stay on 0.12.7 for a few months to let everyone work out the issues
first.

~~~
Twirrim
That's probably the smart approach, in general, other people make awesome
guinea pigs.

------
andrewpe
Exciting to see node moving so quickly

------
smaili
This marks a big day for Node - one which I and many others have been
patiently waiting for, and one which still hasn't quite hit me yet :)

Big thanks to all those who made this possible!!

------
platz
so now which apt repository to I use for node going forward?

~~~
mattkrea
Don't. I don't think Chris Lea is updating his anymore.

Wget the tarball and tar -C /usr/local --strip-components 1 -xvf <tarball>

~~~
STRML
Not so, Chris Lea's PPAs are now part of Nodesource:

[https://github.com/nodesource/distributions/#installation-
in...](https://github.com/nodesource/distributions/#installation-instructions)

~~~
mattkrea
Oh wow! Didn't know about this. Awesome.

------
ErikRogneby
I wonder how fast AWS will adopt it on Lambda?

------
yulaow
Hoping all the main distros include this release as soon as possible in their
main repos.

~~~
therealmarv
I hope not. Many libs are still not compatible with that.

------
atomi
> ARMv6 32-bit Binary: Coming soon

Is there more information on what's holding back this build?

~~~
nathankunicki
The fact that the little Raspberry Pi building it is still...well, building
it! :)

[https://ci.nodejs.org/job/iojs+release/168/nodes=pi1-raspbia...](https://ci.nodejs.org/job/iojs+release/168/nodes=pi1-raspbian-
wheezy/console)

It does look like it's very nearly done though, given that it's tar'ing stuff
up at the moment.

The decision was made not to wait for it here -
[https://github.com/nodejs/node/issues/2522](https://github.com/nodejs/node/issues/2522)

~~~
rylee
Should have used a high-powered Scaleway server as advertised on HN a few days
ago :-P

------
ausjke
the iojs site mentioned nothing about the merge as I checked yesterday,
neither does nodejs site, which is a bit odd.

the new version number is using iojs instead of nodejs's existing version
scheme, which is interesting too.

I just began a php device-configuration-management project and was strongly
persuaded by a senior php developer that I should use nodejs instead, as he
thinks nodejs _is_ the future and many big guns are using it for real
deployment(netflix, linkedin,paypal...), just in time to try the fresh nodejs
release for the new project.

~~~
dragonwriter
> the new version number is using iojs instead of nodejs's existing version
> scheme, which is interesting too.

Well, its a follow-on to both pre-merge iojs and pre-merge nodejs, and has
breaking changes to both, so the most SEMVER consistent version number is the
first major version greater than the greater of pre-merge iojs's last version
number and pre-merge node's last version number -- which is exactly what they
chose.

------
bhanu423
Finally a stable release. Thank You Node Foundation.

~~~
Florin_Andrei
Just curious - what makes it "stable"? We've tried 0.12, then went back to
0.10 for stability reasons.

~~~
saghul
No software is bug free, but AFAIK Node v4 was very thoroughly tested in a
vast array of platforms and configurations, which provides certain degree of
certainty, when talking about stability.

At any rate, if you ran into issues with 0.12, the best you can do is give 4.0
a go and report issues!

~~~
actualprogram
If you're concerned with stability, the best thing you can do is wait for the
LTS release to come off the 4 branch.

A quick glance at outstanding issues will show a number of integration bugs
are still outstanding, and the new v8 was landed only a few days previously -
incompatibilities with new versions of v8 can take a while to surface in node.

It's important to remember that semver makes _no promises about stability_.
While we're used to "N.0" meaning "stable and ready for upgrade," that's a
non-semver idea that is explicitly disregarded in the semver release model.
Node moving from 3.* to 4.0.0 only indicates that there are breaking
changes(1).

If you have concerns about stability, you should take signals on that from the
node LTS group, and pick LTS releases.

1 - whether or not this is good, bad, or merely a different permutation of the
things that are turning your hair grey, I leave as an exercise to the reader.

~~~
scottohara_
Just curious..where are you tracking these outstanding issues?

In GitHub issues (for nodejs/node), I can see the 5.0.0 milestone has 5 open/1
closed issue; but my understanding is that the LTS release will be cut from
4.x; and 5.x is for rapid iteration post-LTS (i.e. changes that would have
previously gone to io.js).

I recall reading that the 4.x LTS release is planned for a couple of weeks
after 4.0.0 (which should be around the end of September, or early October).

I'm interested in tracking progress in the lead up to LTS, as this is when the
node Homebrew formula is expected to bump from 0.12.x -> 4.x.

------
netcraft
The arm support is great too. Great work from everyone involved, io.js was
short lived but will have a lasting impact for the better.

------
intrasight
All I can say is that after reading this thread, I'm glad that I'm not a Node
developer.

~~~
_fizz_buzz_
You are missing out. Node is dope!

------
mark_sz
I remember when many people were complaining about PHP - lack of progress,
inconsistency etc.

Now look what's happened to Node just in 6 years. And this is just the
beginning.

~~~
pluma
I have no idea what you're trying to say.

PHP stalled in pre-6.0 land and then jumped straight to 7.0 because the
release was just not going to happen. The closest thing in Node I can think of
is ES4 (which failed, resulting in a jump to 5 and ActionScript diverging
further).

Node stalled in pre-1.0 land with what was effectively a feature freeze before
io.js split off and jumped to 1.0. Io then went on a regular release schedule
strictly following semver leading to 2.0 and then 3.0. These aren't backwards
incompatible in the sense that PHP 5 is to 4 or Python 3 is to 2 -- most code
will likely still work; they mostly propagated breaking changes caused by
updates to the underlying V8 engine, breaking some native extensions. The
"jump" from 0.12 to 4.0 for Node is because instead of merging io.js back into
Node, Node 0.12 was merged into io.js and io.js became the new Node 4.

------
haberman
Anyone know when Node will get IndexedDB?

~~~
redidas
That's likely out of scope for node.js. I'd recommend checking out leveldb:
[https://www.npmjs.com/package/level](https://www.npmjs.com/package/level)

~~~
haberman
Why out of scope? It's a DB api that has no browser/ui dependencies.

I see that the levelDB implementation you pointed to can use a backend that
uses IndexedDB. So theoretically this levelDB Api could provide an Api that
work across both browser and server.

But argh. IndexedDB is a standardized api. It has a usable open source
implementation in WebKit. Why not just go with that?? Why create a different
API that does the same thing? I've been building an entire app around
IndexedDB, but now I have to port it to a different Api to run on a server?
Why?

~~~
secoif
If you'd used leveldb from the beginning you wouldn't have this problem as it
will happily work on the server and in the browser
[https://www.npmjs.com/package/level-js](https://www.npmjs.com/package/level-
js)

~~~
haberman
Yes I see that. But if IndexedDB were supported on Node I also would not have
this problem. So the question is, why can't node just support IndexedDB (which
is formally specified in a standards document) instead of inventing an
extremely similar but incompatible api?

~~~
pluma
Because IndexedDB is a W3C spec[0] intended for web browsers and LevelDB is a
third-party npm module[1].

Node is just a JS environment. Implementing IndexedDB is as much out of scope
as implementing XHR[2] or the File API[3]. In fact it provides the building
blocks developers to implement any of these on top of Node should they need to
(like node-fetch[4] implementing the Fetch API[5] for isomorphic apps).

[0]: [http://www.w3.org/TR/IndexedDB/](http://www.w3.org/TR/IndexedDB/)

[1]: [http://leveldb.org/](http://leveldb.org/)

[2]: [https://xhr.spec.whatwg.org/](https://xhr.spec.whatwg.org/)

[3]: [http://www.w3.org/TR/FileAPI/](http://www.w3.org/TR/FileAPI/)

[4]: [https://www.npmjs.com/package/node-
fetch](https://www.npmjs.com/package/node-fetch)

[5]: [https://fetch.spec.whatwg.org/](https://fetch.spec.whatwg.org/)

~~~
haberman
This just begs the question. The question is, what about IndexedDB, XHR, the
File API, etc. make them _unsuitable_ for pure-JS environments?

Because there is nothing about the problem domains (indexed key/value store,
asynchronous web requests, filesystem I/O) that are specific to web browsers.

If a problem domain is common across browsers and pure-JS environments, then
it should follow that there can be common APIs. If some part of the API is
necessarily specific to one or the other, then ideally these differences
should be localized to small parts of the API.

~~~
pluma
That's an intuitive assumption but it's naive (i.e. it lacks understanding of
the actual domain concerns).

JS in the browser needs to be sandboxed by default and has to handle concerns
like cross-origin policies and interactively seeking user permissions. It also
has some fairly browser-specific singletons (e.g. a shared global cookie
storage).

The equivalent built-in node APIs are much more low-level, allowing developers
to use abstractions that are useful in _their_ problem domain.

Having an IndexedDB implementation in node core would be an incredibly
pointless effort (most apps out there won't use it) and bring with it several
complications (e.g. pluggable storage backends and concurrency conflicts if
you want multiple node processes to share the same database). Plus it would
mean the Node Foundation would have to get involved in the standardization
process to make its concerns heard and likely introduces concerns that are
irrelevant to everyone else (i.e. browser vendors).

Don't forget that Node is not a web framework. It's a JS runtime environment.
It is primarily used for things that talk over the web or that generate
content for the web, but it's not at all unreasonable to implement other
things in it (e.g. mail servers). The web specs carry a lot of overhead that
is simply unnecessary for most node applications even if it is perfectly
necessary in browsers.

The only spec I can think of that I'd like to see in node is the Fetch API and
for that we have node-fetch, which just wraps node's low-level http module.

What I'm trying to say is that node doesn't need these high-level APIs because
it can give you the low-level APIs to implement them with. Browsers can't do
this, so they need to work at an entirely different layer of abstraction. Plus
node allows you to easily include native extensions whereas in the browser you
can't have that (except for NaCl).

------
aarestad
So, why is the link 404ing right now?...

------
ihsw
Node on Docker Hub needs a new tag.

[https://hub.docker.com/_/node/](https://hub.docker.com/_/node/)

~~~
antouank
Get an alpine based one, it has 10x smaller size. I made one with npm v3 and
node v4.0.0 [https://hub.docker.com/r/antouank/alp-
node/](https://hub.docker.com/r/antouank/alp-node/)

~~~
pluma
Thanks to docker's image layering, using a non-Ubuntu image may actually be
"bigger" if you already use other Ubuntu images.

------
kylehotchkiss
yay

------
Killswitch
So excited!

------
snickmy
0.12.7 -> 4.0.0

Best versioning convention ever :)

~~~
abritinthebay
Actually it went:

0.12.7 -> 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.0.3 -> 1.0.4 -> 1.1.0 -> 1.2.0 -> 1.3.0
-> 1.4.1 -> 1.4.2 -> 1.4.3 -> 1.5.0 -> 1.5.1 -> 1.6.0 -> 1.6.1 -> 1.6.2 ->
1.6.3 -> 1.6.4 -> 1.7.1 -> 1.8.1 -> 1.8.2 -> 1.8.3 -> 1.8.4 -> 2.0.0 -> 2.0.1
-> 2.0.2 -> 2.1.0 -> 2.2.0 -> 2.2.1 -> 2.3.0 -> 2.3.1 -> 2.3.2 -> 2.3.3 ->
2.3.4 -> 2.4.0 -> 2.5.0 -> 3.0.0 -> 3.1.0 -> 3.2.0 -> 3.3.0 -> 4.0.0

You just weren't paying attention.

~~~
ultrafez
If you include io.js, sure. Node did technically jump considerably.

