Pseudosynchronous JavaScript(codewords.recurse.com)
codewords.recurse.com
Pseudosynchronous JavaScript
https://codewords.recurse.com/issues/three/pseudosynchronous-javascript
27 comments
I'm a little unclear on this stuff:
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 like you're making some unusual assumptions about its API – unless I'm totally missing something.
connection.call('collection', 'users');
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 like you're making some unusual assumptions about its API – unless I'm totally missing something.
`.call` is a method in some Promise libraries (eg. Bluebird). Basically,
connection.call('collection', 'users')
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.
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';
});Both parts are incorrect, the native way is `Promise.resolve('done')`. As for .call - native promises let you subclass them. If you have a promise enabled environment you can use generators anyway. I used Q's syntax because that's what OP used.
Regardless - nice comment.
Regardless - nice comment.
It appears you've changed the API though? Just chain the promises instead of nesting them https://gist.github.com/joshhunt/e3761594d10bb7025bcb
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.
That's how I'd do it.
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.
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 - but I beg people who attack these issues to read existing material :)
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 - but I beg people who attack these issues to read existing material :)
> 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
FYI, not everyone who attends the Recurse Center is a new programmer. In this particular case, Michelle (the author) has a decade and a half of experience developing in Javascript and writing Javascript frameworks (ie, writing the frameworks themselves).
FYI, not everyone who attends the Recurse Center is a new programmer. In this particular case, Michelle (the author) has a decade and a half of experience developing in Javascript and writing Javascript frameworks (ie, writing the frameworks themselves).
Thanks for clarifying, I did not know that - I'll make sure I check this sort of stuff in the future.
[deleted]
> 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/
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/
> 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.
You do the promise-as-a-pyramid example, then say you still have to nest and leave it at that, misrepresentation if not malice. Basically, you have a solution through promises you're not showing either because you were unaware or because you chose to, I _hope_ it's the former.
> not an example of how to use promises in production code.
I have some 3 year old production code that begs to differ :)
> 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.
Promises are not a framework, and your proxy queues don't make sense for someone who understand promises. If you go look at Mark Miller's original work on promises you'll see that promises are proxies for asynchronous actions - that's why they were created in the first place. It's also a great read regardless.
> You seem to have the generic concept of a promise confused with a particular promises implementation with some extensions that you particularly like.
I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer.
> The Promises/A[0] specification
Promises/A is an old specification about _interoperability_ that no one (its authors included) care about anymore.
> Even the Promises/A+[1] spec
Promises/A+ is a spec about interoperability between promise libraries. It only specifies `then` and even there only what it must.
> This isn't a criticism of the model, it's an explanation of the model and some suggested extensions.
Then I'm sorry but it's not a particular good one, really, I don't know who you are and I mean no offence but I think your article does a disservice to promises.
> I'm really curious as to how you managed to miss that point.
Your technique added an _extra layer_ on top of an _existing layer_ that already _solves the problem you're solving_. Promises were designed to be callback queues from the 80s by Barbara Liskov and Mark Miller. Reinventing the core concepts is insanely cool but it does a big disservice to the existing tooling.
> I think we can both agree that, to a developer not possessing your level of skill, the revised example is slightly easier to follow.
I think it conflates promises with values, we've offered this technique in Bluebird for years now as an example in https://github.com/petkaantonov/bluebird/blob/master/API.md (see under "Using defaultPromisifier parameter to add enhancements on top of normal node promisification:) without anything more than `.all`ing the arguments.
> 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?
I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land?
> The context might make it easier for you to understand the article itself, making your comments far more valuable.
I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that. I apologize for the tone in the original comment (I'll edit it if you'd like) it was uncalled for but I really think there is a lot to improve in the article.
You do the promise-as-a-pyramid example, then say you still have to nest and leave it at that, misrepresentation if not malice. Basically, you have a solution through promises you're not showing either because you were unaware or because you chose to, I _hope_ it's the former.
> not an example of how to use promises in production code.
I have some 3 year old production code that begs to differ :)
> 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.
Promises are not a framework, and your proxy queues don't make sense for someone who understand promises. If you go look at Mark Miller's original work on promises you'll see that promises are proxies for asynchronous actions - that's why they were created in the first place. It's also a great read regardless.
> You seem to have the generic concept of a promise confused with a particular promises implementation with some extensions that you particularly like.
I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer.
> The Promises/A[0] specification
Promises/A is an old specification about _interoperability_ that no one (its authors included) care about anymore.
> Even the Promises/A+[1] spec
Promises/A+ is a spec about interoperability between promise libraries. It only specifies `then` and even there only what it must.
> This isn't a criticism of the model, it's an explanation of the model and some suggested extensions.
Then I'm sorry but it's not a particular good one, really, I don't know who you are and I mean no offence but I think your article does a disservice to promises.
> I'm really curious as to how you managed to miss that point.
Your technique added an _extra layer_ on top of an _existing layer_ that already _solves the problem you're solving_. Promises were designed to be callback queues from the 80s by Barbara Liskov and Mark Miller. Reinventing the core concepts is insanely cool but it does a big disservice to the existing tooling.
> I think we can both agree that, to a developer not possessing your level of skill, the revised example is slightly easier to follow.
I think it conflates promises with values, we've offered this technique in Bluebird for years now as an example in https://github.com/petkaantonov/bluebird/blob/master/API.md (see under "Using defaultPromisifier parameter to add enhancements on top of normal node promisification:) without anything more than `.all`ing the arguments.
> 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?
I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land?
> The context might make it easier for you to understand the article itself, making your comments far more valuable.
I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that. I apologize for the tone in the original comment (I'll edit it if you'd like) it was uncalled for but I really think there is a lot to improve in the article.
> You do the promise-as-a-pyramid example, then say you still have to nest and leave it at that, misrepresentation if not malice. Basically, you have a solution through promises you're not showing either because you were unaware or because you chose to, I _hope_ it's the former.
Not all promises libraries support `call`. This isn't an article about the differences between particular promises libraries and the cooler features of some of the fancier ones. It's about returning proxy interfaces to seamlessly chain asynchronous operations.
If I were writing a critique of bluebird and left out `call`, then you would be right to accuse me of ignorance and/or malice.
> and your proxy queues don't make sense for someone who understand promises.
Proxy queues aren't for someone who understands promises.
The point of the proposed framework technique is to negate the need for the end user to understand promises, by simplifying the interface as much as possible. It's about making things more accessible for beginners and hobbyists.
> I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer.
No doubt, but it's not an article about bluebird. It's an article about creating frameworks which hide their complexity from the end user by using some interesting techniques.
> Your technique added an _extra layer_ on top of an _existing layer_ that already _solves the problem you're solving_. Promises were designed to be callback queues from the 80s by Barbara Liskov and Mark Miller. Reinventing the core concepts is insanely cool but it does a big disservice to the existing tooling.
I'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough.
My goal is is to prompt people to think creatively about their libraries and how their users interact with them. A lot of people use technology these days to enhance their main profession, and making the code more accessible to them is not a disservice.
> I think it conflates promises with values,
The point is to allow the user to use asynchronous responses as if they're normal values. Promises can be used as a powerful building block to this end, but not the end itself.
> I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land?
http://mootools.net/developers
Why not just be respectful of other developers, though? It's a creative profession, and not everyone will write their code in the exact same way that you would write your code.
> I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that.
I'm pretty sure you understand those things as well. Good for you.
Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles.
> I apologize for the tone in the original comment (I'll edit it if you'd like) it was uncalled for but I really think there is a lot to improve in the article.
I also agree there's a lot to be improved in the article, but it's a rather complex topic and I wanted to target the widest audience possible. However, an in-depth discussion of how developers who are intimately familiar with promises write their code when utilizing their own frameworks would not be one of my improvements, as it has nothing to do the topic I set out to tackle.
What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations?
If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself, or because you wouldn't need to use it yourself. This went through several rounds of technical review, and took quite a lot of work from many different people.
There's no community benefit to discouraging alternative viewpoints, and considering the article's title isn't How Ingor Writes JavaScript, I don't feel particularly bad for not explaining that particular nuance of the topic.
Not all promises libraries support `call`. This isn't an article about the differences between particular promises libraries and the cooler features of some of the fancier ones. It's about returning proxy interfaces to seamlessly chain asynchronous operations.
If I were writing a critique of bluebird and left out `call`, then you would be right to accuse me of ignorance and/or malice.
> and your proxy queues don't make sense for someone who understand promises.
Proxy queues aren't for someone who understands promises.
The point of the proposed framework technique is to negate the need for the end user to understand promises, by simplifying the interface as much as possible. It's about making things more accessible for beginners and hobbyists.
> I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer.
No doubt, but it's not an article about bluebird. It's an article about creating frameworks which hide their complexity from the end user by using some interesting techniques.
> Your technique added an _extra layer_ on top of an _existing layer_ that already _solves the problem you're solving_. Promises were designed to be callback queues from the 80s by Barbara Liskov and Mark Miller. Reinventing the core concepts is insanely cool but it does a big disservice to the existing tooling.
I'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough.
My goal is is to prompt people to think creatively about their libraries and how their users interact with them. A lot of people use technology these days to enhance their main profession, and making the code more accessible to them is not a disservice.
> I think it conflates promises with values,
The point is to allow the user to use asynchronous responses as if they're normal values. Promises can be used as a powerful building block to this end, but not the end itself.
> I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land?
http://mootools.net/developers
Why not just be respectful of other developers, though? It's a creative profession, and not everyone will write their code in the exact same way that you would write your code.
> I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that.
I'm pretty sure you understand those things as well. Good for you.
Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles.
> I apologize for the tone in the original comment (I'll edit it if you'd like) it was uncalled for but I really think there is a lot to improve in the article.
I also agree there's a lot to be improved in the article, but it's a rather complex topic and I wanted to target the widest audience possible. However, an in-depth discussion of how developers who are intimately familiar with promises write their code when utilizing their own frameworks would not be one of my improvements, as it has nothing to do the topic I set out to tackle.
What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations?
If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself, or because you wouldn't need to use it yourself. This went through several rounds of technical review, and took quite a lot of work from many different people.
There's no community benefit to discouraging alternative viewpoints, and considering the article's title isn't How Ingor Writes JavaScript, I don't feel particularly bad for not explaining that particular nuance of the topic.
> Not all promises libraries support `call`.
As I said twice before, the `call` bit is irrelevant, I used it because you used Q in the article. It would have worked with bluebird or When just as well - library is really not the big deal here. It's promises as they were designed.
> Proxy queues aren't for someone who understands promises.
You might want to mention that in the article. Or at least not represent them as a solution to a non-existing problem.
> I'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough.
Of course you're not, you can write incorrect statements about existing tooling all day long. However, do expect people to call you out on it when you misrepresent tooling, and do expect other people that agree to upvote those comments.
> Why not just be respectful of other developers, though?
Not once did I disrespect you, your code however in the promises example was very misrepresentative and frankly I stand by calling it terrible. It seems like that was intentional to show a point but it's still true.
> Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles.
Of course, we don't have to agree on everything! However I do get to post my opinion about your article when you publish it (as I did above).
> What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations?
My goal in the comment was to make sure people who reach your article through Hacker News realize that the way you use promises is not representative of how one would actually use promises in their code nor that the problem you're "solving" doesn't necessarily need that solution.
It would have been entirely possible to show that solution without misrepresenting solutions with promises or other concurrency mechanisms. Moreover, it would have been possible to implement in a much simpler wrapper function way (like the link to the API.md file in bluebird above).
> If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself....
Well, if you don't want criticism on things you publish - don't put them on the internet. I don't have an obligation to be particularly nice - especially when I have what I believe is valid criticism.
If you publish something and make it accessible to the public - be sure people are going to respond to it, especially if you make mistakes in the content. You asked why I don't write my own? The above comment is me writing a response to your article on the discussion about it so basically I'm already doing what you're suggesting :)
By the way, I still warmly recommend http://dl.acm.org/citation.cfm?id=54016 and http://www.erights.org/talks/thesis/markm-thesis.pdf the reason libraries like Q have these functions like `call` in the first place is exactly in order to use them as proxies :D
Anyway, I'm heading out - thanks for the discussion and happy coding :)
As I said twice before, the `call` bit is irrelevant, I used it because you used Q in the article. It would have worked with bluebird or When just as well - library is really not the big deal here. It's promises as they were designed.
> Proxy queues aren't for someone who understands promises.
You might want to mention that in the article. Or at least not represent them as a solution to a non-existing problem.
> I'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough.
Of course you're not, you can write incorrect statements about existing tooling all day long. However, do expect people to call you out on it when you misrepresent tooling, and do expect other people that agree to upvote those comments.
> Why not just be respectful of other developers, though?
Not once did I disrespect you, your code however in the promises example was very misrepresentative and frankly I stand by calling it terrible. It seems like that was intentional to show a point but it's still true.
> Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles.
Of course, we don't have to agree on everything! However I do get to post my opinion about your article when you publish it (as I did above).
> What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations?
My goal in the comment was to make sure people who reach your article through Hacker News realize that the way you use promises is not representative of how one would actually use promises in their code nor that the problem you're "solving" doesn't necessarily need that solution.
It would have been entirely possible to show that solution without misrepresenting solutions with promises or other concurrency mechanisms. Moreover, it would have been possible to implement in a much simpler wrapper function way (like the link to the API.md file in bluebird above).
> If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself....
Well, if you don't want criticism on things you publish - don't put them on the internet. I don't have an obligation to be particularly nice - especially when I have what I believe is valid criticism.
If you publish something and make it accessible to the public - be sure people are going to respond to it, especially if you make mistakes in the content. You asked why I don't write my own? The above comment is me writing a response to your article on the discussion about it so basically I'm already doing what you're suggesting :)
By the way, I still warmly recommend http://dl.acm.org/citation.cfm?id=54016 and http://www.erights.org/talks/thesis/markm-thesis.pdf the reason libraries like Q have these functions like `call` in the first place is exactly in order to use them as proxies :D
Anyway, I'm heading out - thanks for the discussion and happy coding :)
[deleted]
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 [1] http://davidwalsh.name/async-generators
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 [1] http://davidwalsh.name/async-generators
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/
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/
I worked in a similar vein with Horseman:
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') } else { horseman.open('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.
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') } else { horseman.open('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.
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.
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?
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.
Generators and channels using js-csp is much more readable in my opinion.
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