Gemini's different protocol isn't important for technical reasons. Its important for social reasons - to make it effortful to move content to gemini, and effortful for users to start using it. The result is that all the content and users on gemini are people who have done work to opted in to it. And the space populated by small community like that will necessarily end up different from the culture on the web. (If they were happy with the web, they would have stayed there.)
But they have stayed there. Gemini users still use the modern web all the time, mostly to remind everyone that they exist and are rejecting the modern web so hard you guys.
Gemini is no different. There's overlap with the web's use cases, but its its own thing. As a user, why not both?
What does Gemini have to offer to web users that the web itself doesn't? It's entirely possible to write small, simple HTML documents without javascript on the web. Indeed, one could replace Gemini entirely with a Geocities-like service that enforced the same rules, including only allowing linking within the platform.
Alongside the web, Gemini is just a worse version of the web, it isn't different enough to be its own thing, nor does it offer anything unique. Gemini only makes sense as a means of forging a separate identity from and exclusionary of the web, as you yourself said in the original comment I replied to[0]: (If they were happy with the web, they would have stayed there.)
You could e.g. color the links to other participating sites to highlight them (and still have the option to link to a conventional bloated website).
The web is like a badly architected government such that most citizens are unaware of the badness. The collective you describe is like a group who use their own awareness of the badness to improve the country, but that does raise awareness of the government's badness whereas starting fresh by founding a new country does.
Actually, the analogy I just gave is a little too harsh on the web. A more charitable description is that a subset of the web's users is poorly served by the architecture of the web, but most of that subset is unaware of that fact (what with not being experts on the effects of subtle technical decisions on something as vast, open and complex as the internet).
I am not defending Gemini in particular; I use it but have yet to form an opinion of it; I am defending the strategy of founding a new internet service to compete (for the time and attention of users) with the web.
I don't buy this argument.
Even if "he/she ascribes the good experience (...) to the web":
(a) the subset of users that could fell into one of the "participating sites" would be much larger than the subset of users that would install something like Gemini. The subset is open with no barrier at all to every web user. They just need to visit a page. The second subset requires them to have heard about Gemini, to care enough about it, and to actively download a client.
(b) For this reason, even the subset of (a) that could tell "Ahh, this site is fast and nice because it's simple web code" would be much larger than the subset that would install something like Gemini.
(c) If the subset that recognizes the benefits from the simple web design designs to join the movement, they just need to code simple html and deliver to everybody (an easy sell, no new tools needed). For the subset that discovered and likes Gemini, they'd need to find a host and install a Gemini server (much fewer options, no turnkey-host that supports it, unknown code quantity/quality), and then their potential audience is severely limited to Gemini client users (a much harder sell).
(The main problem with using the web to publish plain-text writings is that unless the person doing the publishing is an expert on the technology, in which case he will use something like Github Pages, there is no cheap way to publish a few paragraphs or a few dozens of paragraphs where it fill find a decently-sized audience without enriching some intermediary and subjecting most of the people who over the years will read the writings to either advertising or paywalls.)
I offer no criticism of the web as a way to buy things online or to apply for a passport online or such.
I am avoiding saying that the web is bad: the web might be bad only for a small fraction of web users. I don't know enough about how web users differ from each other to say how large the fraction is. I do know enough about software and how site owners will respond to incentives to be able to tell that the web is bad for users sufficiently like me. Well, I'm fairly certain, too, that the web is severely sub-optimal for blind users (and I wonder if attempts have been made yet to tell blind users about Gemini and to make it easy for blind users to get started with Gemini).
Someone could write a whole book about how seemingly insignificant decisions in the design of something like a web browser (e.g., decisions in the design of web standards) can have profound effects, but I think in this case it is better to show than to tell.
Improving Gemini might eventually show a lot of people that the web is a sub-optimal solution for some of their needs. Note that Gemini need not completely replace the web in a user's life: one session with the improved Gemini might get the point across to a new user (and the user might do nothing but browse Wikipedia during that session).
In contrast, the strategy I originally replied to, namely, a collective of web sites, might significantly improve the experience of many web users, but will cause approximately zero web-tech non-experts to become dissatisfied with the web.
I have no road map for how a large numbers of people dissatisfied with how the web serves some of their needs will eventually find their way to something better. I figure it will take many years. I do believe that increasing the numbers of dissatisfied users is probably a necessary first step.
=> https://gemini.circumlunar.space/docs/faq.gmi
> 2.5 Why not just use a subset of HTTP and HTML?
> Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites can track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they have to. Why not just build non-evil websites using the existing technology?
> Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done.
> The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
> Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they can't. You can do all this with a client you wrote yourself, so you know you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
Also, if this[1] is your HTML parser, it doesn’t look like an actual HTML parser with implicit tags and error correction, just a parser for some easy subset of HTML. If we’re not going to be web-compatible anyway, why not spec a language that’s actually good?
[1] https://github.com/s2607/webthing/blob/d6dd43aa5a3cc6dee15f8...
If a lot of the cruft would be removed then actually, it probably wouldn't be so bad. But you know, compatibility and such. Still, a <link rel="newstylesheet" href="style.newcss"> probably wouldn't be such a bad idea. The base CSS specification can probably be reduced by half if not more, both by removing cruft and by learning from mistakes.
Gemini's selling point is that it's a narrow spec that's basically good for one thing: displaying largely unstructured text. It's not good for PDFs or layout, it's not good for media-heavy documents, it's not good for apps. You probably wouldn't write something like a book in Gemini. It knows exactly what it's doing, what kind of community it wants, and it focuses only on that use-case -- which is why its community likes it.
But how many different implementations do you need to build for this kind of narrow project? Are we really expecting that 50 different hobbyists are going to build custom Gemini parsers? Why? I'm not sure I understand what reason there would be for that kind of implementation diversity with a spec that is deliberately designed to decrease application diversity.
On the web, we have a lot of reasons why we are scared of having only one browser rendering engine. But most of those reasons don't seem to apply to Gemini, because it has different goals from the web. So say there was one zero-dependency C/WASM binary for parsing that was compiled for every platform and could be imported or transpiled into other languages for use in your custom browser/app. What do you feel would be missing from Gemini in that world?
Plus, being able to implement something from the ground up in not much time means it’s possible to explore foundational advances, like building the entire client/server in a memory-safe language.
I think it seems a little bit extreme in some ways, because when we talk about Gemini's implementation being simple, the FAQ isn't just talking about structure/readability, it's saying 100-200 lines for a basic client. To me that crosses from 'should be auditable' into something else entirely -- I'm not sure why having a 1000 line client would make this significantly harder to audit, or build, or re-implement in Rust. I'm not sure Rust is that complicated of a language.
But :shrug:, I guess if you shoot for an extreme metric, then you know you'll end up with something that meets all of your other goals as well, so those requirements do make some sense to me when phrased as part an overall architectural stability/reliability goal.
> But you can serve HTML pages over Gemini either way.
The important question is what people can read over Gemini, I guess. Do Gemini clients effectively render that? I imagine it would be difficult to take Webkit and make it work without supporting JS.
Might as well ask "what good is competing webservers".