Tim Bray on Software in 2014

In his article “Software in 2014” Tim Bray says about the present state of front-end development:

Thus, for ac­tu­ally build­ing ap­pli­ca­tions, you’re going to have to pick a higher-level frame­work. There are lots of them and they com­pete vig­or­ously, it’s easy to poke around the Web and find knock­outs and cage matches; one good high-level com­paro is Rich JavaScript Ap­pli­ca­tions – the Seven Frame­works (Throne of JS, 2012) but wait it’s eigh­teen months old thus prob­a­bly now wrong, which is a symp­tom of the prob­lem. “What prob­lem,” you ask, “choice is good, right?” It is, but this isn’t an or­derly choice, it’s a Cam­brian Ex­plo­sion. I’m sure the soft­ware arche­ol­o­gists of 2113 will enjoy study­ing it, but it’s a prob­lem.

ongoing by Tim Bray · Software in 2014.

I completely agree, right down to the term “Cambrian Explosion”, and I ranted a bit about it in one of the few posts I wrote last year. Client-side development is a scary mess right now, where almost every choice you make stands a chance of blowing up in your face a year down the line.

How to detect a page request from Safari 4’s Top Sites feature

While reading Jeremy Keith’s blog entry “Safari Askew” I remembered that I had looked at this just before Christmas, and found an answer.

The problem is to do with Safari 4’s “Top Sites” feature, which shows you a pretty grid of thumbnails for the sites you visit most regularly (or that you have pinned in place). The interesting thing is that these thumbnails are live (ish) previews of what those pages currently look like. If you don’t happen to have a Top Sites page open in a tab, and if Safari considers that the current thumbnail is sufficiently out of date, it will automatically go and retrieve the latest version.

Safari 4's Top Sites feature

This can cause headaches for site owners, because in order to show the actual state of the page, Safari relies on full page requests: it downloads all the HTML, CSS, images, and JavaScript for the page, and then displays everything exactly as if the user were viewing the page in a standard tab. Adverts are rendered, page tracking scripts are executed, and to the server it looks just like a regular page hit. This can lead to the site recording unnecessary actions, and your site analytics being all messed up.

At Skyscanner, for example, we noticed this because Google Analytics was showing an unusually high number of Safari users (8.5%) with an abnormally high bounce rate (the proportion of sessions where users view a single page, then walk away with no further interaction): Safari 4 users were twice as likely to bounce as other browsers. Useless sessions generated by Top Sites were the problem.

As Jeremy noted, the user agent that Safari 4 reports for a Top Sites request is exactly the same as for a normal page request. Fortunately, there is a way to distinguish the two types of request: in the current version of Safari 4 (4.0.4) the Top Sites request for the base page (but not its JS/CSS/image resources) carries an additional HTTP header, namely “X-Purpose: preview“.

An easy way to verify this is to use an HTTP debugging proxy like Fiddler or Charles to watch what happens when Top Sites makes a request — see the screen grabs below:

Normal and Top Sites HTTP requests from Safari 4

If your pages are dynamically generated, you can adjust your server-side code to examine the HTTP headers of the incoming request, and take appropriate action if this is a “preview” request. Here’s some sample PHP code:

