The JavaScript blog.

AuthorAlex Kessinger

mobile async

Optimistic Server Interactions

Posted on .

Alex Kessinger is a programmer who lives in the Bay Area. He strives to make websites, cook, and write a little bit better each day. You can find more from Alex at his blog, on App.net, and Google+.

At PicPlz we built a hybrid mobile app. We had a native container written for iOS and Android that hosted a web version of our code. PicPlz was the first time I had worked on a fully mobile website. My operating paradigm was that I was building a website for a small screen.

One day, our iOS developer asked me why our follow button didn't just react when a user touched it. He pointed out that most iOS apps work that way. It was a glaring reminder that our app was something other than native. I genuinely had never thought about doing it any other way. I was building a web app, and when building web apps there is network IO. For things to be consistent, you need to wait until the network IO has finished. The other engineer persisted though, claiming that it doesn't have to work that way.

In order to make it feel more native I wrote the code so that the button would activate and change state immediately. If there was an error, which was infrequent, the button would flip back to inform the user. In the other 99.99% of the time the user would feel as if the interaction happened immediately.

Since implementing these interactions in PicPlz I have found out what they are called: Optimistic server interactions. While it is how things work in most mobile applications, it's not how most things work in web applications. Why? Well, we all know exactly what's going on when we make a request to a server -- nothing is certain unless a response is received. When we see a spinner or a loading bar we understand, but does a user? Do they understand that your web page is making HTTP requests on their behalf, or are they about to click away from your website because it feels slow?

I am sure you might be worried that this approach feels strange from a user experience point of view. Yes, it's weird, but how often will this happen? If your code is that fragile, then you might have a bigger problem.

Coding Style

There are times when optimistic server interactions are awkward to write. For example, building a chain of such interactions will result in highly indented callbacks.

Despite this, most cases shouldn't be more complex than the following pseudo-code example:

