trevnorris

"Non-conforming" only means they didn't completely adhere to the ES specification. There should be no possibility of buffer overflow.

Here's a follow up to this completely misunderstood post:

http://blog.trevnorris.com/2013/08/callbacks-what-i-said-was...

Thank you. Yes, that was more along the point. I just get punchy about how I say it after 3am.

my closures are executed oh, about 100 times a second (e.g. completely negligible perf hit). This is a seriously flawed benchmark.

Take Node's case where you're accepting HTTP requests. Each request is going to require a new instance, and call into the connection listener. If the connection listener contains all the function declarations for all events attached to the client then you loose the performance you could have had by v8 using a previously optimized function. The benchmark was intentionally made to show worst case. I don't expect every application to magically run 80% faster just because they moved some function declarations around.

Ah yeah. I forgot that Buffer#fill() only returns "this" in master. I updated the example to fix this.

Those are some interesting ideas. You can look at what we've done at https://github.com/jstat/jstat

The core.js file will run server-side. It has no dependencies and has been included using "this", which attaches to Node.js' modules. So to use it in a script you would just have to add the following line of code at the top of your script:

var jstat = require('path/to/core.js').jstat;

As for outsourcing the grunt work to a C library... We're going to need some community involvement with that one. It would be nice to be able to compile that directly into the server, but it's not on our roadmap right now.

We're getting one up and running on github. Sorry it's taken so long. Right now the code is being completely revamped for community involvement and extendibility. The address is https://github.com/jstat/jstat