Alternative to Promise

[韩冬]

Yes, i understand it’s too late to revise Promise design, my random thought are:

1. Why we put Promise into language? 

Promise are complex state machine, there can be so many variations, each implementation have different performance characteristic, which one should be built into language?

2. Why we don’t look for continuation based implementation at the first place?

Lisp, haskell or even some transpiled to js language like elm use continuation solve callbacks already, why didn’t port them?
Now we invent a complex state machine based solution, a lot of people will creating them everytime using an `async` without understand the cost.

~winter


> On Oct 1, 2015, at 1:46 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> 
> On Tue, Sep 29, 2015 at 10:51 PM, 韩冬 <handong05 at meituan.com> wrote:
>> ES6 Promise is great,  i just want to share my thoughts on dealing with
>> callback hell issue with a different approach here.
>> I’m been try to port ConT monad from haskell to javascript these days, after
>> some work, i believe we can have a much simpler alternative to Promise, read
>> this introduction to my approach please:
>> 
>> http://winterland1989.github.io/Action.js/
>> 
>> I’m not saying it’s better than Promise, but it’s much simpler and easier
>> IMO, any peer are welcomed!
> 
> Promises already exist and are implemented in most browsers already.
> They won't be replaced; anything which hopes to occupy a similar niche
> needs to justify how it is sufficiently useful to be worth having two
> similar-but-not-identical things in the standard library.  There's
> always going to be decisions that could have been made slightly
> differently, and which would make things more convenient for
> particular use-cases, but that doesn't, by itself, justify the cost of
> adding to the standard library.
> 
> Likely anything new will want to fit into the General Theory of
> Reactivity <https://github.com/kriskowal/gtor>.
> 
> ~TJ