3 ms·

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 manif

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?
    - MatthewPhillips 13y ago
      So you are saying that the low level bits should eventually be spec'd (but not necessarily first)? That is what this manifesto is about? If so, I can agree with that, but wish it was more explicitly stated in the manifesto.
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.

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?
  - MatthewPhillips 13y ago
    So you are saying that the low level bits should eventually be spec'd (but not necessarily first)? That is what this manifesto is about? If so, I can agree with that, but wish it was more explicitly stated in the manifesto.

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.