Ten years ago, being a web developer sucked.  Deployment was easy (rsync to production and done), but the tooling available to us was dismal.  And I mean crying-naked-in-a-snowstorm dismal.  Browsers were inconsistent, their built-in programming environment (read JavaScript) was reasonably functional but horridly slow, and hardware wasn't beefy enough to deal with scripting languages for hard-core number crunching.

But we had the Flash Player.  Flash provided an environment that beat all three of those problems, and beat them soundly.  It was consistent across browsers and operating systems, used a similar language to what we were used to (both JavaScript and ActionScript are ECMAScript implementations), and it let the developer compile the script into something a little lower level to run in a dedicated VM on the user's machine which meant it was faster.  Of course, Flash is an animation toolkit, but we figured out how to bastardize it with the single-frame movie with a include-and-stop script in it so we could build applications entirely with script (like we wanted), but leverage the Flash player to actually run them.  Not to mention the rich support for visual stuff.  All this led to the concept of a RIA (Rich Internet Application).  Something similar to what we had on the desktop, but deployed to the web with all the benefits (and some drawbacks) that has.

Then browsers got their act together.  We started seeing a unifying focus on application development with the browser as the environment.  People got serious about fast JavaScript runtimes.  Standards were written (e.g., CSS2/3, Canvas) and largely adhered to.  And hardware got faster.  JavaScript application frameworks (EXT, YUI, GWT, etc.) showed up to leverage all that, and now it was possible to build RIAs using standards supported by a wide array of vendors.

In order to compete with this, Adobe released Flex, which is an application development framework for deploying to Flash Player.  It was horridly expensive, difficult to work with, had all kinds of implementation problems, but was better than what you got with JavaScript.  For a while.  Unfortunately a single software company, even one of the largest in the world, couldn't hope to compete with the widespread interest and momentum around browser-native RIA development.  Flex died as a web application framework pretty much before it was released.  Which isn't to say it wasn't used (it was and still is), but the browser RIA juggernaut crushed it like a bug.

Then we saw the huge surge in mobile devices.  It started with smartphones and now includes tablets and e-readers of various form factors.  Fortunately for both consumers and manufacturers, the web wasn't new, so they were able to jump right on top of all the standards and browser capabilities which had been created for the desktop.  A huge market segment opened up for web application developers and browser-native was reasonable right out of the box.

Adobe again tried to compete by creating Mobile Flash Player, but the benefits of Flash Player are small on new mobile devices, especially considering that so much of a mobile device experience is through web-connected native applications, not traditional web applications.  And here we have Adobe's smartest move yet around Flash Player: killing it for the mobile market in favor of restructuring the ecosystem around using it as a development environment for native applications.

Unfortunately, I don't think it's going to matter because Flash is still really slow and heavy and it's not really that much better to develop with than the truly native dev kits.  Yes, it offers the promise of cross-platform deploy, but just as Java demonstrated 10-15 years ago, that isn't much of a selling point for a single application.  People expect not just native execution, they expect native idioms, which means you have to develop for a specific platform, even if you're using a cross-platform toolkit.

So where does that leave us?  As consumers it leaves us in a great spot: there are lots of ways developers can deliver engaging applications to us, on all our devices.  As developers it leaves us in a weird spot: we're stuck with being either web or native developers, with Flash now trying to occupy a sort of middle ground (develop web-style, deploy native).  On the desktop I think Flash (via AIR) holds some promise, but ultimately I don't think it'll last.  The platform just isn't compelling enough to justify the dedication it requires to use it.  Java was designed for very much the same purpose as AIR, and virtually no one uses it.  Java moved almost entirely server side, something which Flash isn't likely to do.

Most interesting is the PhoneGap/Titanium/etc. movement which is very much paralleling the browser resurgence I talked about earlier.  Huge communities of people are working to take all the skills we have as web application developers and give us a build process to take web-ish apps and compile them into native applications, in much the same way Adobe has use AIR to compile Flash into native apps.  However, I think Flash is going to lose in exactly the same way, and for exactly the same reasons, as it lost in the browser.

