4 ms·

I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those funct

I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those functions into their own project or there should be more common used packages that bundle these one-liners. I mean is_promise() and left_pad() are not worth their own package. Packages-dependencies of 10000 packages for trivial programs are just insane. Is someone going to fix that?

krapp 6y ago
>Is someone going to fix that? Probably not. There is too much code in the wild, and NPM owns the entire JS ecosystem, and there has been too much investment in that ecosystem and its culture at this point for a change in course to be feasible. The JS universe is stuck with this for the foreseeable future.
- jackewiehose 6y ago
  Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.
  - krapp 6y ago
    Not everyone would use it, that's my point. The inertia behind the existing system is too great, especially in enterprise. All that would happen is that library would become just another Node package, and then you've got the "n+1 standards" problem. The "nonexistent standard library" wasn't a problem in the days when javascript development meant getting JQuery and some plugins, or some similar library. It only became a problem after the ecosystem got taken over by a set of programming paradigms that make no sense for the language. Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser.
    - jackewiehose 6y ago
      > Not everyone would use it If the right people would provide the library, it would be used by enough people. > Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser Whats the point of inside or outside of the browser?
      - krapp 6y ago
        The point is that different languages are best suited to different tasks. Javascript is a simple, very loosely typed scripting language with prototypal inheritance that was developed to be run in the browser. It's a DSL, not a general purpose programming language. Using it elsewhere for applications where another language with stronger and more expressive types would be more appropriate requires hacks like compiling it from another (safer, more strongly typed) language like Typescript, which still results in code that can be fragile because it only simulates (to the degree that a JS interpreter allows) features that the language doesn't actually support. See the attempt to "detect if something is a Promise" as an example - the function definition for the package makes it appear as if you're actually checking a type, but that's not what the package does. Most of the unnecessary complexity in modern JS, as I see it, comes from the desire to have it act and behave like a language that it simply isn't.
        jackewiehose 6y ago
        > It's a DSL, not a general purpose programming language Sorry, but I fear that ship has sailed ;-) And I've heard JS was developed by someone who wanted to give us Scheme (you can't go more general purpose than that) but had to resort to a more "friendly" java-syntax. IMHO javascript would be a great general purpose language if the ecosystem wouldn't be such a mess.
        krapp 6y ago
        >Sorry, but I fear that ship has sailed ;-) I know, I know. If anyone needs me I'll be in the angry dome.
  - jessaustin 6y ago
    Several of these already exist, like lodash and underscore (which is a subset of lodash). After the rapid improvements on both the browser and node sides of the last couple of years (which filled in many of the blanks in this hypothetical "standard library"), they are less necessary than they may have been before. Also they can become something of a crutch. Fixing a bug a couple of days ago, I realized that an argument of Object.assign() needed to be deep-copied. Rather than adding a dependency for lodash or underscore or even some more limited-purpose deepcopy package, I just figured out which member of the object needed to be copied and did so explicitly. Done. Another good way to not have to depend on big/tiny/weird modules published by others is to use coffeescript. So much finicky logic and array-handling just goes away.
- hombre_fatal 6y ago
  It's just a cultural problem. There's no reason why a library should abstract away `typeof obj.then === 'function'` if they want to check if something is a promise. Just write a one-liner the same way you don't pull in a `is-greater-than-zero` lib to check x>0. The problem is when you try to level criticism at this culture and a cloud chorus of people will show up to assert that somehow tiny deps are good despite these glaring issues (a big one just being security vulns). And funnily enough, the usual suspects are precisely people publishing these one-liner libs. Then people regurgitate these thoughts and the cargo cult continues. So there's no "fix" for NPM (not even sure what that would mean). I mean, anyone can publish anything. People just have to decide to stop using one-liner libs just because they exist.
aylmao 6y ago
I see a lot of criticism to one-line packages, but IMO in the end what matters is the abstraction. Thinking of the package as a black box, if the implementation for left-pad or is-promise was 200 lines would it suddenly be ok for so many other packages to depend on it? Why? The size of the package doesn't make it less bug-prone. I see plenty of people who are over-eager to always be up-to-date, when there really isn't any point to it if your system works well, and so they don't pin their versions. This will break big applications when one-line packages break, but also when when 5000-line packages break. Dependencies are part of your source, don't change it for the sake of changing it, and don't change it without reviewing it.
- fludlight 6y ago
  It would be more ok if left-pad was part of a package called, say, text-utils which also included right-pad, etc. Same with is-promise, it sounds like it should be a function in a package called type-checker.
- jackewiehose 6y ago
  > The size of the package doesn't make it less bug-prone. Of course it does. It's more bug-prone just by being a package. More code is more bugs and more build-system annoyance is more terror (=> more bugs). If I only need one line of functionality I will just copy and paste that line into my project instead of dealing with npm or github. > Dependencies are part of your source I agree. If you see news about broken packages like this and you don't just shrug your shoulders your build-system might be shit.
t0astbread 6y ago
Isn't this what "utility libraries" like lodash and jQuery (each for their respective domains) are for?

