To understand what aspects of a Web application you need to improve, you must properly analyze the components of the application. This article looks at how you can use the Firebug extension to Firefox and the YSlow add-on to instrument a Web application. After you install these tools, connect to the site that you are developing and click YSlow on the Firefox status bar. This opens the YSlow interface in Firebug. Now click the Performance button. YSlow performs an analysis of your application and provides a report on the different parts of the network transfer time of your application, as Figure 1 shows.
Most of the concepts mentioned are derived from the 10 rules defined by Yahoo! for better web application performance but Kristopher breaks down some of the concepts into examples and provides explanation on how to interpret the data. The explanation of the FireBug profiler is especially helpful to those just coming into the Ajax development space and want a better understanding of how to optimize their code:
John Resig put together a nice overview of the ARIA Live Regions specification with an example of how you can track a list of people in a way that a screen reader can understand when someone is added or deleted. Imagine a todo list application.
aria-live="polite" How polite the live area is (as in, how likely is it to butt in to what the user is currently listening to/interacting with). The default is 'polite' - in that it waits until all forms of user interaction have been completed before describing the updates to the user.
aria-relevant="additions removals" Only notify the user about new node additions and removals. Since we wish to provide the user with a live list of users we can expect them to be both transitioning online and offline - this will give us the appropriate level of updates to make this possible.
wishes to know more about what the contents of the field represent this element can be read to them.
Firefox supports this right now (as of 2.0) and we covered AxsJax the toolkit that helps you implement these features, which Google Reader uses to get the job done.
I really liked getting the Ajax Language API out into developers hands as god knows we shouldn't have to worry about translations. Now we can use the API and have the Google back-end do all of the work.
I have recently had a couple of scenarios where I really wanted a quick translation. I had a few twitter messages pass through my stream in French and Spanish. I had the answer to some technical issues show up on foreign forums.
So, I decided to create a Translate bookmarklet that allows me to select any foreign text, click on the bookmark, and a little window pops up with the English translation if it can work it out. Automatic translation is far from perfect yet, but for many scenarios you can easily get the gist (e.g. you wouldn't want to automatically convert a book).
This is how I created the bookmarklet:
The source
First, I have the raw JavaScript source that will become the bookmarklet. There are a few sections of the code. First, we setup a method that will go off and call the Ajax Language API, passing in the translation and language that we want. This is where you would change the language code for non-English.
alert('No translation found for "' + text + '" guessing the language: ' + dresult.language);
}
});
}
});
}});
}
};
}
Then we setup a method that is able to display a window showing the result. I used the Prototype UI Window object if available, and good old alert() if not:
Finally, we load the Google API loader, and use the dynamic loading option with the ?callback=apiLoaded. This kicks off the main driver that we saw first, and if it is already loaded we call it directly (for multiple translations on the same page).
This is the raw form, and we need to get the bookmarklet form, which you can just use right away if you are wanting English. For this, I use John Grubber's makebookmarklet Perl script to do the conversion.
The Server
The Prototype UI code lives on the server, so I put a striped down version over there which just contains a combined Prototype + Window JavaScript file, and just the one theme CSS set.
In Action
Unsure what I am talking about? Just watch it in action:
I also saw that Mibbit, the Web based IRC application has a new "translate" function that auto translates in the chat rooms. It works two way, so you can go into a foreign channel and be seen to just be a bad speaker as you convert their words back.
Following discussions at the Highland Fling conference with the audience and Gareth Rushgrove (whose excellent presentation on API design we featured here already) I sat down and came up with a wishlist for a great Ajax API.
As an example I used the Google translation API, pointed out its good points and explained what I'd love to see added to it. Specifically any JavaScript Ajax API to me should have the following:
Have a good documentation with immediate copy and paste examples backed up by a full class documentation
Build your APIs modular and allow the implementer to choose the version they want to have
Provide a hook to link the result of the API methods to the initial data entered. The easiest way is to repeat this data, more sophisticated is to allow for a connection ID.
Allow for multiple values to be sent through, it’ll save you API calls and the implementer hacking around the problem of unreliable order of returns.
Allow implementers to add an own object to send and get back to allow for namespacing and other data state retention.
Allow for a timeout, connections are not to be trusted.
With the YouTube API recently released, there's bound to be lots of cool controls coming out soon. Thorsten Suckow-Homberg spent a weekend hacking up a Ext-based user extension that leverages YouTube's chromeless API to build The Ext.ux.YoutubePlayer.
The Ext.ux.YoutubePlayer allows developers to embed youtube videos into Ext applications, using native Ext components for controlling the video playback. It’ll show the buffer status and let’s you jump to any part in the video using a slider component.
Cool features include:
Showing the buffer status
Playback slider that let's you jump to any position in the video playback
When Jay Salvat set out to build markItUp!, he wasn't trying to build the next FCKEditor or TinyMCE. He just wanted to build a simple editor that could allow developers to add enhanced markup capability to textarea elements.
markItUp! is a JavaScript plugin built on the jQuery library. It allows you to turn any textarea into a markup editor. Html, Textile, Wiki Syntax, Markdown, BBcode or even your own Markup system can be easily implemented. markItUp! is not meant to be a “Full-Features-Out-of-the-Box”-editor. Instead it is a very lightweight, customizable and flexible engine made to meet the developer's needs in their CMSes, blogs, forums or websites. markItUp! is not a WYSIWYG editor, and it never will be.
The usage is very straightforward. The following code demonstrates the ease of using markItUp!:
As the title asks, will IE8 & HTML5 make Really Simple History (and other Ajax history managers) irrelevant? Not so much says Brian Dillard, project lead for the Really Simple History project. While additions to HTML 5 & IE8 will definitely make managing page history easier, Brian anticipates that libraries such as RSH will evolve into tools for handling session data, especially as offline storage tools mature:
Other browsers will still require polling and other browser-specific hacks. Even after all browsers support the hashchange event and all non-supporting browsers fade into obscurity, Ajax history management will still play a role. For one thing, we'll still need a mechanism for our Ajax apps to associate state information with a given hash value (assuming, of course, that the hash token itself doesn't contain all the state information you need).
Right now, RSH accomplishes this with a hidden textarea. In the future, though, offline storage mechanisms will probably play the textarea's role. Once we get to the point where offline storage and the hashchange event are universal standards, Ajax history management will morph from a collection of hacks to a collection of convenience methods for native browser capabilities. Let's hope that time is sooner rather than later.
His thought seem to be on target and I think that apart from handling state information, RSH will eventually fill the holes that hashchange leaves behind.
Nitobi ran a survey on Ajax technologies, and you (Ajaxian community) helped out in giving them your feedback.
They just released the results which consists of 570 answers. You must always take results with a grain of salt, since there are quite a few more designers and developers than 570 our there, but it is always fun to analyze. Often the results tell you more about the niche of people that the surveying group has access too than the global truth (e.g. the Ajaxian group skews to a slightly more advanced user base that doesn't mind getting dirty).
The responses that called out to me were:
Which development platforms are you using?
Java and PHP took the server side piece home (many said they were HTML/CSS front end folks). If you aggregate the Java technology (Java, JSP, Servlets, JSF) you get 394 versus PHPs 296, although it is hard to compare since you could choose "all that apply". I am willing to bet that if you are doing JSF now, you may well have done Servlets, JSP, and other!
Which development tools do you use?
Eclipse and Dreamweaver had the most votes here, with a large number of Notepad people (teasing?). Textmate was that low?
What causes you the most pain in designing and development websites?
Browser compatibility: 303
Testing: 114
Javascript: 65
CSS: 36
Deployment: 34
Why do you choose to use Ajax?
Improve user's experience: 276
I want to build slicker applications: 38
Easy to use: 29
My boss wants it: 25
Saves time: 13
Saves money: 2
What toolkits or frameworks are you using in your projects?
This was quite a different result than from our last survey.
We all have bits of reusable code that we store in some fashion. These snippets prove to be invaluable at helping to not "reinvent the wheel" so storing them in a safe and convenient place is important.
The MooTools team wants to make it easy for you to store your snippets easily through the use of their new Adobe AIR application, Snippely. Using the MooTools JavaScript library and the AIR SDK, Valerio Proietti and Tom Occhino created a desktop application that allows easy storage of both code snippets and notes about the code.
When we were thinking about what type of application to make our AIR playground, we tried to think of something that we'd want to use ourselves. Valerio and I are notorious for storing countless bits of code in all sorts of different languages all over our hard drives, and thought it would be nice if we had a central place to store and organize those bits of code. We came up with the idea of 'snippets', and an application called Snippely.
The nice thing about this is that they've designed Snippely so that you can organize snippets by groups and that a snippet entry can consist of multiple snips or notes.
Finally, those looking to get into AIR development will certainly benefit from the fact that the Moo team has released the app as an open source project under an MIT license. The code for Snippely is hosted on Google Code and is available for you to review.
Working client-side with data can be challenging and projects have tried to address this in differentfashions. Ian Smith, creator of Joe's Goals, has his own approach. He's created Taffy DB, a lightweight Javascript database
that allows you to insert, update, delete, order, loop, and query against a client-side collection of data. The great thing about it is that it's library agnostic and can work with all of the popular frameworks.
The idea came to me as I was working on Joe’s Goals 2.0 and I realized that one of the hardest parts about building any Web 2.0 application is working with data. There is no good way to use JavaScript by itself to gather, search, and maintain a collection of data. There are lots of great ways to great interfaces now days, but what about the data behind them? Taffy DB is the result of the research and testing I did for Joe’s Goals and is now avaliable for everyone to use.
Some of the key features include:
Under 10K!
Simple, JavaScript Centric Syntax
Fast
Easy to include in any web application
Compatible with major Ajax libraries: YUI, JQuery, Dojo, Prototype, EXT, etc
CRUD Interface (Create, Read, Update, Delete)
Sorting
Looping
Advanced Queries
The syntax to use the libary is very straightforward:
In addition, Taffy DB provides 12 different conditional statements (e.g.: "greaterthan", "equal", "like") to help build advanced queries that can further filter your results.
Ian has created a Getting Started Guide which will help in getting up to speed on the full capabilities of Taffy DB.
