The idea behind Gemini is that it's useful to have a clean partition where you know the social "crowd" matches a specific type. For someone to use it they've gone and installed dedicated software which intentionally limits itself to what this crowd likes to engage in. This signals they are interested in the same kind of space. The utility of the dedicated software is not in providing some other level of convenience, it's separate strictly so the user "crowd" stays separate. Otherwise I could just register gemini:// as an aliased protocol of HTTP and it'd work in normal browsers or gemini clients all the same.
If Chrome supported Gemini tomorrow a significant portion of the user base would stop using it. Of course that's unlikely, Gemini's trust-on-first-use security model is something unlikely to be added net-new to a consumer focused browser.
It matters to some people that their preferences are enforced by the tooling.
How much sense does it make to switch to some immutable data structure or even a language with support for such rather than just not mutating the one you have? (Works for me.)
There is a philosophy behind Gemini which is to fundamentally simplify the web, not jut individual web pages that opt-in.
No site is an island. Even if I keep my own website's implementation minimal I still end up interacting with the rest of the internet via web pages with less minimal markup.
However, if you also had a like-minded community of similarly minimal websites, a mechanism to minify websites, search engines that prioritized minimal (or minifiable) websites, and a social convention of avoiding linking to any website unless it was minimal (or minifiable) then you'd end up with something like the Gemini community.
In fact, I suspect something like that will supplant Gemini in practice. Browsers already have reader modes and some search engines allow you to block certain domains. I could easily imagine search engines or browsers providing greater end-user control over this sort of thing in the future.
A few have popped up on HN. The problem is, the quality of search results is often terrible, because the assumption that complexity of layout and density of information, much less relevance, are mutual opposites isn't valid.
Having used a few, I agree there's room for improvement.
> the assumption that complexity of layout and density of information, much less relevance, are mutual opposites isn't valid
I agree, but has anyone claimed that there is a correlation between a page's complexity and the quality of its information?
My experience has been that the folks who willingly disable javascript, use niche minimalist search engines and browsers, or otherwise prioritize a minimal ("smol") web experience are acutely aware that they are making a tradeoff. They sacrifice access to a significant fraction of the overall web including many high quality pages in exchange for a user experience they prefer.
Like many who have tried it, I found the experience too limiting, but I appreciate what they're doing. If nothing else, their efforts are making the web better for people who rely on accessibility technology and are forced to make such tradeoffs.
Indeed. What would it be like if websites were designed to "look good" using a text based browser, like Lynx?
In the early days I used to use Lynx, and it was actually really good. It was always quite fast, easy to navigate around with the keyboard, able to zip through things like navigation menus quickly.
Didn't work to well with image maps! (A thing back in the day), but it was a nice experience.
If Chrome supported Gemini tomorrow a significant portion of the user base would stop using it. Of course that's unlikely, Gemini's trust-on-first-use security model is something unlikely to be added net-new to a consumer focused browser.