[jimwise]

Beyond the question of how meaningful these metrics are, wouldn't it be a more useful metric to look at how complex the code you write when you use each framework is, rather than the code that implements each framework?

I suspect -- but don't know -- that these might even turn out to be inversely correlated for some types of frameworks. DSL-based frameworks often require some interesting tricks to get right.

So which is better? A complex framework that lets you write simple, concise code? Or a simple framework that requires a lot of boilerplate and complexity to use?

[obviouslygreen]

I think the answer to your question, and probably the point of asking it, is that It Depends. If you're writing a very simple web service that will be accessed by millions of clients for a small set of straightforward operations, you'll probably want to pick the framework with the smallest footprint and write a very little bit of custom code. If you're writing a vastly complex system to mingle support for new and legacy data and integrate with many disparate third party services, you will want a framework that does a lot behind the scenes to make your own code as painless as possible.

For everything else, aside from Mastercard, there's room for argument and discussion... but I think the only universal takeaway is that most or all of the frameworks mentioned have solid use cases, and none of them work for everyone in every circumstance.