3 ms·

The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modul

by lhnz 11y ago

The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modules, you're wasting a lot of valuable time. Does anybody know a quick way of making the right decision? NPM is like a crowded graveyard nowadays (or like .com domain names - where all of the good module names have been taken along time ago and now all the best practice modules have completely irrelevant names). There are thousands of buggy modules in which development has stalled, and it's easy to waste a lot of time trying to separate the wheat from the chaff. I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only after doing so am I able to make a decision. In terms of knowing what's cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea. I can't imagine what it'll be like to search for a module to handle something as common as config in a couple of years. Even when you constrain yourself to something like '12 factor config' there are many different implementations. Don't even get me started on the insane assembly required to get webpack-, babel-, cssmodules-, and postcss- to all work together. The problem is only going to get worse.

taurath 11y ago
Just like the difference between pre-internet post-internet days, the problem is no longer finding the information, its filtering the large amounts of available information. Same with libraries and modules - there's probably a module for a LOT of things. You eventually develop a good sense for what heuristics make a good module, and you develop in such a way that the cost of an accidental bad module is low. You can certainly find full-fledged frameworks out there that do everything for you and make your decisions for you, but the cost of getting that wrong is far higher than a bad module.
wwweston 11y ago
> I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.
- davedx 11y ago
  Don't keep us in suspense. Which one?
  - RyJones 11y ago
    The find/fix rate is one I look for.
  - wwweston 11y ago
    Honestly, I think it's better as a question/koan than as explained. Asking yourself how good these each of signals really is and asking yourself how they could fail is probably much better than having a random internet commentator try to talk you into it. But: - last commit: I'm not surprised to see this here. Almost the entire industry is deeply invested in the idea that software can never be done, only abandoned, so deeply it's almost invisible. And projects with enough surface area likely are like the proverbial shark: either moving or dead. But for modules with limited, well-defined functionality, reaching a steady state where the project is actually done and updates are rare should actually be a sign of quality. - number of contributors: again, I suspect that where this coheres with quality, it's probably correlated with size/surface area. Plenty of limited, well-defined projects probably are good with one or a handful of contributors. - interfaces: are we talking about presentation of the project? Or the UX of an app? Either one could be a sign of overall craftsmanship, or it could be a sign that the author is concerned with appearances/marketing. - code quality: tautologically true (code quality is related to project quality) but not helpful. One might easily mean "do the authors of this module follow my favorite code style guide," in which case I think this is extra likely to lead you astray. - unanswered issues: unanswered issues seem like a great signal. If they're present (and real), the author(s) either can't fix them, or the project is abandoned while actually needing improvement. Inversely, if there are answered issues, the project is being used and attended to.
EvanPlaice 11y ago
From a library developer perspective, the major issue I find with NPM is that it stores it's own copy of the source. Old but useful libraries will often stagnate and get forked by users who still want/need to carry on development. Linking directly to a repo would make more sense but that's not how most people use NPM. > In terms of knowing what's cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea. A lot of this stems from the fact that todays solutions will likely become tomorrow's technical debt. It's not a popular opinion on HN but adjusting development to follow current/future web standards is insurance against future technical debt. Webpack, for instance solves todays problems: Modules: Currently, there are 3 non-standards (AMD, UMD, CommonJS). To make 3rd party libs interoperable, all 3 standards have to be supported so Webpack handles the messy details. Which BTW is a huge improvement over not being able to use libs that don't support whatever non-standard you choose. As for future standards, Webpack is moving in a very positive direction by adding ES6 module support in v2. Transpiling: Transpiling as it's used today will likely become less relevant over time. In terms of Javascript, ES6 provides useful additions to make programming in vanilla JS much nicer. ES7 has the potential to shake things up even more in a really good way. For instance, decorators will make it much simpler and more straightforward to create higher order functions; which in turn will make it much easier to do functional-style programming in JS. The next major shift will come with CSS extensions. Less, SASS, Stylus are the current common non-standard solutions to the difficulty of managing large CSS codebases. I'd expect that the web standards people will eventually cherry-pick the good parts from them the way they adopted the good parts of CoffeeScript in ES6. Unfortunately, those who heavily rely on Less, SASS and Stylus will either have to adapt or continue to use/support the tools of a dying standard when everybody else moves on. Bundling: Bundling as we know it today is an anti-pattern but also a necessary evil due to the limitations of HTTPv1. Warming intermediate caches helps but a warm local cache trumps all. Unfortunately, bundling is in such widespread use the chances of a user having a warm cache are essentially nil. HTTPv2 will (hopefully) move influence developers to abandon bundling strategies, thereby improving cache reliability for all. The next major shift we need to improve cache reliability is a widely-adopted versioning strategy that library devs use to mark packages for long-term support. It's insane that everybody relies on bleeding version of dependencies but everybody bundles everything so there's no measurable benefit to sticking with an older, more stable version of a dependency. I would touch on the issues with the widespread adoption of functional-specific supersets of JS but -- considering the tastes of many HN users -- I really don't feel like being downvoted into oblivion. > Does anybody know a quick way of making the right decision? Try to see things from a long-term perspective. Stay cognizant of the nature of the hype cycle. Some technologies really do have the potential to provide huge improvements in performance and usability. Some will eventually provide the improvements they promise but the first version won't be good enough. Most tools -- no matter how useful they appear to be today -- will likely die or be replaced by something better in the future.
erikpukinskis 11y ago
Basically, you look at the project's social presence. That sounds kind of airy-fairy, but it's honestly how it works. You look at what the README says, how well it addresses questions, you look at the release history, see how maintainers interact with contributors, read a blog post or two to see how the maintainers are thinking. And then you make a judgement call. You don't have to get it right every time. That's the beauty of the modular approach. If you get it wrong, then you're smarter when you go to replace that piece of the infrastructure.
darkarmani 11y ago
You just have to look at the module named mkdirp to know there is a problem with hypermodularization. Here is all of the modules related to making a directory -- https://www.npmjs.com/search?q=mkdir https://www.npmjs.com/search?q=mkdir

