You don’t need to convince existing developers to adopt it. Remember the early web spirit, where people imagined that everyone would run their own server and publish their own homepage? Turns out it was way too complicated to do, and required you to be a tech enthusiast. Largely, I would say, because HTML was not designed to accommodate for a lot of the things people immediately wanted to do. Even a basic thing like keeping navigation consistent across the multiple pages is impossible.
I think if you designed a document language that took advantage of 30 years of experience of what people actually want to do on the web, you could find an entirely new set of users. People who want to feel ownership of what they publish, want to be able to be creative and improvise, but don’t have the technical skills to create a site in the current web stack. It would probably look more like a social media service, so it could run on top of the web as it is now, or have dedicated native clients.
Honestly, this 'entirely new set of users' sounds like wishful thinking for a problem that does not exist as you describe it.
Back in the early web people couldn't run their own server not because HTML was hard (WYSIWYG editors not only existed since the Windows 3.1 days, but they were very widespread at the time - Netscape Gold even came with one included and that could do pretty much everything you'd see in most pages) but because it was hard to have and maintain the necessary hardware and internet connection.
This still exists and is still an issue today if you want the full ownership down to running your own server. But if you do not care about running your own server and you are fine with shared hosting (which existed even in the 90s, see geocities) or a VPS, then outside of a basic setup you do not need to be much of a technical user (and many hosting and VPS providers have tools to do that setup for you, often for free). For the slightly more technical users, there are tools like Publii (stupid name, but the tool works) that can do mostly full WYSIWYG site editing, management, syncing, etc.
And a dedicated native client? From a user's perspective there is nothing to win here, they already have a browser (and the less technical users are confused by even that), why would they run another browser that wont even work with the majority of the content they want to access?
Really, these are not practical solutions for practical problems. That doesn't mean you shouldn't try to make something like this, but they'll just be toys for fun, not real solutions to real problems and if you expect them to be anything like that you'd be disappointed.
After all Gopher, for example, exists and can be targeted and used, but all of its users are using it for fun and because they can, not because they expect it to compete with the web (well, outside of edgy "the web sux, gopher is the future" comments that are at the same level as "M$ suxx0rz, linux rulez" you'd see not so long ago).
I think we are imagining very different things! For what I tried to describe, I think a dedicated native mobile client would be the most natural way to use it. I don’t think it’s a strange idea at all - consider how popular dedicated apps like Instagram, TikTok, YouTube, Facebook etc are. It’s not confusing or a burden in any way.
Publii or anything you could one-click-install on a web host is nowhere near fully featured for what people actually want to do on the web. Again, look at the type of activity that happen on most social networks - liking, sharing, commenting, replying, bookmarking, retweeting, remixing, curating playlists and galleries, etc. Those communal space-building activities have become as foundational concepts for the internet as linking, but are exceptionally difficult to implement on the current web.
> Really, these are not practical solutions for practical problems. That doesn't mean you shouldn't try to make something like this, but they'll just be toys for fun, not real solutions to real problems and if you expect them to be anything like that you'd be disappointed.
I agree. I like the idea, but there's no way it would get traction without solving a concrete (rather than aesthetic) problem.
It is possible though: the more expressive/powerful a system is, the less we can know/guarantee/figure-out about it. Adding features does have downsides. For example, people are starting to pay attention to pure functional programming, since the restrictions it requires (e.g. immutability, referential transparency, confluent evaluation, etc.) provide lots of nice solutions for things like concurrent, distributed systems.
The classic example on the Web is search: if sites didn't work with dumb, lightweight user agents (search bots), it could have a real commercial impact. These days the big search engines use browser-derived bots, which has changed the dynamics a little; but the core point remains the same. If people find concrete problems or opportunities faced by Web sites, which would be useful to solve automatically, but where the complexities of the current Web prevent that, then perhaps people could be convinced to use a restricted subset of the Web.
I think if you designed a document language that took advantage of 30 years of experience of what people actually want to do on the web, you could find an entirely new set of users. People who want to feel ownership of what they publish, want to be able to be creative and improvise, but don’t have the technical skills to create a site in the current web stack. It would probably look more like a social media service, so it could run on top of the web as it is now, or have dedicated native clients.