7 ms·

The real problem with npm and JavaScript is not the package manager, it is the lack of a standard library bundled with the runtime that has such basic functions

The real problem with npm and JavaScript is not the package manager, it is the lack of a standard library bundled with the runtime that has such basic functions. To someone coming to JavaScript from a Java/C# world, the fact that a package like isArray actually exists, nevermind the ridiculous number of downloads it has, is mind boggling. Using a dependency like this on a Java project will get you crucified in any sane team. If you want to get out of this dependency hell, bundle these small, essential functions into the runtime.

woogley 9y ago
Depends on the team. I would not approve anything other than using a runtime library or importing 'core-js/fn/array/is-array' from the wonderfully modular core-js: https://github.com/zloirock/core-js https://github.com/zloirock/core-js Although for this particular strawman I think `foo.constructor === Array` is probably enough.
- deleted 9y ago
  [deleted]
- alaaibrahim 9y ago
  What if foo is `null` or `undefined` ?
banjomonster 9y ago
Array.isArray is available in the runtime, but it was a later addition so folks may be downloading it for compatibility. There is a LOT of that in the javascript ecosystem. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
styfle 9y ago
They are bundled, it’s called ES6/ES2015. But for backwards compatibility, the userland packages are still used regularly.
- slig 9y ago
  > They are bundled, it’s called ES6/ES2015 I wish. See the `Set` implementation [1], for instance. It's lacking very basic stuff like union and intersection, forcing the user to copy/paste code or add another dependency. Does someone know why they do that? Looking from the outside it seems that the committee in charge of this doesn't know what they're doing. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - styfle 9y ago
    Agree, Set is a disappointment. I think the “Why” is because it’s easier to get everyone to sign off on small changes than large changes that can never be removed. The web platform has to live for a long time and be backwards compatible.
    - slig 9y ago
      But the `Set` was completely new. And things like union and intersection are basic features and without it the `Set` thing is almost useless, so it wouldn't make any sense to remove they in the future as much as it didn't make sense to not include them now.
      - styfle 9y ago
        I agree with you but there are ways to perform union and intersection with existing APIs. http://2ality.com/2015/01/es6-set-operations.html http://2ality.com/2015/01/es6-set-operations.html > Long-term, I expect JavaScript to have built-in functionality for this, e.g. via functions that operate on iterables
deleted 9y ago
[deleted]
pavlov 9y ago
I agree with your general sentiment, but Array.isArray() has been standard since about 2010. It’s even in IE9. Anyone using an npm package for this feature deserves the beating. IMO the problem with npm is that it makes no distinction between snippets, libraries, frameworks and scripted command line tools. An npm package can be any of these. I feel there perhaps should be separate namespaces and package managers for all four — e.g. an inlining minimal “node snippet manager”, a standardized framework installer for things like create-react-app, and so on.
- styfle 9y ago
  Some packages ship with both importable module as well as a global CLI. So it’s hard to categorize packages on into a single category.
  - pavlov 9y ago
    The library should be in a library package manager, and the CLI tool should be installed separately with a dependency on the library. There’s no benefit to mixing these together. If you hand me a .framework and a .app for macOS, it’s immediately clear which is which. This isn’t an unreasonable standard for distributing programs.
TAForObvReasons 9y ago
The flipside is that the standard library from Java / C# are huge, large enough that there's basically one complete and proper implementation. In JS land, you have multiple different implementations with different feature sets and behaviors. Code written for V8/chrome/node may behave differently in safari/jscore or IE/edge/chakra or firefox/spidermonkey.
- ssalazar 9y ago
  By flipside are you suggesting that managing multiple feature sets/behaviors across implementations is a good thing?
  - deleted 9y ago
    [deleted]
- quantummkv 9y ago
  This can be the case for big or difficult to implement functionality like async/await. But for smaller functions like isArray, isObject and leftpad this should not be the case. C++ has a lot of different standards, compilers and implementations. There are differences in vc++ and gcc that can prevent compilation without flags or custom implementations. But I am sure that simple functions like printf or strcpy behave same across implementations. Even in Java you have Oracle JVM and android's custom dalvik/ART. But the standard Java functions still work the same. Same with .net/mono.
  - deleted 9y ago
    [deleted]
