> I'm not saying absolute trust, I'm saying I trust them to write a better polyfill for extensions than I will.
But that's not even the scenario here. You have the choice between bringing in a couple of lines of code you wrote yourself, or another dependency. Sure, in this case the vendor is entirely trustworthy and presumably competent. That's not the general case.
Let's say it was the general case, is it still worth increasing the complexity of your program for that little piece of functionality? Can you judge the runtime cost at all? What about bundle size? (Not applicable in this case, but still) Does the integrating the polyfill cause more work over a simpler solution?
Those are rhetorical questions, I don't want to keep on with the walls of text. The point is, the argument doesn't stop there.
> Counting "number of dependencies" is extremely hard, because like I said cpython does have quite a lot of dependencies, it just depends on where you draw the line.
CPython itself only has a handful of dependencies (libc, libffi, openssl, zlib, maybe a couple more) and almost all of them are optional. I'm drawing the line at actual dependencies of the program, not the operating system or the compiler (though neither GCC nor LLVM have a lot of dependencies either) or the basic build tools that ship with basically any UNIX-like system.
However, even if we added them all up I doubt we would have more "units" (programs, libraries) than in your average NodeJS project.
> And even if you do draw the line at the runtime or compiler, does that mean that the JS dependencies in my package.json that are dedicated to compilation and building don't count toward your numbers?
It doesn't matter, you're probably fucked either way.
But that's not even the scenario here. You have the choice between bringing in a couple of lines of code you wrote yourself, or another dependency. Sure, in this case the vendor is entirely trustworthy and presumably competent. That's not the general case.
Let's say it was the general case, is it still worth increasing the complexity of your program for that little piece of functionality? Can you judge the runtime cost at all? What about bundle size? (Not applicable in this case, but still) Does the integrating the polyfill cause more work over a simpler solution?
Those are rhetorical questions, I don't want to keep on with the walls of text. The point is, the argument doesn't stop there.
> Counting "number of dependencies" is extremely hard, because like I said cpython does have quite a lot of dependencies, it just depends on where you draw the line.
CPython itself only has a handful of dependencies (libc, libffi, openssl, zlib, maybe a couple more) and almost all of them are optional. I'm drawing the line at actual dependencies of the program, not the operating system or the compiler (though neither GCC nor LLVM have a lot of dependencies either) or the basic build tools that ship with basically any UNIX-like system.
However, even if we added them all up I doubt we would have more "units" (programs, libraries) than in your average NodeJS project.
> And even if you do draw the line at the runtime or compiler, does that mean that the JS dependencies in my package.json that are dedicated to compilation and building don't count toward your numbers?
It doesn't matter, you're probably fucked either way.