Bottom line, if you use the web or a web-connected device (read: everybody) the world is going to be glorious in a couple years and only get better.  If you're a developer trying to work in that space, you need to learn browser technologies.  It's the way of the future.  Flash had it's run, but it's been on the way out for a long while.  It'll stick around, just like COBOL and Fortran have, but without an alternative path like Java ended up taking it isn't going to stay relevant to mainstream developers.

The JS has grown slightly more complicated, creating a richer structure to style to handle some of the new stuff:

jQuery(".progress").each(function() {
  var $this = jQuery(this)
  var frac = parseFloat($this.attr("rel"))
  if (isNaN(frac)) {
    return // bad data
  }
  var html = $this.html();
  $this.empty()
    .append(''
      + '<span class="container">'
        + '<span class="status-text-spacer">' + html + '</span>'
        + '<span class="progress-bar" style="width:' + (frac * 100) + '%;"></span>'
        + '<span class="status-text" style="width:' + Math.max(100, frac * 100) + '%;">'
          + '<span class="status-text-spacer">' + html + '</span>'
        + '</span>'
      + '</span>'
    )
  if (frac >= 1) {
    $this.addClass("overage") // strictly for external targetting
      .find(".container")
        .css({
          marginRight: (100 - 100 / frac) + "%",
          width: (100 / frac) + "%"
        })
  }
})

The CSS is still about the same for the base functionality, but with the new stuff, it's far richer:

.progress {
  display: inline-block;
  position: relative;
}
.progress .container {
  display: inline-block;
  position: relative;
  border: 1px solid #999;
  background-color: #f7f7f7;
  color: #f7f7f7;
  white-space: nowrap;
  padding: 0;
  margin: 0;
  width: 100%;
}
.progress .container .progress-bar {
  display: inline-block;
  position: absolute;
  z-index: 0;
  top: 0;
  left: 0;
  height: 100%;
  filter: alpha(opacity=80); /* yeah IE! */
  opacity: 0.8;
  /* .neutral is the default */
  background-color: #ddd;
  border-right: 1px solid #666;
}
.progress.overage.neutral-overage .container .progress-bar {
  background-color: #ddd;
  border-right: 1px solid #666;
}
.progress.ok .container .progress-bar,
.progress.overage.ok-overage .container .progress-bar {
  background-color: #dfd;
  border-right: 1px solid #393;
}
.progress.error .container .progress-bar,
.progress.overage.error-overage .container .progress-bar {
  background-color: #fdd;
  border-right-color: #c66;
}
.progress .container .status-text {
  display: inline-block;
  position: absolute;
  z-index: 1;
  top: 0;
  left: 0;
  color: #000;
  margin: 0;
  padding: 0;
}
.progress .container .status-text-spacer {
  margin: 0 5px;
}

So now instead of just doing this (which will render a neutral bar):

<span class="progress" rel="#raised / goal#">
  #dollarFormat(raised)# of #dollarFormat(goal)# raised...
</span>

You can control the various presentation very granularly (red below 100% and green from 100% up):

<span class="progress error ok-overage" rel="#raised / goal#">
  #dollarFormat(raised)# of #dollarFormat(goal)# raised...
</span>

The original version rendered green bars for everything, with this incarnation you can have neutral, ok, or error semantics for your bars.

The most damning place this bug rears it's head is with autocompletion scripts on form fields.  You necessarily focus the field, bringing up the keyboard, in order to interact with it.  But as soon as you do all your JS can't do timer-based actions.  If you have a naive implementation that responds directly to key events, you'll be ok, but particularly if you're doing remote data retrieval for the autocomplete dropdown, you're going to delay responding to key events so you can collapse multiple events which are temporally close into a single remote call.  Which means you're never going to get to making that call until the user removes focus from the form field.  Oof.