dguo 9y ago
Keeping the Node standard library small seems to be a deliberate approach. See this post for some elaboration: https://medium.com/the-node-js-collection/keeping-the-node-js-core-small-137f83d18152 https://medium.com/the-node-js-collection/keeping-the-node-j...
sixdimensional 9y ago
Perhaps WebAssembly will help with this, we could make a standard library in WebAssembly which is highly performant, and can be called from regular Javascript code.
- chr1 9y ago
  Not likely. Calling from javascript to webassembly is slow, webassembly can't create js objects, and usually it is not much smaller than the equivalent js code, due to lower level of abstraction.
  - sixdimensional 9y ago
    That's interesting - I see from some research that you are right in stating that calling from javascript to webassembly is slow[1]. Which is.. kind of surprising, I didn't realize that. I sort of expected WebAssembly to have a performant JS API, since its origin is in asm.js, which was a peformant subset of javascript - but I see now that asm.js too had this same problem. Which again surprises me, as I sort of expected it to be a bit like Macromedia Flash, which I recall had a Javascript API that seemed to perform well enough, although I suspect it wasn't used for high-performance scenarios, so maybe not. It seems odd to me that the interfacing between these two technologies would be so separate that it would cause performance issues.. why would it not be something that is improved? Perhaps you'll have a flip where you write javascript and some other language, and the javascript runs as an interpreted language on the same VM with some compiled code, together... Hmm.. an interpreted language interfacing with compiled bytecode efficiently... Python.. LISP can do it.. why not Javascript/WebAssembly? [1] https://github.com/WebAssembly/design/issues/1126 https://github.com/WebAssembly/design/issues/1126
koolba 9y ago
If you were planning on writing modern Java and targeting JDK 1.3 you'd have just as many libraries.
vlunkr 9y ago
I think perhaps the biggest problem is the lack of a flat dependency system. So not only does your project depend on isArray, it may depend on 5 different versions of it. The sheer number of deps a seemingly normal React app has is crazy. Especially with webpack, babel, etc.
- lugrugzo 9y ago
  Npm3 has flat dependency system.
  - mstade 9y ago
    It doesn’t. It has a deduping system, which may still leave you with multiple versions installed if there are incompatible version requirements in the dependency tree. A flat system would mean there’s only ever a single version installed. Or at least, I think that’s what OP means, since that’s the only definition I’ve ever heard.
- Kamshak 9y ago
  It's what was there with bower but that has a lot of problems as well. So many in fact that everyone has moved to npm

woogley 9y ago

Depends on the team. I would not approve anything other than using a runtime library or importing 'core-js/fn/array/is-array' from the wonderfully modular core-js: https://github.com/zloirock/core-js https://github.com/zloirock/core-js Although for this particular strawman I think `foo.constructor === Array` is probably enough.

deleted 9y ago
[deleted]
alaaibrahim 9y ago
What if foo is `null` or `undefined` ?

banjomonster 9y ago

Array.isArray is available in the runtime, but it was a later addition so folks may be downloading it for compatibility. There is a LOT of that in the javascript ecosystem. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

styfle 9y ago

They are bundled, it’s called ES6/ES2015. But for backwards compatibility, the userland packages are still used regularly.

slig 9y ago
> They are bundled, it’s called ES6/ES2015 I wish. See the `Set` implementation [1], for instance. It's lacking very basic stuff like union and intersection, forcing the user to copy/paste code or add another dependency. Does someone know why they do that? Looking from the outside it seems that the committee in charge of this doesn't know what they're doing. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- styfle 9y ago
  Agree, Set is a disappointment. I think the “Why” is because it’s easier to get everyone to sign off on small changes than large changes that can never be removed. The web platform has to live for a long time and be backwards compatible.
  - slig 9y ago
    But the `Set` was completely new. And things like union and intersection are basic features and without it the `Set` thing is almost useless, so it wouldn't make any sense to remove they in the future as much as it didn't make sense to not include them now.
    - styfle 9y ago
      I agree with you but there are ways to perform union and intersection with existing APIs. http://2ality.com/2015/01/es6-set-operations.html http://2ality.com/2015/01/es6-set-operations.html > Long-term, I expect JavaScript to have built-in functionality for this, e.g. via functions that operate on iterables

deleted 9y ago

[deleted]

pavlov 9y ago

