[olavk]

I don't get this. It seems to me Gopher basically supports a subset of what is available on the web. All the benefits of Gopher (low bandwidth requirements, no flashy design or interactivity, strict hierarchical navigation etc.) can also be achieved with stripped-down web pages. I see no benefit at all to having a separate protocol.

Gopher is cool as a slice of history though.

[lmm]

You can't be confident of getting a stripped-down web page before you click the link. Trivial example: I can click a gopher link and be confident whatever's on the other end is not going to make a noise.

Human vigilance is fallible. Protocol-level enforcement is necessary.

[jasonkostempski]

I've been thinking about making a site that only takes links to text/plain and other non-mixed-media content. I haven't been able to find one if it exists. I'd also love search engines to support media type filters.

[olavk]

Are you suggesting there are some people who only browse Gopher?

[lmm]

There are people who prefer Gopher and/or particular known sites. If you can see from the URL that a site will be non-horribly designed then that's fine, and if the only option is HTTP then you put up with it.

[NoGravitas]

You could use a stripped-down client. There are currently compatibility problems (with using Lynx, elinks, dillo, etc), but most of those are probably surmountable. I can easily imagine a browser that guarantees either a reader-mode/AMP-like experience or a graceful failure.

[rikkus]

"All the benefits of Gopher [...] can also be achieved with stripped-down web pages"

Can be achieved, but aren't. I'd love a consistent, stripped-down interface. The web doesn't give me this (it doesn't matter if it _could_).

[simonh]

As a client you have no control over this though, because you can't make people provide services using Gopher instead of HTTP.

To put it another way, for someone wanting to provide a service it's daft to choose Gopher 'because it's lightweight'. If you're providing the service, nobody can stop you providing a lightweight HTTP service and in fact doing so is mind numbingly easy. Just do it.

Or provide a URL link to an FTP server. Gopher was basically just a nicer to use menu based alternative to ftp, but visual browser ftp clients are pretty much that now anyway.

Having said all that, it is kind of cool that Gopher is still around. I was using it years before HTTP even existed. If Gopher is going to exits then yes, being lightweight is one of it's strengths, but pretending that this meaningfully distinguishes it from HTTP doesn't strike me as a very strong argument. I suspect a lot of it's attraction is techie cultural exclusivity and contrariness. Not that I have anything against those things whatsoever.

[ramblerman]

> The web doesn't give me this (it doesn't matter if it _could_).

If it was important then the web would cater to it. It's simple economics.

We could create protocols for all the sub needs and desires that people may have but that would be restrictive.

[sp332]

The market can stay irrational longer than you can stay sane on autoplaying video ad-covered sites.

[mjburgess]

Popularity =/= Economic Viability =/= Importance.

The market is NOT a mechanism for delivering what is important.

[dredmorbius]

Gresham's law, market for lemons.

[amiga-workbench]

It stops designers and developers from being "clever" The user gets pages that are highly accessible, straight to the point and free from javascript malware.

[olavk]

Not at all, you can do lots of "clever" things in plaintext, like ASCII-art or aligning table columns with whitespace. This is much less accessible and adaptive compared to semantic HTML.

No protocol will prevent people doing fun and clever things or produce content which you think is useless.

[digi_owl]

The big thing, as best i can tell, is that gopher is built around exposing a FHS and letting the user browse it rather than mask the FHS behind urls and links inside the documents themselves.

Gopher as a protocol can serve up any odd file format, HTML included, if one so wants.