Gmail and Talk have been having some trouble again. It’s been slow more often than not and I captured a few more *error modes*. Today I saw Gmail chat recover 
with this little gem. Hey at least they recognized they are back. Seems I’m not the only one who has had trouble with gmail recently.
Gmail greeted me with this screen for a couple hours today.
Seems now that the day is over things are back to normal and Gmail is happy. Well tomorrow is another day… we’ll see how the big G holds up.
ProgrammableWeb.com now has over 500 mashups listed.
As shown on Mashup Feed the average new mashups per day is up to 2.81. And that is just those added to the database here. This is up from 2.6 or so just about 8 weeks ago.
So looks like it may hit 1000 before the year end.
JSONRequest has been proposed by Douglas Crockford as a new native method for web browsers to exchange data with servers. The biggest notable difference with XMLHttpRequest is that it doesn’t prevent requests to multiple domains. JSONRequest can make requests to any server, not just the origin server like the current XMLHttpRequest. Web applications today that need to make cross-domain requests must use a proxy or a dynamic script tag to make requests to non-origin domains.
JSONRequest also has provisions for long lasting server initiated, live push of data. Crockford calls this “Duplex”.
“JSONRequest is designed to support duplex connections. This permits applications in which the server can asynchronously initiate transmissions. This is done by using two simultaneous requests: one to send and the other to receive. By using the timeout parameter, a POST request can be left pending until the server determines that it has timely data to send.
Duplex connections can be used in real time notification applications such as process management and finance. It can also be used in collaborative applications such as instant messaging, instant email, chat, games, presentation, and shared applications. “
Alex Russell calls this same server-push technique Comet. I actually like Comet a bit more than Duplex. Duplex is a bit overloaded with a few other uses in tech. Like the half or full duplex with configuring network cards or terminal echo. Not as if I have a vote(just like AJAX sotra stuck), but let’s hope Comet wins.
Douglas Crockford knows a thing or two about compressing JavaScript. He wrote JSMin which IMHO is the simplest and fastest JavaScript minifer out there today. Coupled with his lint checker JSLint you’ve got two really good tools to write good solid code. I used JSMin to optimize digg.com’s homepage a few weeks back. As more and more AJAX apps start to take advantage of JavaScript the size and footprint grows dramatically. Even more so when folks import the various AJAX toolkits as a starting point. This means that tools like JSMin become a required part of the build/deploy process for those that are serious about optimizing end-user experience. There are other excellent minifer tools out there including Alex’s ShrinkSafe which is based on Rhino. ShrinkSafe takes an aggressive approach to not modifying the API’s as it uses a real JavaScript compiler/run-time to shrink the code. This is important when you don’t want your public API to change as is true for any JavaScript toolkit developer. Crockford makes the point that obfuscation is really just a small hurdle and any serious programmer, given time can extract the useful bits. This is especially true for JavaScript where no matter how much mangling of the code is done before it’s sent to the browser it’s still sent in plain text. So it’s trivial to attach a debugger like Venkman and walk through each line of code. Glad to see Douglas putting focus back on JavaScript as noted by his many recent updates to JSLint and now his first blog entry on the Y! UI blog. I’d also guess that Yahoo’s focus on JSON for their REST api’s is in part due to Doug joining them.
ref: Minification v Obfuscation » Yahoo! User Interface Blog
Microsoft’s Origami which many are calling the iPod killer is planned to launch at CeBIT. YouTube has a good video which explores some Origami features. The official Origami site is a page right out of Apple’s book. Just enough hype to keep you coming back for more. Reports are that it will run Windows XP, Tablet PC Edition. Intel is expected to reveal more information next week at their developer conference here in San Francisco.
I’ve noticed a few errors in gmail’s new chat interface. The gmail quick contacts are not always up-to-date. Just yesterday I got this this error message:
It’s a new service, so not too surprised that chat is seeing a few bumps. In fact it’s expected. I remember the first few versions of meebo(a web based chat interface for Yahoo, MSN, AOL, and Jabber), and the problems they ran into. One positive aspect of the chat problems are that gmail is unaffected. Email continues to work and is performing well. They’ve integrated it in such a way that quick contacts can fail or be unavailable (like above) but fail gracefully. Many popular web apps, even recent web 2.0 and AJAX apps don’t seem to be designed this way. They fail and fail completely. Designing AJAX apps that can handle partial failures is hard. Many of these app have deep callback stack to get the JavaScript to perform and work seamlessly. There are parallel asynchronous java script calls that need to be requested and handled in whatever order the server responds. So each piece of functionally needs to be carefully crafted to be independent and self sufficient. You need to think about how your app will act if it fails, or worse partially fails. Can it continue to work if it misses a server response or two? Can it error gracefully and continue to work when only a partial set of server functionality is available? This is especially important for companies building desktop replacement applications in which users will rely on for their day to day or even hour to hour work. So take a note from gmail and talk, build apps that are robust to temporary failures. If partial server functionality is available continue to process work and user interaction on the rest of the app. Gracefully poll the server checking for when the full functionality is returned. The error above recovered on it’s own without a reload or restart of the webapp. Impressive to say the least.
On a side note, Gmail itself has been rock solid for me ever since I started using it in June 2004. The spam filters are pretty good, but not perfect (more on that later), and it’s hard to beat the speed of the interface. It’s not the most feature rich mail or collaboration implementation out there but for a small mail volume it does a good job. Works perfect for my personal mail (40-50/day), but I’d have a hard time using it as my primary webmail client for work(200-300/day). I just get too much mail each day for gmail to be useful. It’s missing a few key features to manage extremely large daily mail volume. Saved searches and IMAP support being the first two that come to mind. I need a way to quick search on the same data multiple times a day. Labels work well to automatically categorize and simulate folders but can’t replace a rich search with the option to save. IMAP is a must have for off-line access. POP just doesn’t cut it when you want the server to be your *master* mail store.
Put together an AJAX demo using Amazon’s webservice API. Basically type in an artist name or song title and it’ll return the first 10 hits from Amazon’s music search. It’s using script.aculo.us for the ‘Grow’ effect when the results return. the search itself is triggered via java script, and parsed locally. The result also triggers a contextual AdSense ad. Tried a few different ideas and seems an embedded iframe worked best. My goal was to make it work without a page reload. So to get an AdSense ad that is contextual to the search I needed to generate a url and title string from the query itself. Anything else seemed to lead to generic ads. I’m sure there are ways to improve on it. If you’ve got an idea leave a comment!
First YubNub Suggest example used script.aculo.us. This time tried Dojo’s autocomplete code. Smoother auto complete, including support for arrow keys, but has a harder time selecting an option. Doesn’t seem to like space as a keystroke selector. You can try it out for yourself.
Ran into an interesting problem with JavaScript’s Array.toString() in Firefox. It’s extremely slow even for a very small array. Take an array with a single object and you’d like to call toString() to get the type of the contained object. There are better approaches but for simple uses this might be applied. In this case toString() of the underlying object simple returns the object’s name. This is a very common use of toString() on custom objects. In Firefox calling toString() on the Array is nearly ten times slower than calling toString() on the object itself. In Internet Explorer it’s about three times slower. Needless to say be very careful with JavaScript’s Array.toString(), as it’s not a transparent call into the underlying objects performance wise.
Internet Explorer 6
anArray.toString() – 1829
anObect.toString() – 625
Firefox 1.5.0.1
anArray.toString() – 3093
anObect.toString() – 375
The full test script is posted below.
var anArray = [];
var anObject = {};
anObject.toString = function() {return “anObject”;};
anArray.push(anObject);
var startTime,endTime,i;
var repeat = 250000;
startTime=new Date().getTime();
for(i = 0; i < repeat; i++) {
anArray.toString();
}
endTime=new Date().getTime();
var arrayToStringResult = endTime - startTime;
startTime=new Date().getTime();
for(i = 0; i < repeat; i++) {
anObject.toString();
}
endTime=new Date().getTime();
var objectToStringResult = endTime - startTime;
document.write("anArray.toString() - " + arrayToStringResult);
document.write("<br/>");
document.write("anObect.toString() - " + objectToStringResult);
Few sites these days are using AJAX Auto Complete to help users filter known choices or reduce typing. As more AJAX libraries are released this practice should appear more frequently. Autocomplete generally comes in two flavors; Local Auto Complete and remote or server based auto complete. Local auto complete loads all the data locally into memory and then parses/pages through the data entirely in JavaScript. Server based auto complete like Google Suggest send async queries to a server as the user types. Local autocomplete works well when the entire data set is small enough to process at once think hundred’s or thousand’s or items. Ten’s of thousands may be possible depending on how complex the data and what type of matching is used. Prefix matching requires less processing that a full search for prefix, sufix, and contains matches. The Yahoo UI Team has posted a design pattern on Auto Complete and plan to release code as part of their UI Library. script.aculo.us includes support for both Local and Server autocomplete. They have a few demos posted that you can try yourself.
UPDATE: A couple demo’s of my own:
