Node.js v4 Release Timeline | Hacker News Reader

Node.js v4 Release Timeline

github.com

145 pointsantouank44 comments

Most excited about v8 4.5. Native support for arrow functions and stuff like Array.from really makes the dev experience feel so much smoother.

This is huge. I've been using RxJS lately and arrow functions will make this 100x better.

I may be out of the loop here, but wasn't the big benefit of JavaScript everywhere that it's the same JavaScript everywhere?

Does it matter if server-side is JavaScript Next Gen and browsers lag by a few years of features?

Too many more iterations of this and you'll be back to two programming languages again and web developers heads will explode from having to learn two things instead of one things.

It's been "the same javascript everywhere" mostly due to the ECMAScript group kinda stalling for the past 15 years. The stabilisation created through that has been useful, but the plan is to transition the spec onto a one-year update cycle.

That means that going forward we'll likely have more feature mismatch between engines, making backward compatibility compilers pretty important.

I'm not entirely sure if that's good or not.

Chrome (logically) already supports features of the new JS spec that 'only now' get put into node. With automatic updates for browser being the trend currently I also think that it is now easier to keep the server and browser support for JS in sync.

Not necessarily. I don't think the v8 team really consider the Node project so breaking changes in v8 take some time to get merged into Node/io.js. This is the reason that arrow functions are only shipping now when v8 marked them complete a while back. AFAIK Node is somewhere around 3+ months behind Chrome.

This is not really accurate. Arrow functions shipped in Chrome on Tuesday (Sep 1) with Chrome 45 (V8 4.5).

Gotcha. I guess marking them "shipped" just puts them into canary? That was done a while back.

https://code.google.com/p/v8/issues/detail?id=2700

V8 has had arrow functions for a long time, but until recently they were not fully spec compliant. That is also why iojs put them behind a flag (separate from the flag that enabled stable harmony features).

Yeah, 'ship' means different things in different contexts. In the context of your original comment, node stable is getting arrow functions within a week of Chrome stable getting them.

In general, io.js has been very good at picking up stable V8 soon after it ships in Chrome. The exception was V8 4.3, which was not picked up because of API compatibility issues.

This is not a problem for Chrome because chrome doesn't expose the V8 C++ API to large body of third party module writers like Node does. It takes time to deal with some API changes.

with babel you can use the latest js everywhere.

Latest JavaScript that can be transpiled to ES5 anyway.

Except for symbols and Object.observe.

Well, you can emulate those in ES5 but it's just not the same.

Sadly, it's inevitable. But at least with things like Babel we can still write the same code for browsers, just with an extra transpile step.

Doesn't this include the new class syntax? If so, will the standard libraries change as well to use the new classes?

Yes, classes are stable in V8 4.5 so Node.js 4.0 will have classes without runtime flags.

Is there a list with all the supported ES2015 features?

Probably the same as io.js[0].

[0]: https://iojs.org/en/es6.html

Why are these lists always missing import/export/modules?

Because Node uses CommonJS modules.

On nodejs.org, it says "Current Version: v0.12.7". Can someone explain why this discussion is about "v4"? I'm missing something…

They merged with the io.js fork which has already reached v3.x.

node.js got forked into io.js. io.js made a lot of improvements and changes, while trying to reconcile the fork and the reasons why it occurred. those have been reconciled.

io.js had many contributors and changes, starting at 1.0, they are now on 3.0. 4.0 is the full reconciliation with node.js, as part of the linux foundation.

It's also useful to note that io.js moved fasted in version numbering because they switched to a more semver versioning pattern, whereas Node had been using something a lot more awkward and rather more confusing. It looks like a benefit to the 4.0 jump is that Node will be using semver moving forward.

When are they going to change the webpage and download to v4.x?

Check the timeline posted in the link... presumably it would be:

Thursday, 3rd of September:

Release v4.0.0.

The release has been delayed until Monday (7 September).

If you're hoping to use native V8 Promises, beware using them with other promise libraries / custom thenables because of https://code.google.com/p/v8/issues/detail?id=4162 (more detail and test case in https://github.com/zloirock/core-js/issues/78 )

One issue to go: https://github.com/nodejs/node/issues/2516

A .bat file is holding up the whole thing!

rvagg, in a comment on cited issue:

FYI this isn't holding up release ("A .bat file is holding up the whole thing!"—hackernews), it should be completed by recent commits to core, I'm leaving this open as a reminder to confirm that it's working as expected in the 4.0 RC builds.

I've been waiting for this since io.js was announced.

So excited this is finally happening. I enjoy every bit of node I get to write, really excited for the updated features. Babel has taken a lot of the edge off, but I dont want to pull babel in for every script.

I'm curious, what is your development background, and what do you enjoy most about Node.js?

I come from a Java background, but have been working exclusively with Node.js for the last eight months. Everything I write, I can't help thinking things like "this problem has already been solved in Java many times over", and "this would be safer in a statically typed language", and "this would be faster to write in anything else" (though this is more a reflection on my choice of libs).

Mostly dynamic languages. I really like statically typed languages for certain tasks, but many times a dynamic language that gets out of your way can be quite liberating. It takes a lot of trust compared to a language where your compiler is what you trust - and occasionally you spend a bit of extra time tracking down why things are in a state other than what you expect, but on the whole it takes the time from this is what I need to this is what I have down considerably.

Yes, statically typed languages can help.

However, if you have good test coverage then you can test for that stuff and get a similar experience. For example, if a test break then you know your variable is not a number anymore when you need it to be.

Manually writing tests for things which the compiler automatically picks up is not my idea of 'a similar experience'. Background: ruby and is dev who is now learning Scala and loving having type safety

With TypeScript [1] you can get the best of both worlds: statically checked code with tool-assisted refactoring plus the ability to drop down to JS when the type system doesn't support what you want to do. (Of course, you'll now need to be careful about it and try to isolate the dynamic code from the rest of the system and present a static facade to it)

[1]: http://www.typescriptlang.org/

I've thought that if you're going to go the route of compiling to JS, you might as well go to a higher level of abstraction and use something like PureScript, Haxe, or any of the 100 other languages that compile to JS. Of course, interop then becomes a problem.

Thats precisely why I suggest TypeScript or Facebook's flow, as interop is a non-issue. They're both just ES6 + optional types.

The trouble with PureScript is that its different enough to have a different cost model (in terms of performance) thanks to the pervasive closure allocations resulting from currying as well as the typeclass dictionaries. Though I'm sure that once the compiler matures and those costs are eliminated, it would be the best choice.

There is also TypeScript's tooling - while the language is less safe, the language service tools are a lot more advanced than PureScript's (I can't say if the same applies for Haxe though)

Am I doing something wrong? I find NPM very slow and buggy compared to maven which just works for me. It could be that I'm on Windows or just more familiar with Maven. Use an internal nexus for both proxying NPM and maven.

> It could be that I'm on Windows

It is. NPM is a joy to use on Mac or Unix.

And thankfully Microsoft is helping mitigate this issue.

So it seems this is v4 because io.js got to v3 in it's short lifetime.

Is Chrome somehow setting the pace for version numbers? We don't have major.minor.path. Semver is pointless.

A version is an integer, and every change is a new version?

How long until we see Uint32 overflows on a version number?

io.js does follow semver, that's why it's at 3.x, because certain changes required the major version bump.

Node v4 will be the first Node to follow semver.

I get that you don't like Chrome style versioning, but that's not what's going on with Node.

Reply on news.ycombinator.com