Your argument could be applied to functional programming languages that to many feel 'unnatural', but to others feel like the one true way. Similarly RPN or 'normal' calculators. RPN feels natural to some, alien to others.
Your argument could be applied to functional programming languages that to many feel 'unnatural', but to others feel like the one true way. Similarly RPN or 'normal' calculators. RPN feels natural to some, alien to others.
Trust me, it's not his "personal opinion". The callback spaghetti mess is a real problem, there are several libs that provide not-perfect-but-ok solutions, and even hardcore Node folks acknowledge it. Basically, you cannot NOT acknowledge it, except if you haven't got any experience with a language with proper constructs to avoid this kind of thing.
Your argument could be applied to functional programming languages that to many feel 'unnatural', but to others feel like the one true way.
That's not much of a counter-argument, since those others that "feel like functional languages are the one true way" are few and far between, and those languages never caught on the mainstream ever in 50 years.
And when the new, better thing, came along (functional capabilities in a more friendly syntax, be it Scala or Ruby or whatever) people adopted it much better than all the functional languages with the "strange syntax" combined.
RPN feels natural to some, alien to others.
Same thing here. That's why RPN is not mainstream, because the guys that get it are few and far between.
And that's what he argues --a technology that feels unnatural to many will be replaced with a similar technology that has the same goals/benefits but feels more natural.
You are dead right that callback spaghetti is a problem, but instead of blaming the language/library you might want to reevaluate your implementation. There are a number of ways to deal with node callbacks. This is an excellent easy to follow article: http://seanhess.github.com/2012/02/20/functional_javascript....