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

@ben A couple that come to mind: the total reliance on phone numbers for a very long time (with all the issues that caused), the dubious defenses of centralization (there's a whole story here with them repeating already-debunked talking points), the magical (misleading) claims of metadata privacy through 'sealed sender' that don't seem to have any verifiable technical basis...

They have been a less-than-perfect steward of the platform, and that is a very big problem when it's being marketed to high-risk users like activists while also being heavily centralized and actively hostile towards eg. forks.

Basically, there's enough dubious stuff going on over the years that they've refused to acknowledge and fix, that I do not feel comfortable trusting them with my or anyone else's safety.

@rachaelspooky (As in, none of that "modern phones are too complicated and optimized to be made repairable" nonsense from manufacturers)

@rachaelspooky Having seen the internals of a Fairphone, I'm convinced that it would be totally viable to legally mandate repairable designs (to at least that level) for modern phones

@clarfonthey (And anything you see in the general tech news spheres is almost certainly from the former group, not the latter)

@clarfonthey That's a bit of a difficult one because there's not really one "JS ecosystem", it's more like two separate groups of people that drive change in the broader ecosystem; the startup bros (primarily responsible for the hype cycle) and the radical folks (primarily responsible for the 'invisible' infrastructure).

The latter group actually has a very good track record, and IMO a much better one than the language spec team! They've collectively standardized things like Promises/A+, CommonJS, ndarrays, lots of other semi-core things that are in widespread use. The former group is where almost all of the misery and framework churn comes from.

@clarfonthey Not sure what you're referring to with that - CommonJS was already a reasonable solution, and the idea of formalizing CommonJS in the spec was brought up very early already (including by me), so I don't see any reason why it couldn't have been done

@clarfonthey Right, but this could have literally been solved by just saying "if you use top-level await, your module is marked async and can only be imported with an async importing function" and that's it, you're done, it now exactly mirrors how sync/async works everywhere else in JS already. It didn't require a new, incompatible module format

@clarfonthey (None of this is a surprise given the general hype-driven culture plaguing the JS ecosystem)

@clarfonthey Well, sort of. That's the *immediate* issue, yes, but the more fundamental issue is that there was not actually a reason to reinvent modules in the first place.

None of the supposed benefits of ESM over CommonJS hold any water upon closer inspection. If they'd simply absorbed CommonJS into the spec and formalized it a bit more, this whole shitshow could have been avoided (as I'd already tried to tell some of the spec folks years ago, when there was still time to do so).

As far as I can tell, what happened here is that we had a solution that was basically complete from a functional perspective (CommonJS) but people insisted on making something *aesthetically* perfect and did not sufficiently consider the functional costs of doing that.

@mynameistillian I get the impression that it has improved a bit since people started posting on the Harris tags. Or am I imagining things?