Purely event-based I/O for V8 Javascript

It's designed to be interpreter agnostic, by implementing as much as possible in JavaScript, only dropping down to native modules where necessary (file io, etc). Currently Rhino is the best supported platform but people are working on V8 and Mozilla support as well.

It's still a work in progress but it's at the point where you can start playing with it. All of the Cappuccino build tools use it now, btw.

Then there's JSGI and Jack (http://jackjs.org/), which is how you interface with webservers. JSGI is a standard interface for JavaScript web applications and middleware, and Jack is an implementation of several web server adapters, middleware, and utilities, essentially a port of Ruby's Rack.

For most things it feels pretty fast. A simple timer output showed less than 1, 1, 2 or 3 milliseconds for most operations including File I/O.

Importing files via node's 'import' and 'require' functions is, for lack of a better adjective, Erlang-ish. You must declare in the file you are importing which functions you would like to expose by making them members of a special object called 'exports'. For example if you have a factorial function in a file called factorial.js you must declare it as 'exports.factorial = function() { ... }'. This seems 1) strange, 2) not very Javascripty and 3) like it can severely limit the reuse of server-side js libs with other server-side and non-server-side js implementations. This was the biggest let down for me, since my dream is to be able to write libs that work on both the client and the server.

There was a weird bug I found when writing to a file. If I created a loop like so:

var times = []; for (var i=0,j=1000; i<j; i++) { var t1 = Date.now(); var file = new node.fs.File(); file.open('test.log', 'a+'); file.write(i + ' ' + new Date() + ' Hello World!\n'); file.close(); times.push(Date.now() - t1); }

'file' would contain only 250 new lines of text, while the array times would show it's length to be 1000. I'm assuming this is some kind of bug, as the number of new lines added to the file seems fixed at 250. Setting the loop to 249 produced a times array with 249 items and a file with 249 new lines. Setting the loop to 251 produced a times array with 251 items and a file with 250 new lines. My C++ is very poor, but my guess is that each event has a queue which is hard coded at 250 and my loop over flowed the queue. This could also be a potentially huge issue with writing libraries around node.

It would be nice to see those two issues resolved or explained in better detail, particularly the import / export functionality.

No. MySQL does not provide an API that is usable with an event-loop, so it will need to be run in a separate internal thread. It will notify the main thread when it is complete. With Postgres the situation is better, they have a very nice API that can be integrated into an event loop, so the extra overhead won't be necessary.