It simply depends on what you need.

I am gladly writing my own left-pad.

I am gladly using something like three.js if I need it.

The problem are the extreme stances. Don't add any dependency is as stupid as pulling in dependencies for every second line.

Please don't write your own left-pad. It's built into the standard library, under the name (String.prototype.)padStart.

That example was not picked at random.

Exemplum docet

I have seen this argument made many times, but none of the examples used illustrated it properly. Past a certain point, one becomes suspicious of the argument itself.

Have you ever wondered why padStart is part of the standard library?

You are unaware of a core part of JavaScript history, which is why you don't understand why "I'm not importing a library to do left pad" is not only a proper example, but THE BEST example.

String.padStart was added in 2017.

This happened in 2016 https://en.m.wikipedia.org/wiki/Npm_left-pad_incident

The left-pad incident was a problem with the build toolchain, not a problem with using a dependency. String padding is one of those fiddly things that you have to spend a couple of minutes on, and write 4–5 tests for, lest you get an off-by-one error. It makes perfect sense to bring in a dependency for it, if it's not available in the standard library, just as I might bring in a dependency for backprop (15 lines: https://github.com/albertwujj/genprop/blob/master/backprop.p...). My personal style is to reimplement this, but that doesn't mean it's foolish or unjustified to bring in a dependency.

It is, however, almost never justified to bring in a dependency for something that's in the standard library. The correct solution for that, in JavaScript-for-the-web, is a shim. left-pad is not a suitable example.

A better example would be https://www.npmjs.com/package/ansi-red:

  /*!
   * ansi-red <https://github.com/jonschlinkert/ansi-red>
   *
   * Copyright (c) 2015, Jon Schlinkert.
   * Licensed under the MIT License.
   */
  
  'use strict';
  
  var wrap = require('ansi-wrap');
  
  module.exports = function red(message) {
    return wrap(31, 39, message);
  };

But while this makes a point, does it really make the original point? This ansi-red library has at least two footguns, right off the bat.

My point was, that in the js/node universe - the extreme stances seem to be the default already.

(Unless the LLM is heavily biased towards certain code, maybe because blog entries promoting their libary got too much weight, but looking at a random js source of a webpage - they do mostly ship tons of garbage).

This depends on languages. For c/c++ without a package manager, people hesitate to add external dependencies (and especially when high performance is needed, e.g. game engines).

It surely does, but I think in most languages it is a bad idea, to add a external dependency, where it isn't needed. Like in the cases I mentioned, it was just standard stuff, already covered by the browser standard libaries.

So when I just need a simple connection to a web socket - I don't need that external baggage. But for high performance graphics, yeah, I won't write all the WebGL code by hand, but use Pixi (with the option of writing my own shader where needed).

Same. My standing system prompt for Claude is “do not suggest any 3rd party libraries unless I ask for other options.”

Python perhaps isn’t quite as bad as JS in this regard, but people still have a tendency to pull in numpy for trivial problems that stdlib can easily solve, and requests to make a couple of simple HTTP calls.

fascinating. What sort of web requests are you doing stuff are you doing that it's not just easier to use requests? I use requests pathologically, though I use things in the stdlib when it comes to it. personally I'm more surprised that it isn't in the stdlib by this point.

It's not a matter of easier, it's that I'm against adding dependencies when they're not meaningfully adding value. It's not that hard to use urllib.request if you just need to pull down some file in a script, or fire a web hook, etc.

If you need connection pooling, keep-alive, or any of the other features that requests adds, then sure, add it.