Callback Hell (2016)
callbackhell.com
callbackhell.com
A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main feature of the NodeJS platform - is in no way exclusive to, or even an inherent part of, Javascript/ES the language.
This may seem a nitpick, but I think it's an incredibly important distinction for beginners (or at least, I think it's incredibly important not to mislead beginners into believing in this limitation early on).
Another common example was, up until recently, that Javascript "wasn't powerful enough" to do filesystem access, hardware operations, etc. A simple side-effect of the environment the language was most commonly executing in (the browser) was turned into an inherent limitation of the language in order to "simplify things for beginners".
While bombarding beginners with a lot of info at the start is a bad idea, these kind of misconceptions can be very damaging. They leads to a very narrow idea of what's possible with (any) languages in general, and uninformed decisions on what to learn as a result.
Exclusive no, but considering JS's original environment and constraints it is in fact pretty inherent. `setTimeout` is part of the core language and has been for a long time, a blocking `sleep` is not.
Whereas Ruby and Python are often used without a run loop.
Sure, but criticising a rant about the propogation of misconceptions by propogating a misconception seems like a self-undermining position :)
Like opening a socket, sending data, and blocking on the response.
You can find some of it, but it's the exception, not the rule.
Yes, you can build something specific, just as you can leverage async libraries in languages where it's not the common pattern.
And I personally think not knowing the distinction between the language and APIs provided to it is extremely limiting and misleading for someone approaching learning programming (it was for me, I wish this had been clearer to me earlier).
I'm not sure it is. What's available, without custom work on your own, drives the ecosystem.
I can build an asynchronous application with PHP, but there's not much established practice, existing tools, shared learning and so forth. And, whatever I build that way is limited to an audience that will go out of their way to build my custom php interpreter.
No, I think it's very important, maybe even more important for some of us old dogs still marvelling at having virtual SMP in a desktop rig. While it might be easier to teach people new to programming the old model of a series of instructions that goes step by step, I feel it's also important to express that statements may get run out of order, even in languages not designed for it (optimizing compilers have been doing this forever).
> While bombarding beginners with a lot of info at the start is a bad idea, these kind of misconceptions can be very damaging. They leads to a very narrow idea of what's possible with (any) languages in general, and uninformed decisions on what to learn as a result.
It's also dangerous to always assume that statement A will execute before B just because that's how they appear in the code. Getting people acquainted with the tools necessary to properly do "threading" early on would be a step in the right direction.
I was saying one shouldn't tell beginners that JS is inherently async and other languages are never async.
The fact of the matter is that JavaScript was born with first class functions and event handlers, from the very beginning. In the browser, the majority of projects of any substantial size involves using event handlers, AJAX requests and requestAnimationFrame/setTimeout, among other things.
Even on NodeJS, if you're serving something you're using async. If you're interacting with process events, you're using async. If you're reading files, you're using async. (even the sync functions for files wrap async ones) If you've downloaded anything from NPM, you're almost certainly using async. There is next to nothing that is pure synchronous.
Even if what you said is true, you are suggesting a misconception that could be damaging in the name of avoiding damaging misconceptions. Almost all real world usage of JavaScript uses async code & callbacks, and to split hairs over whether async is native to the language for the sake of beginners is to mislead them.
actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and completed. If you don't design for that, you WILL have race conditions.
Moving to nodejs 2 years ago, and something that I am still mindful of, is that you will NEVER have race conditions, as the entire user code will execute in a single thread, with interrupts only occurring between callbacks.
I like it because it's very easy to construct high performance professional apps in NodeJs (most devs are not multithreading experts) but sometimes I miss the idea of leveraging tons of cores. But that's why we scale horizontally (more 1 or 2 proc servers, less 32proc servers).
Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly:
0.0s - [1] Client 1: Apply coupon
0.0s - [2] Client 2: Apply coupon
0.1s - [1] Server to database: Is coupon marked as used?
0.1s - [2] Server to database: Is coupon marked as used?
0.2s - [1] Database to server: Nope! All good.
0.2s - [2] Database to server: Nope! All good.*
0.3s - [1] Server to database: Update coupon as used.
0.3s - [2] Server to database: Update coupon as used.*
* Coupon has been used twice :(
Node give you freedom from Thread Hell. You enjoy similar performance without locks, threads, synchronisation. Race conditions happen but mostly with cache invalidation where you can have limited consistency guarantees.
If can model your database differently for this rudimentary example, then good for you – you're thinking about race conditions. Many web programmers do not think about them at all, and race conditions are usually not trivial to fix.
How is that specific to only NodeJs?
in fact, an entirely synchronous, 1-user-at-a-time server wouldn't fix this, if there were two or more servers. and honestly, who would design any system that only supports 1 concurrent user?
In the browser, there are web workers. When combined with the "transferrable" argument in the postMessage function [0] you can get zero-copy transfers (with the caveat that you can no longer access that variable from the process that sent it, so they are actually "transfers" not "copies" or "references"). They are not only here now, but they have pretty stellar browser support (back to IE10 and even safari 5.1).
Node had it's own thing for a while as well, and there are many libraries on top of it to make it more capable or close to the web worker spec if you want. Sadly none of them seem to fully implement the web worker spec with the transferable objects ability, but there's no reason why that can't happen.
Personally I prefer this method MUCH more than just giving you classic multithreading primitives and telling you to not shoot your eye out. Going along with what you said, it's significantly harder to get race conditions when you are either copying everything, or are actually transferring the data to someone else. It seems limiting at first, but I haven't hit anything personally that requires more than that to use 100% of the cores on a system. (the few times i've used it in production situations was setup to basically have the main thread split the data, then transfer them off to worker threads to be processed and either transferred back, or the result collected in the main thread when ready)
That being said, there is some work happening on "SharedArrayBuffers" and Atomics [1] which are the real deal "you'll shoot your eye out" shared memory. And I believe they are well into the standardization process. Personally I'm going to avoid them like the plague, but I know that there are use cases out there that can't be solved with "transferrable objects". Mozilla has an MDN page on SharedArrayBuffer at [2] which is pretty useful.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
[1] http://tc39.github.io/ecmascript_sharedmem/shmem.html#Atomic...
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> something that I am still mindful of, is that you will NEVER have race conditions, as the entire user code will execute in a single thread
If your runtime (kernel, VM, etc - not "user code") has theoretical possibility to change user memory/variable (call user code) concurrently, there is theoretical possibility to have race conditions. Concurrent runtime must have certain entry points to user code and everything that can be theoretically touched from these entry points must be treated dirty, which can get pretty expansive with complex callbacks. The only way to NEVER* have race conditions is to use polling - explicitly mark memory dirty (semantically in code) between "synchronisation points" having only flags/counters (in my view they are the same) for communication between userland and runtime.
* If we allow for settling time and do not treat situations "read flag --> have flag value flipped --> execute based on old flag value" as race conditions.
The problem is that most languages are not powerful enough to easily express this. You basically need call/cc in some form or built-in coroutines. And a library/framework designed for this.
For the most part - yes. And not because they want it but because there is no other way. You usually need to do something before you do that next thing anyway.
Also I agree with the coroutine LUA rationale you can read in the link in this same thread. It appears that with Go I still need to alter my own code to use libraries that are written to run async or am I wrong?
That book chapter doesn't really illustrate the utility of Go's concurrency very well, it just explains the basic components that make it work. Let's say you wanted to fetch three text documents via HTTP and print each of them. Here's the regular, blocking way to do that (error handling, package imports, etc. omitted for brevity):
func main() {
documentURLs := []string{
"http://example.org/foo.txt",
"http://example.net/bar.txt",
"http://example.com/quux.txt",
}
for _, url := range documentURLs {
response, err := http.Get(url)
body, err := ioutil.ReadAll(response.Body)
fmt.Print(string(body))
}
}
func main() {
documentURLs := []string{
"http://example.org/foo.txt",
"http://example.net/bar.txt",
"http://example.com/quux.txt",
}
// `documents` is a channel of values of type `string`.
// A channel is a safe FIFO queue.
documents := make(chan string)
for _, url := range documentURLs {
go func() {
response, err := http.Get(url)
body, err := ioutil.ReadAll(response.Body)
documents <- string(body)
}()
}
for doc := range documents {
fmt.Print(doc)
}
}
In the closure we make an HTTP request and read the response body, just like before, but instead of printing the result directly, we send it to the `documents` channel. Basically, we start jobs on three new threads and tell them to put the result of the work in a queue. When we have started the jobs with the first loop, we proceeed to the next loop where we read the strings being sent to the `documents` channel and print them as we receive them. Reading on a channel blocks until there is something to receive.
So I hope you'll agree that this is a pretty simple way to run things concurrently: just use multi-threading. Except we're not using OS threads, which are expensive, we are using goroutines—light-weight green threads managed by the Go runtime. You can have thousands or hundreds of thousands of goroutines running at once, OS threads don't scale that well. If you block a goroutine (e.g., when performing an HTTP request), the Go runtime will just schedule another goroutine, which is cheap. The Go runtime may use a single thread (in which case the program is concurrent but not parallel) or it may use multiple threads (in which the program is both concurrent and parallel).
If instead you were writing a network server with Go, here's how you'd do it (example from https://golang.org/pkg/net/):
ln, err := net.Listen("tcp", ":8080")
for {
conn, err := ln.Accept()
go handleConnection(conn)
}
>It appears that with Go I still need to alter my own code to use libraries that are written to run async or am I wrong?
You can make asynchronous library APIs with goroutines and channels: when a function is called, start the work in a goroutine and return a channel. The goroutine sends the return value on the channel. It's kind of ugly and generally frowned upon; it's cumbersome for users who want to use it synchronously, and it's no better than doing it yourself if you do want to use it asynchronously. Instead it is preferred to expose synchronous APIs, which can then be made to run concurrently as desired.
I think one of the reasons people don't appreciate the importance of explicit effect management is that any one unmanaged effect in your program is usually ok. It's the interaction of multiple unmanaged effects that causes problems.
And yes, a large percentage of our use-cases for callbacks tend to be of the "yield execution of a multi-step task" form. But it isn't just callbacks, it's anything of a "concurrent-and-branching" type flow, so game AIs, UI, etc. also run into this stuff a lot. Sometimes it can be dealt with informally, other times it needs more structure for engineering with confidence to be possible.
A formalized finite state machine is one solution to making sense of the problem in a more generalized way: instead of handing off execution flow based on a morass of polling and callbacks, there's a big switch statement to represent the FSM. The end of each branch of the FSM dictates what the next branch is by setting a branching variable. And every branch ultimately calls into the FSM again, either via a callback or an external loop. This style has the upside of an easier debug trace and the downside of another variable to track and potentially mishandle. (overall, a net gain as the FSM scales up)
A more composable form of FSM used in game AI is the "behavior tree", which encodes blocks of logic in each node of the tree, each node returning a status code: success, failure, in-progress, and optionally taking an action affecting external state like "play animation" or "fire weapon". The general progression is a walk from roots to leaves, with some nodes used to determine the exact sequencing(left to right, pick random, etc.) and other nodes used to tell the tree to yield execution or restart processing by sending back a status code. With behavior trees, there's a substantial win for reusability since the nodes cleanly delineate their needs for parameters, allocation, yielding, etc.
At the language level we're still mostly catching up on strategies that give the idioms comfortable syntax. Yielding iterators (such as those in Python) and promises can sometimes substitute for the simple case of calling a sequence. Full-blown continuations exist in several languages and are very powerful but also encode too much program scope to be used at scale or for long-running, persistent tasks.
Because all mutable state is encapsulated inside the monad and only actually takes effect when the state changes get applied to the outside world, it also allows really cool things like abandoning and retrying state changes if the state's not right. This allows really cool things like STM's 'atomically' operation. Behind the scenes it'll roll back and retry the operation whenever necessary --- but you never need to care: the effect of the operation gets applied to the outside world exactly once.
No. There's no way around understanding that some of your code will run now, and some will run later. It's imperative to understand this in places where you mix sync and async code. It's not possible to avoid mixing them, after all, the async functions have to be called by something.
You could hide all async in a procedural layer if you accepted the constraint that once an async call starts, none of your own code will run until it returns. It wouldn't block the browser or OS, but it would block you. That's the only way to abstract async away, but that's a constraint I think most people would not be willing to accept.
> ...people still kind of want to write code that does one thing after another
I have no choice in the matter. I can't make use of the result of a REST call until I actually have the result.
But, you're right at a fundamental level as well; people do want strict ordering and simple to understand execution with predictable results. The ideal is being able to read a piece of code and see & understand everything about it based on the function you're looking at, and not a bunch of context outside that function. It's the reason functional programming paradigms are favored by so many.
The core.async library for Clojure makes the code look imperative, but handles locking and selecting threads to run under-the-covers ... you may find it an interesting compromise
> No.
Yes. That's exactly what coroutines achieve.
They transparently suspend and resume execution of async code in order to make it look imperative.
See https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl... for a good example.
Co-routines are not imperative, and you cannot treat them as though they are, you still have to understand they're async to use them at all. That is not "abstracted away", that is syntactic sugar.
Furthermore, this syntactic sugar only works locally when examining your coroutines, or promises, or asyc/await code. You still have to trigger that async code from somewhere, and the place it's triggered is always mixing sync and async code, so you can't sugar coat all of it.
There is no getting around knowing and thinking about the async factors when writing async code. You cannot hide it with coroutines or anything else.
That's exactly what coroutines do.
Here is an in-depth description of how Kotlin implements them:
https://github.com/Kotlin/kotlin-coroutines/blob/master/kotl...
Modern JavaScript has gotten very complicated lately because it's so flexible. Many people are developing interesting frameworks to solve niche problems; however, it feels like many of these solutions are overly complicated outside the niche. Yet, developers are adopting these frameworks due to it being trendy instead of choosing the correct tool for the job.
Many times, the correct "tool" for the job can be a mixture of an effective standard library, small specific libraries, and good conventions like the author describes.
I've been a programmer for 18 years now, and I am convinced that simple proven solutions are the way to go.
The author shows some code with lots of nested if/else clauses and claims this is bad because it blocks; fair enough. Then they explain what callbacks are and that some people have trouble understanding the asynchronous nature.
Then they immediately go into an explanation called 'How do I fix callback hell?' and meanwhile I'm scrolling up to see if I've missed something.
Perhaps people unfamiliar with this particular problem are not the target of this article, but that doesn't really make sense to me.
Readability of code is very important. Inline callback definitions hurt this.
Promises and especially async/await let you read code top to bottom once more, with other benefits like monad chains that catch synchronous failure.
For example, you want to know that the code is about to "getAccountData" but you shouldn't need to know how. You see that it is called, and you see that afterward, a callback called "loadAccountDataInReport" will be called. Why should you see all the guts of those two functions inline?
This is where the "just wrap it" argument breaks down.
Though I think promises are only slightly better when you have if-else branches that add to the async chain. It's not til async/await where Javascript finally hits its stride.
In other words, "callback hell" is simply the state of having too many nested inline callbacks. It makes the code uglier and for some harder to read. That's why pulling callbacks out into their own functions (i.e., making them no longer inline) fixes callback hell.
Javascript uses "function references" in a similar fashion to C's "function pointers". This...
function fooAllTheBars() { /* ...quux... */ }
const fooAllTheBars = function() { /* ...quux... */ };
setTimeout(fooAlltheBars, 1000);
setTimeout(function() { /* ...quux... */ }, 1000);
function quuxify(value, calculator, cb) {
calculator(value, function(err, calcResult) {
if (!err) {
cb(calcResult.toFixed(2));
}
});
}
function bazzify(success, failure) {
quuxify('foo',
function(value, cb) {
setTimeout(function() {
if (value > 100) {
cb("too high!", null);
} else {
cb(null, value - 10);
}
}, 1000);
}, success);
}
bazzify(console.log, () => {});
Basically, if you get into callback hell, your control flow starts bouncing around like a pinball hitting bumpers, and figuring out why is nearly impossible (unless you want to dig through fifteen levels of anonymous functions). And the sad part is that in most cases, you can't avoid it altogether because there's something fundamentally asynchronous like a `setTimeout` or an `xmlHttpRequest` waiting at the end of the call stack.
I would rephrase this slightly to "simple proven solutions that solve the immediate problem at hand, and nothing else."
Bringing in lots of extraneous dependencies, or DSLs offering functionality way beyond whats actually needed for the immediate problem at hand, can quickly lead to code that is very hard to understand, maintain, and debug.
Callbacks of course have the drawbacks mentioned. Sure, you can separate the functions, smaller functions and that too is preferred, but still you get code that can be difficult to reason about and read.
Promises, for all the hype, in my view clearly did not help matters much. Promise code can be as weird looking or worse than callback code. Promises did not solve the problem.
Async/await IS the solution. I've started converting callback and promise code to it. It's a great new enhancement.
However, one thing that promises (and other library-based solutions) do better than hand-written callbacks is exception handling. By default, promises will capture and propagate and exceptions thrown inside them, which is something that is very easy to forget to do with hand-written callbacks.
Whereas before you had a clear (if convoluted and in need of refactoring) control flow, now with async/promises you shove it all into an invisible state machine, with transient data structures that are either hard to inspect (promises) or totally inscrutable (async/await).
No thanks. I like callbacks.
Here's my test: can you reason about what a function might do with control flow just by looking at its call site, not its source code? With callbacks you can. With async/await you can't.
Are we back to "semi-colons are uncool"? It's so much eaier for me to glean the intent when browsing JS written with semi-colons.
The key piece of advice. It helps tremendously with backtraces if your program crashes.
Excel has one of the worst cultures when it comes to naming things. Easy to blame the users, but tools end up being used the way their design encourages. Excel gives you meaningless names. So most things have meaningless names.
However they can already be used in Node with the "--harmony-async-await" flag (and without flag in the upcoming Node 8).
[0] http://blog.sigfpe.com/2008/12/mother-of-all-monads.html?m=1
If there is no real benefit to the nested anonymous function style, why do people do it that way? It would never even have occurred to me to write code like that if I didn't see it in javascript all over the place.
It is possible to replicate these effects without closures, but it can get pretty messy: the former by prepending the variables to the callback's parameter list and .bind()ing them where you use it; the latter similarly, but you also have to introduce a layer of indirection via an object to get a "pass-by-reference"-like effect.
So sometimes it really is simpler to just use a function expression in-place.
To contrive a quick motivating example:
var odds = 0, evens = 0;
array.forEach(function (x) {
if (x % 2) ++odds;
else ++evens;
});
console.log("odd:", odds, "even:", evens);
function callback (counts, x) {
if (x % 2) ++counts.odds;
else ++counts.evens;
}
...
var counts = { odds: 0, evens: 0 };
array.forEach(callback.bind(this, counts));
console.log("odd:", counts.odds, "even:", counts.evens);
For instance every database call is async, so for an operation that requires 3 chained calls, you'll have to nest these callbacks together.
Go is the language it was always meant to be, and a significant part of that was handling async.
Once async/await comes along, JS will have a really nice solution, and to be honest, I think it's pretty impressive that JS, with the history of its development, has been able to acquire new technologies of this nature.
Async/await are not really what you want either. There is no fundamental reason JS could not have added a CSP model.
It was honestly a mystery whey people would use this hard to read nested structure when you can write things in a more readable way.
The best theory I can come up with is that it is easier to write that way if, for instance, you are answering a question on StackOverflow, and these examples just find their way into production code via copy/paste without people understanding how they work.
(Of course, as it is for all stylistic considerations, it's a matter of taste, not absolutes.)
fs.readdir source, (err, files) ->
if err
console.log 'Error finding files: ' + err
else
files.forEach (filename, fileIndex) ->
console.log filename
gm(source + filename).size (err, values) ->
if err
console.log 'Error identifying file size: ' + err
else
console.log filename + ' : ' + values
aspect = values.width / values.height
widths
.forEach ((width, widthIndex) ->
height = Math.round(width / aspect)
console.log "resizing #{filename} to #{height}x#{height}"
this.resize width, height
.write "#{dest}w#{width}_#{filename}", (err) ->
if err then console.log 'Error writing file: ' + err
).bind thisI was only commenting on the readability aspect, all other things being equal.
Oh, and callbacks definitely exist in other languages, like C.
What's the deal with this trend of setting up a whole website for a (basic) blog post?
"Simple concept" is subjective. I'd bet that discussing "simple concepts" with an engineer or scientist would likely cause your mind to grasp and instinctively try to relate to your own memorization of facts. But that shouldn't preclude you from discussing what you do know, or for that matter, sharing it with the world.
Yeah you're probably right, I've been a bit pedantic.
I feel this article is unnecessary long for the subject, it would be a good length for something like "setting up a hadoop cluster", but having all sorts of articles about all subjects is a very good thing. My bad.
Basically it's observer pattern on steroids. I'm not good at explaining things though so check out the website.
(Add `begin; rescue; end` where errors need to be handled)
From the site, I get that add(1+1) doesn't require a callback, whereas downloadFile(url) does.
What about somethingHarderThanAddition(noExternalDependency)?
My question is, what is the threshold that I can assume that my code will run sync, and when it cant?
It will always run sync, unless you call something that accepts a callback (either at the first level, or nested in something else you call).
Generally you won't have a choice. If something in your function calls another async function, the function as a whole is forced to be async. If not, then it won't be.
It's possible to make a function fake-async even if it doesn't call any async functions, by just calling the callback at the end. But there's not much point -- and callers may make assumptions about the the callback being called in a separate iteration of the event loop, so doing that could cause subtle bugs. That latter problem is solvable by calling the callback in a setImmediate callback, but again, no point unless you have a good reason to.
(Exception: there are a few apis where you do have a choice, e.g node's randomBytes can be either sync or async. Generally they're things that might block, where the sync version returns an error if it can't satisfy immediately. But generally you don't.)
In other words, it's an engineering decision, based on the expected consequences of the overall design in the context of understanding how the event reactor works.
I think the way author is explaining is weird. It's very hard to follow logic when functions are declared all over the place.
I think programming where we have state and things can happen at any time, where programs wait for events or something similar has proven to be difficult to write/understand/maintain. The 30+ years it has taken to write the (unfinished) Herd micro-kernel is a good example.
I stopped reading right there (well, it's near the end of the article anyway, and I did continue, but you get my point).
Its funny to me because the languages where you get massive nesting you almost want greater indentation as it gets extremely confusing as to what scope you are in.
While I prefer either 4 spaces or tabs (obviously not mixed) I'm not completely revolted with 2 spaces in Algo languages like Java, C or Go (although I suppose Go you have no choice) because you just don't have much nesting.
But Scala and Javascript.... wholly crap is there a lot of nesting. Please for god sakes if you absolutely need that much indenting either refactor or give into the glorious evil that is TAB.
In all serious there is an accessibility thing with 2 spaces. You are hindering people with bad eye sight. I just don't have the visual acuity anymore to discern two spaces easily and I imagine there are many more. It is sort of like building a building and making the stairs extremely steep because you don't like taking lots of steps with your long legs.
To me some parts of FE development kind of require deep nesting, e.g. css, but in javascript if you are 4/5 levels deep in the nest (with the "long lines symptom"), then you should do as proposed in the article: split into modules and functions.
And sometimes (often?) long lines comes from the bad habit to do 3/4 things in one statement. To me good code does exactly one thing per statement, and except for config or urls, is should not be long.
I don't think 4 spaces makes it easier to know in what scope I'm in when there are a lot of scopes. The amount of white space is a bit overwhelming to me.
But you know, it's no big deal, just a matter of taste. Maybe 3 spaces is a better answer, which I guess we'll never know...
If you are say 4 levels deep the additional characters used over 2 spaces is 8 characters. You got whopping 8 additional characters to make an even longer line of code (code to be interpreted or read) and screwed over the people who need the indenting.
If long lines are a problem than just refactor. I agree long lines are hard to read but there is a simple fix. Either refactor or just put in a line feed (or however the PL deal with long lines aka \ for bash or python).
> Maybe 3 spaces is a better answer
Simply put: A promise resolves to a single value asynchronously, an observable resolves to (or emits) multiple values asynchronously (over time).
Taken from here: http://stackoverflow.com/questions/36064303/what-are-the-dif...
"The purpose of async/await functions are to simplify the behavior of using promises synchronously and to perform some behavior on a group of Promises. Just like Promises are similar to structured callbacks, async/await is similar to combining generators and promises." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Also there are now many more libraries that use native ES6 promises.
Before:
function getPhoto(callback) {
someCustomHttpGet("/favorite_photo_id", function(err, data) {
if (err) {
return callback(err)
}
try {
var dataJson = JSON.parse(data)
someCustomHttpGet(dataJson.url, function(err, data) {
if (err) {
return callback(err)
}
callback(undefined, processData(data))
})
}catch(e) {
callback(e)
}
})
}
async function getPhoto() {
const data = await fetch("/favorite_photo_id")
const dataJson = await data.json()
const photoData = await fetch(dataJson.url)
return processData(photoData)
}
relevant:
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Also regarding that article: you can call async functions from non-async functions - you will simply get the Promise object instead of the data.
If you're using TypeScript, your editor will immediately highlight the error if you try to use that Promise object as though it were the data, so zero chance of getting it wrong. Try it yourself - https://goo.gl/vDk3Gz - hover over the `n` inside the `formatName` call.
async function() getZ(){ return promise }
function() getX(){
return x = y * getZ()
}
// sync call globally.
let x = getX(); // NaN
Imagine you have a validation lib, you don't need it to be asynchronous to validate a string of length > 10, but you need to rewrite your whole API if you need to validate the fact a unique index has to be validated from a database.
If not, then the problem is really no different from not knowing what your functions are returning (are they returing a Promise object? are they returning the data itself?). Not knowing the return type of the functions you use is hardly something new. You would have the exact same issue with functions that take callbacks.
See the link I sent there https://goo.gl/vDk3Gz - you can hover over all the variables and functions (once the editor fully loads), try typing "n.", hover over the highlighted errors, etc. The tooling takes care of everything.
TypeError: Converting circular structure to JSON
Seriously, the worst feeling ever is tracing through a huge function tree, only to run into function pointer dereference. Then you have to go on a wild goose chase to find out when, where and what it will be assigned to.
STATIC TYPES PEOPLE.
What's most interesting about your point is that what the article suggests -- naming and de-nesting callbacks -- is in a way what you're warning against. By naming it and physically moving it, execution that was contained within a single block of code is now jumping around, and can move to other places where you have to go looking.
Even though it's considered an anti-pattern for good reasons, there are some advantages to nested callbacks.
What you are asking for is much more closely related to static dispatch than static typing.
Why not just write an article on medium?
This article is exemplary of why any educated and trained developer will not go anywhere near the Javascript community.
IMO, platform IO libraries should support async behavior natively. Joe Armstrong [0] explains this beautifully.
[0] http://joearms.github.io/2013/04/02/Red-and-Green-Callbacks....
If you are manipulating inside a single function call it is atomic, JS is single threaded and doesn't interrupt functions.