In many cases, you can code around the bug with a little trickery.  For example, on a key event, you can record the current time, and then set your timeout.  On the next key event, if your timeout hasn't triggered, but it's been longer than the delay, you can switch the autocomplete mechanism into direct invocation mode.  Hardly ideal, as it requires manual coding for every timeout/interval structure you have in your code, but it does work, and doesn't make everyone pay the price for the Android bug.  For simple autocomplete, this works reasonably well, but it doesn't do so hot for more complex situations.

Hopefully Google will get the bug (Issue 13540) fixed in the near future, and carriers will allow the update to trickle out to their devices.  But even in the best case scenario, that's still months away.

If you've ever built a web app that does background and/or batch processing of stuff, you've invariably created a bit of markup like this:

#numberFormat(sentEmailCount, ',')# of #numberFormat(emailCount, ',')# sent...

which then renders like this:

Wouldn't it be nice to create this markup (simply with a wrapping span) instead:

#numberFormat(sentEmailCount, ',')# of #numberFormat(emailCount, ',')# sent...

and have it render like this:

You think it would be?  I thought so too, so I wrote a simple little jQuery snippet to do exactly that.  Here she be:

jQuery(".progress").each(function() {
  var $this = jQuery(this)
  var frac = parseFloat($this.attr("rel"))
  if (isNaN(frac)) {
    return // nothing to do
  }
  $this.css({
      display: "inline-block",
      position: "relative",
      border: "1px solid #ccc",
      backgroundColor: "#eee",
      color: "#eee",
      padding: "0 5px"
    })
    .append(''
      + ''
      + '' + $this.html() + ''
    )
})

The basic idea is to take the span, make it render like a bar, hide the text (same color as the background), and then append a pair of absolutely positioned spans to draw the progress bar and then lay the existing content atop it.  It's not terribly robust, but it works like a champ if your needs are simple, and the code is straightforward enough that it should be easy to tweak if you have specific needs.

Use it as is, hack it up, turn it into a massively popular plugin and make a bazillion dollars.  Have fun. News of the gambling industry here. Read more.

Update: here's the same functionality, repackaged into separate JS and CSS so it's easier to deal with. JS first:

jQuery(".progress").each(function() {
  var $this = jQuery(this)
  var frac = parseFloat($this.attr("rel"))
  if (isNaN(frac) || frac > 1) {
    return // nothing to do
  }
  $this.addClass("container")
    .append(''
      + ''
      + '' + $this.html() + ''
    )
})

And the CSS:

.progress.container {
  display: inline-block;
  position: relative;
  border: 1px solid #ccc;
  background-color: #eee;
  color: #eee;
  padding: 0 5px;
}
.progress.container .progress-bar {
  display: inline-block;
  position: absolute;
  z-index: 0;
  top: 0;
  left: 0;
  height: 100%;
  background-color: #dfd;
  border-right: 1px solid #6c6;
}
.progress.container .status-text {
  display: inline-block;
  position: absolute;
  z-index: 1;
  top: 0;
  left: 5px;
  color: #000;
}

The basic idea is that your HTML includes a reference to "agg_standard.js", which is an alias for whatever JS files you need for your standard user (as opposed to a mobile user, for example).  That request comes to your server and if the file exists, gets served back like any other JS file.  If it doesn't exist, however, mod_rewrite will forward it to a CFM page to generate it:

RewriteCond     %{REQUEST_FILENAME}     !-s
RewriteRule     (/my_app)/static/(agg_.*)\.js$ $1/aggregator.cfm?name=$2.js

In our example, the request passed to aggregator.cfm would have "agg_standard.js" as the 'name' attribute, which is how we'll figure out what we need to aggregate together:

switch (url.name) {
case "agg_standard.js":
  files = [
    "jquery/jquery" & (request.isProduction ? ".min" : ""),
    "jquery/jquery.ui" & (request.isProduction ? ".min" : ""),
    "yui/yahoo-min",
    "yui/event-min",
    "yui/history-min",
    "util",
    "jscalendar/calendar",
    "jscalendar/lang/calendar-en",
    "jscalendar/calendar-setup",
    "dracula/raphael-min",
    "dracula/graffle",
    "dracula/graph"
  ];
  break;
case "agg_iphone.js":
  files = [
    "jquery/jquery" & (request.isProduction ? ".min" : ""),
    "yui/yahoo-min",
    "yui/event-min",
    "yui/history-min",
    "util"
  ];
  break;
}