I agree with your general sentiment, but Array.isArray() has been standard since about 2010. It’s even in IE9. Anyone using an npm package for this feature deserves the beating. IMO the problem with npm is that it makes no distinction between snippets, libraries, frameworks and scripted command line tools. An npm package can be any of these. I feel there perhaps should be separate namespaces and package managers for all four — e.g. an inlining minimal “node snippet manager”, a standardized framework installer for things like create-react-app, and so on.

styfle 9y ago
Some packages ship with both importable module as well as a global CLI. So it’s hard to categorize packages on into a single category.
- pavlov 9y ago
  The library should be in a library package manager, and the CLI tool should be installed separately with a dependency on the library. There’s no benefit to mixing these together. If you hand me a .framework and a .app for macOS, it’s immediately clear which is which. This isn’t an unreasonable standard for distributing programs.

TAForObvReasons 9y ago

The flipside is that the standard library from Java / C# are huge, large enough that there's basically one complete and proper implementation. In JS land, you have multiple different implementations with different feature sets and behaviors. Code written for V8/chrome/node may behave differently in safari/jscore or IE/edge/chakra or firefox/spidermonkey.

ssalazar 9y ago
By flipside are you suggesting that managing multiple feature sets/behaviors across implementations is a good thing?
- deleted 9y ago
  [deleted]
quantummkv 9y ago
This can be the case for big or difficult to implement functionality like async/await. But for smaller functions like isArray, isObject and leftpad this should not be the case. C++ has a lot of different standards, compilers and implementations. There are differences in vc++ and gcc that can prevent compilation without flags or custom implementations. But I am sure that simple functions like printf or strcpy behave same across implementations. Even in Java you have Oracle JVM and android's custom dalvik/ART. But the standard Java functions still work the same. Same with .net/mono.
- deleted 9y ago
  [deleted]

dguo 9y ago

Keeping the Node standard library small seems to be a deliberate approach. See this post for some elaboration: https://medium.com/the-node-js-collection/keeping-the-node-js-core-small-137f83d18152 https://medium.com/the-node-js-collection/keeping-the-node-j...

sixdimensional 9y ago

Perhaps WebAssembly will help with this, we could make a standard library in WebAssembly which is highly performant, and can be called from regular Javascript code.

chr1 9y ago
Not likely. Calling from javascript to webassembly is slow, webassembly can't create js objects, and usually it is not much smaller than the equivalent js code, due to lower level of abstraction.
- sixdimensional 9y ago
  That's interesting - I see from some research that you are right in stating that calling from javascript to webassembly is slow[1]. Which is.. kind of surprising, I didn't realize that. I sort of expected WebAssembly to have a performant JS API, since its origin is in asm.js, which was a peformant subset of javascript - but I see now that asm.js too had this same problem. Which again surprises me, as I sort of expected it to be a bit like Macromedia Flash, which I recall had a Javascript API that seemed to perform well enough, although I suspect it wasn't used for high-performance scenarios, so maybe not. It seems odd to me that the interfacing between these two technologies would be so separate that it would cause performance issues.. why would it not be something that is improved? Perhaps you'll have a flip where you write javascript and some other language, and the javascript runs as an interpreted language on the same VM with some compiled code, together... Hmm.. an interpreted language interfacing with compiled bytecode efficiently... Python.. LISP can do it.. why not Javascript/WebAssembly? [1] https://github.com/WebAssembly/design/issues/1126 https://github.com/WebAssembly/design/issues/1126

koolba 9y ago

If you were planning on writing modern Java and targeting JDK 1.3 you'd have just as many libraries.

vlunkr 9y ago

I think perhaps the biggest problem is the lack of a flat dependency system. So not only does your project depend on isArray, it may depend on 5 different versions of it. The sheer number of deps a seemingly normal React app has is crazy. Especially with webpack, babel, etc.

lugrugzo 9y ago
Npm3 has flat dependency system.
- mstade 9y ago
  It doesn’t. It has a deduping system, which may still leave you with multiple versions installed if there are incompatible version requirements in the dependency tree. A flat system would mean there’s only ever a single version installed. Or at least, I think that’s what OP means, since that’s the only definition I’ve ever heard.
Kamshak 9y ago
It's what was there with bower but that has a lot of problems as well. So many in fact that everyone has moved to npm