Node.js v0.8.0 [stable] is out
blog.nodejs.org
blog.nodejs.org
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...
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.
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).
Sorry for the non-answer... But take a look at https://github.com/joyent/node/wiki/API-changes-between-v0.6... and https://groups.google.com/d/forum/nodejs-dev for change log (in 0.7 branch).
1. require('sys') throws, use require('util') now. The "sys" module was deprecated in node v0.4.
2.cluster.fork() no longer return a child_process.fork() object use cluster.fork().process to get the object.
3.the 'death' event on the cluster object is renamed to 'exit'
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.
https://github.com/timoxley/node/blob/ddee8bcda50c8377d135d6...
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.
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")
})
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.
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 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.
[1]: http://www.youtube.com/watch?v=jo_B4LTHi3I
[2]: http://nodetuts.com
Not a full tutorial, but hopefully a decent intro for those looking to learn the ropes.(I would love to hear feedback good or bad)
https://peepcode.com/products/full-stack-nodejs-i
https://peepcode.com/products/full-stack-nodejs-ii
(Don't purchase the old ones. They're desperately outdated. These two were published recently and use the latest APIs.)
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.
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.
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.
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.
...which doesn't list 0.8.
Just make sure you specify the latest npm as well. http://heroku-buildpack-nodejs.s3.amazonaws.com/manifest.npm
Upgraded my app to node 0.8.0 and npm 1.1.9 and seems to be working okay.
brew update
brew upgrade node
UPDATE: More on this here http://blog.izs.me/post/3295261330/on-npm-and-homebrew