![\"\"](\"http:\/\/www.visophyte.org\/blog\/wp-content\/uploads\/2011\/01\/jstut-promise-vis-popups-js-parse-failure.png\" "\\"jstut-promise-vis-popups-js-parse-failure\\"")
<\/p>\n<\/p>\n
Asynchronous JS can be unwieldy and confusing. \u00a0Specifically, callbacks can be unwieldy, especially when you introduce error handling and start chaining asynchronous operations. \u00a0So, people frequently turn to something like Python’s Twisted<\/a>‘s deferreds<\/a> which provide for explicit error handling and the ability for ‘callbacks’ to return yet another asynchronous operation.<\/p>\n In CommonJS<\/a>-land, there are proposals<\/a> for deferred-ish promises. \u00a0In a dangerously concise nutshell, these are:<\/p>\n I am in the Promises\/B camp because the when<\/strong> construct lets you not care whether value<\/em> is actually a promise or not both now and in the future. \u00a0The bad news about Promises\/B is that:<\/p>\n To elaborate on the (elegant) complexity, it uses a message-passing idiom where you send your “when” request to the promise which is then responsible for actually executing your callback or error back. \u00a0So if value<\/em> is actually a value, it just invokes your callback on the value. \u00a0If value<\/em> was a promise, it queues your callback until the promise is resolved. \u00a0If value<\/em> was a rejection, it invokes your rejection handler. \u00a0When a callback returns a new promise, any “when”s that were targeted at the associated promise end up retargeted to the newly returned promise. \u00a0The bad debugging news is that almost every message-transmission step is forward()ed into a subsequent turn of the event loop which results in debuggers losing a lot of context. \u00a0(Although anything that maintains linkages between the code that created a timer and the fired timer event or other causal chaining at least has a fighting chance.)<\/p>\n In short, promises make things more manageable, but they don’t really make things less confusing, at least not without a little help. \u00a0Some time ago I created a modified version of Kris Kowal<\/a>‘s Q<\/a> library implementation that:<\/p>\n The end goal was to support debugging\/understanding of code that uses promises by converting that data into something usable like a visualization. \u00a0I’ve done this now, applying it to jstut’s (soon-to-be-formerly narscribblus’) load process to help understand what work is actually being done. \u00a0If you are somehow using jstut trunk, you can invoke document.jstutVisualizeDocLoad(\/* show boring? *\/ false)<\/em> from your JS console and see such a graph in all its majesty for your currently loaded document.<\/p>\n The first screenshot (show boring = true) is of a case where a parse failure of the root document occurred and we display a friendly parse error screen. \u00a0The second screenshot (show boring = false) is the top bit of the successful presentation of the same document where I have not arbitrarily deleted a syntactically important line.<\/p>\n A basic description of the visualization:<\/p>\n You can find pwomise.js<\/a> and pwomise-vis.js<\/a> in the narscribblus\/jstut repo. \u00a0It’s called pwomise not to be adorable but rather to make it clear that it’s not promise.js. \u00a0I have added various comments to pwomise.js that may aid in understanding. \u00a0Sometime soon I will update my demo setup on clicky.visophyte.org so that all can partake.<\/p>\n","protected":false},"excerpt":{"rendered":" Asynchronous JS can be unwieldy and confusing. \u00a0Specifically, callbacks can be unwieldy, especially when you introduce error handling and start chaining asynchronous operations. \u00a0So, people frequently turn to something like Python’s Twisted‘s deferreds which provide for explicit error handling and … Continue reading \n
\n
![\"\"](\"http:\/\/www.visophyte.org\/blog\/wp-content\/uploads\/2011\/01\/jstut-promise-vis-popups-success.png\" "\\"jstut-promise-vis-popups-success\\"")
<\/p>\n\n
\n