The important bits, of course, is the Groovy script that actually does the aggregation and compression.  It uses YUI Compressor, so you'll need to have the yiucompressor-x.y.z.jar file on your classpath (probably in /WEB-INF/lib).  Here it is:

import com.yahoo.platform.yui.compressor.*

sw = new StringWriter()
variables.files.each {
  def f = new File(variables.STATIC_DIR + it + '.js')
  sw.append('/* ').append(f.name).append(' */\n')
  if (! it.endsWith(".min") && ! it.endsWith("-min")) {
    def compressor = new JavaScriptCompressor(f.newReader(), null)
    compressor.compress(sw, -1, false, false, false, false)
  } else {
    sw.append(f.text.trim())
  }
  sw.append('\n')
}
variables.buffer = sw.toString()

Pretty straightforward: it just loops over the files, using a StringWriter to build up the aggregated buffer.  Each file is either compressed into the Writer or simply appended based on whether the file has already been minified (based on ".min" or "-min" in the filename).  Each file also gets a comment label in the Writer above it's contents so that the aggregated file is a little easier to parse (at the expense of a few extra bytes).  Once done, the Writer's contents are stored in the 'buffer' variable caching on the filesystem:

<cfset fileWrite(STATIC_DIR & url.name, buffer) />
<cflocation url="#url.name#" addtoken="false" />

You'll notice that I'm not streaming the buffer back out to the user, but instead 302-ing back to the same URL.  This is important.  The reason is that Apache does a whole bunch of stuff to optimize static assets, and if I serve the content back with CFCONTENT, I'll miss out on all of that.  Yes, the 302 has a little bit of overhead on the initial page load, but it reduces the total transfer size by several hundred KB (because of the GZIPping), and avoids a rerequest on the next page load (because of the cache headers).  So it's completely worth it, the moreso because this is an application likely to generate extended usage rather than a content-centric site that is likely to see single-page "bounce" visits from search engines.

The last piece of the puzzle is handling versioning of your assets.  When you change your JS file, you necessarily have to invalidate your cache (by deleting the files) so the aggregated version can be rebuilt with the new JS.  The easiest way to do that is to use psuedo-versioning of your assets.  You'll see a lot of sites will add a timestamp or a version number to their files (e.g., "arc/yui/reset_2.6.5.css" from Yahoo.com) so that when the update the file it gets a new filename, and is therefore redownloaded by everyone (because it doesn't exist in their cache).  That's great, but it means you have to rename your files all the time which is kind of a pain.  But you can fake it:

<cfset STATIC_ASSET_VERSION = 15 />
<script type="text/javascript" src="static/agg_standard_#STATIC_ASSET_VERSION#.js"></script>

That'll generate a request to "agg_standard_15.js", as you might imagine, which isn't going to work so well.  But we can just change the 'switch' line from the first snippet to this:

