Pseudosynchronous JavaScript
codewords.recurse.com
Pseudosynchronous JavaScript
1–10 of 28 posts
Re: Pseudosynchronous JavaScript
#2I 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
Re: Pseudosynchronous JavaScript
#3I 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.
Re: Pseudosynchronous JavaScript
#4The 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 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
Re: Pseudosynchronous JavaScript
#5The 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 - but I beg people who attack these issues to read existing material :)
Re: Pseudosynchronous JavaScript
#6The 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?!
Re: Pseudosynchronous JavaScript
#7The 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
Re: Pseudosynchronous JavaScript
#8The 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…
> 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).
Re: Pseudosynchronous JavaScript
#9The 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');
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.
Re: Pseudosynchronous JavaScript
#10I worked in a similar vein with Horseman:
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.