Re: Futures

On 04/17/2013 05:51 PM, Dave Longley wrote:
> On 04/17/2013 11:45 AM, Tab Atkins Jr. wrote:
>> On Wed, Apr 17, 2013 at 7:24 AM, Norbert Lindenberg
>> <w3@norbertlindenberg.com> wrote:
>>> On Apr 16, 2013, at 16:55 , Tab Atkins Jr. wrote:
>>>
>>>> On Tue, Apr 16, 2013 at 8:30 AM, Markus Lanthaler
>>>> <markus.lanthaler@gmx.net> wrote:
>>>>> After a short discussion with Robin we decided to use method 
>>>>> overloading to
>>>>> We also considered Futures but decided that introducing a normative
>>>>> dependency to the DOM spec is not acceptable at this stage.
>>>> In this case, your API is a textbook example of Futures. You have an
>>>> async call which returns a single value, or an error.  You can't get
>>>> much more perfect than that.
>>> Maybe Futures should be in a separate spec? They don't seem to have 
>>> any dependencies on DOM, and having them separate would reduce the 
>>> bureaucratic hurdles for non-DOM specs to refer to them. Maybe 
>>> eventually they could migrate into the ECMAScript standard library 
>>> (currently known as ES chapter 15).
>> I suspect that baking them into JS would be a great final destination.
>>   In the meantime, though, that doesn't help the stated bureaucratic
>> hurdles, because a separate "Futures" spec will be exactly as
>> standards-track-advanced as the current DOM spec.
>>
>> ~TJ
>>
>
> I think the API for Futures looks pretty nice. I do have a few 
> concerns about using Futures with the JSON-LD API, however.
>
> 1. Browsers haven't implemented Futures yet. This means that JSON-LD 
> API implementors now have to implement Futures themselves or link to a 
> dependency that does so for them. This is unfortunate overhead, but it 
> could be overlooked if Futures really are the future. But are they?
>
> 2. JSON-LD API implementations in JavaScript are likely to be used 
> both on the client and the server (node.js). Futures are currently 
> tied to a DOM spec which, as others have stated, seems unusual. This 
> may make Futures seem like a client-side-only feature. Users of a 
> JSON-LD library may feel forced to create a more convenient or 
> conventional wrapper on the server-side. JSON-LD libraries that work 
> both in the client and in node.js may expose an alternative API 
> server-side to get better module adoption or to reduce time spent 
> doing support. Users of libraries that provide two APIs may either 
> avoid the Futures API on the client -- or write yet another wrapper 
> around the Futures API to ensure that native support gets used when 
> available. It seems to me that Futures really need to be integral to 
> the language or become more popular and a well-understood alternative 
> to the node.js continuation-passing callback style.
>
> 3. While WebIDL is a language for describing APIs meant to be 
> implemented by browsers, we also expect the JSON-LD API (or something 
> very close to it) to be implemented in various languages (eg: PHP, 
> Ruby, Python). If we include Futures, these implementations would 
> become more complex and their APIs may appear more foreign in certain 
> environments. Implementors may avoid these undesirable effects and 
> APIs will then deviate. I don't think this is necessarily that big of 
> a deal, but it is an unintended consequence of making Futures 
> first-class values in the browser ... as they won't be elsewhere.
>
> So what if Futures aren't chosen to be integrated into ES7 (or 
> whatever the numbering scheme is these days)? What if another choice 
> is made? Here are some possible outcomes, as I see it:
>
> 1. Futures eventually become a part of JavaScript. If JSON-LD uses 
> Futures, this is great. If JSON-LD doesn't, then JSON-LD libraries are 
> in the same boat as every other library that has an API that works 
> both server and client side (presumably, there will be a plan for 
> moving over to Futures in node.js should this happen). A new JSON-LD 
> API spec/note could be put out that describes the API using Futures.
>
> 2. Futures don't become a part of JavaScript -- and no alternative is 
> chosen. If JSON-LD uses Futures, then users of implementations will 
> likely write wrappers that end up making the JSON-LD API use the 
> conventional node.js continuation-passing callback style. JSON-LD 
> libraries may either expose two different APIs or link to the person 
> who writes the wrapper that makes the module familiar to node.js 
> users. In other words, the node.js callback style will be used by 
> anyone sharing code between the client or server -- or just anyone 
> used to writing node.js code who isn't interested in switching styles 
> for a special case. If JSON-LD doesn't use Futures, and Futures do not 
> become popular, there's little to no harm done. If Futures do become 
> very popular, it's not very different from #1.
>
> 3. Futures don't become a part of JavaScript -- and a different 
> Promise/Futures API is chosen. Here all of the confusion/overhead from 
> #2 happens, plus Futures are scrapped. The upside is that if 
> everything from #2 happens, it may be less painful to replace the 
> underlying Futures API because people were avoiding it to begin with.
>
> One of the reasons Futures were created was to standardize 
> asynchronous APIs (this isn't a problem for node.js, but it is for 
> client-side APIs). It seems to me that, until Futures (or any 
> alternative) seem as though they will be integrated into JavaScript, 
> that a better way to standardize would be to choose the path that has 
> already had great success with node.js. That doesn't mean that there 
> aren't other reasons to consider Futures -- it just means that another 
> mechanism has a proven track record. Furthermore, Futures and various 
> other competing asynchronous code-flow organizing APIs can easily work 
> on top of the style node.js has chosen.
>
> Another reason for choosing Futures over an alternative is that they 
> are powerful or technologically superior. This is true when comparing 
> them to the simplistic node.js callback style, but I think it's more 
> murky when comparing them to other various async code-flow libraries 
> out there -- especially considering that Promise-based libraries have 
> been around for a while and are not winning the competition.
>

I find your three-branches argument above pretty compelling, but this 
claim might be even more powerful.   I think you're saying that while 
there is a lot of interest in promises (everyone seems to love them), 
when new APIs are created, for the most part, they still use 
callbacks.    And that we don't know why that is, but maybe json-ld 
shouldn't be stepping out front without knowing why everyone else is 
hanging back.

I'm not sure how to test this assertion.   I browsed around github and 
npmjs.org but it's hard to get a broad picture or do accurate sampling. 
   Searching on words like 'promise' I see lots of downloads/stars for 
promise libraries, but not many for libraries that claim to use 
promises.   One that did show up was q-mongodb, a version of mongodb 
using promises.  On github it has zero stars compared to the 2000+ stars 
for node-mongodb-native.    So that suggests you're right, but it's 
hardly solid data.

       -- Sandro

> To reiterate, I do like the way Futures look -- I'm just concerned 
> that maybe they won't actually be the winner. If they aren't the 
> winner, then a JSON-LD API that uses Futures is a loser. If they do 
> win, then a JSON-LD library isn't in a different position from the 
> myriad node.js modules that run both on the client and the server. 
> There will be a migration plan (if necessary) to deal with that.
>
> Currently, Promises/Futures haven't gained much steam, relatively 
> speaking, in the node.js community (where decent async code flow is 
> vital). Understanding why that is would be very helpful, but may be 
> too difficult to do, especially given the time constraints. If 
> developers would actually prefer to use Promises/Futures over the 
> other choices, but they feel that they can't due to convention or 
> compatibility, that's one thing. However, if they just find the other 
> choices easier to use -- or if it's all just personal preference and 
> there's no real consensus -- I don't think Futures have that strong of 
> an argument.
>
> -Dave
>

Received on Thursday, 18 April 2013 02:34:42 UTC