[Klathmon]

I'd argue that it's not exactly "better", but more that it just makes different tradeoffs.

Using a full well-written* dependency for something not part of your "core competency" (even something seemingly trivial) is often a better choice in my opinion. That dependency will often know the "unknown unknowns" to you since their "whole purpose" is solving that one issue.

In this case, and from what I can see from my VERY small glance at the code, I'd argue using a polyfill would be a better choice in this situation. The polyfill has cross-browser tests, ensures compatibility, continually tests against new browser versions and will alert you and shield you from things if they change, download size is less of a worry for extensions and most of it no-ops away in 100% supported browsers, and it's maintained by mozilla.

Obviously there might be additional reasons why the uBlock origin developer isn't using it, it might be super overkill for his needs, he might consider the browser API part of his "core competency" and therefore shouldn't be relying on 3rd party code for it. I'd trust him more than myself here since I know so little about the domain. And I had a similar question to the GP commenter of why he decided to avoid the polyfill.

Your little saying isn't a useful answer, and the dig at "modern javascript developers" is not only unnecessary but also a real annoyance for me because it's used to dismiss just about every opinion while providing no real reasoning why you think that way. If you think a little copy is better, explain why! Don't just put down a group and leave without giving out any useful information!

* A "well written" dependency meaning something well tested, has a solid development team or dedicated person, and has somewhat widespread usage. Obviously it will differ depending on your needs.

[gridlockd]

> I'd argue that it's not exactly "better", but more that it just makes different tradeoffs.

Yes, it makes tradeoffs that are different, and those tradeoffs are different in that they're better. Often, not always. That's the statement in a nutshell.

> Using a full well-written* dependency for something not part of your "core competency" (even something seemingly trivial) is often a better choice in my opinion.

If it's outside your core competency, you can't really judge if a dependency is well-written. Popularity is an entirely unreliable quality metric. "Well-tested" also means nothing, a lot of people write completely useless unit tests but still fail on integration. How much time are you going to spend researching and vetting the code and the development "team" for that "seemingly trivial" dependency? How about writing a few lines of code and building a little bit of understanding instead? You can still use other people's code as a reference, even copy parts of it.

> That dependency will often know the "unknown unknowns" to you since their "whole purpose" is solving that one issue.

Sure, a few lines of code may have unknown unknowns. You know what else has? Other developers. Unbeknownst to you, "the team" could be the left-pad guy, who turns out to be "political". "The team" could be the guy that just hands over an unmaintained repository to a cryto-thief from China. That one took several weeks to get noticed by the community.

You start with one little dependency for one use-case, you end up with hundreds if not thousands of dependencies. You realistically have no capacity to deal with this in a diligent manner.

One could argue that by using "modern Javascript" with its pathological reliance on micro-dependencies, one has already given up control to the hive of random developers anyway, so one more dependency wouldn't hurt. I probably would agree with that. That doesn't mean every Javascript program would be better off this way.

[Klathmon]

>If it's outside your core competency, you can't really judge if a dependency is well-written.

Of course you can. I can not understand the details of something like the webextensions surface area, but still can look at the polyfill and understand that it's well written, that the tests aren't useless, that the popularity isn't faked, and that the maintainer is worthy of trust.

Nothing is foolproof, but I'd be much more willing to put things that I don't fully understand into someone else's hands who claims to have a lot of experience and has a lot of support from people who do understand that thing. Especially when the alternative is to trust myself who verifiably doesn't understand the thing.

>How much time are you going to spend researching and vetting the code and the development "team" for that "seemingly trivial" dependency?

That's a really good question! For me it depends on the project. A core project which has access to a lot of PII or is an important part of our infrastructure, i'm going to spend quite a while vetting a dependency. I might see what else the author has written, I might see how they release, how long they've been in the game, how their tests look, past PRs and issues, release cadence, backwards compatibility, and more. For an extra utility that is not critical? I might spend like 15 minutes, or even less depending on what it is doing and how widespread it's usage is. Looking at the chances of me getting a malicious developer or a very broken update that I didn't test against or see is much smaller than the chances that I'll write a bug and not test it, or I'll not fully understand a domain and will add subtle bugs into it, and won't even know how to test it correctly.

>Other developers.

And that's a risk that many are willing to take quite often. You can't completely rid yourself of dependencies. You can't 100% vet all 3rd party code, and you can't run entirely on first party code. It's not possible. So you trust some things here and there, you lock down dependencies so they don't update unless you say to, you review things and limit the scope of permissions. All things you should be doing anyway. Yes, it's a tradeoff, but it's one that the vast majority of code I've written is more than safe to make, especially when the author of a library is also the author of the browser it will be running in...

>You start with one little dependency for one use-case, you end up with hundreds if not thousands of dependencies. You realistically have no capacity to deal with this in a diligent manner.

But we do! That's what dependency managers are for! I can seamlessly replace dependencies, even several layers deep. I can scan and get diffs on changes, I can easily audit the dependency tree to determine if known vulnerabilities are found and either remove the library or update it. Again, it won't work in 100% of cases, but you aren't going to write 100% correct code yourself either.

>One could argue that by using "modern Javascript" with its pathological reliance on micro-dependencies, one has already given up control to the hive of random developers anyway, so one more dependency wouldn't hurt. I probably would agree with that.

Using 3rd party dependencies is a far cry from "giving up control to the hive of random developers". Just like how you using a browser to post this comment which relies on a compiler which uses tools written in python which relies on a python interpreter which itself relies on another compiler which relies on OS libraries which rely on more and more and more isn't trusting the "hive of random developers" either. There are checks, there are audits, there are tools to manage that at just about every step. Javascript has them as well.

