Adam Bosworth writes,earlier,when Ajax was talked about,the web was seen as a two edged sword. One the one hand it offered instant and universal access to all their customers on the other hand, they were terrified by the support costs of having millions or tens of millions of customers using their software. Accordingly, they wanted applications (aka web sites) that were as simple to figure out how to use as possible. There is a trade-off between ease of learning and richness of UI. Toolbar icons and right clicks and drag/drop and so on are often great accelerators, but they aren't necessarily obvious. Customers then wanted reach, not rich. Three reasons that these have changed:
- First, the ajax centric applications that are taking off Ajax aren't customer support applications per se. They are more personal applications like mail or maps or schedules, with increasing web awareness, extending the idiom for things like expand/collapse is a lot less threatening than it was then.
- Secondly, With broadband and standard tricks for compressing the script,downloading huge code is a breeze. JavaScript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP.
- Finally, in 1997 or even in 1999 there wasn't a practical way to write these applications to run on all browsers. Today, with work, this is doable
The Key pitfalls on Ajax:
- First, printing is still hard. The browser has never grown up to enable the page author to easily describe an alternate layout for printing which is a shame.
- Secondly, an event driven model for browsers are needed where in addition to the events like typing the page can describe events like an XMPP message or a VOIP request or a data-changed post for an ATOM feed.
- Third, for running applications offline, we need a local cache, a smart template model, and a synchronization protocol are required to build applications that run equally well connected and disconnected and the way that the Blackberry works is a role model for all of us here.
The advent of truly mobile computing on mobile devices will bring in the next steps in change. It is way too expensive to build solutions for mobile on J2ME and often too poor a customer experience when they are built using WAP (except for super simple things). In future , the browsing could be modeled around a pub/sub, events, and caching built in and which doesn't have the problems with re-layout.
|
