I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from there defines the perimeter of its APIs.

For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page apps like Discord etc...

And that's the greatest power of the web, but I can't see how this state of affair won't lead, one way or the other, towards a more monolithic architecture. Keeping HTML and CSS cleanly separated and JS only for the fancy stuff (but always optional!) is noble but it's a pipe dream when the use cases are so diverse. WebAssembly, or something like it, seems to be clearly the path forward.

Overall I think we should be happy too, at least it's not a closed source blob. Remember how long it took us to get rid of bloody Flash? Actually if Steve Jobs hadn't decided to drop it from iPhones I wouldn't be surprised if it had survived in common use to this day.

It's hard to identify specific decisions made by Jobs from the outside, but killing Flash on the iPhone seems like something _only_ Jobs could have done. Sure he and Adobe were in a tiff... Anyway, it's likely that this is a rare case where one person making a unilateral, perhaps tyrannical, decision benefited the whole world.

The fancy stuff can go live in apps, it has nothing to do in a browser designed for webpages first. I mean, just compare the GUIs of VLC and YouTube!

But with the strong advantages of access to the Internet that a website brings (which is itself a whole bag of hard problems to solve), the appeal of building things accessible via browser user-agent (regardless of what the thing is) is huge.

It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.

What prevents access to the Internet from a non-website ? Why use the HyperTEXT Transfer Protocol for things completely unrelated to text - it's not like other, more appropriate protocols are not available, or cannot be designed ! (Or that URLs are limited to HTTP...)

At this point, HTTP has enough tooling around it to do enough significant application-layer things that the opportunity cost of rolling new protocols is extremely high.

It's not just text transfer... HTTP also goes hand-in-glove with HTTPS, which is a technology few people want to build an alternative for (and fewer people should be trusted to do correctly).

Trying to force everything over HTTP is a bad practice that is slowly killing the Internet.

[citation needed]. Traffic, usage, diversity of usage, investment, all of these are higher than they've ever been and still trending upwards. What definitions are we using by which we can look at these numbers and claim the internet is being "killed?"

If that's the definition by which people think the internet is dying, I find the definition suspect. And I find the solution suspect, because the notion of building protocols instead of platforms doesn't address the question of how to route those protocols over a network that has evolved to address the problems associated with laissez-faire protocol management in the past.

There's a very good reason that so many systems block everything except port 80. Does the idea of protocols instead of platforms address that reason? Because most people don't want to make themselves vulnerable to attacks along threat vectors they aren't even aware exist.

> There's a very good reason that so many systems block everything except port 80.

Elaborate? Rather than using different ports for different protocols and filtering what you don't want/need, you instead tunnel everything through port 80 and effectively don't filter at all?

Remember when Windows installs didn't have firewalls on by default and it was pretty trivial to attack people's installations via insufficiently-secure protocols running on open ports? It was a bad time.

HTTP has both elaborate tooling for deep packet analysis and a battle-hardened secured protocol, which we don't get with new protocols.

Well, yes, we used to not care about security as much.

These days, don't you think that consumer routers sold without firewalls should be about as illegal as selling cars with only motor braking ?

What? How is SSL dependent in any way on HTTPS?

Ftp and sftp are different protocols. So are HTTP and HTTPS. So are IMAP and IMAPS. And that's the issue with new protocols being added: the security question is a protocol-layer question, but one can't just hot-drop a new protocol into SSL and call it a day; security requires abstraction-breaking considerations.

Partly firewalls and proxies. If you've not read it already you might be interested in https://tools.ietf.org/rfc/rfc3205.txt ("On the use of HTTP as a Substrate"). I wish we still built protocols too.

Indeed. IMHO the right move would be to put pressure on bad actors that only allow HTTP over port 80 and still claim to be "ISPs"... (And with IPv6 having been finalized, NATs are now obsolete.)

And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.

I believe that the Internet is fundamentally about protocols, and that platforms are to be banned if we care about it : https://knightcolumbia.org/content/protocols-not-platforms-a...

Novel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established.

To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use the hardware, create software to adapt a novel protocol to the higher layers of the networking stack to make it usable by application software (including addressing all of the ways that a new lower layer inevitably breaks an abstraction or two), and create the tooling necessary to make an ecosystem of non-802.11 wireless devices easy to install, maintain, and interoperate.

... But outside of particular special applications where something about 802.11 protocols or the frequencies they communicate upon makes them an ill-fit, there aren't many reasons to do so. Good enough displaces perfect in the common case.

Well, yes, lower level protocols are harder to implement and deploy because they require new hardware - but I'm not sure how are they relevant in a discussion about higher level protocols that are in software and build on the Internet Protocol?

The details of the complexities change, but the complexities are still there. You still need adoption by multiple parties, you still need to solve the application level challenges that HTTP solves (including, most importantly, secure communication over an open network), and you still need tooling to understand the protocol in flight, including its failure modes, to debug an application built atop the protocol. And you lose the utility of libraries and infrastructure built around using the other protocol.

The opportunity cost to do that with a brand new protocol instead of taking advantage of HTTP's flexibility to build new protocol atop HTTP is high.

I can only be suspicious about too much complexity and stacking in what is essentially infrastructure - that should be reliable, and therefore have minimum complexity. Any initial opportunity costs are tiny when these protocols are used by billions of devices !

But they aren't. The vast majority of novel protocols never see a billion adopters. There are a handful that have; the email protocols are one, HTTP is another.

Nobody's stopping anyone from building new protocols... Except, of course, the fact that nobody wants to adopt a new protocol. But if someone does come up with an indispensable alternative to HTTP(s), it should find traction, right?

Google and Facebook were very glad to "adopt" XMPP : https://salibra.com/p/the-death-of-jabber-8ea395e82f5b

XMPP is an excellent example of why existing flexible protocols push out novel protocols. When Google and Facebook wanted to improve the user experience of their XMPP clients, they encountered roadblocks in the fundamental design of the protocol itself. They finally reached a point where exiting the protocol was easier than improving it.

"Exiting" doesn't seem to be the right word? How do we stop Google, who is currently "exiting" HTML ?

Should we? I thought you were making the argument that HTML was a bad fit for non-hyperTEXT content. From up-thread:

"Why use the HyperTEXT Transfer Protocol for things completely unrelated to text..."

If Google agrees with you, would we want to stop them?

By "exiting", I mean Embracing-Extending-Extinguishing.

Complicated lists on the web are really bad. If you have a lazily populated table, it breaks the browser's Find, it typically breaks the scroll bar positioning, there's visible holes while it populates, scrolling is janky slow, the scroll bar will jump unexpectedly.

This is one place where HTML does not give enough primitives for a quality library-based solution.

> These people are missing the point

Maybe not.

If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.