Le jeudi 23 mai 2013 19:32:25 UTC+2, Domenic Denicola a écrit :
> That's overstating it a bit. It's very easy to convert to promise-based
> code, e.g.:
>
> var fs = require('fs');
> var Q = require('q');
>
> var readFile = Q.denodeify(fs.readFile);
> var writeFile = Q.denodeify(fs.writeFile);
>
Thank you gents, perfectly got it now.
On Thu, May 23, 2013 at 10:42 AM, // ravi wrote:
> On May 23, 2013, at 1:28 PM, Baz wrote:
> > Thanks Matt, so just to be crystal clear, if I'm using promises in my
> own code, then I happen to have a flow that depends on fs, for example, and
> since fs d
On May 23, 2013, at 1:28 PM, Baz wrote:
> Thanks Matt, so just to be crystal clear, if I'm using promises in my own
> code, then I happen to have a flow that depends on fs, for example, and since
> fs doesn't return or use promises, I would have to drop out of the promises
> paradigm and manage
f of Baz
[b...@thinkloop.com]
Sent: Thursday, May 23, 2013 13:28
To: nodejs@googlegroups.com
Subject: Re: [nodejs] Re: trying to wrap my head around "promises" - async vs Q
Thanks Matt, so just to be crystal clear, if I'm using promises in my own code,
then I happen to have a flow
Thanks Matt, so just to be crystal clear, if I'm using promises in my own
code, then I happen to have a flow that depends on fs, for example, and
since fs doesn't return or use promises, I would have to drop out of the
promises paradigm and manage that particular part of the flow control with
callb
On Thu, May 23, 2013 at 3:29 AM, Baz wrote:
> I am new to Node and trying to decide between promises, asynch and
> vanilla, there are so many good arguments for each. Mikeal, do you mind
> expanding further how using promises in your own, non-shared, code could
> hinder use of node? Do a lot of t
>
> Using callbacks in your own application code is the path of least
> resistance for using the majority of value in the node ecosystem.
I am new to Node and trying to decide between promises, asynch and vanilla,
there are so many good arguments for each. Mikeal, do you mind expanding
furth
it's not backwards. first function is on top, last at the bottom,
functions, which may appear multiple times in the callback chain are at the
top most position by convention. i use the function declaration statement
for this, because they get hoisted and the definition order is irrelevant
then.
P.S. Coffeescript only supports that way of defining a function.
On Mon, Nov 12, 2012 at 3:51 PM, Mark Hahn wrote:
> Read the message before this. I explained how it works in a forward way
> with your preferred method of function definition. That is what I always
> use.
>
>
> On Mon, Nov 12,
Read the message before this. I explained how it works in a forward way
with your preferred method of function definition. That is what I always
use.
On Mon, Nov 12, 2012 at 3:46 PM, Andy wrote:
>
>
>>
>> In JavaScript the order you define things doesn't matter.
>>
>
> It does if your function
>
> In JavaScript the order you define things doesn't matter.
>
It does if your function declaration style is var funcName = function() {
}; which is the style I use. Personal preference obviously.
>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node
> because you have to define named callback functions first.
No you don't. I always name then in order ...
func1 = -> do something; func2()
func2 = -> do something; func3()
func3 = -> do something
func1()
On Mon, Nov 12, 2012 at 2:48 PM, Andy wrote:
> One of them problems even with this a
On Mon, Nov 12, 2012 at 5:48 PM, Andy wrote:
> One of them problems even with this approach is that you write and read
> code backwards. It executes bottom to top because you have to define named
> callback functions first. I find it much more natural with promises because
> not only is your code
reasons as the first
parameter (i.e. as an error).
This allows you to create libraries that expose both promise-returning and
callback-accepting APIs at the same time.
From: Andy
Sent: November 12, 2012 17:52
To: nodejs@googlegroups.com
Subject: Re: [nodejs] Re: trying to wrap my head around
On Sunday, November 11, 2012 10:46:05 PM UTC-8, Mikeal Rogers wrote:
>
>
> Some people clearly like promises, but the dominant pattern in node is not
> promises, it's callbacks, with complex callback issues managed with async.
>
> Stating your opinion strongly does not make it a fact. This is you
One of them problems even with this approach is that you write and read
code backwards. It executes bottom to top because you have to define named
callback functions first. I find it much more natural with promises because
not only is your code organized, but it reads top to bottom and is MUCH
> If I would choose which tool is best for my project just by popularity factor
> I wouldn't go far.
I have a way to solve this issue that emulates pattern matching in javascript
`github/dscape/p` while maintaing valid JS semantics.
Its so unpopular even I dont use it :) (but it works
This isn't Node specific, but it's a really thorough article a professor
pointed me to with JavaScript
examples: https://raw.github.com/kriskowal/q/master/design/README.js
On Sunday, March 25, 2012 4:42:32 AM UTC-4, Andy wrote:
>
> *Note, I am not asking which tool is better, I am simply trying
Choose either, I do things in callback style personally to match the
ecosystem when I write libraries, thats the expectation of the ecosystem.
For application logic, do whatever makes it faster. There are exactly 0
absolute wins on either side. I can go on at length about the reason both
have p
If I would choose which tool is best for my project just by popularity
factor I wouldn't go far.
It's understood that Async is more popular as it doesn't introduce much
learning factor and most developers are looking for quick solutions. To get
promises you need to devote a while understand it.
my approach to handle callback sallad? use the language features. just
wrote down a script that would have a 7-10 callbacks nested. The problem
with the callbacks is not the callback approach. it's simple and beautiful.
the problem is naive and blind utilization of the closure scope. Just an
ex
It's great that you have a strong opinion. Here's some numbers:
Here's the number of modules that depend on async and Q.
async: 975
Q: 109
Here are the numbers of downloads in the last month.
async: 120,271
Q: 33,242
Some people clearly like promises, but the dominant pattern in node is not
To reply to my own very old thread after getting some solid experiences
with promises, the answers to my questions are:
1. *async* is a library that passes callbacks around. it's ugly and it
sucks.
2. a* promise *is just an object. Don't let anyone tell you differently,
they are just trying to
Hi José
Transforming *every* construct of Javascript is exactly what streamline.js
does. Here is a typical piece of code:
function mongoSearch(_, q) {
var t0 = new Date();
var db = new mongodb.Db('tutorial', new mongodb.Server("127.0.0.1", 27017,
{}));
db.open(_);
try {
I saw your slides and I cant agree more with you. The other day I did some
thinking about all the javascript code I have been writing and I came to
this conclussio (bear with me, please):
- for me the problem with CPS (continuation passing style) for asynchronous
code is not the cascade of nested c
On Sun, Jul 01, 2012 at 04:04:12PM -0700, Alexey Petrushin wrote:
> There are some good use cases for control flow libraries, but, sadly,
> in most cases the end result is even worse than without it.
>
> It seems there's no good solution to this problem - code looks ugly no
> matter what You do -
The article
http://www.infoq.com/articles/surviving-asynchronous-programming-in-javascript
compares seven libraries (including asynch, but not q).
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this messa
Hi Dominic,
I looked at your slides. I think you should also take a look at
streamline.js.
An interesting benchmark of async solutions would be to take the little
tutorial that I just wrote
(https://github.com/Sage/streamlinejs/blob/master/tutorial/tutorial.md - or
any similar kind of app) a
Thanks Domenic, this is indeed an excellent presentation. I especially like
your emphasis on getting the exception propagation right. It's something I
should emphasize more as well.
On Sun, Jul 1, 2012 at 3:43 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I'd like to submit my pro
On Sun, Jul 1, 2012 at 3:08 PM, Ken Whitesell wrote:
> On Sunday, July 1, 2012 2:55:05 PM UTC-4, Mariusz Nowak wrote:
>>
>> n promises approach asynchronous state is represented with the object, so
>> instead of registering single callback, you get the object, which you can
>> pass to many differe
There are some good use cases for control flow libraries, but, sadly, in
most cases the end result is even worse than without it.
It seems there's no good solution to this problem - code looks ugly no
matter what You do - with or without control flow libraries.
So, I believe currently the "fuc
I'd like to submit my promises talk for consideration as well :). I agree
with Mariusz that once you get it you will never go back.
http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript
On Sunday, July 1, 2012 2:55:05 PM U
On Sunday, July 1, 2012 2:55:05 PM UTC-4, Mariusz Nowak wrote:
>
> n promises approach asynchronous state is represented with the object, so
> instead of registering single callback, you get the object, which you can
> pass to many different functions, or on which you can listen for value with
>
@Andy Async is just sugar for control flow written with plain callbacks and
promises address asynchronicity from very different angle.
In promises approach asynchronous state is represented with the object, so
instead of registering single callback, you get the object, which you can
pass to many
>
> Andy, did you ever find good answers to your questions? I have used
> async.js but currently have been motivated to use promises, but I'm having
> a hard time wrapping my head around the differences.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/
Andy,
They are related by the fact that both are trying to help remove some of
the pain of developing asynchronous code. They are different in the way
they go about implementing this.
Check out the articles on the How to Node blog that Tim Caswell runs, there
are some good examples with expla
36 matches
Mail list logo
