I hope you’re right. Personally I think that epoch peaked with jQuery. I’ve been watching the culture of web development steadily descend from what you describe to whatever it is we have now. But software history is circular, so maybe those good times are coming again.

Yeah, I've been watching the same as you describe, and I think jQuery was the peak, but also the beginning of the descent into abstraction.

A couple of years ago, I realized that the art of web development is about to be lost, and I started to re-learn all those lost skills, such as direct DOM manipulation, feature-checking, backwards compatibility testing, etc.

I now have a reasonably functional website which works back to the earliest HTTP/1.1 browsers, like IE3 and NN2, classics like Windows Safari and Opera 12, and many many other lovable, once again usable browsers.

Good to know you’re out there somewhere!

software history is like rest of history. it won't repeat, but it will rhyme.

c.f. endless attempts/experiences rediscovering basic principles behind UI toolkits now taking place in web-dev land. Not identical to 1990-2005, but rhymes like crazy.

You might be interested in Gemini [1][2] then. There is a curated list[3] of clients, servers, and resources.

[1] https://en.m.wikipedia.org/wiki/Gemini_(protocol)

[2] https://gemini.circumlunar.space/

[3] https://github.com/kr1sp1n/awesome-gemini

I like the idea of Gemini, thanks.

In my opinion it has many shortcomings compared to "Web 1.1"

Which shortcomings do you mean, specifically?

Here are some shortcomings of Gemini which come to mind...

There are few choices in clients...

A lot of older hardware is left behind...

The TLS requirement means no human-readable protocol...

But the biggest one, in my opinion as an experienced IT person, is that it is a "clean start", meaning all the same problems which have already been solved in HTTP and NNTP worlds will present themselves again, one at a time, and require solution.

> There are few choices in clients...

It is true, although it is not too difficult to write. (A new web browser could include Gemini (in addition to Gopher, HTTP(S), and possibly others).) However, even if you do not have other client software, the "openssl s_client" can be used, too (although having the specialized software works better, it doesn't mean that such specialized software is required). (It also ought to be added into curl I think, but they didn't do that.)

> The TLS requirement means no human-readable protocol...

I agree that this can be a problem. My suggestion is to add a non-TLS version using "insecure-gemini:" as the URI scheme name.

> ...all the same problems which have already been solved in HTTP and NNTP worlds will present themselves again...

Gemini can be a substitute for HTTP and Gopher (in some cases); it is not a substitute for NNTP, I think.

Yes, it is possible to do it well (the things you mention are helpful), even though it is often done badly.

One idea is to improve the design of the web browser (including the engine), since the current design makes many things difficult for the end user to customize.

No-JS is almost always suitable, although not quite always. When scripts are needed, you should include a <noscript> block, including the documentation, raw data, other protocols, etc as appropriate. (There are some web pages that do this, but it seems to be rare.)

What thing had you been writing?

I look at it as running an establishment...

If I'm running a hotel, for example, my valet has to know how to accomodate old cars and new cars, manual and automatic, electric and combustion, and possibly motorcycles and scooters and such...

If someone comes to the front desk, I have to be polite to them no matter what, whether they look dirty or clean, normal or weird, I can't tell them, your appearance is not good enough, or you don't speak the right language to be at my hotel.

I think the idea of telling the user their browser isn't good enough is the same level of rudeness, it's an act of laziness and arrogance to not even try...

And yes, there are so many different browsers and levels of convenience, and if you want the GUEST to have a good experience, you have to accomodate the shortcomings of their own vehicle, which they may have no choice over, or may even enjoy using and have an attachment to...

The thing I've been working on is mentioned in my profile, the live site is only a few days behind my local dev. Here's a short video I just made with you in mind:) 5igA8Zz56NU

I don't watch a video. I did look at what is in your profile, though. It is the kinds of thing I might use NNTP instead (although having a web interface can also be helpful for the users who prefer that). (Actually, I have a NNTP server myself, and have partial work of a optional web interface too, for the users who prefer that; it displays a link to the NNTP if the scripts is not enabled so it can work even on Lynx (which supports NNTP) or just in case the user prefer to use the NNTP.) I do like that you have accesskey attributes; many web pages don't use it. I did see the git repository about it too, and I had read the documents there too.

(If you have a computer with internet, and if it will serve a plain ASCII text connection even not needing HTML or Telnet commands, nor VT-100 or anything like that, nor non-ASCII characters, then it can work if you have internet, if you have a computer with a keyboard (using a telnet client, or just nc, or whatever); that is the minimal possibility. So, it is another possibility maybe; of course is not only possibility.)

Is there any JS being used in that video at all or is it all HTTP requests?