Just finished writing an overview of my ideas for a post-JS web. Next I'll be expanding on what each of those HTML extensions might look like.
And maybe draft some example code.
I'm keen for feedback!
@alcinnz Though I like some of the aspects, I think on a technical level one thing we need to get way more clear about is completely different use cases "the web" is being used for, as of today. I dare to say that a *very small* crowd of people in 2019s web still does, in example, have sort of a "document-driven" approach, like, "accessing a document resource" to read through it and, this way, extract information. 😉
@alcinnz I see people being attracted way less by *information* itself but actually by *interactivity* surrounding this. In my environment in example, writing weblogs or websites never "got off" the way Twitter or Facebook did, later - because in the days of weblogs or (semi-)static web sites, communication and interaction was somewhat clumsy and difficult and mostly limited to using web forms (slow) or e-mail (slow and considered way too "formal" for random exchange of thoughts).
@z428 Ah yes, that might be a good way to put it. Information brings them to the site, interactivity makes them stay.
@alcinnz At least that's *one* relevant aspect, I guess. Not sure, though, it's *only* information that brings people to particular sites. I've mostly grown up in an age of "starting online communities" (which early-on used to be based on telnet or web forums but got replaced by social networks at some point). In these cases, it was all about communication - which is what people very much use "the web" for, right now, even while it's not at all the use case the WWW was thought to cover. 😉
We may be using the interactive, two-way-communication-oriented ones the most, but there's few of them. So it wouldn't be unreasonable to turn them into native applications.
And they aren't websites, they are web applications.
So make them real applications.
And then see how many features of your web browser no longer have a legitimate usecase for the remaining websites.
@Wolf480pl @z428 Hmmm, one question I've been asking since I've implemented the feature is: Would the Web be much different if browsers would recommend apps to install when opening an unsupported URI? If webdevs didn't have to worry about whether their readers had a e.g. BitTorrent client installed?
And in my writing in that repo I'm starting to ask questions about "What if Google Doc's features were just part of the browser, allowing users collaboratively edit (copies of) all webpages?"
@alcinnz I think it's a mix of all these things. Back in "those days", it was good to have, like, open protocols and applications handling those. However, this also caused an *incredible* amount of trouble (just try sending, in example, a file to an arbitrary XMPP contact, or a pixel-style formatted e-mail to an arbitary e-mail recipient). That's why a lot of teams moved from building a *protocol* (for arbitrary client applications) to building *applications* (that, under the ...
@alcinnz ... hood, of course use protocols which, however, aren't suited or supposed to be re-used for random clients to build on top). Slack is a good example for that. And on the other side, a lot of devs have moved from "native applications" to "web apps" because it makes it easier (or, in some cases, even possible in an economic way) to cater for multiple desktop platforms and get rid of a lot of nasty issues such as deployment/software distribution, remote ...
@alcinnz ... debugging, all this mess. That's what I see right now: A lot of people actually (ab)uses the WWW as a runtime for rich client/server applications and cross-platform clients. Generally, I don't even disagree with this, but it's a completely different use case with different requirements, and doing so on top of means of technology supposed to transport structured (and, at best, visually enriched) information seems difficult. 😉
For me, they can have their client/server application platform, provided that those features required for having a client/server application platform are not available to just any random news site.
Or put it another way: aside from an application platform, we also need a separate hypertext platform.
@Wolf480pl I disagree with the approach they have taken, but I understand that decision nevertheless. We're in the late 2010s, with technology having moved forth quite a bit ever since, but a lot of our protocols are still rooted in (and left compatible to) the late 1970s. Effect: We do have ridiculous constructions such as the whole RFC stack that tries to allow for "rich e-mails" which is in many ways a complex and dreaded mess, abused by some and simply abandoned ...
Half of them doesn't allow rich text of any kind, the other half supports at most markdown or sth like that.
And picture attachments.
This is how much rich text people need.
Not pixel-perfect styling.
Only marketing needs pixel-perfect styling.
@Wolf480pl Well yes, business people expect pixel-perfect styling, just the way they expect their (written) letters or their web site to adhere to a certain visual style. Invoices are a good example (rather than again rendering them to PDF and sending out attachments). 😉 I don't even see a problem here if we actually accept these use cases to be valid. 😀
@Wolf480pl That's what I meant. 😉 A lot of people I know who want to send out "designed" e-mails couldn't care less about HTML or PDF. They however *want* something they can use to make e-mails that allow for basic formatting and that are available without requiring an additional application. So far, HTML is the best (only) thing they got. Which is bad. 🙂
@irl you mean for casual formatting, or for invoices?
If for casual formatting then... uh, I think we don't need a binary format... also, Markdown degrades gracefully, to the point that the even if you view it as plaintext, it's still readable *and* you can intuitively see what the formatting was supposed to be.
Now as for markdown - yeah it's (almost) semantic. Definitely closer to semantic than to styling.
So now my point is:
people don't really want styling/formatting in most of their communication. They want to be able to
- express lists of things
- *emphasize* some words
for which Markdown or sth similar is a better fit than RTF or even BBcode.
@Wolf480pl Hmmm, actually reading the *markup* source code doesn't feel very "graceful" to me. I thought more all along the lines of what lynx or w3m tend to do to web pages if they are reasonably well-crafted. My expectation would be a plain-text representation that makes use of the device at hand as good as possible, including things such as positioning of elements (which works in a terminal as well), text-color, borders, ... . 😉
@Wolf480pl ... by others, and I am convinced e-mail (also all along with instant messaging and the like) could be way better today if we just managed to, at some point, start over from scratch, build something entirely better and then eventually allow for backward-compatibility / graceful degratation layers for "old" protocols (IMAP, SMTP) or clients, rather than considering this to be the common ground and everything else fragile extensions on top. And, the other ...
@Wolf480pl ... part, talking about the "hypertext" platform: Maybe this also would have to change in this way or the other, but, here, we have caused quite some trouble by essentially accepting a web where everything is "gratis" (=free of charge), leaving tracking- and ad-backed funding the only means at hand for most people to actually even earn the money they need to cover costs. I am convinced the web would be a better place if people were ready to throw some cash for services ...
@z428 I'd still argue it's information bringing them to particular social networks, though in this case it's more about who's writing that (usually frivolous) information.
In other words: your friends are there.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!