Which honestly is pretty silly, as lots of caching is about reducing latency for small files not saving bandwidth for large files. Suppose it matters less if the documents are self contained.
If Gemini is ever of even domain-specific serious use, I'd expect both the format and protocol to be added to what is supported by existing major web browsers (it can't be both tractable for small implementers and intractable for Apple/Google/Mozilla), which, as it turns out, know how to support the combination of HTML/CSS/JS just fine and won't likely forget just because a different transfer protocol is involved. Presenting a DOM mapping for Gemini format pages and exposing it at least to extensions even if there is no way to include page scripts doesn't seem unlikely, either.
It's just like the web, the transport protocol (HTTP/S) can be used on any file. But there is a separate spec for the document format (HTML etc.). You could transport CSS over Gemini, just don't expect any of the browsers to render it. Just like how web browsers won't execute alternate scripting languages natively.
> Isn't that TCP's job? Is this person saying Gemini doesn't use TCP?
I didn't really elaborate on this point while writing, because I had nothing to add. I will quote from the projects FAQ:
>> Gemini has no support for caching, compression, or resumption of interrupted downloads. As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection.
Hopefully that clears up what I meant.
> Back in the Gopher days, my "Gemini browser" would be my Web browser.
You might be interested in Castor[1]. It's a browser for the minimalist internet. Rolls support for Gemini, Gopher and Finger all in one.
I can understand why FF removed support. But hopefully smaller applications, like Castor, can fill this gap.
[1]: https://sr.ht/~julienxx/Castor/