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

@teo Right, but the question I am trying to answer with this hypothesis is *why* that is, especially on the "by technical folks" side. Because that's a cultural thing, and that comes from somewhere!

@freakazoid I sort of treat those as agency issues, personally, because they tend to indirectly result *from* a lack of agency.

In a healthy organization, the amount of power that someone has over something, corresponds with the amount of responsibility they have over it. That's ultimately what agency is about in a project context, IMO.

But in the examples you mention, there is an (implicit) responsibility of keeping the thing running, because you will definitely be blamed if it fails, but no corresponding power to actually do so in the best way (eg. refactoring the code). Instead the priorities are set by someone else, who ultimately isn't the responsible party despite what the org chart says.

Likewise, peer feedback needs a healthy balance of power and responsibility; in this case it sounds like the power was functionally with senior folks, but the responsibility was passed off to others (by eg. punishing them in peer review).

I think something similar applies to a lot of workplace issues, where they derive - directly or indirectly, sometimes across multiple steps - from what is fundamentally a problem of agency.

@bananas A big reason I tend to avoid the term 'coop' is precisely that sort of issue; I prefer describing it in terms of people actually having agency, leaving the exact implementation of that undefined

@crumbcake That matches what I've seen, though paired with a crucial other trend that makes this possible in the first place: a broader move towards monolithic frameworks that reinvent their own wheels.

It used to be that modules had a single well-specified purpose, and it did that well, and even frameworks were generally designed to be highly interoperable. This eliminated whole classes of issues like month-long framework upgrade chores, library architecture incompatibilities, and bugs in utility functions (because everyone used the same well-tested ones).

However, since Node.js ended up in the startup hype cycle, that has been changing, with increasingly many do-it-all frameworks appearing (because those are really easy to market - large feature lists!), that barely interact or interoperate with the ecosystem at all, instead having their own buggy homegrown implementations of existing tools inlined into their codebase.

That does mean those frameworks are unlikely to run into issues interoperating with the existing ecosystem of CommonJS modules and can therefore afford to do ESM, but for all the wrong reasons...

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