I probably don't say it in the talk very explicitly (or do I?): the target architecture is web = JavaScript.

Oh, you do say it in the article: "However, for the maximum reach, we want our game to run in the web browsers." I missed that, thanks.

But even so, JavaScript compilers aren't stupid. No need to do this for me of course, but if you got around to measuring the performance impact of the two optimizations separately, I'd be interested in that. (And the ClojureScript developers might be interested too.)

Are you confusing Oleg Grenrus (OPA) and Oleg Kiselyov (http://okmij.org/ftp/)?

Wow. There's more than one of them. Today, I learned something. Thank you.

Good comment!

I did make a too quick judgement there. It turns out you can't easily see how popularality of CoffeeScript has changed.

    It is surprising to see CoffeeScript in this list as a language compiler
    should be mainly a dev-dependency. You compile the CoffeeScript source to
    JavaScript for distribution, so you don’t need coffee-script to be a
    dependency. The packages that depend upon coffee-script include among others:
    grunt, jasmine-node, jscoverage, cucumber and hubot. They all allow you to use
    CoffeeScript sources.

While there isn't anything wrong in supporting CoffeeScript out-of-the-box, I like karma's approach more. It has "karma-coffee-preprocessor", it should be self-explanatory.

I corrected the jasmine stats. The right package is `jasmine-node`, not `jasmine`. Sorry for my mistake.

Though there are now much more users, there are still less than of nodeunit or mocha.

I like the minimalistic nature of npm packages. It also encourages people to publish own packages. If you create an useful test assertion library, you don't need to turn it into full blown framework with all possible bells and whistles!

Short version: node.js of course!

A bit longer one:

One can fetch `jsverify` package metadata from http://registry.npmjs.org/jsverify and all current packages are listed in http://registry.npmjs.org/-/all (this one is special, its size is around 50MiB). Please cache your results, let's not DDoS the registry.

There are around one gigabyte of nice JSON data. After initial fetch you can traverse it using any tools you want. I naturally used node.js for that too.

If you'd rather work with a SQL database, here's a module that attempts to put NPM into a Postgres database: https://www.npmjs.org/package/npm-postgres-mashup

Wow, someone had time and motivation to write all of that boilerplate there. Yet e.g. the license parsing is very naive: compare https://github.com/npm/npm-www/blob/99020b5b3e21607dab24cd69... and https://github.com/rickbergfalk/npm-postgres-mashup/blob/56d...

It was enough to fetch only the package metadata for the analysis in the post.

One could fetch the actual packages too (e.g. the smaller ~20k package set). But there should be more motivators than just counting the amount lines of code :)