4 ms·

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/

by efdee 12y ago

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-case.js https://github.com/blakeembrey/upper-case/blob/master/upper-...

untog 12y ago
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.
- olalonde 12y ago
  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.
  - aikah 12y ago
    > There are higher level frameworks Like?
- morganherlocker 12y ago
  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 https://github.com/Turfjs/turf [2] https://github.com/Turfjs/turf-buffer https://github.com/Turfjs/turf-buffer [3] https://github.com/Turfjs/turf-smooth https://github.com/Turfjs/turf-smooth
- phadej 12y ago
  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!
- lowboy 12y ago
  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
vlunkr 12y ago
Oh man I hope he wasn't being serious when he wrote that. But you are right, number of packages != quality of packages

by efdee 12y ago

untog 12y ago

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.

olalonde 12y ago
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.
- aikah 12y ago
  > There are higher level frameworks Like?
morganherlocker 12y ago
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 https://github.com/Turfjs/turf [2] https://github.com/Turfjs/turf-buffer https://github.com/Turfjs/turf-buffer [3] https://github.com/Turfjs/turf-smooth https://github.com/Turfjs/turf-smooth
phadej 12y ago
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!
lowboy 12y ago
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

vlunkr 12y ago

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