3 ms·

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 everybod

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.

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.