Hacker News Reader

Comment by efdee | Hacker News Reader

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-...

View on HN

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

Reply on news.ycombinator.com