:-D I actually set an alarm this afternoon to submit v0.8.0 as soon as it comes out, if you can possibly believe it (I still can't believe I've done such a low, degenerate thing and am a little ashamed of myself)!
But I'm incredibly happy about this release, specially about the 'new' cluster API[1] that has made my life a whole lot easier! So apologies for being a karma whore, but I was so glad I couldn't resist, if you know what I mean...
I can't believe you managed to get this submitted to HN before I did. That's what I get for posting it to twitter before coming here ;D Since I knew the URL, I could have totally cheated and done it before even uploading the blog post.
Now, quickly release 0.8.1 and make sure you beat everyone ;)
Joke aside, thanks for the great new release. I'm running 0.6 in production sometimes with 3000+ connected users and will soon need to scale. Being able to do so just by upgrading to 0.8 will make my life easier... until many more users come, of course.
Isaac said it would be out in 15:00 UTC, and it was out in 15:00 UTC... I was studying for my exam, my alarm went off and bam! There's the blog post - It was amazing.
You're probably missing some necessary context here: Isaac is the maintainer of Node.js. So the funny thing is that pooriaazimi was so excited to post this to Hacker News that he beat the project's own maintainer to the punch.
Of course not. Just a few seconds of joy, that our favorite platform has reached another milestone...
I posted the above comment to say I was really happy and all (and I wasn't trying to be an ass) - I wish people would stop upvoting that stupid, non-constructive comment (for some reason, it has 10 upvotes).
If you mean changes between 0.7.15+ and 0.8.0, nothing really significant. But if you mean changes between 0.6.x and 0.8.0, well, almost everything has changed!
While the benchmarks look like there's an overall improvement, it's not instantly clear how much of an improvement they demonstrate. To more easily parse what the benchmarks are telling us, I calculated the percentage difference and the results appear really impressive.
Some of the most notable improvements listed below (results rounded, possibly misleading, but nonetheless awesome).
According to these benchmarks, 0.8 is approximately:
* 43% faster at reading files.
* 119% faster at reading 4096 byte buffers.
* 117% faster at writing 16384 byte buffers.
* 243% faster at http benchmark TYPE=bytes LENGTH=123456
* 506% faster at http benchmark TYPE=unicode LENGTH=55555
Be sure to note the actual figures though, as they are what really matter.
It's been a long since I watched "Introduction to Node.js with Ryan Dahl"[1], but although I think it was circa v0.4.0, it's not really outdated. It's a short talk, but it talks a little about Node's philosophy and I highly recommend watching it.
I haven't watched Pedro Teixeira's tutorials[2], but many recommend it.
But I personally think Manuel Kiessling's online book[3] is the best. It really teaches you to think asynchronously. I took a quick look and I don't think any of the modules he's used have had a significant change. Be sure to check it out.
I just started teaching myself node a couple days ago and just finished with Manuel Kiessling's online book yesterday. It really is a great tutorial and helped me a lot. Thanks for the other links, I'm going to check out nodetuts.com later today.
Tekpub has a course on node, it's fairly recent (I think it has been around for 3 months, give or take). The Tekpub site was rebuilt in node as well and the videos talk a little bit about somethings Rob Connery encountered during the process. The series taught me a lot, but my only other exposure was the peepcode video.
This looks incredible. Congrats to node core on this milestone! I really appreciate how laser-focused you guys are on code consistency across the board.
Looking forward to trying out the cluster and domain modules in strata!
"Domains provide a way to handle multiple different IO operations as a single group. If any of the event emitters or callbacks registered to a domain emit an error event, or throw an error, then the domain object will be notified, rather than losing the context of the error in the process.on('uncaughtException') handler, or causing the program to exit with an error code."
This will be great for things like request handlers, initialization code and other "loose" blocks of code where you don't really care about success but you do care about errors not propogating.
I've been reading back and forth between this post and the docs and I'm still not really getting it.
Is this just a way of registering a single callback to respond to error events that could be emitted by different operations? What are some examples when this would be better than handling error events individually?
> Is it sort of like a try/catch for error events?
Yes, but it's also sort of like a try/catch for thrown errors.
d = domain.create()
d.on('error', function(e) {
console.error('an error: ', e)
});
d.run(function() {
throw new Error("whoops")
})
would console.log, rather than crashing the program.
When an EventEmitter is bound to a domain, their error events and any errors thrown while emitting an event on them will be handled by the domain object that they're bound to.
Thanks! It is marked experimental, and we really do mean that. The API won't change in 0.8, but it probably will change somewhat in the next stable release. Please try it out and let us know what you think, especially in what ways it is lacking, how it actually helps or hurts in real apps, etc.
That description at the start of the docs is unhelpful.
After scanning the rest of the docs I get the impression that domains are weak containers for resource cleanup (not just IO), paired with an error handling context.
I'd love to take this opportunity to dive into Node, but I have yet to stumble accross an effective way of organizing medium to large Node projects. What tools do you guys/gals use?
Node is still young, and for its primary use case (multiuser/messaging-oriented apps) it seems like the actual LoC stays pretty low. However, here are some things I've picked up in my studies that seemed to make sense to me as an Express user. Keep in mind I'm still a relative nodenoob, so take this with a grain of salt..
- Keep the actual 'route code' (i.e., code that handles your end points) in a folder, named by the function: i.e., routes/login.js
- The overall route map (i.e., app.get()) lives in the main app.js file or routes/index.js
- Use underscore.js where possible; this raises the cognitive level of your code and its become a 'standard part' of Javascript to some degree. Unfortunately the Node repl treats _ as a special value, so you can't really test with it there. Kinda sucks..
- Use config.js to contain database settings, default port, middleware settings, etc.
- Develop the more complicated parts of your code in libs/. Think of them as open source components; keep them generic and disconnected from your app itself. This increases reusability (obviously) and testability. I think it creates better code overall. Some people even npm the core "hard parts" of their code! This is a really interesting and freeing strategy.
One thing to note is that there is no standard library. Most of your code will be dealing with modules. The most important thing is to get those dependencies right. Node comes with node package manager (npm), which is a great tool for the job. Still, be aware that you might be dealing with a lot of moving parts. Any tool that helps you with this should be worth checking out.
You should also check out modules like step or async, to make your chained callbacks look nicer. This way you will avoid long code pyramids.
Use a tool such as JSHint or similar, to detect errors and potential problems in JavaScript code. Try to integrate it with your editor or your complete development environment.
Regarding editors or an IDE, well, you basically have a standard pick here.
Although there is one interesting and somewhat new player you might want to check out - Cloud9 IDE, an online development environment for js and Node (amongst others). Since the code is available on github you can also deploy it on your own machines if the hosted options don't suit you.
Yay! This looks great. I'm particularly excited about v0.9x as the current SSL performance is still a massive issue when it comes to actually running apps in production (it's SUPER SLOW). It seems that optimising this will be a core focus moving forward:
SSL performance leaves much to be desired at the moment. Node's interface with OpenSSL is somewhat naive and leaves a lot of potential optimization on the table.
If you want to play with this new version but also have code running on older versions that hasn't been completely ported yet, I recommend using nave to manage your node versions. After you `npm install -g nave` you can just `nave install 0.8.0` to get node 0.8 then type `nave use 0.8.0` to start using it!
Or 'nvm'[1], or 'n'[2]... All of them are bash-specific so if you're using 'fish' for example (what I really like to), you're out of luck and you must hack your own.
It is hard to say: that's 2642 worth of revisions in V8.
String (unicode) benchmark throughput was definitely greatly affected by improvements in string handling (both internal operations and writing then out of V8 heap through the API; V8 also reintroduced string slices to avoid copying of characters for long substrings).
Other notable things on the compiler front: V8 has switched to a new counting profiler from statistical one, and now makes slightly different optimization decisions. There were improvements in functions inlining (including inlining of constructors). There was some cleanup in invocation sequences for functions and we enabled type feedback for function calls through local variables on x64 (which opened the door to all optimizations that were dormant at such callsites: e.g. inlining or direct calls).
Other notable things in the runtime: new GC has landed and was tweaked for quite some time. Unboxing of double arrays and tracking of smi-arrays (should not affect node.js though).
I think the only way to see which changes in V8 resulted in throughput boosts is to get per-V8-revision measurements.
Does anybody know the details on cluster.autoFork()? http://nodejs.org/api/cluster.html has it in a couple of examples, but not documented - is that supposed to be there?
The node.js buildpack has good instructions for how to upgrade it yourself if needed: https://github.com/heroku/heroku-buildpack-nodejs (and the buildpack docs are now public since Heroku's Cedar stack became the official default)
I meant when will they update it so that you can use the new version of Node without hacking the buildpack.
>To change the vendored binaries for Node.js, NPM, and SCons, use the helper scripts in the support/ subdirectory. You'll need an S3-enabled AWS account and a bucket to store your binaries in.
I don't want to mess with that, I'd rather wait for Heroku to update so I can change one line in my package.json.
I'm beginning to wonder if Heroku is going to bother with this any time soon. The default version is _still_ 0.4.7 [1] and personally I'm starting to feel the pressure to update, especially considering recent performance improvements.
But I'm incredibly happy about this release, specially about the 'new' cluster API[1] that has made my life a whole lot easier! So apologies for being a karma whore, but I was so glad I couldn't resist, if you know what I mean...
[1]: http://nodejs.org/docs/v0.8.0/api/cluster.html