Comment by lewisl9029 | Hacker News Reader

Comment by lewisl9029 | Hacker News Reader

Parent Full thread

> Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page.

A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand. Regardless, the book metaphor misses a lot of the nuance.

Of course taking the approach to an extreme would be detrimental. However, a vast majority of these small modules that are actually widely used consist of functions that may seem trivial at first sight, but actually contain a lot of corner cases and special considerations that a naive inline implementation could miss.

Sure, there are also plenty of trivial one-line modules on npm that don't fit into a such a description, but those are simply side effects of the unprecedented popularity of the platform and its completely open nature, and shouldn't be used to infer any kind of general trend towards "hypermodularisation" because very few reasonable developers would ever import them into their projects.

> A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand

No, that would not be an apt metaphor for the problem he is describing.

> Regardless, the book metaphor misses a lot of the nuance.

Not if you are trying to understand the point he is trying to make.

Is there any cost to creating modules, uploading them to npm and using them in other projects ? Clearly there is, as is shown by the world-wide breakage from yesterday. This is probably only one of such failure modes.

The point is, breaking everything into micro-modules can have benefits and costs. Ultimately, it is an engineering trade-off.

Now, it is possible that npm modules are at the right level of abstraction, even though other module systems in the world are not this granular. If this is due to the special nature of JavaScript then the point must be argued from that perspective.

> No, that would not be an apt metaphor for the problem he is describing.

That's because I don't agree that the problem he is describing exists, or at least not to the degree he's describing, which was full of hyperbole.

> Is there any cost to creating modules, uploading them to npm and using them in other projects ? Clearly there is, as is shown by the world-wide breakage from yesterday. This is probably only one of such failure modes.

This was a failure on npm's side by including a functionality that allows users to trivially remove packages from a package management system that is used by hundreds of other packages, something that most major package management systems have decided was a bad idea.

> The point is, breaking everything into micro-modules can have benefits and costs. Ultimately, it is an engineering trade-off.

Agreed. And I don't think nearly as many people are erring on the extreme side of this tradeoff to the degree that he's describing.

> This was a failure on npm's side by including a functionality that allows users to trivially remove packages from a package management system that is used by hundreds of other packages, something that most major package management systems have decided was a bad idea.

That is emphatically not the problem. The author of those modules could have just as easily modified the code instead of deleting it:

    function leftpad(str, len, ch) {
        // NPM won't let me delete modules, so here you go
        return "";
    }

Now you'd have an even harder time figuring out what happened to your code that you did if the module just disappeared. What you're asking for is basically for the repository to adopt a policy of "all maintainers must be given free rein to get their modules correct and keep them maintained, but they shouldn't have the ability to do anything that causes problems downstream" which is impossible and frankly silly.

The problem is the dependency, not the precise mechanism by which that dependency screws you when it goes bad.

You can't republish with the same version number, so you would be protected if you're pinned to a specific release.

At which point you don't get bug fixes. This is an old problem and there is no good solution.

You get bug fixes when you upgrade, deliberately.

This is what everyone should do ideally, but that means your solution is conscientiousness, and good luck spreading that across all your dependencies.

> for the problem he is describing.

Because it is a strawman.

Reply on news.ycombinator.com