Do Promises Make Your Code Better?

In a post on GitHub, Dave Winer asks, “What do promises do/make possible that callbacks don’t?

This is a great question, and one, IMHO, that is not often addressed or answered well. It often seems that developers embrace new patterns and API, taking for granted that they are better simply because they are newer.

This question brings me back to when I first had to work in a Promise-heavy codebase. It was five years ago, and I had very similar questions. The answers I got at the time weren’t very convincing. Here’s some sample code that uses the callback pattern:

request.get('http://api.someurl.com/api/resource', function (error, data) {
  if (error) {
      console.error('An error happened', error);
  }

  console.log('Response received:', data);
});

Now, here’s the same code using the Promise pattern:

request.get('http://api.someurl.com/api/resource').then(function (data) {
  console.log('Response received:', data);
}).catch(function (error) {
  console.error('An error happened', error);
});

It’s different, but is it better? It really doesn’t seem to do anything that couldn’t be done with callbacks.

Where Promises started to shine for me was when I needed to compose multiple asynchronous responses. I provided code examples on the GitHub thread.

Dave replied with a link to some code he had written that had some pretty hairy logic involving many levels of nested callbacks.

I decided to refactor this code to use Promises, and then provide it as an example for further discussion of whether the Promise code is better or not. Along the way, I decided to take it a step further and I used some async functions and generator functions. I recorded my screen while I was making this edits. The finished product is on GitHub, the video is below.

Let me know what you think. Is this better or just different?

The Future of Javascript — Who Cares?!?

Yesterday on Slashdot, someone posted an InfoWorld interview of Brendan Eich (the creator of JavaScript).  In the interview he lays out his plans of the evolution of JavaScript into what he calls JS2.  The discussion on Slashdot was over the details of whether the language changes made things better or worse.  The thing about programmers is that they won’t all agree on anything.  Everyone has their own understanding of how software should be written.  My critique isn’t on any of the details of the language changes, its the premise itself.

First of all, let me say that I don’t believe JavaScript to be the Holy Grail of languages.  It’s not perfect, there are things about it that I find irritating.  There are also things about it that I like.  This is true of any language with any competent hacker.

Why JavaScript Matters:

More and more software is being designed to run “in the cloud”.  The benefits are obvious.  Deployment is trivial, as are upgrades.  Developing for the web means not having to care about the users’ platforms.  Connectivity is becoming faster and more ubiquitous every day.  JavaScript matters because it is the language of the web.  It excels not on technical merit, but out of necessity.

In the 1990s, Netscape was in a unique position.  It essentially owned the web platform.  Whatever they decided became standard.  When Microsoft built IE, they had to include JavaScript support so their browser could compete.  Every new browser since then had to include a JavaScript engine.

In todays market, every computer has a web browser and therefore has a JavaScript engine.  JavaScript matters for one reason, and only one reason: it is ubiquitous.

Why JS2 Does Not Matter:

Although Mozilla acts as if they inherited Netscape’s mid 90s status as keeper of the web platform, this is not the case.  They say that it doesn’t matter is Microsoft adopts JS2 or not, they’ll just write an IE plugin.  This may work to increase JS2 adoption, but it doesn’t actually solve any real problems.  JS2 is a solution looking for a problem.

When building TileStack, my main problem with JS isn’t some language feature (native classes, typed variables, etc.) it’s the lack of consistency between browsers.  Granted this isn’t something the Mozilla Foundation can fix, but a new version of the JS language does more harm than good in this context. 

Why JS2 is Harmful to Mozilla:

While Mozilla has the best of their JavaScript team busy writing new language features, the competition is getting tough.  Apple continues to push the limits of WebKit.  The next version of Safari will smoke the competition when it comes to JS performance.  They are packing so much stuff into the browser, that web developers will start to question the need for Flash.  Meanwhile, Mozilla is working on the syntax for the “let” keyword.  Hey Mozilla, where’s mobile FireFox?  How come the poster boy for open source isn’t part of the first open source mobile phone platform (Android)?  Congratulations on all the downloads of FireFox 3.  Too bad it’s killer feature is that it doesn’t suck down resources like FireFox 2.  Wake up guys, you’re starting to lose!

I guess the point is that language syntax is one of the least important features of a platform.  Do developers use .Net for C#’s syntax?  Is Objective-C’s syntax the reason for Apple’s recent successes?  Will the declarative structure of JavaFX Script save the Java platform?  I could go on with more examples, but I wont.  The answer is a resounding NO!  There are much more important things to ensuring the success of a platform than language syntax.

I suppose this doesn’t really need to concern me.  The web as a platform will continue to exist and grow and mature.  It’s just frustrating to observe this waste of time and energy.

UPDATE: I want to give credit where credit is due.  My colleague Josh Gertzen was quoted in AjaxWorld magazine on the irrelevancy of JS2 in an article that ran on Slashdot for a while.

Blatant and Shameless Book Promotion

Yesterday at OSCon, Prentice Hall announced the launch of the Sourceforge Community Press.  It is a special line of eBooks (called Shortcuts) that feature open source projects and are written by the developers themselves.

It is my pleasure to announce that one of the four titles available at launch is the ThinWire Handbook: A Guide to Creating Effective Ajax Applications, co-authored by yours truly.  It is available now for the price of $12.99 as a downloadable PDF, and it is also available through the Safari Bookshelf.

In the book, Josh Gertzen and I provide an overview of the entire framework.  Our goal is to describe the essence of each piece that makes up the complete framework, as well as to document features that may not be obvious to most developers.  So, if you’re into that sort of thing, go pick up download a copy, and start learning the awesomeness that is ThinWire.

Creating and Debugging ThinWire Applications with Eclipse

This tutorial will walk you through the creation of a simple Rich Internet Application with ThinWire using Eclipse 3.2 (Callisto) and the Eclipse Web Tools (WTP). It will also show you how to use these tools to debug your ThinWire application.

NOTE: Neither Eclipse nor the WTP plugins are necessary for ThinWire development. There are also other methods of using Eclipse to debug your ThinWire application that don’t require the WTP, but this currently appears to be the most straight-forward approach. Continue reading “Creating and Debugging ThinWire Applications with Eclipse”