Node v0.10.0 (Stable) | Hacker News Reader

Node v0.10.0 (Stable)

blog.nodejs.org

245 pointsbinarymax44 comments

It's great to see Node mature. When it first came out I was among the many people who said "That's neat.", played with it a bit and moved on.

But I wanted to make a meeting agenda site, since I don't like any of the ones out there right now. So the last 4 days I worked on one writing it as a JS web app that talks to a Node backend. It was quite painless. Anything I wanted to do (whether generating uuids, date formatting, etc.) there was a module available on npm. Couldn't be easier.

The platform has really matured a lot, and I didn't run into any issues with Node itself.

If you haven't yet, the next time you're doing an experiment, give it a try. I will probably write my next project this way too.

I really like nodejs as well but i have some concerns, i built an app in tornado and then i wanted to try out node, so i built it in node as well with a postgres backend. I was surprised how much faster my tornado app was: using bcrypt blocking module for tornado with a factor of 8 gives me 42.51ms for login, on node i get 153ms, geting a user profile 6.7ms on tornado and 16ms on nodejs. These results are consistent across the app, where tornado seems to about 3 times faster. I am assuming that maybe this is due to the quality of the libraries, since i assume node is faster. Reading this article,(https://hacks.mozilla.org/2012/11/fully-loaded-node-a-node-j...) helped to understand node more as well as how some of the libraries deal with threading and async.

1) are you using the synchronous or asynchronous version of bcrypt?

2) cached or uncached templates?

3) throw 1k+ requests per second and tell us which one is faster

I am using the aync bcrypt module for nodejs. I am using it as an api for ios app. I will do the 1k test and let you know.

The pace at which libraries have come up around Node is astounding. Mostly probably the fastest growing eco-system ever.

Yes, quite literally there's more library than we developers/hackers can play with. I've spent a lot of time just browsing through all of them and they are all excellent. But there seems to be 3 types of npm modules on github, 1) active and mature 2)fairly new, stagnating, seldom active 3) abandoned.

How is this any different to the status of other projects in other environments?

Nice try, not going to point specific fingers at certain environments out of risk getting flamed.

My first brush with Node was in a class. We chose to try it for a game only about 5 months after Node's initial release. It was cool and fun to work with but ultimately a bit rough. After a year's break, I can now say I love Node. I'm glad your return was just as encouraging.

Pretty much the same case here, I've abandoned LAMP stack completely. There's no need anymore, I am tired of having to google how to setup Apache config on some esoteric distro to see it fail when traffic spikes, I am not getting the best bang for the buck but with NodeJS, everything is so much easier.

(Though, of course, there are plenty of other alternatives to LAMP -- I find Nginx, Postgres, and Ruby or Python preferable in pretty much every way).

I think having NodeJS serve up static content is a waste of time, and that's not its intended use case. So I'm with you. I set my server up with nginx serving up static content, and when an API call is made nginx proxies to my Node app.

Why is it a waste of time? There are plenty of good solutions now like Hipache.

Perhpas he means it's a waste of cpu time :)

All very good alternatives of course.

I find the strength, openness, and responsiveness of the community (mailing list, freenode IRC chat) to be node's greatest asset. They've done an amazing job in building culture and that should serve node well as it matures.

This is probably a stupid question that can be answered if I read the docs, but how does versioning work? I love using node, but seeing 0.10.0 makes it appear like such young, teething software that people might immediately dismiss it if not for its user base. Why not call this node 10.0 and start at 0.1 instead of having another 0 that looks like it won't ever increment. Does it reflect a developer's sense of completeness or confidence in his/her software or does it come from quantifiable steps toward stability/speed?

THey've defined their versioning based on a subjective assessment of stability, willingness to add new features, and API compatibility. They plan 0.12 to be the final 0.x release before a 1.0 release.

Node uses semantic versioning: http://semver.org/

Not perfectly: "If your software is being used in production, it should probably already be 1.0.0."

> Not perfectly: "If your software is being used in production, it should probably already be 1.0.0."

"Probably" is, ipso facto, not normative.

The public API is not stable, hence a 0.xx number is justified.

That doesn't seem to match what the semver.org site says.

