Hacker News Reader

Comment by orf | Hacker News Reader

I'm really impressed, PyPi only has about 37,000 packages[1] and it has been around for much longer. Really shows how far Node has come.

It would also be interesting to see the average number of lines each package has.

1. http://tomforb.es/how-much-code-is-there-in-the-python-packa...

View on HN

It's not as impressive if you consider that people make modules for everything, no matter how trivial. Case in point: https://github.com/blakeembrey/upper-case/blob/master/upper-...

I've found myself infuriated by this recently. I do understand the desire to compartmentalise everything, but the last time I installed Express (a web framework) I also had to install modules to read POST bodies and serve static files. Quickly my JS file becomes more require() statements than anything else - it just doesn't seem worth the hassle to me.

There are higher level frameworks, Express is meant to be very minimalist. It is also usually a good idea to serve static files directly through Nginx or a CDN. If you find yourself always requiring the same modules in most of your files, a common pattern is to have a `common.js` file where you export all your modules and you then only need to have one `require('./common')` at the top of your files. I personally don't really like this pattern as it makes refactoring harder and is usually a sign of bad architecture.

> There are higher level frameworks

Like?

You can have both. Frameworks like turf (a geospatial analysis library that I authored) have one high level convenience module[1]. You can require('turf'), then run any function from a single object (ie: turf.buffer(), turf.smooth(), etc.).

Finer control is often required, however, for all sorts of reasons. For these cases, turf is made up of a collection of sub-modules [2][3], and these can be required individually.

I like this approach, since it provides a nice curated framework for users simply wanting to get stuff done quickly, but it also allows for more tuned usage in production environments. It has been a bit more work to maintain (~70 repos, instead of 1), but I have been pleased with the approach so far.

[1] https://github.com/Turfjs/turf [2] https://github.com/Turfjs/turf-buffer [3] https://github.com/Turfjs/turf-smooth

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!

Modularity is good for restructuring, among other things. I'd rather type out a buttload of require() statements than have to try and de-couple parts of a monolithic system if I wanted to replace one part.

Also, static files should be a part of Express:

>Express 4 no longer depends on Connect, and removes all the built-in middleware from its core, except express.static

Oh man I hope he wasn't being serious when he wrote that. But you are right, number of packages != quality of packages

Npm is impressive, but pypi is also growing nicely - currently it has 48k+ packages (the article is from Dec 2013)

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 :)

That impressive number is caused by tiny standard lib in JS. Node packages tend to be smaller and depend on others.

Average Django app has less deps than similar Express app.

Reply on news.ycombinator.com