It’s worth noting that HTTP itself has unparalleled performance for the Web due to the protocol itself (and web servers that deliver it) being optimized over the years to support compression, transfer encoding, encapsulation, etc.
Gemini also transmits a mimetype that’s text-based (text/gemini) but it runs on port 1965 — as opposed to the usual 443 (HTTPS) or 80 (HTTP) that Web browsers usually connect to by default. Gemini therefore needs customized “browsers” that will read the protocol and parse the data that’s received from a Gemini server, however there are Web Proxies that do this as well [0].
In that sense, it’s an alternative to the Web inasmuch as it’s an alternative to HTTP; but (importantly) without any maturity, performance, or scalability whatsoever.
Now to be fair, Gemini doesn't claim to replace HTTP in any way; being a niche, small-web technology.
But in my opinion it's pretty pointless since it uses a strict subset of the HTTP spec which makes it feature-delimited by design.
Using HTML sans CSS/JS will give you a similar yet better experience.
I can understand why the vast Gopher community would immediately dump/mirror all of their content into Gemini Space. My question is why anyone else will, when one can easily create an equally-spartan experience using universal web technologies.
If you approach that question as a developer, it makes sense. Why not just restrict yourself to a subset of HTML+HTTP, which is what many people do.
However, as a user, I can't be sure what's behind each URL. Does communitywiki.org require JavaScript? Do they set cookies? Do they violate my privacy with telemetry and analytics?
If I see a gemini:// link, I know the answers to all of those questions -- they don't because they can't, not because they choose not to.
You can check what any URL does, actually; unfortunately, the browser does not make that easy.
A gemini:// link can't set cookies, but it doesn't prevent serving HTML or any other type of file. However, a browser may disable HTML with Gemini by default, or not support HTML with Gemini at all. Doing so may be useful in order to more easily answer the questions you mention.
Using HTML over HTTP in any form opens you to tracking, through the referer header, ETag lookup, and cookies.
The idea behind Gemini is to cut off all such capabilities (even when useful for good things) and prevent attempts to add them as extensions. This may make sense in the niche they are targeting.
This also prevents common session tracking mechanisms, but even form submission is not a thing in Gemini anyway.
It won't prevent serving HTML with GET forms (although POST forms won't work, and neither will cookies), although a client may very well not understand the document (or any other HTML document) and not display it (and even if it does understand HTML, it might restrict HTML with Gemini by default, in order to avoid tricking the user into thinking that one kind of document is a different kind, and/or in order to avoid doing things which are undesirable with Gemini; HTML is probably mostly undesirable with Gemini anyways).
If you need an interactive system, then SSH or Telnet might be better, rather than Gemini or HTTP(S). For other things, other protocols will be better, e.g. for communications, IRC or NNTP would help (depending on the kinds of communications). They also mentioned a Titan protocol, for writing to Gemini files.
I suppose that as the Gemini network grows, someone will create a search engine. The old-school "?foo+bar" style of GET queries should be enough even on clients supporting only standard Gemini markup. (Arbitrary MIME types are supported, so enhanced or entirely different interfaces are possible.)
Gemini also transmits a mimetype that’s text-based (text/gemini) but it runs on port 1965 — as opposed to the usual 443 (HTTPS) or 80 (HTTP) that Web browsers usually connect to by default. Gemini therefore needs customized “browsers” that will read the protocol and parse the data that’s received from a Gemini server, however there are Web Proxies that do this as well [0].
In that sense, it’s an alternative to the Web inasmuch as it’s an alternative to HTTP; but (importantly) without any maturity, performance, or scalability whatsoever.
Now to be fair, Gemini doesn't claim to replace HTTP in any way; being a niche, small-web technology.
But in my opinion it's pretty pointless since it uses a strict subset of the HTTP spec which makes it feature-delimited by design.
Using HTML sans CSS/JS will give you a similar yet better experience.
[0] https://proxy.vulpes.one