switch (REReplace(url.name, "^(agg_.*?)(_[0-9]+)?\.js$", "\1.js")) {

Now it'll strip out that "fake" number string and switch on just "agg_standard.js", which is what we want.  But that 'fileWrite' call later will still use the full filename (with the number embedded).  That way subsequents will get the filesystem cacheing, the headers and GZIPping from Apache, and all the other love.  And when you rev your files, you need only increment the STATIC_ASSET_VERSION variable and you'll have a brand new set of virtual URLs for all your assets, no fuss, no muss.

Oh, and just in case you're wondering, the aggregation and compression is fast.  If you've ever used the command line or Ant task, you might fear that it's slow, but most of the time you see there is from the JVM spinning up, not the actual compression.  Since this is all in-JVM, you don't pay any of that cost.  It's certainly not fast enough to have it run in production on every request (hence the file caching), but it's totally reasonable to do on your production box as part of deploying a new version of the app.  It's also probably fast enough to have running every request on your internal test/staging boxes, though that'll depend on how much you're aggregating/compressing among other things.

<ul id="twitter_update_list"></ul>
<script type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></script>
<script type="text/javascript" src="http://twitter.com/statuses/user_timeline/barneyb.json?callback=twitterCallback2&count=5"></script>

That works, but it puts the JSON/P call (the second SCRIPT tag) into the main page flow, so anything after the call won't render until the script load is complete.  When Twitter is slow/down it can cause problems, but even when it's fast you still get a brief hang with a partial page before the rest snaps into view.  Fortunately, the solution is simple: do the call on DOMLoaded instead of inline.  I'm using jQuery, but the principle is the same regardless of what framework you use (or none at all):

<ul id="twitter_update_list"><li class="load-ind"><img src="http://www.barneyb.com/s/loading_indicator.gif" /></li></ul>
<script type="text/javascript">
jQuery(function() {
  jQuery("body").append(
    '<sc'+'ript type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></sc'+'ript>' +
    '<sc'+'ript type="text/javascript" src="http://twitter.com/statuses/user_timeline/barneyb.json?callback=twitterCallback2&amp;count=5"></sc'+'ript>'
  );
});
</script>

Now the SCRIPT tags will be written on DOMReady, allowing the full page to render before the calls to Twitter are dispatched.  This gives a faster user experience, though you do get a reflow of the sidebar when the statuses load.  This has become so prevalent on modern websites, however, that I don't think it's worth caring about, but if you're concerned, you could specify a height to the loading indicator LI that is approximately what the rendered tweet list will be to mitigate the effect.  It won't avoid the reflow, but it'll make things move less because the space will be reserved up front.

I've also added a simple "loading" image to the UL that the JS will place the tweets in.  The way blogger.js is written, any content within the UL will be removed (i.e. the tweets overwrite the content; they're not appended to the content), so no need to explicitly remove the image or it's container LI.

As I tuned the presentation, however, I ran into a couple issues.  First, the included styling sets the table width to 100%, but that was easily fixed with a .css("width", "auto") call.  I also wanted alternating row backgrounds, and a quick look showed that there is a 'zebra' widget built in that does exactly that, it just has to be enabled.

The biggest problem was with number formatting.  Some of the sortable columns contained large numbers, and when I wrapped the output with numberFormat() to add commas, the sorting reverted to textual instead of numeric.  A quick look through the source showed why: the 'digit' parser respects only numbers, the decimal point, and an optional leading +/-.  So the commas made it skip any numeric sorting and fall back to textual sorting.  Fortunately, the fix was simple.  Before initializing the table, I just added a new parser that piggybacks on the 'digit' parser's implementation:

jQuery.tablesorter.addParser({
  id: "commaDigit",
  is: function(s, table) {
    var c = table.config;
    return jQuery.tablesorter.isDigit(s.replace(/,/g, ""), c);
  },
  format: function(s) {
    return jQuery.tablesorter.formatFloat(s.replace(/,/g, ""));
  },
  type: "numeric"
});

The only difference between it and the 'digit' parser is that it strips all commas from the string before handing off to the backing methods (the blue stuff).  Works like a champ.  The separator should probably be parameterized like the decimal stuff is, but I only deal with comma separators in this app, so I didn't bother.

The only thing I wasn't able to figure out (though I'll admit I didn't try very hard) was setting the initial sort to be descending, so when you click a column header for the first time it does a descending sort rather than ascending (with subsequent clicks reversing the sort as normal).  Setting up the on-initialization sort to be descending is simple, but I didn't see a way to parameterize user-triggered sorts.

jQuery("#selector").bind("click", {name: "barney"}, clickHandler);

And then you use it like this:

function clickHandler(e) {
  alert(e.data.name);
}

The 'e' variable is the standard jQuery event object passed to all event handler functions.  The 'data' key within it contains the bind data created when the handler function was bound, if any.  Even this simple case is potentially interesting because you're controlling the alert message at bind-time, not in the function itself, without the extra wrapper function you'd otherwise use:

