Meet Achilles

Achilles is a tool that sets out to solve a daily problem in web development: how can a site offer both dynamic user experiences and the robustness of static pages without the developer having to repeat herself? Maybe you’ve seen it go by on twitter or toyed with an early release from the sparks repository. We’re still a little ways out from a stable release, but it’s time for Achilles to start meeting the world.

It’s a dilemma

Mobile devices and the narrow pipes that bring them the internet do quite well with static HTML sites. But they can do even better (at least, once the initial footprint is loaded) if their content requests are met only with the page fragments they actually need. Script-based acceleration is becoming a must-have for content-heavy mobile sites, but it also requires developers to provide explicit pathways for requesting and delivering specific fragments of content.

The opposite issue arises when an assistive technology (think screenreaders) chooses for one reason or another to ignore the dynamic elements attached to a page. With a good fallback this is no issue, but if the website dependend on Javascript to deliver information a homepage can immediately become a total dead end.

Accessibility by design

Developers typically manage these scenarios with one of two buzzwords: “progressive enhancement”, where applications are developed to support nearly everyone then enhanced where advanced features are available, and graceful degradation, where applications are built to the most current specs but augmented with “graceful” fallbacks for unsupported features. Skipping the lengthy debate on the merits of the two, their common ground is in the significant expenditure of effort they require from their practitioners. Inefficient, repetitive, and annoying—everything a developer wants to avoid.

It doesn’t have to be that way.

Think of Achilles as a framework for progressive enhancement. It isn’t pixie dust that can be smattered on a website to turn it mobile or make it accessible overnight, but (if used appropriately) it can help applications easily meet multiple audiences’ needs at once. It isn’t the right tool to use for a Javascript-driven application, nor for a site consisting solely of static HTML. But in the no-man’s land between the two, it can eliminate repeated effort and significantly speed development. Here’s how it works:

How it works

Achilles uses the same code to process requests no matter where they originate. By envisioning websites as a granular collection of content and providing tools to remix them according to each client’s needs, the same views and controllers in the MVC model that handle static requests can be easily adjusted to deliver data asynchronously as well. Check it out:

// SomeKindOfController.php

public function index () {

    $myviewfragment = $this->load->view('myviewfragment', $mydata, true);

    if ($this->achilles->use_achilles()) {
            ->flush(); // output ends

    $data = array(
        'fragment' => $myviewfragment

    $this->load->view('layout', $data);

See what’s happening? If Achilles is the originator of the request ($this->achilles->use_achilles()), then it is also given an opportunity to respond. Achilles’ system consists of two parts. On the client-side, a single script (achilles.js) is responsible for interpreting responses and acting on them. Take a closer look at the response that achilles sent:

    ->flush(); // output ends

This snippet sends the client-side script instructions equivalent to the following:

$('#fragment').replaceWith('<div>some content</div>');

It’s jQuery, plain and simple, dynamically generated by the server and executed without an eval() in sight! Rather than hurting maintainability by cluttering views with one-off snippets of javascript, achilles provides a simple interface for calling client-side libraries directly from the server. And if Javascript isn’t available, the same response will simply be returned inside a static layout.

Getting started

Achilles is currently available as a spark for Codeigniter, and installation information is available on the project site.

The spark’s source code is hosted on Github, and community contributions are very much encouraged. Love it? Hate it? Have comments, suggestions, or requests for the future? All lines are open.

Additional Resources