Bluebird shock, part 2

20 views
Skip to first unread message

David Spector

unread,
Aug 25, 2019, 7:22:36 AM8/25/19
to bluebird
(URLs cause posting failure here, so this is Part 2, without the URL:)

In today's terms, moving from one line with an async operation to the next in this example means leaving one function and starting another. But this internal detail is hidden. This is elegant.

So, it was with some interest that I looked through some of the promising Bluebird documentation.

I found it almost impossible to understand.

For example, The Explicit Construction Anti-Pattern seems to be an important warning. But I can't understand it. I can't even see which variables are Promises. I would never write code like this, because it can't be understood by a casual reader.

The "simple" version of this anti-pattern looks almost as obscure to me and, surprisingly, is only 14% shorter. Surprising, for such an important "anti-pattern".

As an example of the obscurity in the "simple" version, there are four nested return statements. What could this possibly mean? I'm used to one return at a time in my own simple-minded code. Can a programmer really learn to think upside-down and inside-out? I hope not; I can't and won't do it: I want my programming to be easy to understand, both for my sake and for others.

While I can and do understand how to use the current native Promise class, and can appreciate the (rare) need to stop processing when one of a set of async operations completes, or when they all complete, the many operations listed in the Bluebird API seem like overkill. And, worst of all, you can still see clearly the
promise.then(func1).then(func2).catch(err)
construct, which requires using callbacks, either in-line anonymous functions (ugh, so many nested parentheses, brackets, and lines) or out-of-line named functions (ugh, so many names, function syntax, and extra lines).

The latest async JavaScript syntax merely makes callback functions use fewer characters. The callback functions are still there, almost visible.

I'm hoping for a new and better language for the age of the browser. One language instead of four (HTML/CSS/JavaScript/Serverside), and one language that includes what is needed for web-based apps, whether local or using a server, with full security and overriding security (when appropriate), both easy to do.

Reply all
Reply to author
Forward
0 new messages