The depth of libraries available in the Python or JVM ecosystems is going to dwarf what's available for Node. Were you able to find everything you need for Node?
The actual number for Java is a little bit skewed probably. You're only using one maven central repository (which is already big enough). But there are other repositories as well such as RedHat's (JBoss, Hibernate, etc). SpringSource's (Spring frameworks, grails probably, and everything under SpringSource umbrella).
And also keep in mind that scripting languages have higher number largely because people use them for writing scripts/command-line as well. And if they insist to use Java for scripting well then... they deserve to be punished by walking up and down the stairs 20x per library per decision.
I would venture to guess that the lack of such libraries is more the result of community focus.
The rails community (and by extension ruby) is generally more product focused, whereas the python community (and by extension django) are more science focused.
I intentionally ordered the language and the framework differently for each because most people who use ruby/rails, got into that community for the sake of the framework, whereas most of the people who use python/django, got into that community for the sake of the language.
Finally, python has a much greater adoption among in the academic world, so it's natural to expect that its community will have built more academic libraries like those you mentioned.
Node.js and Javascript are seeing adoption among those interested in real-time applications, evented systems and applications that bridge the chasm between the client and the server, so it is natural to expect that more libraries focused on problems within those domains.
One thing I like that I've seen from the node.js community is that the fact that they are developing with the same language on both the client and server, that they consider them one in the same. The only thing separating the two is latency and connection reliability. The latency issue is psychologically not much different than having a bias for doing things in memory and avoiding disk IO server-side. The lack of connection robustness is likely to evolve into solutions that mirror the problems that the erlang/OTP community has spent a lot of time solving.
The ecosystem around languages are heavily influenced by the strengths and weaknesses of the communities that adopt them, and the community that adopts them is largely the result of which problems that language is well suited for either by language design or historical coincidence (e.g. Javascript is in the browser)
Count of modules seems like a useless metric. A better one would be modules that are considered ready for production. Even then, the only ones that matter are the ones you will end up needing for a project.
Having said that, the only ones I consider moderately painful is when we need to deal with node-thrift, which on the Python or JVM is well maintained by existing groups.
Part of this though is because web apps are for better or worse increasingly being almost nothing but javascript. And it becomes tedious moving back and forth between javascript and another language. Even if that language is really good. So i think people are just going with javascript for "everything" and rewriting their libraries in it.
How does it calculate the size of the code base for each language? Most people would be using jquery as a minified oneliner. How can that inflate the numbers so much?
It doesn't measure line length, which could be a good way to detect minified JavaScript. It uses file extensions and byte size. There is some exclusion of commonly bundled libraries, but it's a rough heuristic on file paths.
Of course it depends what libraries youre looking or. If youre looking for libraries for build the "basics" of a web app then there are plenty of libraries available. If yore doing other things though and looking for libraries that dont exist maybe its because youre using the wrong technology.
Not necessarily. Sometimes the lack of libraries isn't solely because it is the wrong technology, but because it is the wrong community. Language and community are pretty intertwined.
LISP for example is a great technology for a lot of things, but library-wise it suffers because within that community there is a tendency for people to "roll their own" solutions.
Java has tons of libraries, but I'm not sure most people would say it's the right technology for a lot of things. It's generally the right technology for projects that involve lots of developers with mixed levels of ability (before some Java person down votes me for this, consider that Gosling himself made this point back in the mid-90s when he invented the language)