krapp 6y ago

>Is someone going to fix that? Probably not. There is too much code in the wild, and NPM owns the entire JS ecosystem, and there has been too much investment in that ecosystem and its culture at this point for a change in course to be feasible. The JS universe is stuck with this for the foreseeable future.

jackewiehose 6y ago
Does it need much to change? I didn't mean to fix NPM. The problem is the non-existing standard-library. Just create one that everybody will use and everybody could cut their dependencies by thousands.
- krapp 6y ago
  Not everyone would use it, that's my point. The inertia behind the existing system is too great, especially in enterprise. All that would happen is that library would become just another Node package, and then you've got the "n+1 standards" problem. The "nonexistent standard library" wasn't a problem in the days when javascript development meant getting JQuery and some plugins, or some similar library. It only became a problem after the ecosystem got taken over by a set of programming paradigms that make no sense for the language. Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser.
  - jackewiehose 6y ago
    > Not everyone would use it If the right people would provide the library, it would be used by enough people. > Yes, in my mind you'd have to change everything from the ground up, starting with no longer using javascript outside of the browser Whats the point of inside or outside of the browser?
    - krapp 6y ago
      The point is that different languages are best suited to different tasks. Javascript is a simple, very loosely typed scripting language with prototypal inheritance that was developed to be run in the browser. It's a DSL, not a general purpose programming language. Using it elsewhere for applications where another language with stronger and more expressive types would be more appropriate requires hacks like compiling it from another (safer, more strongly typed) language like Typescript, which still results in code that can be fragile because it only simulates (to the degree that a JS interpreter allows) features that the language doesn't actually support. See the attempt to "detect if something is a Promise" as an example - the function definition for the package makes it appear as if you're actually checking a type, but that's not what the package does. Most of the unnecessary complexity in modern JS, as I see it, comes from the desire to have it act and behave like a language that it simply isn't.
      - jackewiehose 6y ago
        > It's a DSL, not a general purpose programming language Sorry, but I fear that ship has sailed ;-) And I've heard JS was developed by someone who wanted to give us Scheme (you can't go more general purpose than that) but had to resort to a more "friendly" java-syntax. IMHO javascript would be a great general purpose language if the ecosystem wouldn't be such a mess.
        krapp 6y ago
        >Sorry, but I fear that ship has sailed ;-) I know, I know. If anyone needs me I'll be in the angry dome.
- jessaustin 6y ago
  Several of these already exist, like lodash and underscore (which is a subset of lodash). After the rapid improvements on both the browser and node sides of the last couple of years (which filled in many of the blanks in this hypothetical "standard library"), they are less necessary than they may have been before. Also they can become something of a crutch. Fixing a bug a couple of days ago, I realized that an argument of Object.assign() needed to be deep-copied. Rather than adding a dependency for lodash or underscore or even some more limited-purpose deepcopy package, I just figured out which member of the object needed to be copied and did so explicitly. Done. Another good way to not have to depend on big/tiny/weird modules published by others is to use coffeescript. So much finicky logic and array-handling just goes away.
hombre_fatal 6y ago
It's just a cultural problem. There's no reason why a library should abstract away `typeof obj.then === 'function'` if they want to check if something is a promise. Just write a one-liner the same way you don't pull in a `is-greater-than-zero` lib to check x>0. The problem is when you try to level criticism at this culture and a cloud chorus of people will show up to assert that somehow tiny deps are good despite these glaring issues (a big one just being security vulns). And funnily enough, the usual suspects are precisely people publishing these one-liner libs. Then people regurgitate these thoughts and the cargo cult continues. So there's no "fix" for NPM (not even sure what that would mean). I mean, anyone can publish anything. People just have to decide to stop using one-liner libs just because they exist.

aylmao 6y ago

I see a lot of criticism to one-line packages, but IMO in the end what matters is the abstraction. Thinking of the package as a black box, if the implementation for left-pad or is-promise was 200 lines would it suddenly be ok for so many other packages to depend on it? Why? The size of the package doesn't make it less bug-prone. I see plenty of people who are over-eager to always be up-to-date, when there really isn't any point to it if your system works well, and so they don't pin their versions. This will break big applications when one-line packages break, but also when when 5000-line packages break. Dependencies are part of your source, don't change it for the sake of changing it, and don't change it without reviewing it.

fludlight 6y ago
It would be more ok if left-pad was part of a package called, say, text-utils which also included right-pad, etc. Same with is-promise, it sounds like it should be a function in a package called type-checker.
jackewiehose 6y ago
> The size of the package doesn't make it less bug-prone. Of course it does. It's more bug-prone just by being a package. More code is more bugs and more build-system annoyance is more terror (=> more bugs). If I only need one line of functionality I will just copy and paste that line into my project instead of dealing with npm or github. > Dependencies are part of your source I agree. If you see news about broken packages like this and you don't just shrug your shoulders your build-system might be shit.

t0astbread 6y ago

Isn't this what "utility libraries" like lodash and jQuery (each for their respective domains) are for?