jQuery("#selector").click(function() { clickHandler("barney")});
function clickHandler(name) {
  alert(name);
}

But that's not the really useful bit.  What you might not have noticed about the two examples is that in the first, the string "barney" is evaluated once (at bind time), but in the second it's evaluated every time the click event is dispatched.  No big deal for a string, but for complex expressions that can create a performance issue.  Since event handlers are typically executed more than once (and often a lot more than once), moving stuff out of the callback and into bind data can actually yield a noticeable difference in UI performance, as I learned this evening.

In a photo viewing app I built I'm using JS to display multiple photos sequentially via a single IMG tag, just swapping out the source, width/height, title, etc.  I wanted to center the photo tag, but couldn't do it with CSS because some dynamically-sized absolute-positioned elements needed to be accounted for, as well as the size of the photo itself.  I'd originally written a handler that looked something like this:

jQuery("#theImage").load(function() {
  var base = getOffsets("content");
  var total = jQuery("#floatyControlBar").position().left;
  var object = jQuery("#imageContainer");
  var xd = Math.max(0, (total - object.width()) / 2)
  object.css({
    left: base.x + xd + "px",
    top: base.y + "px"
  });
});

It worked great, except that it made a noticeable jump from the old position to the new position when the image loaded.  I first tried the Flash-style "add an animation to mask the slowness", but the browser couldn't handle sliding a big image around very gracefully, so it wasn't any better.  Enter bind data.  Changing the handler to this resolved the issue:

jQuery("#theImage").bind("load", {
  base: getOffsets("content"),
  total: jQuery("#floatyControlBar").position().left,
  object: jQuery("#imageContainer")
}, function(e) {
  var xd = Math.max(0, (e.data.total - e.data.object.width()) / 2);
  e.data.object.css({
    left: e.data.base.x + xd + "px",
    top: e.data.base.y + "px"
  });
});

Basically I just changed it so most of the data collection happens at bind time (so it only happens once) and as little as possible happens when the handler is actually called.  It's a simple optimization, but it eliminated the visible jump.  The code has paid a slight price in readability, no question there, but while we all tout readable code as a hallmark of good code, user experience is still what software is about, so the latter wins.

Of course, you could achieve the same effect by setting the base, total, and object variables into the scope containing the .bind() call so the handler can access them via closure-nature.  But that pollutes (breaks encapsulation), so using bind data is a better solution in most cases.

The workaround is pretty simple, though kind of kludgey: add the stuff in bold to your handler.

jQuery("#selector").live("click", function(event) {
  if (event.button != 0) {
    // wasn't the left button - ignore
    return true;
  }
  // do some stuff
  return false; // "capture" the click
});

Hopefully this will be addressed in the future, but for right now you have to pick between manual button detection and sticking with the "normal" handlers.

To that end, I wrote a small demo app that uses several different bits of tech to get the job done (render an ugly page with auto-expanding URLs).  It uses JSON/P to load some tweets containing shortened URLs from the Twitter Search API, writes them to the DOM with jQuery after wrapping the URLs with A tags (the part Ray did manually), and then wires a jQuery mouseover listener to trigger expansion (virtually identical to Ray's).  Of course, the server side is what I was actually interested in, so here it is:

<cfhttp method="get"
  url="#attributes.expand#"
  redirect="false"
  result="cfhttp" />
<cfoutput>#cfhttp.responseHeader["Location"]#</cfoutput>

Pretty simple, eh?  Both a rapier and a howitzer can kill a man; picking the right one is important.

Why does this work?  Because every service is just doing a HTTP 301 with a Location header from the short URL to the full URL.  Some of them expose APIs for creating and querying the short URLs, but for this task, we don't actually care, we only care about the Location header.  The only special processing require is for preview.tinyurl.com links; I simply convert them to normal tinyurl.com links so they do the "right" thing.

As always, there is full source (all 55 lines of it, in one CFM template) displayed beneath the app itself should you wish to see all the details.  The JavaScript stuff is far more complex than needed for a demo app, but I wanted to do a little experimentation on the client side as well as the server-side stuff.