if ($_SERVER["HTTP_X_PURPOSE"] == "preview") {
	echo "preview";
} else {
	echo "normal";

("X-Purpose" is not a standard HTTP header, and you won’t find “HTTP_X_PURPOSE” in the PHP documentation. It’s the CGI specification that specifies how HTTP headers should be handled: they should be made into an environment variable with an “HTTP_” prefix followed by the header name, with dashes replaced by underscores. Hence, the value of the "X-Purpose" header is placed in the "HTTP_X_PURPOSE" environment variable, and retrieved as $_SERVER["HTTP_X_PURPOSE"].)

If all you’re looking to do it fix your site stats in Google Analytics, then you should just make sure that you don’t write out the GA tracking code for preview requests. If you are concerned about excessive load on your servers, unwanted user actions, or spurious advert impressions, you can take more aggressive action, perhaps by rendering a lightweight version of the page. An extreme possibility I considered was generating a completely different version of the page, specifically designed to look good in the thumbnail format of the Top Sites preview page:

Safari 4 Top Sites with custom preview thumbnail: PROBABLY A BAD IDEA

However, doing this runs counter to the notion that these thumbnails represent previews, and I don’t know how your users would react. More importantly, Google might consider this cloaking, and come round your house in the middle of the night with a baseball bat. Just because it’s possible, doesn’t mean it’s a good idea…

Zero Years of Scroll


Eschewing the faddish, Scroll features in depth articles by deeply experienced practitioners in the fields of user experience design, web design, web development, information architecture, accessibility and more.

If you want to go beyond the hype and the hip, and to the heart and mind of the web, Scroll is your magazine.

Looks nice; pity their “Buy as a PDF” option doesn’t work yet buy it here.

@Media Ajax

@Media Ajax logoI was at the conference @Media Ajax conference last week. In hindsight, “@Media JavaScript” would have been a better title, though. It is less than two years since Jesse James Garrett coined the term “Ajax”, but we are already at the point where Ajax development is just the way we do things now, rather than something that needs to be explained, discussed, and evangelized.

During the wrap-up panel at the end of the second day, one of the questions was directed to the audience: who would have attended the conference if it had in fact been called “@Media JavaScript”? Most people put up their hand. I would not be surprised if Vivabit run a sequel to this conference next year; but the main reason for them to keep the term “Ajax” in the title would surely be to make it easier for developers to convince buzzword-hungry managers to let them attend.

Monday 19 November

Keynote presentation: “The State Of Ajax” by Dion Almaer and Ben Galbraith

Dion AlmaerBen GalbraithThis presentation set the scene for the rest of the conference, briefly covering subjects like JavaScript 2 and the heated politics surrounding it, the emergence of offline support for web apps (Google Gears) and runtimes with desktop integration for web apps (AIR, Silverlight), and the evolution and convergence of JavaScript frameworks. Their demonstration of Google Gears’ WorkerPools was an eye-opener for me; I hadn’t realized that Gears was about so much more than offline storage. They closed with a reflection on how Ajax has transformed our expectations of web applications, and how it is enabling a more attractive web.

(Note to self: get more familiar with Tamarin, ScreamingMonkey, Google Gears, AIR, HTML5, Dojo, Caja.)

“But I’m A Bloody Designer!” by Mike Stenhouse

Mike StenhouseMike talked about how in modern web development, the traditional barriers between designers and developers are breaking down. Designers need to be aware of the consequences of their choices, and how things like latency and concurrency will influence a feature. Developers need to increase their awareness of interaction design. This led to a discussion of how he feels thatBehavior-driven development has made him a better designer (and developer). He mentioned WebDriver for writing and executing BDD test cases, but the demo code he showed looked more like Ruby… I think I missed something there. Good tools and techniques to explore, though.

Update:: RSpec?

“Real World Accessibility for Ajax-enhanced Web Apps” by Derek Featherstone

Derek FeatherstoneProviding good accessibility for web content is hard enough; once you start building dynamic web apps, you’re practically off the map. Derek took the zoom/move control in Google Maps as an example of bad practice, showing how difficult it is for someone with only a voice interface to use. He walked through some more examples, with useful advice on how to make improvements in each case.

One of the toughest problems for Ajax applications is how to inform screen readers that a part of the screen has been updated. Derek noted Gez Lemon and Steve Faulkner’s technique for using the Virtual Buffer as being one of the best options for tackling this right now. Another cool technique that I hadn’t seen before was updating an input field’s <label> element with error information when the form is validated (so that a screen reader is made aware of the change), but then using CSS positioning to display the error information where a sighted user would expect to see it–possibly on the other side of the field than the label itself. Very clever.

I’m also going to have to familiarise myself with the ARIA (Accessible Rich Internet Applications) work coming out of the WAI: ARIA proposes to extend (X)HTML with additional semantics that would allow web applications to tap into the accessibility APIs of the underlying Operating System.

“How To Destroy The Web” by Stuart Langridge

Stuart LangridgeAfter lunch, Stuart Langridge put on his Master of EVIL hat, and tried to coax us to join him on the Dark Side by teaching us about all the things we can do to make a user’s experience on this hyperweb thingy as shitty and 1998-like as possible. Remember: if your app doesn’t use up all of a user’s bandwidth, they’ll only use it for downloading…well, something else. (“Horse porn” sounds so prejudicial.)

(Stuart’s slides lose a certain something when taken out of context.)

“Planning JavaScript And Ajax For Larger Teams” by Christian Heilmann

Christian HeilmannChristian works for Yahoo!, and has for a long time been a great evangelist of unobtrusive javascript and other modern JS techniques like the module pattern. In this presentation, he talked about working with JavaScript in larger teams. This is interesting, because until recently, there were no such things as “large JavaScript teams”. JS was something you copy-and-pasted into your web site, or got your resident front-end geek to bolt on as an afterthought. JavaScript has matured enormously over the last few years.

Many of Christian’s points are good software development practices in general: comment your code, follow a code standard, work as if you will never see your code again, perform code reviews, use good names, etc. Take five minutes to read through Christian’s presentation slides (they’re very readable and comprehensible, even out of context), and then take another five minutes to think about them. JavaScript is a first-class citizen of web development now: let’s treat it as such.

(Note to self: make more use of the BUILD PROCESS.)

“Ajax A Work: A Case Study” by Peter-Paul Koch

Peter-Paul KochPPK wrapped up the day with a case study of a genealogy/family tree application he is building. He walked through the decision processes behind:

  • building the app as an Ajax app in the first place
  • choosing XML instead of JSON (or HTML or CSV) for its data format on the wire
  • deciding on an optimal loading strategy to ensure a highly responsive user experience

Interestingly, PPK was the only speaker who used the “strict” definition of Ajax (i.e. Asynchronous JavaScript and XML) as the basis for his presentation. I didn’t agree with all of the decisions he described, but it was an interesting view anyway. (And besides, it’s not my app 🙂 His write-up of the conference, as well as his slides, can be found on his Quirksmode blog.

Tuesday 20 November

“The State Of Ajax” by Brendan Eich

Brendan EichBrendan Eich is the man who invented JavaScript. There are few mainstream languages that have both been adopted so widely, and dismissed out of hand by so many. In the keynote presentation, Dion and Ben characterised Brendan Eich as wanting to use the JavaScript 2 (ECMAScript 4) spec to “just let him fix his baby”. That’s a pretty crude caricature of Brendan’s position, though. He is very keenly aware of all the problems in JavaScript as it stands right now. (And there are some really big problems.) With JS2 he is trying to take the best bits of JS1, and build a language for the next 5-10 years (or more) of the web.

However: JS2 really is a different language. It adds new syntax, and it will not be compatible with existing interpreters. The other side of the “future of JavaScript” debate wants to see incremental improvements to the current implementation(s), so as to maintain compatibility and not “break the web”–because we’re still going to be stuck with IE6 for a long time to come.

I’m not going to run through the technical guts of all the things going into the JS2 spec–there are just too many of them. Take a look at Brendan’s roadmap blog to get pointers to what’s going on.

“Building Interactive Prototypes with jQuery” by John Resig

John ResigThis presentation did exactly what it said on the tin: an introduction to coding with jQuery. It appears to be compact, simple, expressive, and ideal for a lot of everyday JavaScript work.

“Metaprogramming Javascript” by Dan Webb

Dan WebbDan showed how to use some of JavaScript’s best features (prototypal inheritance, expando properties, using Functions as Objects, etc.) to produce some surprising results. Because of these techniques, JavaScript really is a language that can bootstrap itself into a better language. Very slick.

(See the slides for the presentation on Dan’s site.)

“Dojo 1.0: Great Experiences for Everyone” by Alex Russell

It appears that no @media conference is complete without a doppelgänger. I hope I’m not the only one who sees the obvious resemblance between Alex Russell and Ryan Reynolds. (Photo of Ryan Reynolds shamelessly lifted from Tharpo on Flickr.)

Hollywood star and sex symbol Ryan Reynolds Dojo toolkit lead developer Alex Russell

Alex is the lead developer for the Dojo toolkit. He talks really fast on stage! He is full of energy and seemed eager to share his insights with the audience, even though some of those insights paint a rather depressing picture of the state of the web. Personally, I lapped it up. I think it was the best presentation of the conference. Rather than talking just about Dojo, he discussed among other things:

  • the complexity of web development, and why there is a need for JavaScript libraries/frameworks in the first place
  • the burden of bringing new semantics to the web
  • how the lack of progress and competition is putting the whole open web in jeopardy

You can get the slides for the presentation on Alex’s blog, but without his lively and passionate narrative, they lose a lot of their power. Although he also talked about the technical capabilities of Dojo itself (powerful internationalization features, accessibility already built in to all its widgets, all built on top of a tiny core), it’s the strategic positioning of the toolkit that is going to make me download it and try it out.

“JavaScript: The Good Parts” by Douglas Crockford

Douglas CrockfordDouglas Crockford is one of the people most responsible for bringing JavaScript to its current level of maturity. He invented JSON, and wrote the JSLint checker and JSMin minifier. He reckons that JavaScript is the world’s most misunderstood programming language. His presentation covered some of the best bits, which you probably would not discover on a first glance at the language, such as Lambda expressions, closures, and dynamic objects.

Douglas stands in the opposite camp to Brendan Eich when it comes to evolving JavaScript. He wants to see the language become more secure (very important, given how glaringly insecure it is right now), but he thinks that the radical changes proposed for JS2 are wrong. One of the best parts of JavaScript is its stability: there have been no new design errors in the language since 1999, because that’s how long JS1 has been frozen. (There have been minor iterations to it since then, but nothing on the scale of the fundamental architectural changes that JS2 will bring.) He is still keen on evolving the language, but in a much more gradual way.

One very interesting thing that Douglas briefly mentioned was ADSafe. This is a subset of Javascript, designed for safety: a script built with the ADSafe subset can still perform useful work (it still has access to the DOM, and can make network calls), but it is not allowed to use any of the features that make JavaScript inherently unsafe (e.g. access to global variables, use of eval, etc.). ADSafe is a static checker: you run it to verify the code before you allow the code to appear on a page. If it isn’t safe, you don’t let it run. Google’s Caja works in a different way: it takes untrusted code and transforms it into safe code. To understand the use of these tools, consider Google’s iGoogle home page, where you can have widgets from a variety of sources all running on the same page. Without some kind of safety container, these scripts would have access to each other’s code and capabilities — very dangerous.

(The slides Douglas has on his blog are not quite those he used for this presentation, but they’re close enough.)

Wrap-up panel discussion with Brendan Eich, Stuart Langridge, Alex Russell, Douglas Crockford, and moderated by Jeremy Keith

Brendan EichStuart LangridgeAlex RussellDouglas CrockfordJeremy Keith Jeremy tried to keep this light-hearted, but there was clearly some tension between the panellists. I was pretty tired by this point, though, and the thing I remember most is Alex berating Yahoo! (Douglas) for not open-sourcing the YUI framework and coming together with other toolkit developers to present a unified front to browser vendors. Other subjects that came up included Google Gears (again), how badly CSS sucks (I see their point, but I still like it anyway), and capability-based security (see also The Confused Deputy).

(Jeremy’s has write-ups day 1 and day 2 on the DOM Scripting blog.)


It was a very interesting conference. It didn’t feature as much technical content as I had expected: it was more strategic than tactical. I didn’t mind at all, though, that it wasn’t just about “Ajax”. I love JavaScript, and I came away feeling excited by the amount of activity in the field.

The most important things I took on board:

  • Make more use of the build process
  • Investigate Google Gears – there is a lot of interesting stuff going on there, and it will start making its way into browser implementations soon
  • If you’re doing any kind of JavaScript development beyond simple form validation, you really should be using a library…
  • …probably jQuery…
  • …but Dojo looks REALLY interesting

“atmedia” tags on Flickr

A tagIn their write-ups of @Media 2006, Eric Meyer and Peter-Paul Koch have both spoken out to discourage the use of the “atmedia” tag for photos on Flickr which have no (apparent) relevance to the event itself. Personally, I’m with Russ Weakley in the opposite camp.

The whole point of tags on Flickr (and elsewhere) is that they are not rigid categories decided by the site owners. Everyone uses them differently, and most people pay no heed whatsoever to the global namespace. For example, when I tag pictures of my family, I use “family”, and the first names of whoever appears in the photo, e.g. “family martin fiona”. This is because I’m thinking about the relevance of these tags in the context of my personal space on Flickr. I’m tagging these photos for my benefit, and for my friends and family–not to provide the entire Flickr user base with a convenient way of reaching these photos via a global search.

Tags are descriptive rather than prescriptive metadata. With tags, you can throw as much or as little description as you like at an item. This allows for enormous flexibility, which encourages people to actually attach metadata in the first place. This is a good thing. However, the metadata is also likely to be incomplete, imprecise, and highly subjective. But this subjectivity is actually a strength when it comes to “social” tagging schemes.

The reason tags are gaining ground on traditional fixed classification schemes is that people like being able to create their own labels, with their own personal relevance. People like not having to ponder whether they should file a photo of Westminster Abbey under “Places:UK:London” or “Architecture:Churches:Gothic”. Would Flickr contain even a tenth of the metadata if it provided a set of categories instead, and asked people to classify their photos accordingly? I don’t think so. Aside from the cognitive overhead involved in making those decisions, there’s the usability aspect to consider, too: repeatedly navigating a categories is going to be more difficult than just throwing a bunch of tags into a textbox.

So although it may be frustrating for one person to search for the tag “atmedia” and be confronted with photos of Big Ben instead of Big Veen, someone else is sitting in front of their computer perfectly delighted with Flickr for allowing him to group all the pictures from his trip with a single convenient, and–for him–highly specific and descriptive tag.

It’s fine to suggest a canonical tag for use in classifying photos or other data (blog posts, links, etc.). But trying to specify exactly what that tag should and shouldn’t be used for, goes against the grain of the system. It’s a futile effort at best.

In fact, Flickr already has a mechanism for grouping photos with a narrow set of common criteria: groups. It takes a few more steps to submit a photo to a group than it does to tag it, but that’s the price you have pay for increased relevance in this case. There was a group for @Media 2005, but there doesn’t seem to be one for this year’s event yet. If anyone is interested, I’ll create one.

(As a final note, I have to say that I’m absolutely gagging for the new Tags feature in Movable Type 3.3. It’s about time…)