Node v0.10.23 (Stable) | Hacker News Reader

Node v0.10.23 (Stable)

blog.nodejs.org

82 pointsshawndumas41 comments

Does anyone know when ECMAScript6 (Harmony) is supposed to be finalized? The last I heard is December 2013, which is this month... wondering when all of the harmony features that are in node 0.11 are going to make it to the stable releases?

In about 10 years.

Really interested in this.

Played around a bit with the generator functions and being able to replace straight callbacks with yields made the code so much cleaner and more readable.

Unfortunately, interoperability with callback/promise based libraries is a bit clunky.

See AGen Spec[1] & gens[2], which implements it.

[1] https://github.com/AsynchronousGenerators/agen-spec

[2] https://github.com/Raynos/gens

Have you looked at fibers? We've had a very good experience with them at https://starthq.com

Here's a talk my co-founder Alex gave on it: http://youtu.be/pmyDJnEza6A

- November 2013, Final review draft

- June 2014, Editorially complete (STH: we said June in the meeting, but July makes more sense, since we don't have to submit to the GA until September, IIUC)

- December 2014, ECMA approval

https://github.com/rwaldron/tc39-notes/blob/48c5d285bf8bf0c4...

I'd also be interested in how many Harmony features are currently implemented in V8/Node.js?

You can follow all of that information (and more) here:

http://kangax.github.io/es5-compat-table/es6/

I think a lot of those features need to make it into V8 first. I myself cannot wait for destructuring assignment to make it into node.js.

CoffeeScript has destructuring assignment...

Curiously though, CS still doesn't support yield despite there being solid PR's, no matter how many times I thrash the refresh button on the github's issues page.

Ick! No thanks. It produces the ugliest, most obtuse javascript code I've seen.

Furthermore, where I work we do lots of high performance Javascript code and some of the conventions in the code CoffeeScript outputs is extremely wasteful when performing lots of calculations, such as calcing matrix multiplications per requestAnimationFrame. It simply produces far too many unnecessary expressions to evaluate. I would not be surprised if it reduces frame rate to half or a quarter of what you can achieve with pure JavaScript.

Yes, the JavaScript CoffeeScript produces often uses a more performant structure here and there than what many developers would naturally code. However most CoffeeScripters I've met have never really learned JavaScript well enough to understand how many cycles it throws away unnecessarily.

If someone writes CoffeeScript code that doesn't have to be fast, then more power to them for choosing a language they are happy with and feel productive. However, if they're writing a single page web app in CoffeeScript and wondering why it is dog-ass slow, CoffeeScript is going to be one of the contributing factors. It probably won't be the biggest factor, but it certainly won't be negligible.

It sounds like you actually have done some benchmarking and understand the places it really is necessary to get to the bare metal. Many forget that most code doesn't have to be that fast (see: premature optimization). Much better to save developer cycles.

Besides, I thought we were talking about server-side JS, where a native CoffeeScript implementation is a completely reasonable proposition.

True, however even the server-side CS code gets compiled to JavaScript before execution by node.js. At least with the server though, you can enjoy the benefit of throwing more servers at the problem or you can write high-performance code in optimized C.

There's no reason server-side CoffeeScript must be compiled to Javascript, that's just the most common example. There are native implementations, like Poetics [1]. And note that high level languages are starting to really encroach on C's performance crown [2].

[1] https://github.com/brixen/poetics [2] http://benchmarksgame.alioth.debian.org/u32/which-programs-a...

Node.js has been out for 4 years and it's only at 0.10.23? At this rate it will be 50 years before they get to version 1.0

And then it will be at 10.0 a year later, at least that's the way these things seem to happen.

Only in browsers, and only if The Other Guy is doing it, :p.

Or if you're Slackware Linux:

"In 1999, Slackware's release number jumped from 4 to 7. Patrick Volkerding explained this as a marketing effort to show that Slackware was as up-to-date as other Linux distributions, many of which had release numbers of 6 at the time, and Volkerding expected them to reach version 7 by the time of the jump."

http://en.wikipedia.org/wiki/Slackware

I believe you are using the wrong metric to measure software maturity.

What's the right metric? Pre 1.0 typically means the software is still in beta. I realize node.js is used by many sites and large sites, but if it is stable/reliable the versioning should reflect that.

As with people, pay attention to what it does rather than what it says. The right metric is action, not words or labels!

There is an annoying trend in software where the devs want 1.0.0 to be the final version. Look at c3p0.

http://semver.org/

Can you expand on that any further? I can't tell what you are trying to say, because my comment was made in awareness of Semantic Versioning.

While I support a de facto standard around the meaning of version numbers, you must judge a project's version number by the versioning rules the development team communicates. By the Semantic Versioning Specification's own guidelines, Node.js should be at least at v1.0.0, but the developers have decided against it. Therefore, when judging the stability and maturity of Node.js by the version number alone, you can only compare it to previous releases of Node.js.

In the "Semantic Versioning Specification", it's seems inconsistent when you look at #4 and #5 and compare it to rule #1 at the top. Changes in x (x.y.z) should be reserved for "when you make incompatible API changes", but the #5 in the spec forces you to change x (to 1) even in some situations where there may not be "incompatible API changes".

I can't tell if you're being sarcastic.

Just because a build is stable (which is what 0.10.23 stable means) doesn't mean the APIs are stable (which is what 1.0.0 generally means).

For example, the streams API hasn't been deemed stable. The specific build is stable, but it's possible that the interface may radically change in the near future.

http://semver.org/

One might just want to assume that node.js never wants to build a stable API. They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. If they'd ever release a stable version they'd suddenly have to backport fixes and care about keeping an API intact for something other than a few months. Like they will not be able to do that thing anymore where they dismiss all those who built upon 0.6 and don't get security updates unless they rewrite big portions of their code base and find new libraries to replace all those they use that have gone dark.

Have they at least committed to some kind of date range for a stable API?

It's kind of silly to worry about because all the various node.js libraries that so many people depend upon are either weekend fads that get abandoned, or moving at the same speeds and likewise breaking compatibility.

> They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic.

The team claims to have turned the corner. relevant comment from @isaacs: https://www.youtube.com/watch?v=82hJbjqbIt4#t=120

> Have they at least committed to some kind of date range for a stable API?

@isaacs mentioned 2014 once. From the same talk, https://www.youtube.com/watch?v=82hJbjqbIt4#t=730

Oh that's awesome then. I hope it happens.

This should really be the top comment, as it explains the frustrations you will run into with this fantastic platform. I love async webservers and most of my dev is done on python Tornado but i built two projects on nodejs and experienced the above issues, so many people start projects and just abandon them, the quality of a lot of libraries are not good and then you get some really cool libraries. Everything changes really fast, so you really need to have your ear to the ground to make adjustments to your codebase. All in all, i had a lot of fun with nodejs but for serious dev, i am using Tornado, when nodejs fully supports backwards compatibility, then i will develop more longterm projects on it. I still believe that if you doing a simple crud api for mobile, the current node will work very well as it is so fast and the code will be easier to maintain.

Yes. One by one, I have been encountering issues with projects I've done in Node that are more easily fixed by rewriting in Python than by researching replacements for abandoned libraries that are breaking or dependencies that are not updated with the APIs they were written to interface with.

It's still handy for Grunt and Bower though!

What's the best replacement for socket.io in Python?

I'd argue that relying on backwards compatibility for very long is a smell. Probably the stinkiest, most common one in most corporate settings.

And not providing any backwards compatibility is BS :)

You do need a stable base to build upon. Not quicksand.

In addition to semver, it's worth checking out the Node.js docs stability guide:

http://nodejs.org/api/documentation.html

While semver is great for getting an overview of the stability of the API interface for a project, I think their guide is a great complement in that it helps people determine the stability of specific interfaces that someone might want to use. This is increasingly valuable as the API surface of a project becomes quite large (which is common for a framework).

From what I understand, 0.12 (odd numbers are used to test new features before the next even number release, and right now they are at 0.11) will be the last version before they go to 1.0

Does anyone know approximately how close we are to 0.12? I know 0.11.9 came out a few weeks ago, but I don't follow the community close enough to get a feel for how near the next stable branch is.

I reckon we'd move to 0.12 when there is a change that warrants a minor version bump. Whether or not there are such changes already in one of the development branches that are soon to be pulled into master, I do no know.

Are the bless and release scripts not set up to automatically publish to all the major package managers (rpm/pacman/apt/etc), including homebrew? I had assumed that `brew upgrade nodejs` would already work following a new release.

Reply on news.ycombinator.com