The Extensible Web Manifesto

by porker • 13 years ago

97 14 13 years ago

porker• 13 years ago

There's an accompanying blog post by Yehuda Katz covering the reasons behind the manifesto: https://medium.com/the-future-of-the-web/2fcd1c1bb32

MatthewPhillips4• 13 years ago

I'm not sure how this manifesto differs from how things work today. Today we get a mix of high level (AppCache) and low level (Touch Events) APIs. Is this manifesto saying always start with the low level ones? There are strengths and weaknesses no matter which way you go. Does this manifesto have a solution for the problems that exist when we don't have high level APIs, namely that the most common scenarios aren't well served, and library support is usually weak for new (less than several year old) APIs? For example in 2013 it's still a pain in the ass to detect a `tap` that works on both a touch screen and keyboard/mouse. The solution for this particular problem is a high level API (Pointer events).

So it's not clear to me that this manifesto is actually the right choice. For every high level API misstep there is a corresponding low level one as well.

bkardell2• 13 years ago

Did you read Yehuda's explanatory post https://medium.com/the-future-of-the-web/2fcd1c1bb32 or the linked readings on the manifesto? It's quite a bit different than today actually.

MatthewPhillips4• 13 years ago

Yes, I did. Again, some times high-level APIs fail to account for extreme needs, and some times low-level APIs are too hard to use to be practical for common needs. This is the trade off. Unless I am misinterpreting it, this manifesto seems to suggest that we sacrifice the latter in favor of the former. Which I disagree with.

slightlyoff3• 13 years ago

Hi Matthew,

So, first, it's not the mark of failure for their to only be a high or low-level version of some capability in the platform; at least not immediately. The issue arises when, having exposed one or the other, we [users|vendors|spec-authors] think the job is done.

It's like saying you've got a map of a continent having mapped either the outer shoreline or the inland lakes. It's a nonsensical thought, but it's where we tend to leave things today.

Your brought up AppCache -- which, as it happens, is a topic near and dear to my heart as I'm currently trying to engineer its low-level explanation: https://github.com/slightlyoff/NavigationController.

AppCache had relatively well-known, overwhelming deficiencies early in life...yet instead of attempting to peel the onion and explain the layers below the manifest format, the spec process rewarded piling into the clown-car of declarative configuration. It's the natural thing to do, after all.

What we're after here is _connecting_ the high and low levels. Creating a fully descriptive map that has texture, color, and major features marked and named.

We must always start somewhere, but we must also be anxious to know and describe what we can sense but can't yet explain. And that requires a sense of urgent investigation.

And THAT is what is missing today.

Regards

MatthewPhillips4• 13 years ago

I'm afraid I still don't understand what you're getting at.

What we're after here is _connecting_ the high and low levels. Creating a fully descriptive map that has texture, color, and major features marked and named.

A low level AppCache API doesn't exist though. So there is no connection to happen, right? I realize people wish AppCache had been designed differently. I wish Touch Events had been designed differently. The web is littered with mistakes, I don't think a manifesto is going to prevent them from occurring.

What is the essence of this manifesto? I read it as favoring low level APIs. Ideally we could have both but there aren't the resources to make that practical.

samth• 13 years ago

Low-level API design problems are usually of the form "this API is hard to use". For example, XHR. This is (a) work-around-able, as any developer who's used XHR successfully knows, (b) fixable, as witnessed by the numerous libraries that are better versions of XHR.

High-level API design problems are often of the form "there's no way to make this do what I need". That's what Yehuda's blog post about AppCache points out, and the result is either building something less good, or not building things on the web at all. That's much much worse.

agentultra• 13 years ago

It makes sense to me on some level. I realize that not everyone is a fan of Emacs but there's some truth to the old jab: "it's a decent operating that just needs a good text editor." It's more like a decent lisp that provides a kernel for implementing a text editor. I think it would be interesting if the web took that bottom-up approach (what I call the, "Emacs Philosophy," for lack of a better word): establishing a kernel for implementing a web browser. The interesting thing about Emacs is that there are several implementation of web server that are fully capable of interacting with the rest of the "environment" inside of your running Emacs process: it can serve up a web page that renders your currently active buffer for instance.

The problem with this approach is the trade-off with standardization: some vendors will implement things in different ways and libraries may not always work together without a little effort on the part of the user. Standardization does have its benefits... we almost went down the rabbit hole of active-x and "this site is made for Y," in the web world and it would be a shame to repeat that nasty bit of history (but we're already looming fairly close). The problem is that not everyone will cooperate and fickle web developers concerned with elegance and prettiness will go off and write three different incompatible implementations of the same thing. Users don't care about that stuff.

szany• 13 years ago

Alan Kay has been calling for this for a long time now.

_greim_• 13 years ago

What would be some examples? Low-level (sax-style?) access to the HTML parser is something I looked for years ago and never found. Would we be able to extend native CSS selectors, kind of like how you can do with jQuery selectors now? It sounds really promising.

bkardell2• 13 years ago

Yes, in layers. The problem currently is that if you want to tweak something you have to basically replicate the entire stack. That sucks - see Yehuda's article linked elsewhere in the comments for better examples. ps, if you want to play with jquery-like selector plugins to prollyfill a proposed feature, check out hitchjs.com

The Extensible Web Manifesto

Related Stories