The problem with most of these discussions is they assume Gemini is a substitute for the web, when it is actually a substitute for Gopher.
Gopher never really went away. A few enthusiasts were keeping it alive. Those enthusiasts realized that Gopher had a number of shortcomings, so Gemini was created to address those shortcomings. It was not created to address the shortcomings of the web. (At least not directly. Indirectly one could argue those enthusiasts kept Gopher alive due to the shortcomings of the web.)
As for styling and inline images: in a sense, Gemini offers styles to a limited degree. Those styles are tied to the structure of the document, while the appearance is left to the software rendering the document. Even though inline images are considered a faux pas, I seem to recall Lagrange offering that feature. Again, we are dealing with the rendering software making the decision rather than the author. Since the end user chooses and configures the rendering software, it is the end user who has control (rather than the author).
I think this is true only up to a point. The sets of Gopher enthusiasts and Gemini enthusiasts surely overlap, but they are not coterminous (disclosure: I administer gopher.floodgap.com).
From my view in Gopherspace, Gemini is a better fit for the Gopher+TLS thing people keep trying to do which is both incompatible and doesn't square with Gopher being an ultra-light protocol, and thus most appealing to those people who thought Gopher would be the "new smol web" but found it's more its own thing. In particular, Gopher's signature strong menu-document hierarchy that a lot of us Gopher nerds like doesn't have any true parallel in Gemini.
I started gopher.floodgap.com back when it was gopher.ptloma.edu in the late 1990s largely as a historical preservation because I remembered all the cool stuff you could get there. Back then the Web hadn't metastasized to the Tetsuo blob it is today, so that obviously wouldn't have been the reason. I can't speak for the later adopters, but Gemini doesn't scratch my Gopher itches fully (see also https://oldvcr.blogspot.com/2020/11/a-gopher-view-of-gemini.... , my notes on this from 2020).
I didn't mean to suggest that Gopher and Gemini enthusiasts are one and the same. Rather, I meant to suggest that it was a subset of Gopher enthusiasts that decided to address some of the shortcomings of Gopher. At least that is the impression that I received while watching from the sidelines. It never really struck me as being a derivative of the web.
And thank you for gopher.floodgap.com. While I had some exposure to Gopher in the mid-1990's, most of my exposure was through Floodgap (and SDF) in the early 2000's.
I agree that basic styling and in-line images add something, but I like how Gemini strips so much faff out that the prose and links must stand strongly on their own.
I've taken to writing my markdown and other documetns simiarly. Cory Doctorow does something similar.
I feel that if there were some way of promoting a Javascript-free web, everything the world needs is already there in all modern browsers.
I suspect that between HTML5, and indeed XHTML, and CSS and all the many modern image formats and so on, everything important that almost any site needs could be done using these tools and no JS at all.
And the result could also be interpreted and rendered successfully by much smaller simpler browsers, along the lines of Netsurf and Dillo, which are 10% of the size of a full dynamic-content browser or less.
The question is how.
A contest? Make the richest website you can that uses no Javascript, Typescript or anything else, and win a prize as well as promotion?
I don't think a contest is needed. Just a desire to participate in the "Smol Web". Back in the day we had the "best viewed in any browser" badge indicating a page worked fine in IE and Navigator and probably also lynx. Personally I hate making web pages that don't work in Dillo or lynx.
I think a contest would be antithetical to the idea being circled here. The early web (to me) was filled with content front people who put out there because they wanted to share. Put your page up because here’s something you think is cool. I feel like it loses something with a contest.
What I want is less use of Javascript and related scripting languages across the web. I'd like more websites that don't need it.
I am merely proposing a mechanism for getting people to explore what can be done without it, and how it might in fact be easier, more fun, and more maintainable.
> I like how Gemini strips so much faff out that the prose and links must stand strongly on their own.
I don't think that's working at all. Their website is so unapproachable bad, that it fails in selling me reasons why I should even care about this or read further. Letting something standing on its own only really works well if you have a small amount to deliver. Any slightly lengthy text will just bury you in a desert of letters.
> Any slightly lengthy text will just bury you in a desert of letters.
So what do you make of books, then?
I don't think people "keep trying to make Gemini happen" in the sense that you mean. They're not aiming to replace the web. They've got a cozy little community that likes the 'smol', text-based web. And while 90% of people might think they're crazy, there are others out there who would like it too if only they knew it existed. Posts like this make the community a few individuals larger. I think that's the goal.
This webpage is not a book. It has a different purpose. With a book, I know what it contains, where it's leading to, usually they have an abstract for this.
I have nothing against Gemini and the people in general, I'm just saying the limitation is not working well for every type of text. Pictures and a bit more structure would be useful for the boring informative texts.
Webpages aren't as monocultural as books, though. There are webpages that have interactive 3D models (which physical books can't). There are webpages that are basically books though. Some webpages will port well to gemtext, some will not. The purpose isn't to replace HTML. The purpose is to make long-form uninterrupted text a first-class citizen by forcing other elements to be second-class citizens.
> Any slightly lengthy text will just bury you in a desert of letters.
Is this a bad thing?
Books are a "desert of letters", with little to break the text up outside of chapters, sections, and paragraphs. If you broaden the scope a bit, you can added illustrations and photos. People have been reading books for generations. While many books do break that mould, many books continue to follow that tradition.
Depends on the purpose. For a Webpage, which is a collection of short texts, to sell you on something, it is bad.
> Books are a "desert of letters"
Depends on the book. A phone book would be a desert of letters, I don't think many would enjoy reading them. Something like a novel, would be a forest of chapters, full of trees with letters arranged in a meaningful way, leading you on a road toward a goal. But a webpage is not a novel, it has an informative purpose, and is full of little small texts of equal value.
I use a rss client which has a content view, and it's barely different than what gemini offers. I also read plenty of epubs and while inline images are possibles, it's often looks really bad. I think there's a value on prioritizing content over forms. Some contents won't fit to these restrictions and that's ok. It's not like it's a web replacement, just an alternative whose restrictions create some kind of exclusivity.
Have you actually seen books? While typographic traditions did go down the drain in the recent decades, it's still hard to find a domain as varied as books.
Even the most boring books often have things that Gemini purposefully omits: from styling to inline illustrations to diagrams to insets, asides, footnotes, tables of content, just tables, typographic marks etc. etc. etc.
> Books are a "desert of letters", with little to break the text up outside of chapters, sections, and paragraphs.
You're forgetting pages. The fact pages physically limit the visual bounds of all the letters helps people read them. The words from page 6 aren't going to come into view while you're reading page 4 but scrolled down a little too far.
Not sure if going back to 2008 or so pre-HTML5 will prevent people from injecting kilobyes and megabytes of JS libraries or nesting dozens of divs because reasons.
My feeling is that Gemini's entire purpose is being opinionated and somewhat inconvenient. It purposefully threw the baby out because it didn't want the baby.
Everything Gemini does, you can do it in HTTP. In fact, a subset of HTTP+HTML would be even simpler than Gemini (mostly because of a lack of TLS) and still compatible with all the modern web stack. Simplicity isn't the main goal of Gemini. Exclusiveness is.
Gopher never really went away. A few enthusiasts were keeping it alive. Those enthusiasts realized that Gopher had a number of shortcomings, so Gemini was created to address those shortcomings. It was not created to address the shortcomings of the web. (At least not directly. Indirectly one could argue those enthusiasts kept Gopher alive due to the shortcomings of the web.)
As for styling and inline images: in a sense, Gemini offers styles to a limited degree. Those styles are tied to the structure of the document, while the appearance is left to the software rendering the document. Even though inline images are considered a faux pas, I seem to recall Lagrange offering that feature. Again, we are dealing with the rendering software making the decision rather than the author. Since the end user chooses and configures the rendering software, it is the end user who has control (rather than the author).