”When the heck are you guys going to open registration for The Ajax Experience this year!?”
Over the last 3 months that is, without question, the most frequently received email we’ve had from Ajaxian members like you. The good news is that the wait is finally over! Registration has officially opened for this year’s Ajax Experience conference and best of all, we’re offering you $300 off when you register by July 31st. Check out our just-launched Web site right here for all the benefits we have lined up for you this year: The Ajax Experience, September 14-16 in Boston, MA
Please Note: While we’ll be adding the bulk of our sessions to our individual conference tracks over the next few weeks, we want to be sure you take advantage of the early-bird discount now. That said, we’ve once again confirmed today’s best and brightest Ajax minds from across the globe and we’re featuring a number of these keynote presenters and session experts for your review on the site right now, including:
* Ben Galbraith and Dion Almaer, Co-founders of Ajaxian.com
* Brendan Eich, Creator of JavaScript and CTO of Mozilla
* Douglas Crockford, Creator of JSON and Author of JavaScript: The Good Parts * Bill Scott, Director of UX at Netflix
* Ross Boucher, Co-founder of 280 North and the Cappuccino & Atlas frameworks
* Joe Walker, Creator of DWR
* Nicole Sullivan, Creator of Object-Oriented CSS
* David Wei and Xiang Chaong, Research Scientists at Facebook
* And more!
More essential speakers and sessions to be announced in the coming weeks, so stay tuned and start planning. One feature we think you’re going to love this year is “session previews.” Each morning we’re featuring 5-minute lightning rounds where presenters entice the audience to attend their session by giving them a brief synopsis of what they will learn. Now you’ll have even more exposure to new, cutting-edge technologies and proven solutions - and a better idea of how to spend your days.
Don’t delay, register now for The Ajax Experience to take advantage of your $300 early bird savings.
Micah Snyder of Digg posted on DUI.Stream, an experimental library that implements a multipart XHR technique to bundle resources into one request and then breaks them out at the other end:
One of the ways that high-performance websites like Yahoo suggest speeding up load times is by reducing the number of HTTP requests per page. We started thinking about what we could do to reduce HTTP overhead, and where we could get the biggest benefits from it. Well, one thing led to another and the next thing we knew we were talking about writing a generalized framework for bundling files, sending them through a single request, then separating them for use once they head down the pipe.
We call this technique MXHR (short for Multipart XMLHttpRequests), and we wrote an addition to our Digg User Interface library called DUI.Stream to implement it. Specifically, DUI.Stream opens and reads multipart HTTP responses piece-by-piece through an XHR, passing each chunk to a JavaScript handler as it loads.
Why do this? Well, DUI.Stream will allow developers to drastically improve the speed of uncached page loads by bundling most of their resources into a single HTTP request, with a single time-to-first-byte and no request throttling by the user agent. Additionally, the size of the response has no effect on the rendering time of each chunk, as the client handles each piece of the response on the fly and can inject it into the DOM for rendering immediately, in the exact order you specify. On a high traffic, high-activity site like Digg, we have to display incredible amounts of data on each permalink — typically hundreds of user images within the first 50 comment threads on a page alone, not to mention the UI chrome and actual comment data. (You can see this for yourself: notice the number of HTTP requests that queue up when you expand a page of comments). So our primary use case for DUI.Stream is turning that first long, arduous page load on an empty cache into something nearly indistinguishable from a page of data with fully cached resources.
You can take a look at a demo in action. Reloading the puppy shows how life varies so much on each request. The demos looks like this:
Let’s talk a bit about the architectural benefits of implementing MXHRs with DUI.Stream. Back when the web was based largely on a page metaphor (i.e.: one central document with external references), whenever you loaded the page, the page requested its images, stylesheets, etc, then you were done. These days you’re just as often loading an application; the page progressively enhances into a stateful UI by loading extra stylesheets, scripts and a whole mess of UI chrome after the initial request. Yet, we’re still using the old model flow of get markup –> render markup –> request external resources –> load and display externals.
Take our modal login dialog box for example. In order to reduce requests we bundle its JavaScript in with the rest of the page, we put its CSS up in the header with the rest of the styles, then we request only the markup for the dialog box, render it, and let it fire its own HTTP requests for the images that make up its chrome. In this broken model, HTTP connections and rendering behaviors split our UI architecture up into different parts of the page that all render at different times at the browser’s discretion. Even if we put everything into one cohesive structure and loaded the CSS link, script tag and markup together, they’d still all fire their own HTTP requests and the images would still come in afterwards on the first page load. This just won’t do.
Now, let’s rethink how our login dialog could work using DUI.Stream. We can request a Stream that contains everything needed to render and use the dialog box. As each part comes in, it gets passed through to be built, and renders immediately with no image backfill or delayed JS behavior. The DUI.Stream framework can then pass those resources back into cacheable elements for our next page load, which can happily 302 its way quickly through the rendering process. Pretty sweet right? Right.
Why choose which Ajax framework you can use, when you can let The Machine tell you! Jim Briggs of Athenz has pointed his decision machine at the age old problem of choosing which darn library to script src!
Here is what Jim told us about the new service:
There has been some discussion lately on Ajaxian about “What is the best framework?” As Dion said in another post, “It is agonizing. It is hard. It isn't pretty.” Both newbies and gurus have weighed in on the subject. As a Ajax programmer, the issue is personally important to me, but rather than cast out another opinion, I’ve created a web site, The Ajax Frameworks Decision Center, that allows anybody to evaluate and select the Ajax or RIA framework that best meets their particular needs. The Decision Center includes a 100-plus requirements model, tools to prioritize, compare, and evaluate frameworks, and a 35 page guide that elaborates on the requirements and the features that you find in frameworks.
In addition, anyone can publish an evaluation of any framework and vendors can publish product information inside the Decision Center. All of this is free.
Objectively, the choice of a framework can be difficult. Subjectively, the choice can be agonizing. The Decision Center doesn’t eliminate all the difficulty, but it provides a way to make a good and justifiable decision and feel confident about it in the end.
This is a brand new service and I’ll respond quickly to any feedback so I can make the site better and so I can help you make better technology decisions now and in the future.
Or see it at work:
You have to signup to check it out, and it may feel like you are filling out a TPS form ;)
Matt Raible has posted on the analysis the he has done for a client on choosing an Ajax framework. This is the age old question "which Ajax framework should I use?" It is agonizing. It is hard. It isn't pretty. We created a dartboard:
Matts take compares Dojo, Ext JS, GWT, and YUI using various criteria that you can see here (including his ratings):
What you quickly see is that it is fairly hard to choose between the popular frameworks (and this is a specific subset that was narrowed down, hence no jQuery, Prototype, Mootools, etc).
I am interested in seeing what other criteria people use to choose.
Launched in June, 2007, AjaxRain.com has continued its steady growth of aggregating awesome extensions for the popular JavaScript frameworks. It was a late starter coming after the popular site MiniAjax but while MiniAjax unfortunately stopped updates, AjaxRain continued loading up with top scripts from around the web. Currently listing 1200+ scripts, it has become the starting place for finding cool features to leverage in your apps.
Looking at the jQuery, MooTools & Prototype categories you can see a wealth of options for all types of functionality.
They've also just updated the site:
Enhancing the UI
Improving advanced search options to increase discoverability
Tags for every aspect of UI design
In addition, they've now started to leverage Twitter and Facebook to spread the word about new scripts.
Finding good scripts is tough as it is with so many being hosted all over the web. So it's good to see a service which is offering to wrap all of these up in a nice centralized manner.
We're seeking a few good technologists and speakers for The Ajax Experience 2009, to be held in Boston on September 14-16, 2009. If you have experience with frameworks, techniques, or technologies that drive high performance Web applications, or build frameworks or other tools to enable the creation or test of Ajax applications, take a look at our call for papers to see where your talk may fit in.
Please click here for more details on what we're looking for and how to submit your proposals. Here is the official submission form. Deadline for submissions is April 1st.
I enjoy the US show Chuck (maybe because a geeky guy gets to hang with a beautiful woman? :) and there is a 3D episode to launch their new season. Our 2009 Ajax season relaunches an old favourite meme, the Ajax loaders (e.g. ajaxload.info) with a new 3D special.
Timur Gafforov has given us Preloaders which allows you to select size, speed, and from a set of 3D spinners. Make your users wait in style! :)
He talks about how some frameworks have code paths for specific browsers to shorten the if (foo) type overhead. Having a compile step like GWT does makes this easy. TIBCO GI "builds an optimized code tree for each major browser release (the opposite of the approach jQuery 1.3 and others have taken, as code only makes it into a build for that browser if that browser is known to support that functionality)."
excludeStart(”webkitMobile”)
Dylan then discusses what is happening in the Dojo community:
In recent discussions on the Dojo mailing list, discussions turned to how to make Dojo faster for mobile users. In most cases, this involves removing code and features that are not needed on that platform given the precious resources available on mobile devices and over mobile networks.
Alex Russell checked in some work he started last year that looks like this:
While we would love to switch to pure feature detection over browser version detection like John has done with jQuery 1.3, version detection is generally more concise and precise, and does not necessarily make Dojo any less forwards compatible.
Version detection also makes it easy to exclude code created solely for browsers that require major workarounds, such as IE 6. To get the most out of this though would require doing something similar for each major browser, which would make Dojo more challenging to understand and maintain, would probably require a build step even during development (not just in production to improve performance).
At this point, there are no clear answers, just a lot of questions on how to create a toolkit that offers edge of the web features for desktop users, and still preserves performance for mobile web users. What approach do you think is best?
John Allsopp has a thoughtful piece that races some old concerns about the new tag set in HTML 5, and how we will ever be able to jump on that train when the cabooze still has IE.old train cars.
It is great to have new semantics for <section> and all, but what will browsers do with these new tags?
John walks through a simple example with the new tags, shows some issues, and then wonders if we could use the existing extension points (attributes):
Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:
<div structure="header">
Let’s see how our browsers fare with this.
Of course, all our browsers will style this element with CSS.
In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.
John then goes on to discuss the potential use of the role attribute, and more.
It feels like there are two issues here:
Are new tags the right way to provide new semantic value
Are there work arounds to back/forward compatibility.
Without compatibility, it will be impossible to get this off the ground for many people. What if we mix both worlds, and a shim is put in place to convert the new tags to divs and the like at runtime for browsers that don't support it. Is that enough?
It comes to the age old issue of how "desktop-y" do you make your Web application? Herb believes that having them look like desktop apps is natural. I think that I disagree. I like Gmail because it is a great blend of web-y and desktop-y. In fact, it is more like pine on the Web than Outlook on the Web :)
The best applications seem to nail that blend of both worlds. What do you think?
This is Herb's conclusion:
Most SaaS/Web 2.0 applications today look and feel pretty much the way GUI applications looked and felt like on DOS, before technologies like Windows and OS/2 PM existed. Around the late 1980s, people wrote lots of GUI applications that ran on DOS, but we didn’t have a widely-used common GUI infrastructure that handled basic windows and menus and events, much less standards like CUA that tried to say how to use such a common infrastructure if we had it. So they each did their own thing, borrowing where possible from what seemed to work well for GUIs on other platforms.
Twenty years ago, everyone writing GUIs on DOS designed the UIs as best they could, borrowing where possible from what they saw worked on platforms like the Macintosh and Xerox Alto and Star — but the results were all over the map, and would stay that way until a standard environment, followed by standard guidelines, came into being.
Today, everyone writing rich Web 2.0 applications is doing their own thing, borrowing as best they can from Macs and Windows and others — but the results are all over the map, and will continue to be until there actually is such a thing as a UI standard for rich-GUI web applications. You can see that in the differences between Zimbra and Outlook Web Access. In the meantime, it’s not just okay to borrow from what we’ve learned on the desktop; it’s necessary.
And the question isn’t whether metaphors users already understand on the desktop will migrate to the web, but which ones and how soon, because it’s the whole point of SaaS. The industry will soon be going well beyond Google Apps; with offerings like Office Online already announced for the short term, which puts still more rich-client GUI apps like word processors and spreadsheets in the browser (with functionality somewhere between Google Apps and the desktop version of Office).
Zimbra and Outlook Web Access aren’t examples of poor web app design, but exactly the opposite: They’re just the beginning of the next wave of rich web apps.
I am proud to be able to announce the new currency converter on Yahoo finance. Why? Because it is a perfect example of how a complex rich user interface can be built in an accessible manner.
About 9 months ago my fellow co-worker, the User Experience Designer Graham Beale, and I started developing ideas for a prototype of a new Currency Converter for the worldwide relaunch of Yahoo! Finance.
We wanted Features we haven't seen like this in the Internet so far. We wanted conversion without a page reload, searching for currencies like in the Firefox 3 "awesome bar", total accessibility, much more and of course everything in realtime.
There will be an in-depth article on how Dirk and his colleagues (with a special mention to Artur Ortega who did all the screen reader testing) build the converter on the Yahoo Developer Blog after the holidays. For now, have a look at the code and see the wonderful attention to detail. One of the main tricks they've done can be mentioned already: dynamic re-writing of form labels.
Most everyone knows that Google has really stepped up to the plate by helping many JavaScript library projects host their builds on the Google AJAX Libraries API. Apart from providing a central distribution point for these libraries, the bandwidth cost savings alone go a long way in helping frameworks service their users in a sustainable manner.
Thanks to Vadim Spivak at Google and Dion Almaer (now at Mozilla) for helping to make this additional option available to the YUI developer community. We love that Google is supporting web developers in this way — grabbing YUI files from Google’s global infrastructure is a fantastic option to have.
This is great news for YUI developers who now have a choice of linking directly to YUI via yui.yahooapis.com and ajax.googleapis.com. YUI team lead, Eric Miraglia, has a great write-up on the YUI blog about this and goes into detail on how the framework's users can take advantage of this new hosting option.
jQuery and Amazon CloudFront
With nearly 2.5 million requests per day to the jQuery website, the jQuery project team is constantly on the look out for ways to decrease hosting costs while still managing the growing number of requests for the site's resources. Originally leveraging Amazon S3 for many of their static pages, the project has now turned to Amazon's new CloudFront CDN. The change has allowed for jQuery pages to be globally hosted as opposed to being centrally located in Amazon's Seattle-based S3 hosting center.
In tests, John Resig, team lead for the jQuery project, noticed substantial performance gains based on the switch:
I ran a similar test here in Boston and even managed to see a large improvement. I was seeing latency of anywhere from 50-200ms on Amazon S3, but only a latency of 17-19ms with CloudFront.
What does all of this mean? It means that the jQuery site is going to load even faster than it does now. We already receive some excellent hosting from Media Temple but being able to off-load these static files to the fast-loading servers will only make for a better browsing experience.
In less than 24 hours the project had received almost 2.5 million requests for over 50GB of data. The only drawback is an increase in bandwidth costs but still substantially less than that of a traditional hosting plan. The jQuery project makes use of the Google AJAX API as well and recommends it as choice for linking to the jQuery and jQuery UI libraries.
The hosting is free and what makes it unique to something like the Google CDN is that it allows Ext developers a central access point for their own custom builds.
We are pleased to announce that Ext has partnered with CacheFly, a global content network, to provide free CDN hosting for the Ext JS framework. Cachefly’s globally distributed network and aggressive caching accelerate the delivery of web content like JavaScript and CSS, making for an even faster Ext experience.
In recent presentations, Ben and I have been taking a look back on the rise of Ajax (where Ajax == popularity of dhtml :). At its core, I think it all comes down to UI responsiveness.
When you look at the killer apps such as Google Suggest and Maps, they broke through a set of myths on the Web.
Latency is the killer issue on the Web
We are used to autocomplete in fields and forms these days. However, if you think back to when Google Suggest came out, if someone had asked you whether it was a good idea to do a background request on each key press you may think they were insane. The beauty of suggest is that it broke through and gave great performance. You could do this on the Web.
Rich interactions are not possible on the Web
Again, we are used to applications that allow us to interact with data in a better way. With Google Maps, you feel like you are moving around the map. You are interacting closely with the data. Before hand, we were used to a static view that had us clicking up/down/left/right or zooming around. Every click responds with a wait and a repaint of the entire screen.
This seems crazy. No application framework would ever do a refresh like this, and dhtml broke us out of that box.
This is all pretty obvious, especially when you take a look back at the HCI research on how anything that takes more than a second drives your users batty (and gets them out of the zone). Getting down to 0.1 seconds and your users will feel like they are at one with the app :)
The responsiveness that Ajax gave us opened up the Web for truly useful applications that users could live in without getting frustrated. This bridged us from pages to apps.
We continue to see movement here too. The reason that WorkerPool was added to Gears (Web Workers in the standard) was to give developers the ability to send "work" (run code) to a place that isn't on the UI thread, which is a big no-no for building any kind of responsive application. As we write bigger and bigger Ajax applications, we end up running more code, which competes more with the browser. Having Web Workers in the browsers natively, and available to those that don't via Gears, allows us to build compelling applications.
Add to this fast JavaScript (SquirrelFish Extreme, TraceMonkey, V8), and we can get to a happy place with respect to performance.
So, if the original Ajax revolution was about UI responsiveness, where do we go from here?
I think that we have a few directions that we need to go in:
Productivity
We need to be more productive. We all feel a lot of pain with Web development, even as we get a lot of benefit from the reach and openness. This is pain is the reason that Ben and I are working under a developer tools umbrella at Mozilla. We want to work with the community to become more productive. It is extremely important to do so.
It shouldn't be hard to put together the hundreds of applications that the Enterprise and beyond spend too much time and money on every day.
We shouldn't have to fight the browsers to get things working as much as we do today.
Any ideas on what would help you? We are all ears.
Compelling applications
We have spent a lot of time in the weeds talking about the engine of the car. We jump on a point release of some framework, and argue about the minutia of framework differences.
Maybe it is time to pop our heads up a little and think about how we can build compelling, feature rich applications.
The browser is extending to the desktop more, to give you nice full experiences. The real-time Web is kicking off, and Comet will become a big part of how we develop many applications in the future. It needs to be as natural to us as the simple request/response world that we are used too.
UI latency is only one piece of user experience. There are many others. HTML 5 gives us richer components and semantics to work with. We have been working on different UI paradigms such as the Form History pattern that we have discussed before. Aza Raskin and others have been doing really good work on new paradigms too.
Personally, I think that new input devices are going to create a huge change for us, and the abilities of Web applications. We played with the WiiMote as an input device. We then have multi-touch, which is available on touch pad devices as well as touch screens. Finally! We are moving past the prehistoric inputs where we can point and say "Ug".
I am incredibly excited about where we are, and where we are going. There is a ton of work to do, but people feel engaged. Let's "get 'er done".
Where do you think we are going?
This presentation goes over some of these points, in more detail:
XHR is so 1997. Now it is time for some CSSHttpRequest action, a device that allows you to run cross domain Ajax requests thanks to a CSS hack:
Similar to JavaScript, this works because CSS is not subject to the same-origin policy that affects XMLHttpRequest. Like JSONP, CSSHttpRequest is limited to making GET requests. Unlike JSONP, untrusted third-party JavaScript cannot execute in the context of the calling page.
A request is invoked using the CSSHttpRequest.get(url, callback) function:
Data is encoded on the server into URI-encoded 2KB chunks and serialized into CSS @import rules with a modified about: URI scheme. The response is decoded and returned to the callback function as a string:
Matt Raible has posted on the Ajaxified Body pattern, that loads content into the main area instead of reloading an entire page.
The surrounding template stays put, and the red area changes when you have an action:
This is an old question: "When should you just reload the page?" In the sample application you see the trade offs. Every click causes a red "Loading..." indicator, and just the main area changes. The browser doesn't have any indication that something is happening, hence the need for the custom red indicator. You also then have to implement support for browser history, make sure that direct access works and the like. The positive is that you don't get a refresh flash, but is that enough to warrant the change?
One of the use cases on the page is the rich table component. That should definitely be able to refresh and page without the page changing, but when the main content gets swapped in, I start to question. What do you think?
Matt uses SiteMesh, a great technology that can knit together the look and feel, and can fit in very well in this kind of world. If a browser goes directly to a page it can piece together the entire page, but an Ajax request can come in and it can just send back the main content. Very nice.
, Ajaxian.com Announcements
