6 ms·

The Extensible Web Manifesto

97 points by porker 13y ago

MatthewPhillips 13y 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.
- bkardell 13y ago
  Did you read Yehuda's explanatory post https://medium.com/the-future-of-the-web/2fcd1c1bb32 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.
  - MatthewPhillips 13y 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.
    - slightlyoff 13y ago
      Yeah, you are misinterpreting. See my other comment.
- slightlyoff 13y 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 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
  - MatthewPhillips 13y 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.
    - slightlyoff 13y ago
      This misunderstands what happens inside implementations. There ARE low-level bits "down there", but they aren't spec'd. That what the Navigation Controller is: a spec for the low-level bits. As a part of that process (and Web Components before it), the goal isn't to throw out what has come before (we don't get that luxury out here on successful, non-proprietary platforms), but to re-cast it in the light of a lower-level thing that explains it. You can go the other way too. Noodle on this to get a sense for it: how much of the <audio> element can be implemented with some JS and the Web Audio spec? Since those connections make sense, why isn't <audio> spec'd in terms of Web Audio, such that you can plug in/out the bits you need when you need something slightly different?
- samth 13y 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.
porker 13y 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 https://medium.com/the-future-of-the-web/2fcd1c1bb32
agentultra 13y 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 13y ago
Alan Kay has been calling for this for a long time now.
_greim_ 13y 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.
- bkardell 13y 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

97 points by porker 13y 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.

bkardell 13y ago
Did you read Yehuda's explanatory post https://medium.com/the-future-of-the-web/2fcd1c1bb32 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.
- MatthewPhillips 13y 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.
  - slightlyoff 13y ago
    Yeah, you are misinterpreting. See my other comment.
slightlyoff 13y 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 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
- MatthewPhillips 13y 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.
  - slightlyoff 13y ago
    This misunderstands what happens inside implementations. There ARE low-level bits "down there", but they aren't spec'd. That what the Navigation Controller is: a spec for the low-level bits. As a part of that process (and Web Components before it), the goal isn't to throw out what has come before (we don't get that luxury out here on successful, non-proprietary platforms), but to re-cast it in the light of a lower-level thing that explains it. You can go the other way too. Noodle on this to get a sense for it: how much of the <audio> element can be implemented with some JS and the Web Audio spec? Since those connections make sense, why isn't <audio> spec'd in terms of Web Audio, such that you can plug in/out the bits you need when you need something slightly different?
samth 13y 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.

porker 13y 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 https://medium.com/the-future-of-the-web/2fcd1c1bb32

agentultra 13y 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 13y ago

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

_greim_ 13y 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.

bkardell 13y 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