Node's public API is not changing in a backward-incompatible way every day (or even every week, or every month). The software is widely used in production.

I think node 1.0.0 should have been some time ago, and this release should have bumped the major version again.

"Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." -- from semver.org

"The software is widely used in production."

Depending on how you define the "public API", things have changed from 0.8 to 0.10 (streams API, for example).

Your definition of Node 1.0.0 is based on your conception of how others are using node. People can use experimental software in high-profile places without deeming the underlying technology stable.

"Node's public API is not changing in a backward-incompatible way every day (or even every week, or every month). "

Also: in general, development is highly nonlinear. I would say the API is stable when the core developers deem it stable.

Semantic Versioning: http://semver.org/

IMO, seeing 0.10.0 makes it appear like something that's worked on very carefully, in a professional manner, that's being nice and honest and realistic in what it promises. A version like "10.0" would lead me to think completely the opposite (that it was written by people more concerned with marketing than the quality of the product) and therefore put me off. It's funny how equally irrational we can be, in completely opposite directions :)

I think exactly the same. I'd love to give Node a go for some of my projects but seeing a version like 0.10 kind of dissuade me. On the other hand, there are some big sites built on Node like MySpace, and don't know what to think of it.

Can some recomend some decent source material to learn about Node.js and some best practices about it? I've read "The Node Beginner Book" and found it quite easy but somehow it didn't click.

I would read the core documentation (maybe takes 4 hours), then find a project you to do in node and do a lot of googling on ways to get certain aspects done. It is an unstructured way to learn and can be slightly inefficient since you will go down a few rabbit holes, but I think you will learn a lot more and have a lot more fun.

When you are in the docs make sure you focus on stream, callbacks, and event emitters. Once you have those down start gluing NPM modules together.

[How do I get started with Node.js](http://stackoverflow.com/a/5511507/251453)

I'm neither a user nor a fan, but congratulations on the release and good luck for all of Node's future endeavours.

I hope that nodejs debian maintainers will package it into sid soon. v0.8 was never there.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692312

Very cool. I just tried it with my app. Can't run it until a few npm modules are updated to support it and of course Heroku needs to be updated to use it too. How bleeding edge. =)

probably most happy off the bat to see performance gains (who doesn't like that?). I'm hoping the fs readstream boost will help with static hosting.

Why 0.10 and not 1.0?

This is toward the end of the page (seems that they're still making major changes, but not breaking backwards compatability. Looks like 1.0 will mostly lock down new features):

"After 0.12, the next major stable release will be 1.0. At that point, very little will change in terms of the day-to-day operation of the project, but it will mark a significant milestone in terms of our stability and willingness to add new features. However, we've already gotten strict about maintaining backwards compatibility, so this won't really be so much of a shift. "

Version numbers aren't like numbers. Don't read the . as "point". It's "major dot minor dot release". There's no reason to increment the major version just if the minor version happens to coincide with the number base we use. That's for versions with backwards compatibility breaks (apart from 1.0, which defines the stable public API). See http://semver.org/.

They are actually using meaningful numbers. 1.x generally describes maturity. More so it means the software toolkit is, for the most part, stable and ready for the real world. Since version numbering in the closed source world generally helps sell products it's nice to see an open source project act as it should where the first number after the point increments as features are added and the second number with an optional second point reflects bug fixes and patches. It's a big deal when a version hits 1.x. A project like node.js doesn't have to pander to the masses like mozilla did with the firefox so called pseudo psychological numbering scheme.

Rake, for example, was perpetually stuck in the 0.x version because the author just mentally mapped the "0." part away. It recently moved to version 10.x :)

This is a better version of my question. Why use dot decimal notation unless just a fun way to model versions after network addresses

The dot indicates division of something into smaller parts. For most things we choose our range for the minor denomination to coincide with our base or a multiple thereof like having 100 cents in a dollar, but software being what it is we need to be slightly more flexible.

very excited about the new version but probably won't bother upgrading my app until a few weeks. Is there a 'one liner' command to update node on OSX?

Well, there's a 'one double-clicker': you just run the OS X Installer package and it will update you.

brew upgrade node ;)

Reply on news.ycombinator.com