[terracottage]

The separation between documents and programs assumes we know ahead of time all the things people might want to put inside a document. The evolution of the web shows this not to be true.

Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.

For comparison, consider that apple just proposed adding a html tag to display 3D models, just like an image.

The problem is that even basic interaction with a 3d model requires complex controls. There is no single standard for materials and lighting. The going methods are optimized for photorealism.

So adding a model tag just means baking in a set of assumptions, and doing so before you have a good idea of the kinds of things people will want to do with it and can't.

This is the real story of the web: poorly conceived standards and APIs, frozen before the medium had time to find its feet. It's a horse designed by committee in a world of cars.

You could turn the question around: why should webpages be dynamic at all? Just make a dumb client that requests rendered SVGs from a server after a client tells you its screen size.

Oh but that can't work because it's not really a document, but a dynamically laid out program after all.

If you want to displace the single page apps of the world, design a "document" format actually capturing all the nuances people want from them... Or get off the pot.

[chubot]

Yeah very good example -- a map is a program and is usefully embedded in documents.

Also this series of pages was extremely popular on HN, and can't be done without programs embedded in documents:

https://ciechanow.ski/gears/

In this case it's done quite "literally" !

https://ciechanow.ski/js/gears.js

Although on closer reading the OP does make a distinction between documents embedding programs, and programs that build up documents (like medium.com), which I agree is an anti-pattern.

[shadowgovt]

There was an experiment at Apple ages ago with the idea of reframing user interaction from the app to the document. OpenDoc (https://en.wikipedia.org/wiki/OpenDoc), which is remembered nowadays as an answer to Microsoft's OLE, was built around the idea that the nexus of programming could be not "What program is being run?" but instead "What data is being manipulated?" Different pieces of data would automatically invoke different code to interpret and / or modify them on-the-fly.

It was novel at the time, and we have something like that today in the form of the web browser... Though most data one fetches isn't intended for in-place editing, the convenient thing about web pages is that their hierarchical, dynamic, and self-modifying nature allow for a lot of the concepts explored in OpenDoc and OLE to be implemented within them.

[mckinley_]

> The separation between documents and programs assumes we know ahead of time all the things people might want to put inside a document. The evolution of the web shows this not to be true.

> Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.

I would argue that websites would be better off embedding an image of the location that links to a dedicated map viewing service like OpenStreetMap.

I might be in the minority here, but I always hate trying to use interactive maps in tiny boxes on people's websites.

[pbronez]

I agree. The reason it seems like web standards are always “behind where we should be by now” is mostly a coordination problem, with some prognostication error. To work seamlessly, we have to agree on what the standard should be and implement it well, broadly, and consistently. That’s always going to be slow and patchy.

I don’t think it’s possible to anticipate exactly how everyone will want to use everything, but maybe we could reach a world where it’s easier to iterate on this.

For example, what if there was a way for the community to implement new HTML tags for their preferred browser? This could be implemented as an extension, though perhaps not under the dominant WebExtension paradigm. This would allow much faster iteration on the semantics of HTML within the secure sandbox provided by the browser. The IPFS extensions are a nice example of doing this at the protocol level.

Similarly, what if you could version HTML tags? That would be a bit of a nightmare, but would also allow authors to communicate more information to the browser about what functionality is expected from the tag.

Of course, this would lead to a strange ecosystem with many dependency management headaches for users. You’d have to worry about what new features were needed by the page you’re trying to view, which extensions you have installed, do they implement the tags you need, and do they do it well?

This would lead to “super extensions” that address many tags and become de facto requirements for everyone. Then those become security targets. Of course, they would have their own coordination process, parallel to W3C. This would become a business target just like W3C is, with google trying to manipulate it to liquidate user freedom to support advertising.

It’s hard to get big groups of people to work together effectively.

[wruza]

Strangely “we” can do that for linux, but cannot for the web. “apt install myapp” pulls the required trusted binary dependencies, if they aren’t there, and that’s it. Qt, wx, gtk, ffmpeg, mesa, you name it. Potentially malicious code is reviewed by distros and is not included, so if you want to distribute libhacky with your myapp, the entire ecosystem has to accept it before a user could trust it. But browsers are somehow different. I think the main reason is that browser vendors want their control over the market, and the entire issue is not technical/community at all.

It’s hard to get big groups of people to work together effectively.

One of the valid ways to deal with it is to let them work separately.

[shadowgovt]

It doesn't work nearly as well in Linux as we'd want to impose such a design on the web.

"apt install myapp" works 95-99% of the time. The remaining time, you drop yourself into DLL hell of some flavor or other (package was poorly maintained, or your clone of the package repo indices is out of date, or you installed a local copy built-from-scratch of one of the binaries and it's now fighting with the distro binary, &c &c). And then remote tech support is impossible because for someone to provide support, they either need intimate knowledge of your configuration or you need to be running a stock configuration (and with very few, usually vendor-controlled exceptions, "stock configuration of a Linux distro" is a non-concept).

There was, ages ago, a paper describing what the design of a componentized browser rendering engine would look like (where pages could basically declare "I require engine components X, Y, Z" and the browser would have a library of them that could be spun up on a page-by-page basis). I wish I could grab a link to it; I think it may have been a Mozilla experiment? If I recall correctly, the complexity meant it never gained traction.

[selfhoster11]

An embedded map is definitely a document. The problem being that this document is too large to fit on your computer, so it needs to be stored on someone else's computer and therefore can only be accessed piecemeal.

> You could turn the question around: why should webpages be dynamic at all? Just make a dumb client that requests rendered SVGs from a server after a client tells you its screen size.

> Oh but that can't work because it's not really a document, but a dynamically laid out program after all.

What prevents one from sending a screen size and getting a server-side rendered SVG back with that exact screen size? It was a thing in Telnet days, and it's what Stadia/Mighty browser are doing. Not that I'm saying it's a good idea, but it is feasible.

[layer8]

> Is Google maps a document? Obviously not. But a document can still embed a Google map meaningfully and sensibly.

But it would be better if the application functionality of Google Maps was part of the document viewer (or selectable from within the document viewer), not of the document, because that gives you the flexibility to use your map viewer of choice, instead of being bound to Google Maps. That’s the point of separating document from viewer (and/or editor). Turning everything into an app reduces choices and interoperability.