On 11/20/2015 10:24 PM, Justin D'Arcangelo wrote: > One valid reason I’ve heard from Jim in favor of this type of iterator > callback API is that it would allow the first few records of data in a > given query to be put on-screen faster. That being said, there are > several ways to solve the “get data on-screen fast” problem with an HTTP > API, one of which is to have paginated calls so you can get the first > 10-20 records super-fast and defer the query for the remaining items. > Another solution is “better caching” which can be solved any number of > various ways via ServiceWorkers or other means.
One of the benefits of a callback-based API over pagination/batching results into groups is that it's simpler. Obviously, indexedDB already works like this (indeed, so do many database APIs). Designing the APIs that will sit "on top" of indexedDB to work in a similar way as indexedDB keeps minimizes complexity and removes one source of possible bugs or performance issues. If the Music backend's API used one callback call per item, our glue code could be quite a bit simpler compared to code that paginated the results. This underscores one of my main issues with parts of the NGA work. While we can still achieve good performance (e.g. by paginating results or taking advantage of caching at another level, like in gaia-fast-list), it requires us to be smarter. For the most part, OGA allowed us to write "dumb" code and still achieve good performance. We did have "advancedEnumerate", but that's just a regular enumeration where we skip the first N results. A hypothetical version of OGA Music that used gaia-fast-list might not even need that. In my experience, the best APIs are the ones that don't force users to write complex/clever code to get good performance. Good APIs should try to hide complexity from the user and make it obvious how to get the best results from it. Then we can spend our effort on other hard problems. All of this doesn't mean that Service Workers will never be a good idea, but I think we'd have to show that they're better for a particular app than bridge.js (or even than a single-document app). Currently, I think Service Workers are strictly worse than bridge.js, since the former has worse performance and fewer features compared to the latter. While being able to flip a switch and use Service Workers in the Music app is a nice way to test them out, I don't think this benefits the Music app today. Given the choice, I'd rather take advantage of all the niceties that bridge.js has to offer and then tell the people working on Service Workers, "here are the things we need in order for Service Workers to provide value for us." If and when those things are supported, we can switch to Service Workers, which hopefully will be a relatively simple task if we've designed our codebase well. - Jim _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
