spion/async-compare — pull request #3 by gfxmonk (2013-09-01 00:30:39+00:00)
Title: added stratifiedjs implementation

Hi there. Thanks for the great writeup, I'd love to have [stratifiedjs](http://onilabs.com/stratifiedjs) included in the analysis (disclaimer: I helped create it).

I've added an .sjs implementation, but I did have to change a few parts of the supporting code to get everything working. Briefly, they are:

- added loader.js. requiring stratifiedjs needs to go via the sjs require function, not node's require function. This compiles code as needed, and operates asynchronously. (In real code you wouldn't need to care about this, you'd just run the `sjs` binary instead of `node`)
- modified stacktrace parsing and printing (sjs stacktraces are accessed via the error object's.toString() function, and use file:// URLs for local paths)
- also had to change fakemaker to return the API (as well as adding it to global), because the SJS require function runs vanilla .js modules in a separate `global` context (mainly for the purpose of having stacktraces from vanilla modules work correctly, IIRC). Again, this isn't really something you'd notice in a real sjs project, either you wouldn't assign to globals directly, or you'd convert such code into .sjs and then it would work fine.

Oh yeah, and you need to run performance with `./examples/*js`, rather than `examples/*.js` - the sjs require mechanism uses the extension to know what language a file is in, so I couldn't do in an implementation with a .js extension.

Please let me know if I've broken something - I tried my best to make sure everything still worked the same, but may have missed something.

As for the analysis, a few points:
- stratifiedjs compiles .sjs to .js, but the compiler runs on-demand in both node and the browser, so you rarely need to deal with the compiler
- everything is written in a synchronous style, but async stuff still happens under the hood. One of the big plusses for developers is that error handling and stacktraces still work as expected in when underlying operations are async (illustrated by our 100% debuggability scores, which I'm pretty happy about).

Let me know if there's anything else I can clarify.