Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@Scmbradley @schratze Responding to this seriously for a moment: I always put a lot of work into making sure my software works reliably. Sometimes that means not having certain features because they are impossible to implement reliably.

But what then happens, is that it fails to gain traction and adoption the way that shinier, less reliable options do, because on paper my thing has 'less features'. There are more factors that affect adoption, of course, but this is definitely a real issue.

And while adoption for the sake of adoption isn't useful, widespread adoption *is* usually how people learn of the existence of a thing. So the result is that I can't reach people who would have been interested in it.

And I feel like that's part of the problem here, not just for me - we need structures for distributing knowledge of tools and devices that may be obscure, but that are deliberately reliable, that don't rely on things just coincidentally landing at the feet of the right people, because that implicitly depends on it having mass market appeal.

Otherwise all the incentives are aligned to do the less reliable but more appealing thing.

@zens@merveilles.town I was providing a partial correction on a common misconception, with rationale and a boundary of where it applies, because this one often leads to people painting themselves into a corner and I would like to help prevent that.

I wasn't signing up for an adversarial argument that basically boils down to "I have no idea what you're doing but you definitely don't need X".

@zens@merveilles.town I have no idea what you're referring to there, to be honest, but I also don't feel like this is going to lead to a constructive discussion, to be honest.

You seem to have already decided that transitive dependencies are the wrong solution no matter what, and any attempt to engage with the question seems likely to just result in skipping over the nuance to try and find a way to argue that it's wrong anyway. I don't have the energy for that kind of adversarial discussion.

@affine@yourwalls.today Didn't get the weewoo here today :(

@crumbcake That holds true for (bundled) browser code; but crucially, not in environments with native support for modules, like Node.js, as there is no build step there.

Leading to a situation where everything seems to be 'fine' to people who only do browser-side code, but constant breakage in server environments of the same modules... 🥴

@zens@merveilles.town "Don't use transitive dependencies" is just a "you're holding it wrong" argument and not really useful; it doesn't recognize that there are very good reasons to do so, or provide any avenue for finding other solutions to those needs.

And yes, manifests exist. That's what I was referring to "just a manifest of the full dependency tree" - but that doesn't change anything about needing to do bundling, because you still need to *generate* that manifest, and "walking the dependency tree and building up a manifest of all the modules" is what bundling *is*; the output format (manifest or concatenated code) is just an artifact of that.

@zens@merveilles.town This one isn't *quite* right; the problem still exists to a more limited degree, as you still can't traverse a dependency tree over the network depth-wise without a full latency roundtrip per level, regardless of pipelining (as you can't predict transitive dependencies).

So you still need some kind of bundling process, the only question is whether it outputs a single bundle, many bundles, or just a manifest of the full dependency tree after doing so.

@isotopp@chaos.social @vladh And to be clear, it is very important to recognize the triviality of this 'solution' in the bigger scheme of things, and make sure that everyone understands that it is, at best, a small first step, and there is more work to do - such a project shouldn't start seeing itself as a saviour.

But that doesn't mean that there aren't still reasons to do it anyway. Many hands make light work, diverse tactics especially so.

@isotopp@chaos.social @vladh Yes, I understand what you're saying. What I'm trying to explain is that that isn't how it works - you can't just tell someone "go write letters instead".

Just because someone is able to optimize power usage of code, doesn't mean they are also able to spend that same time writing letters to politicians! If you tell them not to 'waste their time' on code optimization, chances are that instead they will do... nothing at all, as that is just not where their ability and interest lies.

Even *if* improving code efficiency had no meaningful benefit (and I suspect that to a degree, that is true), at the very least it is something that allows someone to engage with the topic of climate change and become involved with fighting it. A small but nonzero portion of those people will get involved in larger, more impactful efforts.

Also, "writing letters to politicians" is an odd example to pick here, given that that is almost the least efficient way possible of engaging with politics.