

Pseudosynchronous JavaScript - bglusman
https://codewords.recurse.com/issues/three/pseudosynchronous-javascript

======
inglor
The promise usage here is so terrible it's not even funny. I've made a gist of
how it'd look like with correct usage. Just contrast the single level of
nesting (for the branching) in the correct version vs. the 5 nesting levels
version in the incorrect version used in the article
[https://gist.github.com/benjamingr/d08cfe94d3f0db1f954d](https://gist.github.com/benjamingr/d08cfe94d3f0db1f954d)

Not to take away from the original thought in the post - but it's hard to take
a criticism on a model seriously where the OP doesn't understand the model.
Here's a related StackOverflow question on the topic
stackoverflow.com/questions/22539815/arent-promises-just-callbacks

~~~
madeofpalk
It appears you've changed the API though? Just chain the promises instead of
nesting them
[https://gist.github.com/joshhunt/e3761594d10bb7025bcb](https://gist.github.com/joshhunt/e3761594d10bb7025bcb)

~~~
inglor
Chaining them is also perfectly viable (still one nesting level), as long as
you're not dipicting a non-existing problem ("callback hell") it's all good. I
used .call since OP used Q promises in the article - this works about as well
with other libraries.

------
skrebbel
I like the idea, it's a bit like how lazy list processing works, but then
applied to promises.

However, I don't completely see the appeal as soon as ES6 or ES7 transforms
with a tool like Babel are ok for you. ES7 is probably going to have C#-like
async/await syntax[0], which takes this problem away entirely and in a much
less complicated matter. This syntax works great today with babeljs. And even
if you don't dare using experimental ES7 features yet, you can accomplish just
about exactly the same with ES6 generators[1].

If you really really need to avoid compiling your code, then I can see the
appeal of this "pseudosynchronous" idea, but I do feel that it's much more
complex and error prone than setting up a build process instead.

[0] [https://github.com/lukehoban/ecmascript-
asyncawait](https://github.com/lukehoban/ecmascript-asyncawait) [1]
[http://davidwalsh.name/async-generators](http://davidwalsh.name/async-
generators)

------
xg15
I think debugabillity of this would be a huge problem. It's enough of a hassle
to single-step through "traditional" asynchronous code. Using the proposed
pseudo-synchronous interfaces, the only thing your own code basically does is
to specify what should be executed, but not actually executing anything by
itself.

At the time things are actually executed, you're almost 100% in library code,
making stepping through your program extremely hard.

I'm surprised the article doesn't mention spawn functions or the async/await
proposal for ES7[1], which seem to solve the same problem in a way that could
be both more efficient and more debug friendly.

[1] [http://jakearchibald.com/2014/es7-async-
functions/](http://jakearchibald.com/2014/es7-async-functions/)

------
impostervt
I worked in a similar vein with Horseman:

[http://horsemanjs.org/](http://horsemanjs.org/)

The library runs PhantomJS. While there are many libraries that do this, I
wanted a synchronous, chainable API. So I could do

var links = horseman.count('a'); if (count > 3) {
horseman.open('[http://www.google.com'](http://www.google.com')) } else {
horseman.open('[http://www.yahoo.com'](http://www.yahoo.com')) }

Under the hood, using the library literally blocks. Which is a very, very un-
javascript/Node thing to do, and introduces other weirdness, I know.

------
staltz
With RxJS, you can compose with existing Promise-based libraries, solve
asynchronous programming (and error handling) in an elegant fashion with code
that looks like simple linear chains (or DAGs) of Observables, and you don't
need to give up non-blocking JS.
[https://www.youtube.com/watch?v=XRYN2xt11Ek](https://www.youtube.com/watch?v=XRYN2xt11Ek)

~~~
findjashua
eventstreams are handy for handling a stream of events (user actions in UI,
streaming API client), but when a request gets a single event as a response
(ajax/http), async/await looks like a much simpler option (functions return
the output, instead of taking a handler to process it). Thoughts?

PS: enjoyed your talk 'user is a function', looking forward to how cycle
evolves.

~~~
staltz
What is an event? Put differently: what cannot be an event in your
application?

~~~
findjashua
While events can be used anywhere in your applications, they're not the best
option in my opinion. I still think functions should take an input and
'return' the output, not take a handler function to process it.

------
thesorrow
Generators and channels using js-csp is much more readable in my opinion.

