What Web Can Do Today

> What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that.

I was about to argue that this website is actually an excellent example of what you seek -- each link has a separate URL associated with it that returns a page containing that content. The links point to these real URLs so they work with "open in new tab" and "copy link" and in browsers without JavaScript enabled, while the JavaScript that runs when you click it changes the page content via AJAX (possibly saving a few round-trips) and updates the current page URL so that back/forward history and the address bar both work just like you're navigating between real webpages.

And this works perfectly in Firefox (with JavaScript) and almost perfectly in Lynx (the table of contents still fills the first screenful, but that's hard to fix since Lynx doesn't support CSS). But it completely fails if you have JavaScript disabled in Firefox.

Every page starts with the table of contents visible and the content collapsed (through CSS). The page then seems to assume that JavaScript will be able to immediately switch the page to the correct view (i.e. the site is broken if you have working CSS but not JavaScript). Navigation to a given page directly should start the other way by default, and to make that happen is just 21 missing characters (` class="page-feature"` on the tag). However, this unfortunate error completely ruins this otherwise beautiful example of progressive enhancement.

what does python or go have to do with this web page? what does go have to do with making web apps faster?

You're talking about "progressive enhancement". It's a romantic idea, but it never happened, probably because it's too hard and the cost is not justified given most users run with their browser's default settings.

The precursor of the web made by Tim Berners-Lee dates back to 1980, but it was not based on HTML or HTTP. These happened later in 1990 and early 1991. But then CSS happened in 1994. And Javascript happened in 1995 at Netscape, but then Javascript was completely useless until Microsoft came up with the iframe tag in 1996 and then with XMLHttpRequest in 1999, which was later adopted by Mozilla, Safari and Opera. And people still couldn't grasp its potential until Google delivered Gmail in 2004 and Google Maps in 2005.

Not sure what the "the web was meant to be", we should ask Tim Berners-Lee sometimes, but in my opinion the web has been and is whatever its developers and users wanted it to be, with contributions from multiple parties such as Netscape, Microsoft, Mozilla, KDE/KHTML, Apple, Google and many other contributors, being a constantly evolving platform.

I think the parent knows exactly what CORS is and you're misunderstanding.

There's no fundamental reason browsers can't be configured to not send the user's cookies when making XHR requests, and in fact there's already a mechanism for a webpage to ask certain kinds of CORS requests to be "anonymous":

    The "anonymous" keyword means that there will be no exchange of user
    credentials via cookies, client-side SSL certificates or HTTP authentication

https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_setti...

Because of this arbitrary technical limitation, if a webpage wants to make a request to to an arbitrary URL equivalent to what a native app could ("anonymous"/cookies-free, of course), it'd have to make an AJAX (or WebSockets) call to an intermediary server running native code to do so, which is what the parent is referring to as a "CORS proxy".

--

> > * Open TCP and UDP sockets

> There are websockets, which aren't the same, I'll admit. Frankly, I'm not sure I want my web pages to be able to arbitrarily open TCP/UDP sockets. (I don't really want my native apps to be able to on whim, either…)

Sure, whatever, you don't want arbitrary native apps being able to open arbitrary TCP/UDP sockets, but you're missing the point. We both agree that it should be possible to, somehow, download an FTP client and somehow configure security settings so that it can work, right? (Restricted ports and filesystem or chroot or whatever.) There's no fundamental reason browsers can't have the same security framework so that you can open an FTP client web app and somehow configure browser security settings so that it can work, right?

--

> > * Barometric sensors

> You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.)

According to XKCD, "a lot of new Android phones" have a barometer sensitive enough to "actually see the pressure difference between your head and your feet."

https://what-if.xkcd.com/64/

(Obviously that's not an authoritative reference, but I think it's sufficiently addresses your question, and it's a fun article.)

> (and what would I want this for?)

What a great question, I'd love to know too!!