[kerkeslager]

Ultimately, I think the failure of the open web runs deeper than that. When I visit, for example, a cookbook website, when I view a recipe, the problem isn't just that the site can run arbitrary scripts on my computer. It's also that I have no control over how that recipe displays because so much of that display is in HTML. I can't pull it into a useful format and store it with all my other recipes because it's in HTML. And contrary to its goals, HTML isn't a semantic markup language. I can't automatically convert imperial into metric units, because they aren't represented as measurements at all. I can't configure the display of the recipes for my nearsighted grandmother because that configuration happens when the recipe is rendered from a recipe document into an HTML document. The failure of the open web is that we need JavaScript to reasonably render the various kinds of documents which are being stripped of their metadata so they can be shoehorned into a non-semantic document format.

Removing JavaScript prevents malware and adware vendors from running their programs on our machines, but it doesn't empower users. We can control or data but we still can't analyze data websites give us.

The way forward, I think, is to create more standardized document types and let people build renderers for them. If I go to a cookbook website, I should be able to download recipe documents. If I don't like how my cookbook program renders the recipe, I should be able to download another program can render it. This breaks the power that websites have as the sole entities with the capability to render their documents, and gives the power back to users.

[jdmichal]

I'll repost a comment by mcphage on why this doesn't work, in general. TL;DR is that common ontologies sound great but don't work in reality, because it leaves no room for value-added services from individual providers. (Recipes would probably be OK, because there's just not a lot of value-add you can really provide. Or, alternatively, I'm just completely ignorant about how value could be added.)

https://news.ycombinator.com/item?id=13214134

"""

I'm not sure this goal is very practical, even in the toy example you used (being able to swap data sources for weather forecasts).

If you can use a common vocabulary to access multiple APIs, that requires that all APIs implement the same feature set. Which means getting the API sources to agree on the features to implement, and how to describe them, and stop them from adding any features on that the others don't have. But of course, they'll all be motivated to add their own features, to distinguish themselves from their competition.

And once a API consumer is using a feature that other API producers don't support, then the consumer is locked into that producer, and the whole shared vocabulary is for naught. And of course the API consumers will be looking for additional features, because those translate into features that they can offer to their customers.

Basically, this requires API producers to work together to hobble their ability to meet their customers' needs, all to make it easier for their customers to drop them for a competing endpoint. So it looks like a net negative for everybody.

"""

[kelnos]

Eh, that's not entirely true.

To still allow for competition, you define a base feature set and representation, and then you allow vendor extensions. You need some sort of standards body that can promote vendor extensions to standardized, supported things. And clients can choose to support whatever (or no) vendor extensions that they want to.

However, I agree with you that it's not very practical, but for different reasons: 1) competitors don't necessarily like to cooperate to that level and 2) it will slow down progress a lot, which is a decently good reason for #1. And 3), which I think is the big one:

Companies doing this stuff really don't want standards if they're the first-mover, because standards necessarily enable competition. If I'm an anti-competitive producer (or even just a producer that doesn't mind competition, but wants to maintain a head start long enough to secure a market position), I don't want to start off with a standard: I want to do my own thing, and get people to adopt it, and then I can lock them in, at least temporarily. If someone comes along later and clones my format, that's fine, but they have to do work to figure it out, and I still own the format, so I'm naturally ahead.

[jdmichal]

> To still allow for competition, you define a base feature set and representation, and then you allow vendor extensions. You need some sort of standards body that can promote vendor extensions to standardized, supported things. And clients can choose to support whatever (or no) vendor extensions that they want to.

Right. The problem is in the first step. The moment a consumer likes a vendor extension and begins relying on it, they are locked in until the standards body gets around to standardizing it. So all this cooperation to pick a standard and maintain it, and consumers still end up locked in because they like certain extensions more than others. And software providers for consumers still have to write individualized support for all the providers to in order to manage all their extensions.

So all these cycles went to building a standard, and where's the actual win? We still have handlers customized to individual providers. We still have consumers choosing to rely on singular providers.

[kelnos]

That's just the tradeoff you make. The lock-in is only temporary until the new feature is standardized. If users like the non-standard feature enough to use it and want it in the standard, then it's a good thing. Otherwise you end up with stagnant crap and no innovation.

[kerkeslager]

You left out users when you said "everybody".

Yes, this model makes it so content creators actually have to create content or their customers will drop them for a better content creator. That sounds great for users.

I'm not sure why I should care that a few user-hostile rent-seeking entities won't have complete control of the internet anymore.

The API extensions causing vendor lock-in complaint is fairly bogus. Features would be driven by the content renderers, not the content creators. It's that very abdication of power that browsers have given to content creators that the system I'm proposing would avoid.

[jfrankamp]

An interesting choice of example because recipes are one of the best defined and used micro formats on schema.org and used practically by google (which encourages adoption). Writing a generic recipe reader is relatively easy, I've done it although not for your use case. Your point stands though, just not for recipes IMO.

[rotrux]

Oh but don't worry! As soon as someone breaks www.cookbooksRus.com's "Encrypted Media Extensions," you or someone totally benevolent will be able to help render ANYONE's www.cookbooksRus.com browser-experience! Server-protection isn't always a 0-sum game against client-protection, but in this case it totally is.

[otakucode]

Sure, and I'm sure the users will step up to fund your legal defense when you go down for violating the DMCA and CFAA and whatever else they can come up with.

[rotrux]

Phooey & patooh! Obv the internet population doesn't know what's good for them. Politicians are WAAAAAY smarter than normal people. Everyone knows this.

One must simply route their VPN traffic through Eritrea => Thailand => Russia => Cyprus => China => back to some AWS server in SF & rejoice.

Just make it more expensive to trace you than the value of what you took/broke/F'd-with! Lawyers' fees not necessary!

[kerkeslager]

When the files being passed around are self-contained documents, the central server becomes less and less even a necessary component of the system.

[TeMPOraL]

As it should be. I hope the DRM folks will ignore IPFS until it's too late.

[chrisweekly]

Respectfully, I see your complaint as conflating or combining several orthogonal issues. Addressing your sight-impaired grandmother's needs is a matter of accessibility; user-centric responsive design considerations relate more to CSS than JS.

Gotta push back against the "create more standardized doc types" bit (wat) -- it sounds like you want more APIs and more user-friendly tools for consuming them, which would be great and is more compatible with reality. SoA and recent shifts toward empowered-client approaches like GraphQL are steps in that direction.

I'm also glad you mentioned "documents" so often, because your ideas relate to a document-centric web. Which is not what we have. Rather it's evolved into an application delivery context.

[kerkeslager]

> Respectfully, I see your complaint as conflating or combining several orthogonal issues. Addressing your sight-impaired grandmother's needs is a matter of accessibility; user-centric responsive design considerations relate more to CSS than JS.

That's exactly what I'm saying. JavaScript isn't the only part of the problem: HTML and CSS are also components of the problem.

Your distinction between applications and documents is an insightful one. Perhaps one way to describe the problem is that HTML and CSS contain elements of "application" rather than "document". If we think of a document as being purely semantic and layout/style as being elements of an application's rendering, then it becomes clear that only a fraction of HTML is actually document-relevant. CSS and the rest of HTML is application.