[Dojo-interest] Becoming promises-aplus compliant

Eugene Lazutkin eugene.lazutkin at gmail.com
Mon Apr 22 18:43:42 EDT 2013


Inline.

On 04/22/2013 10:48 AM, Dan Rumney wrote:
> That's a good point; I probably misstated my intent.
> 
> Adding a second to the start of every Deferred is definitely something
> to be avoided. However, I would be concerned if the mechanics of how
> `then` and `when` is implemented were exposed too much to the user. A
> cursory glance at the likes of Stack Overflow and other Q&A sites shows
> that novice JS developers have a really hard time getting their heads
> around asynchronous code. The idea that Deferred would be sometimes
> synchronous, sometimes asynchronous gives me the willies when it comes
> to training junior developers.

Let's all switch to Basic, which didn't have this problems from the day
1. :-)

Seriously, I personally investigated a problem of "sluggish UI" only to
see that a dynamic chain of dozens promises was formed, those promises
used setTimeout(), and it lead to 300-500ms delays right there, which
were well noticeable by end users.

Just several days ago my friend noted to me that working with an
asynchronous framework he saw chains as big as a hundred of promises.
The framework in question assumes that all user callbacks can be
asynchronous so all communications (arguments and return values) are
promises. Talk about "paying for abstraction".

> As previously stated, async code should be written with zero assumptions
> about *when* it is run... as such, it *should* run cleanly whether it is
> executed in the current thread or in a new thread.

How about: "async code should be written with zero assumptions about
*when* it is run... as such, it *should* run cleanly whether it is
executed in the current thread or in a new thread" --- it is easy to
understand even for novices. And doesn't require extra code, which is a
clear win in my book --- the best code is a code never written.

> However, I certainly see that changing the internals so that Deferreds
> can resolve as soon as possible (including immediately) could be a good
> thing. It's certainly possible that this could break some users' code
> out there, but it's arguable that this code is, strictly speaking,
> incorrect, since it makes assumptions about when some async code will
> run, i.e. *not* in the current thread.
> 
> 
> ... I'm not sure I have a point :)

As long as we talk about using promises once per page in a single IO
operation, we are fine with *any* promise implementation. To be frank,
with such setup we are fine with callbacks. The main promise of a
promise (no pun intended) is that it provides a *composable* and
*scalable* foundation --- try to juggle hundreds of callbacks. On the
surface it is true, and smart people can even dive into monads to show a
potential of promises. Let's not bog down this promise with our
implementations. Foundation blocks, which can be used on a mass scale,
should be as fast as possible in order to be truly scalable and practical.

Cheers,

Eugene

