8 ms·

Node.js v4 Release Timeline

145 points by antouank 11y ago

netcraft 11y ago
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.
- jestar_jokin 11y ago
  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).
  - netcraft 11y ago
    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.
    - dmarg 11y ago
      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.
      - te_chris 11y ago
        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
  - spion 11y ago
    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/ http://www.typescriptlang.org/
    - jestar_jokin 11y ago
      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.
      - spion 11y ago
        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)
- potatosareok 11y ago
  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.
  - abritinthebay 11y ago
    > It could be that I'm on Windows It is. NPM is a joy to use on Mac or Unix.
    - Killswitch 11y ago
      And thankfully Microsoft is helping mitigate this issue.
Killswitch 11y ago
I've been waiting for this since io.js was announced.
atestu 11y ago
On nodejs.org, it says "Current Version: v0.12.7". Can someone explain why this discussion is about "v4"? I'm missing something…
- ilaksh 11y ago
  When are they going to change the webpage and download to v4.x?
  - kbaker 11y ago
    Check the timeline posted in the link... presumably it would be: Thursday, 3rd of September: Release v4.0.0.
    - onestone 11y ago
      The release has been delayed until Monday (7 September).
- 0x0 11y ago
  They merged with the io.js fork which has already reached v3.x.
- jerrysievert 11y ago
  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.
  - WorldMaker 11y ago
    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.
rakk 11y ago
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.
- mattkrea 11y ago
  This is huge. I've been using RxJS lately and arrow functions will make this 100x better.
- seiji 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - sciolistse 11y ago
    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.
  - rakk 11y ago
    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.
    - mattkrea 11y ago
deleted 11y ago
[deleted]
timdorr 11y ago
One issue to go: https://github.com/nodejs/node/issues/2516 https://github.com/nodejs/node/issues/2516 A .bat file is holding up the whole thing!
- jessaustin 11y ago
  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.
deathtopg 11y ago
so does this mean I don't update iojs and start updating node.js?
Arnavion 11y ago
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 https://code.google.com/p/v8/issues/detail?id=4162 (more detail and test case in https://github.com/zloirock/core-js/issues/78 https://github.com/zloirock/core-js/issues/78 )
stephenr 11y ago
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?
- saghul 11y ago
  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.

145 points by antouank 11y ago

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.

jestar_jokin 11y ago
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).
- netcraft 11y ago
  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.
  - dmarg 11y ago
    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.
    - te_chris 11y ago
      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
- spion 11y ago
  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/ http://www.typescriptlang.org/
  - jestar_jokin 11y ago
    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.
    - spion 11y ago
      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)
potatosareok 11y ago
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.
- abritinthebay 11y ago
  > It could be that I'm on Windows It is. NPM is a joy to use on Mac or Unix.
  - Killswitch 11y ago
    And thankfully Microsoft is helping mitigate this issue.

Killswitch 11y ago

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

atestu 11y ago

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

ilaksh 11y ago
When are they going to change the webpage and download to v4.x?
- kbaker 11y ago
  Check the timeline posted in the link... presumably it would be: Thursday, 3rd of September: Release v4.0.0.
  - onestone 11y ago
    The release has been delayed until Monday (7 September).
0x0 11y ago
They merged with the io.js fork which has already reached v3.x.
jerrysievert 11y ago
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.
- WorldMaker 11y ago
  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.

rakk 11y ago

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.

mattkrea 11y ago
This is huge. I've been using RxJS lately and arrow functions will make this 100x better.
seiji 11y ago
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.
- deleted 11y ago
  [deleted]
- sciolistse 11y ago
  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.
- rakk 11y ago
  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.
  - mattkrea 11y ago

deleted 11y ago

[deleted]

timdorr 11y ago

One issue to go: https://github.com/nodejs/node/issues/2516 https://github.com/nodejs/node/issues/2516 A .bat file is holding up the whole thing!

jessaustin 11y ago
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.

deathtopg 11y ago

so does this mean I don't update iojs and start updating node.js?

Arnavion 11y ago

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 https://code.google.com/p/v8/issues/detail?id=4162 (more detail and test case in https://github.com/zloirock/core-js/issues/78 https://github.com/zloirock/core-js/issues/78 )

stephenr 11y ago

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?

saghul 11y ago
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.