https://news.ycombinator.com/item?id=23734442 (emphasis mine)

I see a lot of comments expressing that all we need is markdown plus this or that little bit. I think that's unreasonable. It might suit Joe developer just fine for reading blogs and news, but the world benefits enormously from the ability to build complex software applications at low cost. Imagine the alternative: Welcome to Mario's Pizza - you can order right from your own computer after we mail a disc* to your house (*requires Windows 8 or newer)!

Also, some of the CSS and JS hatred is piffle. Publishers absolutely abuse these languages and it gets pretty bad on news websites especially. But I do not find that most or even many of the sites I visit perform badly on my hardware (2016 iPhone SE and a 2017 MBP). They work fine. Moreover, I appreciate nicely designed and competently implemented experiences on the modern web.

I have no interest in trading the modern web - warts and all - for some spartan plaintext utopia.

https://news.ycombinator.com/item?id=23043745 (emphasis still mine)

I see that they've specified both a transport protocol, to replace HTTPS, and a document format, to replace HTML. BLUF: They should have just run the text/gemini format on top of HTTPS 1.1, make a gemini --> HTML formatter, and maybe a restricted subset of HTTPS, and called it a day. Replacing HTTPS is a waste of time. Also, most of the benefits of the document format could be gotten with a sane subset of HTML. There are no mandatory bad parts to HTTP or HTML.

I've seen this "The Web is too complex, we need Gopher" sentiment on the Fediverse a few times and it looks like the same class of thinking as "C++ / Rust is too complex, we need C."

They are complaining about how bad parties use HTTP and HTML and concluding that good people should disavow HTTP and HTML as a result. It is like refusing to drive your pickup truck because someone else's truck has truck nuts on it.

But I've run websites with the "Motherfucking website" HTML style and it's fine.

All the complexity of the web is opt-in. Switching my site to Gemini wouldn't prevent, say, the New York Times from wanting a complex HTML website. All I'm doing is shooting myself in the foot to spite my enemy. The FAQ says they intend to co-exist with the web, so I'm sure they agree with me on this. They just want to lead by example. I also don't think it's a good example.

About extensibility, from Section 2.1.2 in the FAQ:

"Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based "supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol."

These claims are made:

• Privacy violations are inherent to HTTP/HTTPS/HTML - Making a protocol non-extensible is feasible

But if you're specifying a completely new client and server, you could also just refuse to send and accept the ETag and cookie headers that are known to allow privacy violation.

And no protocol is non-extensible. They seem to think that software and ideas are controlled and owned by the first people to think of them. But if Gemini catches on, then it can be forked. This should be obvious to people working in FLOSS. I seem to recall it happened to IRC. Designed simple, forked into incompatible competing versions, the official next version is in dev hell, and now it's also competing with XMPP and Matrix.

Perhaps that belief is why they chose to make a new spec instead of defining a subset of HTTP and HTML. They think that HTTP and HTML are atomic and we must not reuse any good ideas from them, they've been tainted with bad ideas, so we have to change everything all at once.

To this end they even made the status codes different from HTTP.

"Importantly, the first digit of Gemini status codes do not group codes into vague categories like "client error" and "server error" as per HTTP. Instead, the first digit alone provides enough information for a client to determine how to handle the response."

They could have just specified a subset of HTTP status codes, to make it easier to remember which codes are which. Personally I like having 4xx and 5xx separate. Maybe they were really happy to save 33% of status code bytes compared to HTTP.

Regarding performance, the spec says, "Connections are closed at the end of a single transaction and cannot be reused."

I believe there's also no inline media, so 1 document == 1 connection == 1 request.

Again, this is completely possible with a sane subset of HTML and HTTP - Just write a server that can't reuse connections, and write HTML that doesn't have inline media. Use a linter or transpiler (from text/gemini to HTML) to enforce that.

But if you do reuse connections, or use something like QUIC, then you can get better performance. So they are making that impossible. Again, until someone forks it and adds it anyway.