Callbacks vs promises

[dontcallmedom]

VIAS uses callbacks for its asynchronous operations, when most of the JS world has moved to promises (which also enables usage of the new async/await ecmascript keywords).

Is there any reason to prefer callbacks to promises?

[aShinjiroUrata]

Hello Dominique( @dontcallmedom ) -san,
Thanks for the comment.

Is there any reason to prefer callbacks to promises?

Honestly, I have to say that there is no strong reason.

Histroically saying, I took over the editor's task from my successor around April 2017 and originally it was callback style.
The topic of changing to promise style was once raised in a discussion but at that time it was not strongly pushed to the 'promise' direction.

At the time, I did not push to 'promise' direction as well with minor reasons such as

• I was not confident that promise will be the best practice for long time since there are other asynchronous syntaxes such as generator, async/await. ( and we sometimes hear word like 'promise hell'.)
• API users can easily write a wrapper with Promise or other syntaxes to cover callback style API if he/she prefers.
• At the time(May to June of 2017) I was hurry to fix the spec for turning to CR since it was already late for the scheduled timeline (=move to CR on April2017).

After that, I had been busy for other task and not updating VIAS for sometime.
During the time I personally got a few comments like 'shouldn't we use promise?' and I have been
thinking about whether we should change to Promise at this phase.

@dontcallmedom ,
do you think changing to promise style is something like nearly mandatory?

[dontcallmedom]

Mandatory is probably too strong of a statement, but I can't think of any recent asynchronous Web API that would still be using callbacks. Promises aren't perfect, but they have much cleaner semantics, and they play very well with async/await.

Naturally, VIAS can be wrapped into promises - but since VIAS is itself a wrapper to the protocol, this starts to be lots of wrapping :)

(note that I am personally unconvinced that a standard wrapper is needed at all - see #233)

[aShinjiroUrata]

Thanks for the comment. That sounds reasonable to me.

I'd like to hear if there is other people who have opinion on this issue?

[wonsuk73]

I am on the position with promise rather than callback. Because that is promitive JS feature for supporting async call and which provides a clear benefit for developing and maintaining the program code.

[peterMelco]

@wonsuk73 Not being a web developer could you show by a simpe example what you mean ?

[wonsuk73]

@peterMelco There are many articles to compare the two different approaches (callback and promise). Below article is good simple note for differences between them.
http://smilyanp.com/callbacks-vs-promises-differences-simple-notes/

[aShinjiroUrata]

@wonsuk73 , @peterMelco
Thanks for the comment.

I am on the position with promise rather than callback.

I suppose this may be good timing to change get() and set() to promise style.
Please let me know if other members has affirmative/negative opinion.

[sou3ilow]

+1 for promise where both are ok. I'm not sure that all callback can be changed to promise.

…

On Mon, Sep 25, 2017 at 1:49 PM, Shinjiro Urata ***@***.***> wrote: @wonsuk73 <https://github.com/wonsuk73> , @peterMelco <https://github.com/petermelco> Thanks for the comment. I am on the position with promise rather than callback. I suppose this may be good timing to change get() and set() to promise style. Please let me know if other members has affirmative/negative opinion. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#232 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-qroSz9u7PbEd9hCfas4DTYTpJe8lAks5slzDugaJpZM4PbAD6> .

[aShinjiroUrata]

@sou3ilow -san, thanks for the comment !

[anawhj]

I'm sure that all callbacks can be replaced with promises or other ways. Apart from @aShinjiroUrata's comments on why we chose the callbacks above, there seems a discussion in the last f2f meeting in #198.

I would like to put some comments to consider reasonable designs of VIAS. I hope we can finalize the work while properly solving the concerns on VIAS, even though it would be a WG note or a reference for the relevant library as raised in #233. I believe that VIAS is a valuable work in terms of making the web apps easily access the VIS server.

• Note that W3C standard API should be designed following the recent trends with strict and elaborate. Otherwise, it will lose public confidence. There seems no callbacks for asynchronous Web API these days in consideration of readability, maintenance, and developer friendly API so that the most async functions have been handled with promises even in JS libraries. (more info, for why promise, not callback).
• There has been some issues such as stream data that couldn't be handled by promise according to the guideline for using promise. subscribe() method is one of the examples because the method should always be run for waiting to receive push messages even after the method is called once. we can investigate a way to effectively handle the case in Push API. In the spec, subscribe() method is handled with promise through reasonable mechanisms within the algorithm description.
• I encourage VIAS to use pre-defined IDLs made by W3C. For example, VIAS defines VISError dictionary with several attributes, but we could see the pre-defined types in error names tables and just refer the names within promise algorithms. I wish we could try to use the existent terminologies and IDL as much as we could. Presentation API would be one of the great examples to make the best use of terminologies from other references. In VIAS, there could be possible to re-use some IDLs such as Web Messaging, WebSocket.

[aShinjiroUrata]

Thank you very much for the valuable comments, @anawhj -san.
Thanks for good references as well.
Basically I agree to your opinion.

• Although, using promise for rucurring event seems not common method, I agree to investigate PushAPI's subscribe() method.
  I suppose revising one shot APIs (such as ge, set) to promise style would be not controvertial and I'd like to revise VIAS on this point when I can work.

• Regarding VIAS's error handling, I agree to the idea that use pre-defined IDLs is preferable.
  On the other hand, VIAS have to be able to handle Error variations defined in VISS. So I would like to look at VISS error definitions as well, when considering to use pre-defined error name tables.

[aShinjiroUrata]

Excuse me to become so late.
I have updated oneshot methods to promise style with below commit.

3bf1b36

Then, close this issue.