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
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
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.
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.
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
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
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
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 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
> 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
>
> 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
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
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,
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.
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
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 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 -
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
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 {
>
> 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
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
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
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
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
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
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);
>
26 matches
Mail list logo