
Bye Bye JavaScript Promises - tosh
http://sriku.org/blog/2014/02/11/bye-bye-js-promises/
======
jerf
And thus does the javascript ontogeny finally finish recapitulating phylogeny,
and we arrive at the inevitable end point: The Erlang/Go way is the best way
to do this stuff after all.

If you still end up using Javascript at the end of the process, hey, great, go
nuts, but after years of swaggering optimism in the JS community about how
somehow their stuff was so much better than anybody else's despite "event-
based code" being _extraordinarily_ well-trodden ground since the 1990s (as in
being the _default programming model_ for all serious code and entire major
dominant operating systems), it might be worth people taking a moment to
consider whether some more listening at the beginning of the process might
have cut some years off this journey of discovery. The Javascript community
has not been leading the charge of writing asynchronous code... _they just
caught up_.

~~~
Touche
Wow, what a mean-spirited comment. You should seriously think about why you
hate a community as bad as you obviously do.

~~~
slowmovintarget
That was not a mean-spirited comment, especially if you imagine someone with a
bit more experience seeing the same thing recur needlessly. Grouchy with a
touch of get-off-my-lawn, yes. Mean-spirited, no.

Over-exuberance sometimes requires admonishment, especially when there is such
a colossal waste of energy and effort like in the JavaScript "community" (OP's
word, but still...). If JavaScript programmers spent more time listening and
reading and less time posting "so I wrote my own" blogs we might have had
things like Reactive libraries for JavaScript years ago.

Throwing a word like "hate" around tells me you're likely too young to really
understand what that means.

Also, you picked on his tone and let the Go comment slide? Really?

In short, get seasoned, dude.

~~~
gagege
Thank you, thank you, thank you.

Even I, (young, unseasoned) know that criticism, admonishment and even a
little "I told you so" do not equal hate.

Ugh, that word.

------
vkjv
Bluebird also solves 2 and 4:

2\. Promise.prototype.bind 4\. You can put try / catch / finally anywhere. It
doesn't have to be in the end, but it does have to be close to what you want
to wrap (just like any other try / catch).

Coming form a large node project where I have been spending the better part of
my waking hours for several weeks closing memory leaks caused by holding onto
closures indefinitely, I would advise against the sort of meta programming
advised in this article.

------
peterhunt
Promises + ES6 generators (Promise.coroutine() in bluebird) solve all of these
problems.

~~~
jc123
Will promises still be needed with generators?

~~~
cwmma
yes generators can help you control the flow as you do async programing, but
you can't use generators to do something like an ajax function which gives you
an async value, you'd need promises or something for that, generators allow
you do use those async function is a more natural way.

~~~
inglor
Promises _are_ an async value. By yielding promises you're doing exactly that
:)

------
api
JavaScript and C++ have a similar problem. There are so many ways to do so
many things, that the result is endless stylistic fragmentation and tons of
library bloat. C++ is getting better as C++11 introduces standard ways to do
things like lambdas, tuples, etc., but JavaScript is obviously still in its
experimentation phase.

------
inglor
IT's very easy to criticise a technology when you're not using it correctly.
Please consider reading the Bluebird usage examples, what you're doing is
_definitely_ not the recommended usage.

You can achieve what you're doing without any macros, with better throw
safety, better debugging traces and more.

------
AgentME
It seems like there's two ideas here: new error handling syntax, and new
asynchronous task handling syntax. About asynchronous tasks: I think many
people here might be interested in taskjs which combines Promises and ES6
generators ([http://taskjs.org/](http://taskjs.org/)) and the similar ES7
async function proposal
([http://wiki.ecmascript.org/doku.php?id=strawman:async_functi...](http://wiki.ecmascript.org/doku.php?id=strawman:async_functions)).
You can use await on a function that returns a promise and write code just
like the code in this article (besides the error handling stuff). In basic
sequential code, you never have to call .then() on a promise, but you're still
able to dive down and do that if you have some non-linear asynchronous code
that requires it.

------
johnhenry
While reading this article, I remembered this:
[https://github.com/jlongster/js-csp](https://github.com/jlongster/js-csp),
which explicitly relies on es6 generators. I wonder if anyone can help us out
by comparing and contrasting this to the subject of the article
([https://github.com/srikumarks/cspjs](https://github.com/srikumarks/cspjs)).

------
aikah
tldr; macros

Yes but No.I personally think macros are the "root of all evil". Because they
just make languages unreadable. That's one thing to have a complete different
language that compiles down to JS,but as soon as you introduce macros is your
code you make it harder to understand and document.I'm glad it works for
you,but in my opinion the use of macros should be banned.While limited to
nodejs, I personally think fibers are better alternative.

4\. I actually think that it makes promises elegant. You can chain 20 then and
have a single catch in case things are wrong,but you need to adjust the logic
accordingly.Using different Error "classes" and checking the type is usually
what I do.

I still believe promises are an elegant way to deal with async programming,and
ES6 lambdas will make them even less painfull.

I'm not sold on generators for async programming strangely ,for multiple
reasons(lack of support in browser land,especially on mobile).

EDIT: macros are fine in LISP likes because it's not like these languages have
a complex syntax. And in C,well you cant program without them. My point is
javascript has enough features to make macros unnecessary.

~~~
davexunit
I don't think you understand the ability for macros to make code _more_
readable.

"However, as we confront increasingly complex problems, we will find that
Lisp, or indeed any fixed programming language, is not sufficient for our
needs. We must constantly turn to new languages in order to express our ideas
more effectively. Establishing new languages is a powerful strategy for
controlling complexity in engineering design; we can often enhance our ability
to deal with a complex problem by adopting a new language that enables us to
describe (and hence to think about) the problem in a different way, using
primitives, means of combination, and means of abstraction that are
particularly well suited to the problem at hand."

[https://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-25.htm...](https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html)

~~~
aikah
see the edit.I still think they are unecessary in javascript.

------
doty
It's interesting to me that people seem to be trying to bridge Promises with
CSP. Why aren't more people investigating the more straightforward async/await
transformation that the C# compiler does? CSP just seems like one
transformation too far.

~~~
Arnavion
async/await is trivial to mimic with yield - run the outer-most generator in
spawn, use yield* with "async" methods, and use yield with Promise-returning
methods. Projects like Regenerator already know how to convert yield to
straightforward JS. So you already have the transformation the C# compiler
does.

------
x86_64Ubuntu
I'm sure the JS world will just cook up 3 or 4 libraries to bolt on the
desired functionality...

~~~
moe
...each of which will have distinct bugs, leaks and gotchas. All of which will
be incompatible and conflicting with one another.

------
kin
A bit off topic but in the context of promises and Angular, I love the ability
to set a set a promise for the timeout parameter. This is super valuable
'cause it lets me manually cancel any request instead of waiting for a
response or timing out via time.

~~~
aikah
> I love the ability to set a set a promise for the timeout parameter.

please explain .

~~~
bengarvey
You can pass a promise into an $http request as a parameter. If you hold on to
this promise and resolve it before the request returns, it cancels the
request.

[https://docs.angularjs.org/api/ng/service/$http](https://docs.angularjs.org/api/ng/service/$http)

------
SerpentJoe
There seem to be two major ideas going on here: CSP, and modifications to
try/catch syntax. It would be easier to understand the former without the
latter.

------
double051
The 'code' blocks on this page are all using variable-width fonts, making it
quite difficult to read the examples.

Consider changing the 'font-family' to 'monospace'?

