Hacker News new | ask | show | jobs
by bluefish 6220 days ago
I played around with node last night a bit more. Here are one noob's observations:

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.