Without internet or AI I wouldn't attempt writing anything like that.

Let's agree to disagree.

It's becoming too complex, too unpredictable. Every query and variable becomes a surprise in production. It's too smart for its own good.

Calling it "Grey zone conflict" feels like the "Deep state" shenanigans... It's primarily marketing to achieve your goal.

We've seen the invasion of Iraq; that was all based on lies. We got ISIS as a result... "National security circles" look for evidence so it fits their narrative. Like watching FoxNews. It's a very narrowminded funnel of carefully picked pieces of evidence. They are not truth seekers that aim to provide a holistic view of the situation. No, they are scared aged men who love to control the narrative and see danger in everything in the hope to get more funding for their next projects.

Btw; banning TikTok is a good thing, but for other reasons entirely.

> Today many web developers consider jQuery to be “legacy software.” With all due respect to this perspective, jQuery is currently used on 75% of all public websites, a number that dwarfs all other JavaScript tools.

I feel that is misleading. I worked on a lot of websites and none of them included jQuery willingly or sometimes even knowingly.

Either it's shipped as a peer dependency or we're talking about wordpress and the like which use it (and drives much of the web!).

I've seen it frequently shipped because of scripts embedded into a larger frontend codebase. Stuff they really don't want there to begin with.

I do not for a second believe that 75% of frontend dev work is in jQuery. In fact, I'd be surprised if it's more than 5% of all frontend engineering work is using jQuery.

Obviously some people might still use it for whatever reason; but those are a tiny majority (and probably quite vocal about it / over represented if they still prefer it).

So yes, to all intends and purposes I would claim jQuery is legacy software. Current usage (wherever they got that number from) does not mean it's still the preferred choice for the majority of web developers.

First time I heard of OKLCH tbh. Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here?

Looking at the examples it does seem to offer some advantages; but was primarily surprised that they now use it as a default.

I do remember Go making backwards incompatible changes in some rare scenarios like that.

(and technically the loopvar fix was a big backwards incompatible change; granted that was done with a lot of consideration)

This will sound extremely harsh; but I noticed I strongly favour colleagues who do use AI-assisted tooling over those who do not. The PR, documentation and code just looks cleaner.

So if it comes to who I favour working with; it's usually people who rely on AI-tools. They deliver code I like maintaining more.

In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time debugging, this is true for any codebase.

But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of "learning-on-the-go" with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages).

Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere.

RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.

- Everything is a POST, so normal HTTP caching is out of the question.

- JSON RPC code generators are non-existent or badly maintained depending on the language. Same with doc generators.

- Batching is redundant with HTTP2, just complicates things.

- Because everything is a POST normal logging isn't effective (i.e. see the url in logs, easy to filter etc). You'll have to write something yourself.

- Not binary like Protobufs or similar

But yeah, "the silent pro's choice"... Let's keep it silent.

JSON RPC is pretty much dead at this point and superseded by better alternatives if you're designing an RPC service.

I'm shocked.

There must be something fundamentally different between the two, and I'm not sure what it is.

For good reason; the more TODOs and FIXMEs a codebase contains, the less impactfull they are. We had so many TODOs no-one every batted an eye when seeing them, and they never got fixed. It just made you feel bad.

Also a lot of TODO's expressed opinions about the "ideal" scenario, but in practice most of those TODOs were for code that was "fine" or "good enough". In those scenarios it's better to omit the TODO/FIXME keyword and just describe the design decision that was made.