by lhnz 11y ago

taurath 11y ago

Just like the difference between pre-internet post-internet days, the problem is no longer finding the information, its filtering the large amounts of available information. Same with libraries and modules - there's probably a module for a LOT of things. You eventually develop a good sense for what heuristics make a good module, and you develop in such a way that the cost of an accidental bad module is low. You can certainly find full-fledged frameworks out there that do everything for you and make your decisions for you, but the cost of getting that wrong is far higher than a bad module.

wwweston 11y ago

> I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.

davedx 11y ago
Don't keep us in suspense. Which one?
- RyJones 11y ago
  The find/fix rate is one I look for.
- wwweston 11y ago
  Honestly, I think it's better as a question/koan than as explained. Asking yourself how good these each of signals really is and asking yourself how they could fail is probably much better than having a random internet commentator try to talk you into it. But: - last commit: I'm not surprised to see this here. Almost the entire industry is deeply invested in the idea that software can never be done, only abandoned, so deeply it's almost invisible. And projects with enough surface area likely are like the proverbial shark: either moving or dead. But for modules with limited, well-defined functionality, reaching a steady state where the project is actually done and updates are rare should actually be a sign of quality. - number of contributors: again, I suspect that where this coheres with quality, it's probably correlated with size/surface area. Plenty of limited, well-defined projects probably are good with one or a handful of contributors. - interfaces: are we talking about presentation of the project? Or the UX of an app? Either one could be a sign of overall craftsmanship, or it could be a sign that the author is concerned with appearances/marketing. - code quality: tautologically true (code quality is related to project quality) but not helpful. One might easily mean "do the authors of this module follow my favorite code style guide," in which case I think this is extra likely to lead you astray. - unanswered issues: unanswered issues seem like a great signal. If they're present (and real), the author(s) either can't fix them, or the project is abandoned while actually needing improvement. Inversely, if there are answered issues, the project is being used and attended to.

EvanPlaice 11y ago

From a library developer perspective, the major issue I find with NPM is that it stores it's own copy of the source. Old but useful libraries will often stagnate and get forked by users who still want/need to carry on development. Linking directly to a repo would make more sense but that's not how most people use NPM. > In terms of knowing what's cutting-edge practice it seems you have to watch Twitter a lot and be careful not to follow every single bad idea. A lot of this stems from the fact that todays solutions will likely become tomorrow's technical debt. It's not a popular opinion on HN but adjusting development to follow current/future web standards is insurance against future technical debt. Webpack, for instance solves todays problems: Modules: Currently, there are 3 non-standards (AMD, UMD, CommonJS). To make 3rd party libs interoperable, all 3 standards have to be supported so Webpack handles the messy details. Which BTW is a huge improvement over not being able to use libs that don't support whatever non-standard you choose. As for future standards, Webpack is moving in a very positive direction by adding ES6 module support in v2. Transpiling: Transpiling as it's used today will likely become less relevant over time. In terms of Javascript, ES6 provides useful additions to make programming in vanilla JS much nicer. ES7 has the potential to shake things up even more in a really good way. For instance, decorators will make it much simpler and more straightforward to create higher order functions; which in turn will make it much easier to do functional-style programming in JS. The next major shift will come with CSS extensions. Less, SASS, Stylus are the current common non-standard solutions to the difficulty of managing large CSS codebases. I'd expect that the web standards people will eventually cherry-pick the good parts from them the way they adopted the good parts of CoffeeScript in ES6. Unfortunately, those who heavily rely on Less, SASS and Stylus will either have to adapt or continue to use/support the tools of a dying standard when everybody else moves on. Bundling: Bundling as we know it today is an anti-pattern but also a necessary evil due to the limitations of HTTPv1. Warming intermediate caches helps but a warm local cache trumps all. Unfortunately, bundling is in such widespread use the chances of a user having a warm cache are essentially nil. HTTPv2 will (hopefully) move influence developers to abandon bundling strategies, thereby improving cache reliability for all. The next major shift we need to improve cache reliability is a widely-adopted versioning strategy that library devs use to mark packages for long-term support. It's insane that everybody relies on bleeding version of dependencies but everybody bundles everything so there's no measurable benefit to sticking with an older, more stable version of a dependency. I would touch on the issues with the widespread adoption of functional-specific supersets of JS but -- considering the tastes of many HN users -- I really don't feel like being downvoted into oblivion. > Does anybody know a quick way of making the right decision? Try to see things from a long-term perspective. Stay cognizant of the nature of the hype cycle. Some technologies really do have the potential to provide huge improvements in performance and usability. Some will eventually provide the improvements they promise but the first version won't be good enough. Most tools -- no matter how useful they appear to be today -- will likely die or be replaced by something better in the future.

erikpukinskis 11y ago

Basically, you look at the project's social presence. That sounds kind of airy-fairy, but it's honestly how it works. You look at what the README says, how well it addresses questions, you look at the release history, see how maintainers interact with contributors, read a blog post or two to see how the maintainers are thinking. And then you make a judgement call. You don't have to get it right every time. That's the beauty of the modular approach. If you get it wrong, then you're smarter when you go to replace that piece of the infrastructure.

darkarmani 11y ago

You just have to look at the module named mkdirp to know there is a problem with hypermodularization. Here is all of the modules related to making a directory -- https://www.npmjs.com/search?q=mkdir https://www.npmjs.com/search?q=mkdir