Earlier quoted context omitted.
If someone launches a new HTML-based Web with crippled javascript ( no network comm access, for one, including ability to trigger links or forms), some small, restricted subset of CSS, and much better built-in dynamic table and form elements, I'm there . This Web's about to be eaten by DRM and WebAssembly anyway. Pretty soon it'll just be a way to deliver QT apps (or some other framework that runs in WebAssembly and…
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 HT…
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.
"""