Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js v4 Release Timeline

github.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Node.js v4 Release Timeline

#41

Post by spion »

jestar_jokin wrote: post #11
netcraft wrote: post #7

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…

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/

Re: Node.js v4 Release Timeline

#42

Post by saghul »

stephenr wrote: post #40

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.

Re: Node.js v4 Release Timeline

#45

Post by WorldMaker »

jerrysievert wrote: post #5
atestu wrote: post #3

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

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.

Re: Node.js v4 Release Timeline

#46

Post by ofrobots »

mattkrea wrote: post #26
ofrobots wrote: post #25

Earlier quoted context omitted.

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

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.

Re: Node.js v4 Release Timeline

#47

Post by jestar_jokin »

spion wrote: post #41
jestar_jokin wrote: post #11

Earlier quoted context omitted.

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…

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.

Re: Node.js v4 Release Timeline

#48

Post by spion »

jestar_jokin wrote: post #47
spion wrote: post #41

Earlier quoted context omitted.

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)

Post reply on HN