There is a key point which articles like this fail to understand about Gemini. Gemini draws our attention to the distribution of responsibilities between client

There is a key point which articles like this fail to understand about Gemini. Gemini draws our attention to the distribution of responsibilities between clients and publishers on the web, and the implications of that distribution, and asks us to question this balance in a new medium. On the web, the publisher is entirely responsible for both the content (HTML), layout (HTML+CSS), and its presentation (CSS). But with Gemini, the publisher supplies only the content, and the client (or rather, the user agent) deals with the layout and presentation. This allows for clients to work in a huge variety of situations different from yours - some people render gemsites for ereaders or for print, some people "render" them with TTS as homebrew podcasts to listen to on the train, and others rely on screen-readers to browse - and the constraints of Gemini provide all of them with a first-class experience that the web cannot. This is why the markup format, gemtext, is heavily constrained. You should try to express yourself within the constraints of the medium. The medium I'm using now is constrained, too - I can't add inline images or links on Hacker News, but we all seem to have found productive uses for this site nonetheless. And would HN really be better if we could write arbitrary HTML/CSS/JS in our comment bodies?