There are many kinds of application domains. One is a system programming.
Node's core and the majority of npm modules belong to such domain. In
system programming whether function performing IO, blocking or not is
important matter. Assuming that any kind of faux blocking enabled let's
consider the following line:
mkdirp('path/to/something')
What does it mean? It's sync? It uses faux blocking? If it's so, why it
doesn't allow me to run it in parallel?
I guess for the reasons above Tim Caswell wrote:
> Node “promises” had a method called “wait” that would just suspend the
> current stack and return the value after the promise was resolved. This was
> dangerous because libraries were using this technique and it meant that
> *any* function call could potentially cause your code to get suspended and
> have things change out from under you.
Please correct me if I get it wrong.
System programming is about solving small concrete tasks with non-changing
requirements and known in advance data flow. May be it's about something
else, but practice shows that it's always possible to organize system code
so that it wouldn't be a hell while sticking with only callbacks, event
emitters and pipes. I personally agree with the following and came to the
same value:
> Also, despite being the author of half a dozen control flow libraries, I
> never use any of them anymore. I don't like the extra dependency on my
> library or app, and most importantly, I don't like all the inserted frames
> in my stack traces.
>
Everything above was about system programming. There are other application
domains. Saying business apps. Lets consider the following:
calculate_taxes(item)
It doesn't have IO? It has and blocks? It has but doesn't block? The answer
is - who cares? To day it does IO, yesterday it didn't, tomorrow it will
become sync again. The only right way to program in such conditions is to
hide IO completely. Consider the case when all you code consist's just
from functions like calculate_taxes. Is it possible to stick with pure js?
No!
So "How to avoid callback hell?" The answer is - you should learn to
program. Sometimes it's better to refactor your code while sticking with
pure js, sometimes you should pull extra dependency like fibers. There is
no definite answer and everyone can make a mistake.
PS: I just recently heard about node's past ability to froze stack with
promise.wait(). It's sad that this ability was removed just because some
guys used it wrong. It's useful and needed feature for right hands.
On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote:
>
> I posted a follow-up on my blog:
> http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/
>
> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote:
>>
>> I'm trying to write a simple app that preforms a db query when a user
>> connects to a tcp port.
>>
>> I can get the query working if I do everything as callbacks:
>>
>> db.open(... fn() {
>> db.collection(.... fn() {
>> db.query(...... fn() {
>> });
>> });
>> });
>>
>> But as you can see this creates callback hell.
>>
>> What I would like to do is have a class, but being as everything is
>> async it makes it incredibly difficult to ensure all your variables are
>> set.
>>
>> var client;
>> db.connect(connect, fn(){
>> client = connect;
>> });
>> client.close();
>>
>> Will cause an error because client hasn't been set yet. Another thing I
>> thought of doing was chaining it all together:
>>
>> db.connect(connect, fn(){
>> ...
>> process.nextTick(fn(){ doNext(); });
>> });
>>
>> this gets very messy and hard to manage, how can I deal with callback
>> hell?
>>
>>
>>
On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote:
>
> I posted a follow-up on my blog:
> http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/
>
> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote:
>>
>> I'm trying to write a simple app that preforms a db query when a user
>> connects to a tcp port.
>>
>> I can get the query working if I do everything as callbacks:
>>
>> db.open(... fn() {
>> db.collection(.... fn() {
>> db.query(...... fn() {
>> });
>> });
>> });
>>
>> But as you can see this creates callback hell.
>>
>> What I would like to do is have a class, but being as everything is
>> async it makes it incredibly difficult to ensure all your variables are
>> set.
>>
>> var client;
>> db.connect(connect, fn(){
>> client = connect;
>> });
>> client.close();
>>
>> Will cause an error because client hasn't been set yet. Another thing I
>> thought of doing was chaining it all together:
>>
>> db.connect(connect, fn(){
>> ...
>> process.nextTick(fn(){ doNext(); });
>> });
>>
>> this gets very messy and hard to manage, how can I deal with callback
>> hell?
>>
>>
>>
On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote:
>
> I posted a follow-up on my blog:
> http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/
>
> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote:
>>
>> I'm trying to write a simple app that preforms a db query when a user
>> connects to a tcp port.
>>
>> I can get the query working if I do everything as callbacks:
>>
>> db.open(... fn() {
>> db.collection(.... fn() {
>> db.query(...... fn() {
>> });
>> });
>> });
>>
>> But as you can see this creates callback hell.
>>
>> What I would like to do is have a class, but being as everything is
>> async it makes it incredibly difficult to ensure all your variables are
>> set.
>>
>> var client;
>> db.connect(connect, fn(){
>> client = connect;
>> });
>> client.close();
>>
>> Will cause an error because client hasn't been set yet. Another thing I
>> thought of doing was chaining it all together:
>>
>> db.connect(connect, fn(){
>> ...
>> process.nextTick(fn(){ doNext(); });
>> });
>>
>> this gets very messy and hard to manage, how can I deal with callback
>> hell?
>>
>>
>>
On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote:
>
> I posted a follow-up on my blog:
> http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/
>
> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote:
>>
>> I'm trying to write a simple app that preforms a db query when a user
>> connects to a tcp port.
>>
>> I can get the query working if I do everything as callbacks:
>>
>> db.open(... fn() {
>> db.collection(.... fn() {
>> db.query(...... fn() {
>> });
>> });
>> });
>>
>> But as you can see this creates callback hell.
>>
>> What I would like to do is have a class, but being as everything is
>> async it makes it incredibly difficult to ensure all your variables are
>> set.
>>
>> var client;
>> db.connect(connect, fn(){
>> client = connect;
>> });
>> client.close();
>>
>> Will cause an error because client hasn't been set yet. Another thing I
>> thought of doing was chaining it all together:
>>
>> db.connect(connect, fn(){
>> ...
>> process.nextTick(fn(){ doNext(); });
>> });
>>
>> this gets very messy and hard to manage, how can I deal with callback
>> hell?
>>
>>
>>
On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote:
>
> I posted a follow-up on my blog:
> http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/
>
> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote:
>>
>> I'm trying to write a simple app that preforms a db query when a user
>> connects to a tcp port.
>>
>> I can get the query working if I do everything as callbacks:
>>
>> db.open(... fn() {
>> db.collection(.... fn() {
>> db.query(...... fn() {
>> });
>> });
>> });
>>
>> But as you can see this creates callback hell.
>>
>> What I would like to do is have a class, but being as everything is
>> async it makes it incredibly difficult to ensure all your variables are
>> set.
>>
>> var client;
>> db.connect(connect, fn(){
>> client = connect;
>> });
>> client.close();
>>
>> Will cause an error because client hasn't been set yet. Another thing I
>> thought of doing was chaining it all together:
>>
>> db.connect(connect, fn(){
>> ...
>> process.nextTick(fn(){ doNext(); });
>> });
>>
>> this gets very messy and hard to manage, how can I deal with callback
>> hell?
>>
>>
>>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
