I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years:

"...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works..."

By LOC he's referencing 'ye ole Lines of Code paradigm, and trying to make the point that in the end it just doesn't measure up to the prime directive of "containing complexity".

... and that's where I beg to differ.

What I think is being completely overlooked here is the net cost of abstracting away all that complexity... It's performance.

Every extra line of code, extraneous function call, unnecessary abstraction ( I'm looking at you promise ), every lazy inclusion of an entire library for the use of a shortcut to document.getElementById -- these all add unnecessary costs from the network down to the cpu.

And who pays these costs?

The end users of your slow, memory hogging, less-than-ideal set of instructions to the cpu that you call an application... but hey, it's easier for you, so there's that.

> ye ole Lines of Code paradigm

Little-known fact: the *y in old signs is actually a 'þ', which is an Old English letter named 'thorn' and pronounced like modern 'th.' Thus, the old books & signs were really just saying, 'the.' Incidentally, þ is still used in modern Icelandic.

Completely off-topic, but I þought you might be interested.

holy shit, I had no idea. That's cool.

edit: and I double checked, because the internet :)

http://www.etymonline.com/index.php?term=ye

it's true! that's awesome.

I really þink ðat we ought to use þ and ð in modern English, but oddly enough no-one agrees wiþ me:-)

Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)

We had, and still prefer (looking at npm stats) the async module. Eg:

    promise.then(function(){}).then(function(){}) 

is not substantially different than:

    async.waterfall([function(){}, function(){}])

Promise advocates kept pretending async didn't exist though, and everybody was using callback hell.

There's a lot of old cruft using async (my current workplace being one of them) - bluebird also has 4x the downloads of async.

async is pretty terrible though, you cannot pass the results from one execution to another, i.e. passing results from one function in async.series to another, which results in developers tending to pollute variable scope by defining above and filling it in inside each callback. This prevents the ability to write clean isolated testable functions.

You can return the first from a function and it will be a promise. Promises are reusable. Also they contain exceptions in their context. Those can be handled at any point of the promise-chain.

So promises are way more composable than callback based solutions.

Nobody pretended that async didn't exist, we just knew its the best "solution" that ignored the problem.

Which was: throwing away the entire language's compositional features, including the concept of input arguments and return values, results with... poor compositionality, of course.

I thought the problem was callback hell. I've sat through a bunch of promise talks and the problem was never 'JS should be more compositional'.

Yes, uncompositionality of callbacks leads to callback hell. Or to reinventing every single thing but for callbacks. Like array.map (which works with promises) or array.forEach (also works with promises) or every single synchronous function (they all work when passed to promises).

If you solve callback hell for a series of sequential functions by using an actual series of sequential functions, you don't have nested callbacks and you didn't require Promises or composition - just a basic understanding of data structures and first class functions.

It seems you're defining callback hell as 'whatever promises solves' rather than it's common definition of over-nesting.

Callback hell is a "loss of composition" problem. Most languages, including JavaScript, have things called expressions. Expressions rely on functions returning their output. They become useless when functions give their output through a callback passed as their input: they don't compose with that frankenstein.

Node style callbacks are a prime example of how in the quest for "simplicity" and hate for abstractions its easy to build a monster / frankenstein like caolan's async. Node callbacks were a self-contradicting philosophy: it abandoned all thats already in the language in the quest to avoid an abstraction that was not already in the language :)

Hrm, it's always seemed natural (and not frankenstein) that a function would be input as much as a number or string is. 'My name is Steve, my age is 7, and here's what do to one the database has saved'.

That said I see how the inconsistency you're talking about with how expressions return values with callbacks and you've certainly put the point very well.

> Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though...

Rather than copy paste someone else's unmaintained thing and handle all the bugs, or write their own code and unit tests, they use the same library as a few thousand other people?

If you don't know how to write a function to left-pad a string without copy & pasting, you have other problems..

What makes you think people who don't write their own left pad function can't write a left pad function?