When Ajax first started appearing on the web, the uptake was astonishing. It was the spark that triggered the explosion in the 2.0 era, being implemented left and right, added to existing pages and even more astonishing, creating a whole new tier of the Internet that really signaled a change in the way the web was created and displayed, much to the detriment of multi-platform/mobile compatibility, which struggles to display Ajax content.
In a way it has become the new “Killer App” for any online application’s implementation, anyone in the “software game” has no doubt been asked if they can make their application “Look Web 2.0.” In fact I was told recently by a customer that our application required “too many clicks to do something.”
At first I thought about it logically, trying to think of any pages that require many clicks to achieve a certain task that could have the number of clicks reduced, finally realizing most pages require that many clicks irrespective of what you are doing (the click to initiate something, you enter the content, then the click to complete it). The issue that this brings to hand is the impression it is giving end users, that everything should be Ajax with flashy graphics and everything moveable/editable, irrespective of whether it has an actual function, or speeds up the page at all.
Ajax is slowing down the web for both end-users and web-developers.
This is a big problem that is being tackled currently, the fact that running Ajax slows down both the web server and the browser displaying the content.
The reason for servers slowing down? well previously every page was something different served up to different people as needed, or there was one static page that displayed to all end users. Now we display a different page per user, or serve a widget out that shows custom content inside of it. The problem is the fact that all this data is (traditionally) going through a single web “API” (The interface used), resulting in a potential slowdown or overload in times of high usage (though this will be fixed in the future with better load balancing across multiple severs)
The reason for browsers slowing down? it’s not the content the Ajax is displaying, but the Ajax itself. JavaScript is what drives Ajax (Asynchronous JavaScript and XML), and JavaScript was originally created as a lightweight programming language to do some pretty simple things on the web. But as with most web-based technology, it has been warped over time into a, or dare I say the basis for web development.
You may be surprised to hear that JavaScript is a single threaded language, meaning that anytime JavaScript is being evaluated or run, everything else has to wait its turn (all in a single line). This has become especially problematic in blogs, where people have used Ajax “Widgets” from multiple sources. The problem is that all the JavaScript (often) tries to load at once, resulting in a delay where your content is not displayed until the JavaScript has done its thing.
Now this isn’t a problem if you are staying on the same page doing something simple like refreshing a table, or sorting information, (which will be significantly faster with Ajax). When you have to navigate through different pages that consist of a mash-up of JavaScript and HTML content, with an odd mix of some pages loading (almost) instantly, and others taking significantly longer, it becomes increasingly frustrating.
There is no Ajax standardization, resulting in poor quality of code.
Although this is starting to be fixed with JavaScript libraries, too often developers are inexperienced with Ajax resulting in poorly written code that has issues across different browsers and user environments (this not not true for a valued few). Adding to this is the fact we can’t easily provide feedback on the user experience locally like we can with standard web technologies.
I’m not saying that Ajax is inherently bad, I think quite the opposite. The problem is that every upstart web designer likes the look of it, so they’ve all taken a hand to trying to create (badly written) Ajax items, which becomes an issue when you have the new “social media” sites that mash together multiple plug-ins and widgets.
The Conclusion?
The basic conclusion that I want people to take away from this is to think out what benefits Ajax gives to the customer. If there is no benefit (re-arranging navigation on a blog does not count as a benefit) then don’t include it on the page, or at the very least, limit the amount of code on your page. Make your pages clean, easy to use, and fast loading. Let’s not try re-creating the “I can have a whole website made of Flash Animation!” movement.
Ajax is new territory (in the public forum) and as with other new technologies, it goes through stages from unknown to explosion to useful implementation, I just wish we could get past the explosion stage already…
