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

Poverty can be a form of disability; it can significantly impair your executive functioning, and make you literally unable to complete certain tasks

Fuck you, #Adobe, and the "open-use" you rode in on, for expecting bloggers to do your unpaid(!) advertising for you, and trying to dress it up as a courtesy

The internet works a lot better when you actually plug the fiber back into the modem

Every single data fetching library seems to make the exact same mistake:
- Realize that nested data retrieval can be reliably decomposed into multiple retrieval calls
- Settle on this approach in the library design and build around all the tools around it
- "Oh right, we need support for mutations too"
- Try to extend the existing fetching model with a 'mutation mode'
- Fail to realize that nested mutations *do not* decompose into multiple mutation calls... and end up with a completely bolted-on mutation API

Is this like, the data fetching API design equivalent of "forgetting to put on the heatshrink before soldering the connector every time", or something?

Show me someone talking about their favourite language features, and I will tell you their politics

(Hardly a novel insight, and one that has appeared in many fields besides programming, but somehow programmers still like to believe they are 'objective' and 'neutral')

"But people want known-good libraries, instead of hunting for them!"

If you have functioning package management (which you should, it's 2023!), then you can literally just have external packages for those libraries that are published and officially sanctioned by your core devs

Now you get all the benefits of standard libraries with almost none of the downsides

Nothing should be standardized in your programming language or standard library unless it is absolutely critical for the functioning of the ecosystem

Because it doesn't matter what your deprecation policy is on paper, as soon as you declare something an official part of the language, it is set in stone until the heat death of the universe, due to the special status it conveys to users

You will be forever stuck with it, even if the design turns out totally broken

I don't know... maybe because the async actually *works* the first time, everytime? And you don't need to play Quartets to try and find async libraries that work with each other?

Because there's an off-the-shelf library for almost every problem you might have, without being forced to buy into a monstrous-to-upgrade "framework"?

Because aside from globals (which ~nobody uses anymore), there's a near-guarantee that you can trace back any identifier or reference to its point of definition, without needing special analysis tools?

Because it has actual isolated modules, rather than some conflict-prone "namespace" nonsense that causes dependency version conflicts down the line?

Because it doesn't impose an arbitrary requirement of "one version per dependency across the entire codebase, including transitive dependencies", and so eliminates the usual dependency hell?

Because you don't need to be constrained to highly restrictive class syntax, just to get some good performance out of your code?

Because there are extensive and near-perfect compatibility layers to make the absolute most recent language features, even *experimental* ones, work in positively ancient environments?

Yes, I wonder why anyone would ever want to use Javascript.