Pseudosynchronous JavaScript • Hacker News Board

Re: Pseudosynchronous JavaScript

#11

Post by [deleted] » Thu, Jun 25, 2015, 12:46 PM UTC

inglor wrote: post #5

inglor wrote: post #4

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 Not to take away from the original thought in the post - but it's hard to take a cr…

The reason this works is that promises are already representative of queues of pending values. To contrast, here's the ES7 version (works with babel) I added to the gist https://gist.github.com/benjamingr/d08cfe94d3f0db1f954d#file... It's awesome that it's a post by someone who just attended the recourse center and they're a new programmer and already struggling with these interesting issues and trying to solve them…

[deleted]

Re: Pseudosynchronous JavaScript

#12

Post by mAritz » Thu, Jun 25, 2015, 1:22 PM UTC

sirsuki wrote: post #6

inglor wrote: post #4

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 Not to take away from the original thought in the post - but it's hard to take a cr…

If only I could upvote this more than once. I'd upvote this to 100! That was my first take on the article. Why the hell would anyone write promises like that?!

It's rather common to see promises used as pseudo-callbacks actually. I think it has to do with the fact that just assigning something async (the promise) to a variable seems so counter-intuitive to someone who has programmed with callbacks for a while.

Re: Pseudosynchronous JavaScript

#13

Post by renekooi » Thu, Jun 25, 2015, 1:35 PM UTC

kevincennis wrote: post #9

inglor wrote: post #4

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 Not to take away from the original thought in the post - but it's hard to take a cr…

I'm a little unclear on this stuff: connection.call('collection', 'users'); Is `connection` a function? As in, you're essentially using Function#call and passing the string 'collection' as `thisArg`? Or is `call` a custom method of whatever `connection` is an instance of? I was under the impression from the article that `DatabaseClient` was just sort of an example, not a specific implementation of anything. It seems…

`.call` is a method in some Promise libraries (eg. Bluebird). Basically,

    connection.call('collection', 'users')

is a shorthand for:

    connection.then(value => value.collection('users'))

Re: Pseudosynchronous JavaScript

#14

Post by thesorrow » Thu, Jun 25, 2015, 2:19 PM UTC

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

Re: Pseudosynchronous JavaScript

#15

Post by csytan » Thu, Jun 25, 2015, 2:43 PM UTC

renekooi wrote: post #13

kevincennis wrote: post #9

Earlier quoted context omitted.

I'm a little unclear on this stuff: connection.call('collection', 'users'); Is `connection` a function? As in, you're essentially using Function#call and passing the string 'collection' as `thisArg`? Or is `call` a custom method of whatever `connection` is an instance of? I was under the impression from the article that `DatabaseClient` was just sort of an example, not a specific implementation of anything. It seems…

`.call` is a method in some Promise libraries (eg. Bluebird). Basically, connection.call('collection', 'users') is a shorthand for: connection.then(value => value.collection('users'))

Thanks for clarifying. This is a very neat way of removing what would be an extra level of nesting.

It doesn't look like native promises support this unfortunately: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Another nitpick I have with native promises is that they require an extra level of nesting to get the resolve callback.

    // How it is now
    new Promise(function(resolve, reject) {
        resolve('done');
    });


    // vs. What most libraries implement
    var p = new Promise();
    p.resolve(function() {
        return 'done';
    });

Re: Pseudosynchronous JavaScript

#16

Post by frank-weindel » Thu, Jun 25, 2015, 2:59 PM UTC

madeofpalk wrote: post #7

inglor wrote: post #4

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 Not to take away from the original thought in the post - but it's hard to take a cr…

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

That's how I'd do it.

Re: Pseudosynchronous JavaScript

#17

Post by msteigerwalt » Thu, Jun 25, 2015, 3:09 PM UTC

inglor wrote: post #4

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 Not to take away from the original thought in the post - but it's hard to take a cr…

> The promise usage here is so terrible it's not even funny.

Unnecessary hyperbole aside, I think you're confusing two conflicting goals. One is to provide code examples in order to explain a particular concept to an audience not already familiar with that concept, by building upon examples previously explained in the article. Another is to explain how to write production code using existing promises frameworks.

For the purposes of explanation, I used a similar code flow as the standard callback example previously described, except that I included the chaining of error handling with parallels to synchronous try/catch/finally flows.

The promises excerpt you've derided is an example of what promises bring to the table over straight callbacks for simplifying complex chains of asynchronous operations, not an example of how to use promises in production code.

Additionally, this is an article about framework design, not how to use them, making your corrections (which involve using a framework with chainable proxy queues) somewhat tangental to the discussion.

> var users = connection.call('collection', 'users');

You seem to have the generic concept of a promise confused with a particular promises implementation with some extensions that you particularly like.

Not all promises libraries support `call`, and many don't support the return of the expected proxy interface from another proxy interface, which is the very technique described in the article.

The Promises/A[0] specification barely touches upon the subject and specifies that call "returns a promise to provide the return value of the requested function call," not a chainable proxy to the expected return interface. Even the Promises/A+[1] spec seems to ignore the subject of `call` entirely.

> it's hard to take a criticism on a model seriously where the OP doesn't understand the model.

This isn't a criticism of the model, it's an explanation of the model and some suggested extensions.

Considering I clearly stated both in the intro and the conclusion, "This approach builds on promises and standard callbacks" and, "The great thing about this technique is that it can compose really well with existing promise frameworks," I'm really curious as to how you managed to miss that point.

To demonstrate, here's a simple diff of your "correct" example enhanced using my proposed technique:

https://gist.github.com/Yuffster/4ca84f31cfaef33c4138/revisi...

I think we can both agree that, to a developer not possessing your level of skill, the revised example is slightly easier to follow.

> It's awesome that it's a post by someone who just attended the recourse [sic] center and they're a new programmer and already struggling with these interesting issues and trying to solve them

Thank you very much for the encouraging words, but in the future, could you do everyone a favor and either read an author's biography or click on the author link before making wild assumptions about his or her programming background?

The context might make it easier for you to understand the article itself, making your comments far more valuable.

---

[0] http://wiki.commonjs.org/wiki/Promises/A

[1] https://promisesaplus.com/

Re: Pseudosynchronous JavaScript

#18

Post by staltz » Thu, Jun 25, 2015, 4:53 PM UTC

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

Re: Pseudosynchronous JavaScript

#19

Post by findjashua » Thu, Jun 25, 2015, 5:01 PM UTC

staltz wrote: post #18

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

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.

Re: Pseudosynchronous JavaScript

#20

Post by staltz » Thu, Jun 25, 2015, 5:38 PM UTC

findjashua wrote: post #19

staltz wrote: post #18

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

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.

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