Ajax Asynchronous Javascript + XML: "A Fundamental Shift in What'S Possible On The Web"
Ajax Asynchronous Javascript + XML: "A Fundamental Shift in What'S Possible On The Web"
Ajax Asynchronous Javascript + XML: "A Fundamental Shift in What'S Possible On The Web"
• Renewed interest in networking platforms that are good at dealing with lots of little connections,
perfect for Ajax servers, e.g.
– Twisted, an event-driven networking framework written in Python and licensed under the MIT license.
• A move away from the limitations of Javascript, towards a better language or set of languages: the
.NET framework and CLR show what this direction could offer.
• Architectural styles are derived from technology and drive further development.
– Which comes first, the chicken or the egg?
What is AJAX good for?
• What kinds of applications is Ajax best
suited for?
– We don’t know the full range yet.
– Because this is a relatively new approach, our
understanding of where Ajax can best be
applied is still in its infancy.
– Sometimes the traditional web application
model is the most appropriate solution to a
problem.
Some Example Applications
• Real-Time Form Data Validation
– Form data such as user IDs, serial numbers, postal codes, or even special coupon codes
that require server-side validation can be validated in a form before the user submits a form.
• Autocompletion
– A specific portion of form data such as an email address, name, or city name may be
autocompleted as the user types.
• Master Details Operations
– Based on a client event, an HTML page can fetch more detailed information on data such as
a product listing that enables the client to view the individual product information without
refreshing the page.
• Sophisticated User Interface Controls
– Controls such as tree controls, menus, and progress bars may be provided that do not
require page refreshes.
• Refreshing Data on the Page
– HTML pages may poll data from a server for up-to-date data such as scores, stock quotes,
weather, or application-specific data.
• Server-side Notifications
– An HTML page may simulate a server-side push by polling the server for event notifications
that may notify the client with a message, refresh page data, or redirect the client to another
page.
Who is Using AJAX Now?
• Google is making a huge investment in
developing the Ajax approach.
• All of the major products Google has introduced
over the last year are Ajax applications.
– Orkut
– Gmail
– Google Groups
– Google Suggest
– Google Maps
Developing with AJAX
• Are Ajax applications easier to develop
than traditional web applications?
– Not necessarily.
– Ajax applications inevitably involve running
complex JavaScript code on the client.
– Making that complex code efficient and bug-
free is not a task to be taken lightly.
– Better development tools and frameworks will
be needed.
Developing with Caution
• Do Ajax applications always deliver a better
experience than traditional web applications?
– Not necessarily.
– Ajax gives interaction designers more flexibility.
– However, the more power we have, the more caution
we must use in exercising it.
– We must be careful to use Ajax to enhance the user
experience of our applications, not degrade it.
Potential Drawbacks
• Complexity
– Server-side developers will need to understand that presentation logic will be required in the
HTML client pages as well as in the server-side logic to generate the XML content needed by
the client HTML pages.
– HTML page developers must have JavaScript technology skills.
– Creating AJAX-enabled applications should become easier as new frameworks are created
and existing frameworks evolve to support the interaction model.
• Standardization of the XMLHttpRequest Object
– The XMLHttpRequest object is not yet part of the JavaScript technology specification, which
means that the behavior may vary depending on the client.
• JavaScript Technology Implementations
– AJAX interactions depend heavily on JavaScript technology, which has subtle differences
depending on the client.
• See QuirksMode.org for more details on browser-specific differences.
• Debugging
– AJAX applications are also difficult to debug because the processing logic is embedded both
in the client and on the server.
• Viewable Source
– The client-side JavaScript technology may be viewed simply by selecting View Source from
an AJAX-enabled HTML page.
– A poorly designed AJAX-based application could open itself up to hackers or plagiarism.
Example Dangers
• Not giving immediate visual cues for
clicking widgets.
– If something I'm clicking on is triggering Ajax
actions, you have to give me a visual cue that
something is going on.
– An example of this is GMail loading button
that is in the top right.
• Whenever I do something in GMail, a little red box
in the top right indicates that the page is loading, to
make up for the fact that Ajax doesn't trigger the
normal web UI for new page loading.
Example Dangers
• Breaking the back button
– The back button is a great feature of standard
web site user interfaces.
– Unfortunately, the back button doesn't mesh
very well with Javascript.
– Keeping back button functionality is a major
reason not to go with a pure Javascript web
app.
Example Dangers
• Not using links I can pass to friends or bookmark
– Another great feature of websites is that I can pass URLs to
other people and they can see the same thing that I'm seeing.
– I can also bookmark an index into my site navigation and come
back to it later.
– Javascript, and thus Ajax applications, can cause huge problems
for this model of use.
– Since the Javascript is dynamically generating the page instead
of the server, the URL is cut out of the loop and can no longer be
used as an index into navigation.
– This is a very unfortunate feature to lose, many Ajax webapps
thoughtfully include specially constructed permalinks for this
exact reason.
Example Dangers
• Too much code makes the browser slow
– Ajax introduces a way to make much more interesting
javascript applications.
– Unfortunately interesting often means more code
running.
– More code running means more work for the browser.
– Thus, for some javascript intensive websites,
especially poorly coded ones, you need to have a
powerful CPU to keep the functionality zippy.
– The CPU problem has actually been a limit on
javascript functionality in the past.
– Just because computers have gotten faster doesn't
mean the problem has disappeared.
Example Dangers
• Inventing new UI conventions
– A major mistake that is easy to make with Ajax is:
'click on this non obvious thing to drive this other non
obvious result'.
– Users who use an application for a while may learn,
for example, that if you click and hold down the
mouse on a certain widget that you can then drag it
and permanently move it to some other place.
– But since that's not in the common user experience,
you increase the time and difficulty of learning your
application
• a major negative for any application.
Example Dangers
• Asynchronously performing batch
operations
– With Ajax you can make edits to a lot of form fields
happen immediately.
– But that can cause a lot of problems.
– For example
• I check off a lot of check boxes that are each sent
asynchronously to the server.
• I lose my ability to keep track of the overall state of checkbox
changes.
• The flood of checkbox change indications will be annoying
and disconcerting.
Debugging AJAX Apps
• With this new way of doing things comes a whole bunch
of new problems.
• The main problem is with debugging a page where the
content, presentation, and code can change as the user
interacts with the page.
• With a traditional page, the code is in a JavaScript file,
and when an error occurs, it is relatively easy to track
down where in the code the error lies.
• BUT, when the code is sent up over time in fragments,
and exists only in the memory of the client's computer, it
is a whole different story.
• Determining what the error is, and recreating the exact
steps to reproduce the error is tricky
– And so is determining the source of the buggy code.
Debugging AJAX Apps
• The same is true for the presentation and the content
aspects of the page.
• If there is a problem with the appearance of the page, it
is not as simple as going through the HTML and CSS
code for the page
– the actual data that is being rendered may be drastically different
from the original data.
• Therefore, a new set of debugging tools and techniques
are needed to work with Ajax applications.
• Fortunately, a number of tools currently exist, and are
mature enough to be really useful for solving the
problems that one would encounter when creating an
Ajax application.
Debugging AJAX Apps
• XMLHttp Debugging
– Microsoft Fiddler
– Spike Proxy
• JavaScript Debugging
– Venkman
– Microsoft Script Debugger
• DOM Debugging
– Firefox DOM Inspector
– Microsoft Web Developer Toolbar
– Mouse Over DOM Inspector