$('body').on('click', '.favorite', function() {
  var button = $(this);
  $.post('/follow', { 'favorite': true }).fail(function() {
    // flip favorite button to inactive
    // inform user action failed.

Another criticism is that if this happens too often, users will begin to question whether their actions are actually doing anything. This is a valid concern, but as I said earlier if your code really is failing this often then you probably have larger problems.

To be fair, I haven't really tried this on any major piece of code. This is a trick I use mostly for small interactions like follow or favorite buttons. Web apps like Google Docs are clearly using this type of interaction all the time. Still, this technique is slowly working its way into larger interactions. If you do client-side rendering, then you're 90% there. You can capture user input and update the interface immediately.

I'd like to thank Mark Storus for providing counter arguments.


events dom code-review flickr-async

Flickr's Asynchronous Script Loading Part 2

Posted on .

Alex Kessinger is a programmer who lives in the Bay Area. He strives to make websites, cook, and write a little bit better each day. You can find more from Alex at his blog, on Twitter, and Google+.

Part One: Flickr's Asynchronous Script Loading

This is part two of Production Teardown: Flickr's Asynchronous Script Loading. To recap, if we use an async JS loader, or even if we just put our script tags at the bottom of our pages we have a problem. There is a small window where it's possible to interact with the page before the code has loaded.

Flickr uses something they call an actionQueue, and their code is very tight and isolated. With little modification I think we could use that exact same piece of code for other things. We are going to build a simple page to put this to the test. To start, we need to make a few changes to the original code so that we can load multiple modules instead of just one.

Note: I am using QUnit to run the tests.

Adapting actionQueue.js

The code: actionQueue.js.

I had to make a couple of changes to the stock code for the purposes of generalizing the library, and to make it more testable. First, the original module is hard to test because its state is private. I wouldn't expect anything less, the state is only used by the actionQueue function. However, during testing we need to reset the internal state of actionQueue.

One possible way to do this is to write an actionQueue factory. This is a function that creates a brand new actionQueue every time it's called. Then it can be assigned to A.actionQueue as required. This has a lot of advantages but seems like overkill for our requirements. An alternative solution is to simply create a new function that can reset the internal state of the module. I've called this function refresh_module.

The second thing I did was to use [JSLint](http://www.jslint.com/) to help clean up the original code. For example, there were cases when a variable was assigned in a `for` loop:
for (var i in an_array) {

This is usually a bad idea because it's re-initializing `i` every iteration of the loop. A better form suggested by JSLint is this:
var i;  
for (i in an_array) {

I expect the engineers who wrote this code knew about this. I don't even think everything needs to pass JSLint, it's just a rubric that one can use to begin the process of evaluating code. What I think happened here is that they used the first version to save space. In the second version `i` is repeated twice, it's not as small as the first version. Also, they were also looping over a very small array. They probably optimized their code for the most pressing priority which was code size. Given that this code is going to show up in many, many pages on Flickr, which is an extremely popular site, then the size argument makes sense.

I got this wrong. As some people in the comments have pointed out the variable declaration is hoisted. I have corrected the error, and welcome any additional criticism. To be clear though, I would rather have an error in everything I have ever written, than to not write at all. We can't walk through the world constantly second guessing everything we say, or we wouldn't say anything. The best we can do is welcome being wrong, and fix it.

With testability improved and static analysers applied, I made one more major functional modification. When I started looking at Flickr's code I could see that there was an internal flag called queueing. When true, which is its default, interim functions get executed. When false, nothing happens; everything just passes through to the queue_click function.

What's curious about queueing is that it's global. actionQueue was clearly written with the idea of multiple modules, but apparently that part ended up not being needed. When the first module gets loaded queueing is set to false. That means all queue_click calls now pass through, even for modules that haven't yet called module_load. I have a feeling that Flickr loads all of its modules in a monolithic file. They aren't seeing any repercussions in this code because if one module has loaded, they have all loaded. I don't think that this will be the story for everyone who might want to use this code. So, I modified it so that each module has its own queueing state.

I've added the code on line 38 to set queueing to true for any new modules that get added by the register function. Then as module_loaded gets called, it will only turn queueing off for that module. You can see all my tests, and how I tested the multiple module section in actionQueue tests.

Building a Like Button

To demonstrate this code, we are going to build a simple "like" button. There will be two steps. When clicked it will change state, and then there will be an action for when the module loads. The compete example is here: actionQueue in practice.

This simple markup creates a like button with two states. The visual state is controlled by flipping a class name. Then I set up some initial code building our global container, and include the actionQueue code.

Line 20 is where we start to see how the like button is going work. This is comprised of two steps. In the interim step the like button will get a new class. This will flip the visual state. In the cleanup state, which will fire after the module, like-handler loads and the like button is set to Done!.

The like button itself is implemented as HTML. It's important to note that the anchor tag has an onclick. I know, this looks dirty, but really it's the easiest way to handle events before all of the code has loaded. The arguments behind this were covered in the previous tutorial. So, when a user clicks the like button an event gets fired into the action queue which will first fire the interim step.

Later I setup a link that will 'load' the module. This will then fire the cleanup function.


By first researching Flickr's code, then adapting it to be easier to test, we've created something genuinely useful and reusable. And although using onclick might be a little bit controversial, the previous part had a great comment from Ross Harmes that explained the thinking behind it:

I can speak to why we use onclick in this situation. For performance reasons, we want to load as little JS as possible until the page content is fully loaded. We also don't want to litter the page with script blocks just to attach these interim events. These two constraints mean that we can't load a library that normalizes event handling across browsers, nor can we attach event listeners in the standard way, using JS only. onclick is the only approach left to us, but it isn't a bad one. Like you said, we try to not be too dogmatic about these things.


events dom code-review flickr-async

Production Teardown: Flickr's Asynchronous Script Loading

Posted on .

Alex Kessinger is a programmer who lives in the Bay Area. He strives to make websites, cook, and write a little bit better each day. You can find more from Alex at his blog, on Twitter, and Google+.

Part 2

If you are using a script loader, or even if you are just putting your scripts at the bottom of your DOM, you have a problem. In some cases your scripts will load after the user has clicked on something that requires a JavaScript function to handle the click. It's possible you have a pure HTML version, but if the user has JavaScript enabled then we want to use it, even if the JavaScript hasn't loaded yet. There needs to be a way of handling events before all of the assets have finished loading.

There are a number of ways we could do this, but it's helpful to look at a working implementation. This is going to be a two part series. First, we are going to look at how Flickr does this. In the second part, we'll take the code that Flickr uses and extract the main features so that anyone can use the code.

In all of the code that Flickr loads before the body this is the part that matters to us: Isolated actionQueue Code.

Let's walk through this. F is the global Flickr object that contains all of Flickr's JavaScript. Not only is this a common pattern among frontend developers, this technique is widely taught, and accepted at Yahoo. By keeping all of your site's functionality in one global object you are not polluting the global namespace. It also is a great way to organize your code.

If a user is able to interact with the site before the scripts have finished loading, you still want to handle the user's click somehow. It may not need to be completely handled, but the interface should be responsive. Code may run in the time between when the click event is fired, and when the module that can handle the event is loaded. Finally, it should be possible to run code after everything has loaded.

Using Flickr's terminology, there are two phases: interim and cleanup. Interim code will be run right away, as soon as the user clicks something. Cleanup code will run as soon as the rest of the code has finished loading.

Flickr calls this module the actionQueue. Given that we now understand the basics of how the actionQueue works, the first step is to register a click_queue handler. The fav button is a good example of this.

How the Fav Button is Supposed to Work

In the un-faved state the star is black and white:

Flickr Favourite Button

The active state is a colour star:

Flickr Active Favourite Button

There are two things that need to happen when a person clicks on the favorite button.

  1. The button needs to change state to purple
  2. An Ajax call needs to be made to register the state change

The visual state change is as simple as adding a class to the element. Very little code is required for that. On the other hand, the Ajax operation is going to require a lot more code. So, to use actionQueue an action should be registered so that in the interim the visual state can be changed, and in the cleanup stage the Ajax operation will be performed.

The advantage of this approach is immediate feedback. Once the module has loaded then the Ajax operation can be performed. And, this is exactly how Flickr implemented this functionality: Flickr actionQueue Fav Handler.

The register function only handles potential actions, and not actions that have actually been triggered. That is what the queue_click function is for. The queue_click function can be called when an actual event has happened. In the case of the fav button, this will be a click event.

Looking at the HTML for the button shows that the queue_click function is just called from the onclick handler. In turn the function will return false if the page is still waiting for code to load, thus canceling the browser's default operation: Flickr Favorite Button.

Now, this is where things get awesome. I am a fan of killing sacred cows. One of those in the front-end community is to not use onclick attributes -- it's certainly become dogma for many. Clearly Flickr doesn't care about this. I don't know the details of why Flickr is using onclick, but I have to assume it's because it's the lowest common denominator, and it works.

And, that's it. In this manner Flickr is able to handle all of us who are able to click faster than JavaScript is able to load. After breaking down this technique I wondered if there might be an easier way to handle actions before they loaded.


Now that we have seen how Flickr handles this problem, how can we use the techniques in our own code? In part 2, I'll explore Flickr's code in detail, and demonstrate how it can be used with any site.


JSON templating discussions

Discussion: JSON vs. Markup Fragments

Posted on .

Alex Kessinger is a programmer who lives in the Bay Area. He strives to make websites, cook, and write a little bit better each day. You can find more from Alex at his blog, on Twitter, and Google+.

Recently at work we were discussing a new trend in
web application development, whereby markup is rendered on both the
server and client. The Google+ team talked about this openly in this
post by Mark
with particular focus given to performance. Why does rendering content
on both the server and the client improve performance?

This is clearly something that people seem to think is a good idea. Some
templating languages, like mustache, are
available in many different languages, making it easy to use them on
both the client and server. Now, if you're a front-end developer by
trade, you might be more comfortable with rendering everything on the
client. That doesn't mean that it's faster; it's more of a comfort

So, community, my questions for you are as follows:

  • Is Google+'s approach of rendering markup on the server really faster than transmitting data?
  • Are there ideological or philosophical arguments for delivering data or markup?
  • Is it appropriate to mix both approaches?


language essays

Changing Perceptions of JavaScript

Posted on .

Alex Kessinger is a programmer who lives in the Bay Area. He strives to make websites, cook, and write a little bit better each day. You can find more from Alex at his blog, on Twitter, and Google+.

JavaScript is weird. There's the obvious weirdness of prototypal
inheritance, </code> vs. <code>=; but those are
just surface issues. One feature that boggles non-JavaScript programmers
is space optimizations. JavaScript is unique in this fact. Much of our
insane syntax flows from the fact that the code goes over the wire.
Space saving optimizations are not just acceptable -- they are

Think about that for a moment. How long has it been since programmers
have had to worry about the size of their code? Front-end developers do
this all the time, but to anyone else it's crazy.

At Yahoo I got really good at space optimizations. There were a bundle
of internal documents you could turn to that would offer tricks, and
rules for making your code smaller. The importance placed on these
syntax rules turned code reviews into a checking off process. Every time
we passed the list we patted ourselves on the back. We thought it was
the best use of our time, and we plodded on, writing the same code over
and over. It was prettier, smaller, and well documented, but there
wasn't a ton of original thought that went into it. At least on my part
there wasn't. I am embarrassed to say this now, but I felt like I was at
my JavaScript zenith during this time. Oh man, was I wrong.

I don't think like that anymore. My rubric for good code is how well
others can readily understand it. I no longer consider something useful
until someone else has successfully modified it. And still, the finish
line keeps speeding away from me. There is always a way to be better.

When I moved from a large place like Yahoo, where I rarely had other
kinds of engineers looking at my code, my code habits had to change.
Other kinds of engineers -- especially more polyglot engineers -- were
looking at my code. I found I had to explain myself constantly.

Their acceptance of my crazily optimised code was tepid. Over time, the
craziness started to wear on me. Every time another programmer had to
interact with my code I had to explain everything to them. I felt like a
baboon pounding my chest then leaning over and saying "see, it's simple,
right?" -- it wasn't! And I had to admit, the blame did not lie with the
language or the environment. I am sure that I had become lax in my
syntax, and my code wasn't as clean as it used to be. When there is no
one to call you on your habits, you slide a little.

I was the only front-end developer for a while, but even that wasn't the
worst part. The biggest failure was forcing other kinds of engineers to
accept the craziness, and not taking their code habits into
consideration. I thought that was how it has always been done, and will
forever be done. My coworkers enlightened me. In a small but diverse
team, shared code habits might be the most important key to
understandable code.

With shared code habits in mind, we set about mixing and matching a
front-end system that was more understandable to everyone. I had to
learn how others would see the front-end system. We went about
encapsulating things in a way that would make more sense to others. Some
engineers think of JavaScript as something that needs to disappear, like
in GWT, but our reformulation was more like a blending of technology
that kept the good parts of JavaScript.

During the transition I began to realize the reasons other programmers
reel away from front-end code. Engineers who are fully capable of
writing code for the web will be turned off by the syntax. It might even
stop them from writing web code. Then, even if they do write some code,
they switch off their analytical brains when using something they don't
like. They'll just do what they need to do to get the job done. You
won't get them to help you make the code better. In the end you took
someone who could have been a net positive on code quality, and created
a net negative on code quality. And for what; smaller code?

One of the best things we did was to switch to intermediaries.
Uglify.js is a great example of an intermediary code processor. We have begun to use a number of these
tools. Basically, you can use something like Uglify.js or
CoffeScript to bridge the gap of understanding. You can turn something that people found ugly,
into something beautiful. And then you start to switch the editorial
part of their brain on.

None of this means that I don't care about optimizing code, or keeping
things small. This is important for everyone, and especially so for
high-traffic websites like Yahoo. It is not a means to an end. It's that
90% of my checklist has been replaced by code compressors like
Uglify.js. I don't know what I would have done at Yahoo code reviews if
we started using Uglify.js. It would have been a lot of latte sipping,
and crying as the company crumbled around me.

We should have used better tools, and spent more of our time learning
better ways to code.