The problem

Treating Ajax as an “all or nothing” technology.

It will take a lot of time and effort to create a “separate but equal” non-Ajax version.

The solution

Progressive Enhancement

Progressive Enhancement in theory

• Begin with content
• Mark up the content in a semantically meaningful way
• Add a presentation layer
• Add a behaviour layer

Progressive Enhancement in practice

• Begin with content
• Mark up the content in a semantically meaningful way (X)HTML
• Add a presentation layer CSS
• Add a behaviour layer DOM Scripting

CSS: inline vs. external

Gotta keep 'em separated

• Inline

  <p style="font-weight: bold">This is an introductory paragraph.</p>

• External

  <p class="introduction">This is an introductory paragraph.</p>

  p.introduction { font-weight: bold; }

JavaScript: inline vs. external

• JavaScript pseudo-protocol - Awful!

  <a href="javascript:window.open('help.html')">contextual help</a>

• Pointless link - Bad!

  <a href="#" onclick="window.open('help.html'); return false;">contextual help</a>

• Using the DOM - Better.

  <a href="help.html"
  onclick="window.open(this.getAttribute('href')); return false;">contextual help</a>

• No inline JavaScript - Best!

  <a href="help.html" class="help">contextual help</a>

External JavaScript function

function doPopups() {
  if (document.getElementsByTagName) {
    var links = document.getElementsByTagName("a");
    for (var i=0; i < links.length; i++) {
      if (links[i].className.match("help")) {
        links[i].onclick = function() {
          window.open(this.getAttribute("href"));
          return false;
        };
      }
    }
  }
}

Unobtrusive JavaScript

Avoid:

• <a href="#">
• <a href="javascript:">
• inline event handlers

Applying Progressive Enhancement to Ajax

“But it's a whole different paradigm — the old rules don't apply.”

“But it's not a website anymore — it's more like a desktop application.”

Why it matters

“It must degrade well. It must still be accessible. It must be usable. If not, it is a cool useless piece of rubbish for some or many people.”

Thomas Vander Wal

The Hijax approach

• Begin by creating a website using traditional page refreshes.
• Data is sent to the server via links and form submissions: the server returns updated pages.
• Intercept (hijack) those links and forms using (unobtrusive) JavaScript.
• Send that data to XMLHttpRequest instead of the server.
• The server returns just the information that's required instead of an entire page.

Server-side requirements

Back-end architecture should be modular.

Web pages are created by joining modules together (e.g. navigation, log-in form, shopping cart, etc.)

[Hint: APIs are very modular]

The paradox

• Plan for Ajax from the start
• Implement Ajax at the end

Pattern recognition

A page that includes a form: when the form is submitted, the same page is returned with just part of the page updated.

• Blog comments
• Registration forms

Example: Contact form (JS)

More pattern recognition

Clicking on a link returns the same page but with one portion changed (different data or different view of data).

• Product ratings
• Filtered result set
• Navigating archives

Example: Shopping cart (JS)

Choosing a data format

• XML + DOM methods
• JSON + eval()
• HTML + innerHTML

  So simple, it's a microformat: AHAH

Keep It Simple Stupid

Use the XMLHttpRequest object like a dumb waiter:

• Send data from the client to the server
• Send page fragments from the server to the client

Client-side processing is kept to a minimum: all the heavy lifting happens on the server.

Example: Sorting tables (JS)

Benefits of Hijax

• No need to spend time and resources building a non-Ajax version.
• No duplication of logic (e.g. form validation).
• Keeps your application logic on the server.
• Keeps your JavaScript file size down.
• Links are spiderable and potentially bookmarkable.