Node v0.10.14 (Stable) | Hacker News Reader

Node v0.10.14 (Stable)

blog.nodejs.org

76 pointsshawndumas32 comments

They released v0.10.15 shortly afterwards http://blog.nodejs.org/2013/07/25/node-v0-10-15-stable/

I guess it wasn't so stable after all.

Stable mean feature complete. Not bug free.

To me it also means "stable API", which means published APIs are neither removed nor their function signatures changed (cough Ruby).

Usually a release would be marked for a stable release after a decent amount of testing... so, it should be relatively bug free. Having a new release just a few hours after this one doesn't instill a lot of confidence in their testing.

From the mailing list this is an npm fix mostly for OSX:

    The main fix here is letting users on Mac to upgrade globally installed modules. Also the linux binaries have been rebuilt with an older glibc so people with older systems will actually be able to use it.

I've recently gotten into Node and it has been such an awesome and fun time. Anyone on the fence about it should definitely go and try it out.

+1 Node is lots of fun, and a good platform for JavaScript. As a long time (since the late 1970s) Lisp programmer (also with lots of Ruby and Java work) I have in the past generally detested JavaScript.

That has changed, big time. I now find that JavaScript (and CoffeScript) is really a nice language. By using a small subset of the language, and always having JSLint running in IntelliJ: coding is fast, code is readable, good run time performance, and fairly low memory use. Node, Express, Meteor, and Ember.js round out the ecosystem for me.

I have had a multi-year love-fest with Clojure, but I am now seriously considering the JavaScript/Node ecosystem to be a bit more practical.

I would love to hear a more detailed reason why. I'm in the opposite boat. Been using node on a number of projects, have recently discovered clojure and want to get away from node and to clojure, once I can justify doing so.

Logging, toolchain, ease of deployment, and callback hell on "large" projects are the reasons that I'm down on node.

-edit- basically help me understand the skeletons in the closet you've discovered in clojure -edit-

There are no skeletons in the Clojure world: beautiful language and solid infrastructure. My point is that JavaScript, Node, Meteor, etc. seem a bit more practical for some things I have been working on.

To chime in with another viewpoint: I've just written a sort of remote-control solution that can use WebSockets and fall back to SSE (Server-Sent Events) + HTTP POST if necessary. I wrote it in node.js, which I hadn't used before, because it had (has) great libraries for both WebSockets and Server-Sent Events. So I though I would put to use the adagio "best tool for the job". I don't regret it because I was able to write this thing in about 5 days and together with runit restarting it when it throws an exception I have a solution that hasn't failed me yet.

But... I really kinda hated the callback spaghetti, and no matter what library I tried (Step, Async, ...), I couldn't get myself to feel more comfortable with it. So I decided I would only use node.js when the libraries make it too hard to pass up.

I had a similar experience with the callback spaghetti at first. It felt kind of off and awkward. Once I got the hang of it (day or two), I started really enjoying all the callbacks and passing functions everywhere. Maybe all this Javascript coding finally got to me and now I'm crazy :)

Do you use the module feature that much? If you break your code down into small enough pieces it's less of a problem. Also the terseness of coffeescript functions makes anonymous functions less painful.

I've found it becomes almost an art, trying to write your code without having to fall into the callback quagmire.

You can usually do it, though. Usually.

Promises are the only real solution. https://github.com/kriskowal/q

It's still callback spaghetti though right.

You still need to break function "doAll()" into function "doPart1()", "doPart2()"...,"doPartN()". It's just that now you have a new syntax for calling all of the functions. Like Rx for JavaScript instead of C#.

I do believe the syntax for calling all of the component functions is better.. but it would be great if you didn't have to make the component functions at all.

Have you looked at https://github.com/olegp/common-node?

>So I decided I would only use node.js when the libraries make it too hard to pass up.

So, all the time then? --For me at least ;)

v1.0 is coming up soon. Just found this ROADMAP talk about it here: http://blog.strongloop.com/the-road-to-node-js-v1-0/

I'm finishing learning Rails and next wish to get some JS under my belt- I wish someone would please explain the difference between Javascript, Angular, Ember, Node, and where a noob Rails dev with no JS knowledge whatsoever should begin in all of this.

For anyone willing to learn node which would be an easy way to install the latest version on a server?

Ubuntu 13.04 repository only has node v0.6.19

Just use nvm[1]. It's awesome, use it dev/prod. It's also easy to build and install from source on debian-based distros (my only experience).

[1] https://github.com/creationix/nvm

Nave[1] works like a charm for me.

[1]https://github.com/isaacs/nave

https://github.com/joyent/node/wiki/Installing-Node.js-via-p...

You mean besides the binaries on the page linked in this post?

I've also been using a PPA to keep an up-to-date version on my home Ubuntu box for playing around with.

Oh, so am I supposed to drop the binaries to my bin or sbin directory?

Which PPA did you use?

The main download area has a link to "Installing from Package Managers"[0] which links to "Installing Node.js via package manager" [1]. This page has information on setting up the PPA for Ubuntu/Mint.

[0] http://nodejs.org/download/

[1] https://github.com/joyent/node/wiki/Installing-Node.js-via-p...

The site has been hammered lately. Have been trying to update to latest Node via Homebrew and keep getting timeouts.

The particulars of semantic versioning aside, am I the only one who chuckles at "Stable" being applied to version-zero releases?

You are probably not the only one, it do not mean you're right either.

Stable mean that they will support this set of feature for some time, that's all.

The guys responsible for Node have been on record as saying that Node could probably be considered "stable" starting at 0.8, because that's when they decided to start supporting backwards compatibility rather than habitually breaking the API.

It means stable api as in they won't be adding or removing major features.

Reply on news.ycombinator.com