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);
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
further
On Thu, May 23, 2013 at 3:29 AM, Baz b...@thinkloop.com 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
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
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 that depends on fs, for example, and since fs
doesn't return or use
On May 23, 2013, at 1:28 PM, Baz b...@thinkloop.com 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
Thank you gents, perfectly got it now.
On Thu, May 23, 2013 at 10:42 AM, // ravi ravi-li...@g8o.net wrote:
On May 23, 2013, at 1:28 PM, Baz b...@thinkloop.com 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
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
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
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
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
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 I
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 your
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 delvarwo...@gmail.com 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
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 delvarwo...@gmail.com wrote:
One of them problems
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:
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 delvarwo...@gmail.com wrote:
In JavaScript the order you define things doesn't matter.
It does if
P.S. Coffeescript only supports that way of defining a function.
On Mon, Nov 12, 2012 at 3:51 PM, Mark Hahn m...@hahnca.com 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
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
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 {
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 -
On Sun, Jul 1, 2012 at 3:08 PM, Ken Whitesell kenwhites...@comcast.netwrote:
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
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
25 matches
Mail list logo