> 
> 
> On Mon, Apr 22, 2013 at 7:31 AM, Shane Green <shane.green at me.com
> <mailto:shane.green at me.com>> wrote:
> 
>     Sorry, premature send, the concern…
> 
>>     Why should performance matter?
> 
>     That was the reason it was being discussed.  True, code should be
>     written to be agnostic and to when and where it's called back by a
>     deferred, by asynchronous operations are, in general, a performance
>     enhancing mechanism.   If you added an additional second to every
>     RPC invocation that polls live-values for a real time monitoring
>     page, for example, you'd have introduced a real problem.  There are
>     probably lots of applications where adding a full second to the
>     /start /of every deferred operation might add up to what users
>     considered an unacceptable hit on performance, don't you?  
> 
> 
> 
>     Shane Green
>     805-452-9666 <tel:805-452-9666> | shane.green at me.com
>     <mailto:shane.green at me.com>
> 
>     On Apr 22, 2013, at 5:23 AM, Shane Green <shane.green at me.com
>     <mailto:shane.green at me.com>> wrote:
> 
>>     Why should performance matter?
>>
>>
>>
>>
>>     Shane Green
>>     805-452-9666 <tel:805-452-9666> | shane.green at me.com
>>     <mailto:shane.green at me.com>
>>
>>     On Apr 22, 2013, at 5:04 AM, Dan Rumney <dancrumb at gmail.com
>>     <mailto:dancrumb at gmail.com>> wrote:
>>
>>>     I have to admit, I was also a little confused about the
>>>     discussion around the performance of callbacks when a Deferred is
>>>     already resolved. Why should this ever matter?
>>>
>>>     Like Eugene, I write my asynchronous code with the assumption
>>>     that any Deferred callbacks could be called at any time. Writing
>>>     async code in our applications using assumptions about whether it
>>>     will (or will not) run in the current execution thread would be
>>>     considered a major design flaw.
>>>
>>>     Sent from my iPhone
>>>
>>>     On Apr 22, 2013, at 1:04, Eugene Lazutkin
>>>     <eugene.lazutkin at gmail.com <mailto:eugene.lazutkin at gmail.com>> wrote:
>>>
>>>>     I am all for the code correctness. Yet implementing promises
>>>>     three times
>>>>     now, I don't understand the problem. Could you explain what is it
>>>>     exactly? Better yet, do you have a code I can use to test the
>>>>     problem
>>>>     you experienced?
>>>>
>>>>     My rule of thumb for promise callbacks is simple: do not make any
>>>>     assumptions about when this code is going to run. So far it
>>>>     worked with
>>>>     my implementations, and with others. Did I miss something?
>>>>
>>>>     Cheers,
>>>>
>>>>     Eugene
>>>>
>>>>
>>>>     On 04/21/2013 08:42 PM, James Burke wrote:
>>>>>     On Sun, Apr 21, 2013 at 2:05 PM, Eugene Lazutkin
>>>>>     <eugene.lazutkin at gmail.com <mailto:eugene.lazutkin at gmail.com>>
>>>>>     wrote:
>>>>>>     Still I don't see why "the next turn" should be a universal
>>>>>>     answer for
>>>>>>     all use cases, even if we forget about its implementation for
>>>>>>     a moment.
>>>>>>     here are places, when it is appropriate, that's true, but it
>>>>>>     is far from
>>>>>>     a universal requirement. Moreover, if I want a delay, I can
>>>>>>     add it, with
>>>>>>     the current implementation, when needed. The latter is not
>>>>>>     true for
>>>>>>     delay-based promises --- you cannot make them immediate no
>>>>>>     matter what
>>>>>>     you do.
>>>>>
>>>>>     I am not doing the work, just a bystander, so feel free to discard:
>>>>>
>>>>>     In the interests of compat, the default be next turn. I've
>>>>>     written AMD
>>>>>     loaders that try doing sync or next turn on the fly, and it is
>>>>>     difficult to get the logic right. In short, I have hit code
>>>>>     correctness bugs that are hard to get right if there is a
>>>>>     mixture. And
>>>>>     this is all in code I control.
>>>>>
>>>>>     Code correctness and allowing dojo modules to be composable
>>>>>     with other
>>>>>     modules and that may use other promise implementations are more
>>>>>     important than speed concerns. Using the postMessage hack and
>>>>>     setImmediate where available should be used if measured to be
>>>>>     faster
>>>>>     than alternatives, and try to push for faster next turn
>>>>>     capabilities
>>>>>     in JS environments when available options are not sufficient.
>>>>>     As DOM
>>>>>     Futures get further along, there will be natural pressure to
>>>>>     get fast
>>>>>     next turn anyway.
>>>>>
>>>>>     James
>>>>>     ________________________________________________________
>>>>>     Dojo Toolkit: http://dojotoolkit.org/
>>>>>     Tutorials: http://dojotoolkit.org/documentation/
>>>>>     Reference Guide: http://dojotoolkit.org/reference-guide
>>>>>     API Documentation: http://dojotoolkit.org/api
>>>>>
>>>>>     Dojo-interest at mail.dojotoolkit.org
>>>>>     <mailto:Dojo-interest at mail.dojotoolkit.org>
>>>>>     To unsubscribe, visit:
>>>>>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>>>
>>>>     -- 
>>>>     Eugene Lazutkin
>>>>     http://lazutkin.com/
>>>>
>>>>     ________________________________________________________
>>>>     Dojo Toolkit: http://dojotoolkit.org/
>>>>     Tutorials: http://dojotoolkit.org/documentation/
>>>>     Reference Guide: http://dojotoolkit.org/reference-guide
>>>>     API Documentation: http://dojotoolkit.org/api
>>>>
>>>>     Dojo-interest at mail.dojotoolkit.org
>>>>     <mailto:Dojo-interest at mail.dojotoolkit.org>
>>>>     To unsubscribe, visit:
>>>>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>>     ________________________________________________________
>>>     Dojo Toolkit: http://dojotoolkit.org/
>>>     Tutorials: http://dojotoolkit.org/documentation/
>>>     Reference Guide: http://dojotoolkit.org/reference-guide
>>>     API Documentation: http://dojotoolkit.org/api
>>>
>>>     Dojo-interest at mail.dojotoolkit.org
>>>     <mailto:Dojo-interest at mail.dojotoolkit.org>
>>>     To unsubscribe, visit:
>>>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>>
> 
> 
>     ________________________________________________________
>     Dojo Toolkit: http://dojotoolkit.org/
>     Tutorials: http://dojotoolkit.org/documentation/
>     Reference Guide: http://dojotoolkit.org/reference-guide
>     API Documentation: http://dojotoolkit.org/api
> 
>     Dojo-interest at mail.dojotoolkit.org
>     <mailto:Dojo-interest at mail.dojotoolkit.org>
>     To unsubscribe, visit:
>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
> 
> 
> 
> 
> ________________________________________________________
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> 
> Dojo-interest at mail.dojotoolkit.org
> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
> 

-- 
Eugene Lazutkin
http://lazutkin.com/



More information about the Dojo-interest mailing list