There's being careful, and there's being paranoid. Sometimes paranoid is needed, and I do actually agree with a lot of your arguments if they apply (For the love of god don't use one-line dependencies, don't use dependencies written by an author with an agenda who has shown themselves willing to delete/maliciously-break packages, don't just add dependencies without any review or oversight or testing), AND I do agree that the JS ecosystem takes it a bit far (although I'm not fully on-board with if it's a bad thing entirely yet), but don't just throw out statements like "a little copying is better than a little dependency". That's how you get dogmatism which just swings the pendulum in the other direction and we end up with unmaintainable statically-compiled messes with vulnerabilities that can't be found and patched on any realistic timeframes.

[gridlockd]

> Of course you can. I can not understand the details of something like the webextensions surface area, but still can look at the polyfill and understand that it's well written, that the tests aren't useless, that the popularity isn't faked, and that the maintainer is worthy of trust.

No you can't, at least not in the general case. You can trust Mozilla because it's Mozilla, but ultimately that's an "argument from authority".

> Looking at the chances of me getting a malicious developer or a very broken update that I didn't test against or see is much smaller than the chances that I'll write a bug and not test it, or I'll not fully understand a domain and will add subtle bugs into it, and won't even know how to test it correctly.

Perhaps, but unless the code you are writing is "safety-critical", those "low chances" are outweighed by the fact that a malicious actor can do far more damage than some bug you introduced.

Also, you have to multiply those low chances with the large amount of micro-dependencies that you might bring in through this attitude.

> You can't 100% vet all 3rd party code, and you can't run entirely on first party code.

Of course you can, unless you count the runtime environment as third-party code, which I don't.

> But we do! That's what dependency managers are for!

Yeah, well. Believe that if you must.

> Just like how you using a browser to post this comment which relies on a compiler which uses tools written in python which relies on a python interpreter which...

This is a slippery slope argument. I think there's a distinction to be drawn here.

CPython doesn't have a lot of dependencies, certainly no micro-dependencies. The amount of contributors is rather small and changes are extensively vetted. The standards for browsers are similarly high.

Your average NodeJS project, on the other hand, pulls in a thousand packages from a thousand authors, supposedly vetted by the community - but not really.

> don't just throw out statements like "a little copying is better than a little dependency". That's how you get dogmatism...

It's a proverb, I didn't make it up. I put in the "Often" just to make it sound less dogmatic. You took it out again, presumably so that your long diatribe doesn't look so misplaced.

Your mileage may vary.

[Klathmon]

>No you can't, at least not in the general case. You can trust Mozilla because it's Mozilla, but ultimately that's an "argument from authority".

I'm not saying absolute trust, I'm saying I trust them to write a better polyfill for extensions than I will. An argument from authority is okay when the alternative is an "argument from ignorance". I know I don't know the details, and I'm trusting someone who literally writes the runtime to know it better than me.

>Perhaps, but unless the code you are writing is "safety-critical", those "low chances" are outweighed by the fact that a malicious actor can do far more damage than some bug you introduced. >Also, you have to multiply those low chances with the large amount of micro-dependencies that you might bring in through this attitude.

I'm genuinely curious about this, because from my point of view the number of times that I've encountered a malicious actor is extremely small and is often dealt with within days if not hours. The number of times that i've encountered my own vulnerable code is much more common. And with non-malicious bugs/vulnerabilities the number is similar. It could be just because I find my own bugs easier, but I really think there is something to relying and trusting that the community is going to be able to do something better, faster, and more correctly than I will be able to. Add on the npm audit system which is constantly scanning and notifying about known vulnerable dependencies means I'll be able to find and solve bugs and vulnerabilities much faster than if I had written even most of it myself.

I'd love to see some actual studies done that aren't just relying on anecdotes to see how things really shake out, but I'm not sure how that would even work as there are so many other confounding factors here that make it really hard to make a hard rule about these things (there is a lot of garbage code on the internet and across most package managers, any study would need to separate the "nobody should ever use this" from the "looks good at first glance" code, and at that point you're just making an automated code reviewer...)

>This is a slippery slope argument. I think there's a distinction to be drawn here.

I completely agree, but often drawing those distinctions is arbitrary. You may draw it at the runtime, I tend not to because a runtime (or the tools that make the runtime, etc...) often have much more ability to cause problems than any runtime library does. 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's compilation depends on quite a lot of smaller tools, and the compilers they support and use depend on even more. As you get further down the stack things slow down and are often vetted much more, but that itself doesn't mean much as the "payoff" for a malicious actor to get into it is often equally greater.

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? And if you don't count the transitive dependencies for something like cpython, then it seems disingenuous to include them in your statements about how a node package pulls in thousands of dependencies. And if you draw the line at some dependencies being "okay" and others not based on number of authors, dependencies, the amount of vetting, and more, well you're doing exactly what I was advocating for above!

>I put in the "Often" just to make it sound less dogmatic.

That is fair, and I did remove it from the quote. But I started this whole thing because you didn't describe the reasoning behind why you felt that way, and without the why it is literally just dogmatism.

And to be honest I still don't feel you've given a great answer for it besides the idea that as the number of some dependencies goes up the risk of a malicious actor goes up. Which I don't necessarily disagree with! I guess I just draw the line at a different spot. For me the risk of a malicious actor is miniscule compared to the risk of not completing the project from having to write so much code to avoid dependencies, writing bugs in domains that I don't understand, or copying code into my codebase that I don't fully understand breaking the dependency link that I can use to do automated scanning of. Not in every project, but in most.

[gridlockd]

> 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.