What about "content" that certainly is a document, but which just happens to not be a hypertext document? For example, a mind-map, or zoomable-level-of-detail timeline. Content that, on the modern web, you'd expect to be sent as a lightweight Javascript viewer app wrapped around the document itself. But where that's only required because the web-browser itself isn't already doing the job of attempting to render that document. Like it does with, say, SVG.
A lot of people think that "web browser" has some fundamental identity with "hypertext document viewer", but that's not what "the Web" is — the web is the set of resources you can request over HTTP; not the subset of those resources that are formatted in HTML. A "web browser" is fundamentally "a tool for letting you navigate to the resources at HTTP URLs" — essentially an address-bar with a "meta-renderer sandbox" attached.
(Remember RealPlayer, QuickTime, and other plugins you could install that would enable your web browser to "natively" render new content types? Those things are all also "the web"!)
And to put an even finer point on it: if you put a PDF, or an SVG image, at a URL; and that PDF or SVG image contains clickable links — then that document is a web hyperdocument. A web of PDFs is just as much a web as a web of HTML documents is! So not even "publishing hyperdocuments on the web" is necessarily coupled to HTML. (Tangent: remember VRML? It allowed clickable links, too. VRML was a hyperdocument format!)
(Are plaintext files that happen to include textual URLs, hyperdocuments? If so, then a gopher or FTP client would also technically be a "web browser." That's going a bit too far, I think.)
You are arguing a point I didn’t make. I think it would be great if we build standards for consuming media and content like mind maps and charts - I just don’t want to be forced to open up to running any arbitrary code to be able to consume that content. We’ve been lead into a false dichotomy.
My point was that — allowing that "the web" is just arbitrary 'stuff' at URLs, and that a "web browser" is a tool for viewing that arbitrary 'stuff' — there are always going to be novel non-standardized, proprietary document types residing at URLs, that people will nevertheless expect their web browser to display for them (and rightly so!)
How will users view these documents in a timely manner (i.e. not on the W3C's glacial schedule)? Whatever your answer, it's going to necessarily involve some kind of arbitrary code execution at some point. Whether that means Javascript; Java/ActiveX applets, or PPAPI (NaCl); Chrome Apps or other in-browser centrally-managed-lifecycle apps; installable NPAPI plugins like Flash; or COM component servers (as seen when e.g. IE/Edge is navigated to an .xlsx file URL.)
Presuming the user discovers they can't view document X, and therefore goes and hunts down tech Y and installs it to make X viewable, all such "tech Y" are equivalent in the sense that they're someone's arbitrary proprietary code, that the user is rolling the dice on hopefully allowing them to view X, while not doing anything other than allowing them to view X.
> allowing that "the web" is just arbitrary 'stuff' at URLs
It's not. The majority is just textual content I want to read. Possibly with a few images.
I don't need Javascript for that. And being forced to use Javascript for it is the exact problem.
For the minority (something clever that requires user interaction beyond reading text and looking at pictures, this "non-standarized", maybe even "proprietary" stuff) Javascript is just fine.
But don't force me to use Javascript for the rest.
The majority of web developers think the semantic web is a waste of time. (I don’t)
Pushing your point further, you’re saying that every new development that could be shareable over the web gets published as a standard and that browser developers build implementations of those standards, before the content is released. By the time that’s happened, your mind map will be out of date.
When anyone creates a novel representation someone will need to develop new code that renders it. Whether that goes into a native browser or a Java applet or a JS script, it’s still arbitrary code downloaded from a source you need to establish trust with.
You’re taking this too far. (And I admit my illustration smudges both your and my point).
The problem we really have is that advertising and SEO have corrupted the web to the point of unusability. If we (google mostly) hadn’t monetised individual tracking, we wouldn’t need the worst bits of what people do with javascript. Publishers are fighting for your attention because that creates surface for advertising. And advertising creates revenue. If they could sell content directly rather consumers wouldn’t get caught in an attention war and websites would be less intrusive and demanding.
Javascript itself isn’t the problem. I’m not convinced that scripted documents are the problem. The problem is surveillance capitalism and the attention ecconomy.
GP's critique is not that web browsers render SVG and PDF in addition to HTML. It's the outsized role of JavaScript specifically: our browsers execute arbitrary (possibly user-hostile) code while simultaneously trying to protect us from its effects.
The point I was trying—perhaps failing—to make, is that it doesn't make much sense to create a web browser that can render "web documents" but not "web apps", since the concept of a "web document" is basically "anything you can access over HTTP", and so a "web browser" — a tool for viewing arbitrary "web documents" — really doesn't work as a concept except by adding some mechanism to execute arbitrary code in the service of viewing those arbitrary documents.
That mechanism doesn't necessarily need to involve code being delivered directly from the same server the document is coming from, mind you. It could instead involve an out-of-band app store, where accessing a URL zero-installs a heavily-sandboxed plugin required to view it, and loads it into the browser. (Implementations of this: iOS App Clips; Sandstorm grains.) But those apps are usually still created by the same developer as the document anyway, so there's little difference between this out-of-band zero-install app approach, and having Turing-complete web documents. Either way, the developer of Boogle Maps can still mine bitcoin in the background while you have the map loaded.
The B2B productivity/collaboration app space — where you can expect that all your users are mainly using full PCs — is firmly all-in on in-browser web-apps, with their mobile experiences being second-class afterthoughts.
I imagine apps are better at being apps than a web browser, and due to their complexity webapps are also tightly coupled to a specific brand and version of browser, so you have less compatibility problems by bundling your preferred vm with your application.
I'd argue today that "apps" do pretty well whether they're in a browser or native. Native Slack is pretty good. Web Google Docs/Sheets is pretty good. VSCode is almost the same regardless of where you run it. But equally, Sketch and Ableton Live are also pretty good. Native Teams and Zoom are travesties of usability and stability.
Basically, I don't see consistent patterns of good or bad between web and native apps to justify your comment that "apps are better at being apps than a web browser".
Most GUI apps, native or otherwise, get associated with a brand. Especially the good ones. I'd buy Ableton swag, I love the brand that much.
The VAST bulk of web apps are NOT browser version specific. It's largely only bespoke, internal corporate apps that are tied to one version of a browser.
A lot of people think that "web browser" has some fundamental identity with "hypertext document viewer", but that's not what "the Web" is — the web is the set of resources you can request over HTTP; not the subset of those resources that are formatted in HTML. A "web browser" is fundamentally "a tool for letting you navigate to the resources at HTTP URLs" — essentially an address-bar with a "meta-renderer sandbox" attached.
(Remember RealPlayer, QuickTime, and other plugins you could install that would enable your web browser to "natively" render new content types? Those things are all also "the web"!)
And to put an even finer point on it: if you put a PDF, or an SVG image, at a URL; and that PDF or SVG image contains clickable links — then that document is a web hyperdocument. A web of PDFs is just as much a web as a web of HTML documents is! So not even "publishing hyperdocuments on the web" is necessarily coupled to HTML. (Tangent: remember VRML? It allowed clickable links, too. VRML was a hyperdocument format!)
(Are plaintext files that happen to include textual URLs, hyperdocuments? If so, then a gopher or FTP client would also technically be a "web browser." That's going a bit too far, I think.)