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.
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.
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.
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.
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.
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
Although for this particular strawman I think `foo.constructor === Array` is probably enough.
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.
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.
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.
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.
> This thing lets you understand the performance cost of npm install ing a new npm package before actually adding it to your bundle.
Unless you are specifically concerned about the `npm install` performance in node, in which case the npm package size is relevant, you never include the whole NPM package in your bundle. Most universal packages include separate dist files and separate entry points for node usage, so most of the content is actually not included.
If you are truly interested in bloat, let your bundler give you a summary at the end. Webpack can give you detailed information about what files were included, how much each file costs, and why the costs were incurred.
Lodash is a good example of this. The whole package is pretty big, and includes a functional programming variant (which I suppose is mostly wrappers around the other stuff, but it still adds weight).
So in practice you'll pretty much never be using the full package on account of 1) going for either require('lodash') or require('lodash/fp'), but not both, and 2) requiring specific functions through require('lodash/each') or whatnot.
The only way to get an accurate picture is to analyse the bundled package, or I suppose as part of the pipeline of whatever packaging solution you use.
Sorry, I think I broke it because I didn't understand it. I was really curious to see what angular-cli came in with in your tool, because my feeling is that it's very costly in terms of dependencies. The result never came back.. stuck at "Calculating File Sizes" was I not supposed to look at such types of packages?
If you're the author of `react-button`, it wouldn't make sense to add `react` + `react-dom` to account for it's size. In most cases, peer dependencies are already present in the user's projects.
good call, i'm a python guy who usually does science/infrastructure stuff but occasionally look at what is goin on with our front end libaries. Whenever i read thru our dep-chain i'm like holy shit guys, isArray is in here 4 times with 4 different versions.
All in all though cool project, looks great, works fast, provides good info. thanks and congrats
left-pad only adds 7ms on edge, seems worth it.
On the other hand, Jquery adds almost a second. And you hardly ever see pages that don't use it. (Unless they use some other heavy js library). But it's just soo convenient.
7ms is an eternity. You can do half of this [0] in 7ms or you can download one line of code. I’d be out of a job if I introduced 1/10 of that time for text padding.
Readit News
If you want to get out of this dependency hell, bundle these small, essential functions into the runtime.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
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.
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.
Although for this particular strawman I think `foo.constructor === Array` is probably enough.
Deleted Comment
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/Refe...
Deleted Comment
Unless you are specifically concerned about the `npm install` performance in node, in which case the npm package size is relevant, you never include the whole NPM package in your bundle. Most universal packages include separate dist files and separate entry points for node usage, so most of the content is actually not included.
If you are truly interested in bloat, let your bundler give you a summary at the end. Webpack can give you detailed information about what files were included, how much each file costs, and why the costs were incurred.
So in practice you'll pretty much never be using the full package on account of 1) going for either require('lodash') or require('lodash/fp'), but not both, and 2) requiring specific functions through require('lodash/each') or whatnot.
The only way to get an accurate picture is to analyse the bundled package, or I suppose as part of the pipeline of whatever packaging solution you use.
You can also see size results now when browsing a package on yarnpkg.com (look for "Size in browser") or as a sheild on some repos (WIP).
Suggestions welcome.
Thanks for building!
That's usually where I run in to bundle-phobia mentality (whether its warranted or not is another discussion).
All in all though cool project, looks great, works fast, provides good info. thanks and congrats
just ... wow :D
https://marketplace.visualstudio.com/items?itemName=wix.vsco...
But seriously great service, I was thinking about a CLI tool like this to estimate dependency impact before using it.
[0] http://www.adriancourreges.com/blog/2017/12/15/mgs-v-graphic...