Etcd, or, why modern software makes me sad

React I have been thinking about, having worked with it a lot and also recently done a React / TS / GraphQL (GraphQL may have been the poorest choice I made; time will tell) project.

I think React itself is awesome and I've always enjoyed it. While I'm not an expert, it's conceptual foundations and core abstractions felt right, and I do think it makes lots of frontend tasks simpler, especially for non-small projects.

At the same time the frontend ecosystem is a mess, as we all know, and as my CSS skills advance I see more just how much could be done with HTML / CSS / limited use of JS and your classic REST app, that's not a single-page app, and how much complexity might be able to be avoided and thus time saved.

At the same time, I don't think it's just "trendiness" that has caused the growth of React and SPA's. I think they give us various wins that we probably take for granted because we're now used to them.

So, the short answer to my long ramble is, I don't know.

But I do think React itself, specifically, hit a sweet spot in terms of being a powerful yet understandable tool, and still remaining a tool, as opposed to a framework.

I wish more people stuck with templating yaml would just issue a toJson instead of fiddling with indentation levels

The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.

To be clear, it's not like there are any HTTP/2-only servers in the world. HTTP/2 is something a client connection upgrades to. One might think of HTTP/2 and HTTP/3 not precisely as versions of HTTP, but rather as variants—HTTP/2 is "optimized binary HTTP, fixed-station profile" and HTTP/3 is "optimized binary HTTP, mobile-station profile."

(Mind you, they are versions relative to each-other, because HTTP/3 is strictly better at doing what HTTP/2 does than HTTP/2 is, so there's no reason to use HTTP/2 if you have HTTP/3.)

But as I was saying: nobody forces mobile devices to use HTTP/2; and by-and-large, they don't. HTTP/1.1 still has its use-cases; neither HTTP/2 nor HTTP/3 was designed to obviate HTTP/1.1's entire set of use-cases.

You know how SSH has sub-protocols, e.g. SFTP? HTTP/2 and HTTP/3 are to HTTP/1.1, as SFTP is to SSH. It's a mode you can put the connection into, that will optimize it for a certain profile of use-cases. No more, no less.

(You know what else is a mode you can put HTTP/1.1 into? Websockets! Again, a complementary use-case.)

> So, instead of optimising for file transfer, a control layer, and a communication/serialisation layer, they came up with a horrid mush that is http3. (or the googlenet)

If you think you're so smart, write an RFC (or even just, build a reference server) that's competitive in production performance for its use-cases over similar links.

There comes a point when explicit OSI-style encapsulating layering becomes an active hindrance; and for the use-case of "a server serving a million concurrent requests"—the FAANG-scale problem—they passed that point long ago.

Yes, we mere mortal client users and backend developers might not find such use-cases relevant; but take the perspective of e.g. an internet backbone ops engineer. By volume, most of the traffic going around the Internet goes to these sites. Optimizing just the traffic going to these sites—with a special protocol clients only use when speaking to these sites—makes the whole Internet faster, by reducing in size the huge blob of bandwidth-contention the requests to these few sites create.

Also, a design hint, if you actually want to try to build something competitive to HTTP/3: most of the problem being solved by HTTP/3 is that certain things are known to be optimal, but despite that, nobody can just force their corporate overlords to mandate a switch to those things right away. So HTTP/3 needs to be optimized for the case where you do the most fundamentally-performant things (e.g. using zero-copy binary serialization protocols like Capn Proto from a process with direct userland Ethernet access); and also for the cases where you do less fundamentally-performant things (like generating and streaming a JSONL or CSV stream line-by-line as the output rows gets computed by an in-process dataflow engine.) One might call HTTP/3 an arbitrary custom protocol, that happens to have semantics such that it can be downgraded to HTTP/1.1 by a link-to-link proxy. And that is a hard constraint to optimize under.

He is talking in absolutes (Kubernetes being the worst piece of software, etc) and trying to convince reader that "megacorporations" are the faceless evil enemy and they are making everything worse for everybody. Either you are with him or against him (servant of the evil megacorps' interest), there is no middle ground.

This person is not looking for a conversation, but looking for a fight. He seems to be angry and cannot direct his anger to "make good art" (Neil Gaiman - Make Good Art), instead trying to insult people and pushing them to a place where their emotions takes control and can be dragged into the mud.