Proof Mobile AJAX Only Works In A Parallel Reality

Ajit at Open Gardens seems like a nice enough guy - an outrageous name dropper, but generally fairly harmless. However his most recent post - that US Customs people are very nice and they don't always get the kudos they deserve - finally provides proof that he's living in a parallel reality. I'd love to know how many other people (particularly those without US passports) would agree with this summary - from personal experience and anecdotal evidence from others, I'd have to estimate in the long term - we'll get to the criteria for when later - though exactly how mobile and web worlds will collide and what they'll leave behind is open to question.

Anyone can read the future technology roadmap of the GSM Association, see the clear trend for more processing power in phones, and draw the obvious conclusion that some form of mobile web will eventually be available and possibly useful and desirable on a mobile device, some time. This does not take visionary skills, just a bit of common sense extrapolation and a willingness to ignore today's reality and live in the indefinite future.

Ajit's angle, excellent self-publicist that he is, is to spot the inevitable convergence, tack on today's buzzwords, and repackage the whole thing as a visionary dream around which he can sell a lot of 'strategic consulting', books, speaking spots and whatever else - and everytime any web thing happens on mobile, his vision is vindicated. Fair play to him in some ways - I have nothing against Ajit as a person, and he has spotted a niche which the right person can make lots of money shouting from - it's just that I have to disagree with almost everything he says about the near- and medium-term future of mobile. Long-term is too far away to try and call.

I see most mobile commentators split into two camps: technically knowledgable and pragmatic (Guy Kewney, Michael Mace, et al) and tech-lite but buzzword-compliant (Ajit, monkey boy and fellow cult members). The former tend to write insightful articles which understand the limitations of the medium, the latter tend to get very enthusiastic about future technologies which will solve all the problems we have today and assume everyone wants whatever their new idea is. The latter tend to call themselves names like 'visionary', 'pioneer', 'innovator' or 'imagineer' (ugh) as well, terms which tend to rub me up the wrong way when bestowed on oneself. You can argue that the world needs both sets of people, but I'd rather sit closer to the former camp - I have found that exciting future technologies tend to grow organically and unexpectedly, following user demand (the web, SMS) rather than as preplanned visions which appear fully-formed (think WebVan); this makes understanding the present and near future rather important.

So what's wrong with mobile AJAX? I think you need to look at the technical hurdles and the words of those pushing it.

There's a great little scene in one of the Asimov Foundation books (which I read far too long ago to quote in any detail), when a diplomat arrives and signs a giant treaty with the 1st Foundation, a frontier world, guaranteeing safety and blah blah. Everyone thinks it's a great sign of their importance and safety until one of the professors at the university applies some logic to it, cancels out the contradictions, removes the meaningless fluff, and ends up with nothing - a treaty designed to look impressive but saying nothing useful. I often think of this when reading Open Gardens, where you can see a huge enthusiasm for mobile widgets or whatever else is flavour of the day, without any real analysis of why people might want them, what value they provide the user, whether they can even work for the majority of users. There are attempts at analysis and explanations, but they always rely on an implicit assumption that everyone wants new technology and it must be good - this always bothers me. Maybe I need to go to California and take whatever the techno-evangelists and asymptote guys take for a while...

Blue Favour's recent post "10 Things I learnt about Mobile 2.0" covers a lot of what the web 2.0 beta crowd want from the mobile market, and infuses the points with some realism when commenting on the key trends that speakers discussed at the Mobile 2.0 Conference recently.

The key point which springs out of this to me are: there are a lot of people who want to push the Web 2.0 bubble onto mobile, AJAX and all. They don't appear to fully understand the differences in the medium - I really don't think people want to casually browse on a mobile in the same way that they do on a PC, I think they want to accomplish certain tasks quickly and efficiently, and those certain tasks revolve around things you need on the move. In a perfect world, the widget concept does seem to fit in with this requirement and I think this is why it has had a lot of traction recently - though I have always been heavily underimpressed when actually using the things.

The web 2.0 crowd seem completely PDA and smartphone centric, because that's what they carry, and this just hilights the fact that what they eprsonally want is totally independent from what the average person wants (as different as their smartphones are from the average person in the street's handset). The more they see their handsets capable of, the more they assume the market is inexorably moving towards web-browsing fully-programmable smartphones - but it isn't. Smartphones are selling better than last year, but almost all because of Nokia's S60 platform being targetted increasingly at the middle of the market and operators trying to leverage the potential for own-brand products by pushing Windows clones. Most people are picking up phones as fashion statements, not as computers - so don't expect any change in the platforms you can use to develop real world apps on any time soon.

A crucial point - shared by all mobile app platforms - is the impact apps have on battery life. Javascript allegedly drains the battery at 4-5 times its normal rate. Javascript is a high-level programming language and AJAX generates a lot of network traffic, both downloading every single little iteration of the code (and the massive libraries required to make it work cross-device) and when doing all that funky asynchronous stuff. I don't have figures for Java but it doubtless uses quite a bit too, but with a fat client you can minimise network traffic to a single download, intelligently minimise bandwidth and connections and generally offer a streamlined user experience which gets the job done as fast as possible.

When it comes down to it, AJAX is designed for powerful CPUs and low-latency broadband connections charged for by the month. It is not designed for the high-latency slow and flaky wireless connections, particularly not those charged for by the Kb or (if you're lucky) by the Mb. You couldn't design a less appropriate technology. Let's look at each point:

• Data Quantity
• XML is a very heavy way to describe data. For passing small amounts of data around you can instantly treble the payload size using it.
• Fast iterations and rapidly changing code are great in theory, but when you download entire libraries each time you visit a site you are really piling on the pounds. Especially when those libraries have to allow for every runtime environment.
• "Unlimited" tariffs are coming to mobile, but they tend to be limited in bandwidth and carrying a number of limitations. This may change, but only if the network's backhauls start playing catch-up.
  
• Data Speed
• Current 3G offers pretty slow connections with very high latency, a lot like 56Kbps modems in fact - OK for small WML pages, but pretty awful for big heavy things (see Data Quantity).
  
• 3G has just reached 10% penetration in Europe and the US. Do you even want to know how slow a GPRS connection will be with this stuff?
  
• HSDPA may fix all this, where it is rolled out, if the backhaul can take it, once users have HSDPA phones. Don't hold your breath.
• Remember boo.com? Remember why it failed?
• Programming Model
• Javascript is a high-level language. It's deceptive - at first you think it's really simple to code, and many non-coders do give it a try. This leads to incredibly inefficient design, code bloat and generally the kind of things that trained developers who have worked in mobile have heart palpitations about.
• Anyone suggesting that fragmentation will not occur is living in a fantasy world.
• Java is a very carefully designed language which requires central certification of environments, and it still fragmented for two reasons:
• Phones are consumer electronic devices developed to tight deadlines, and often they ship before they are ready, with bugs.
• Even carefully written specs with heavy centralised test suites have gaps.
  
• Javascript has no carefully written spec, no centralised test suiute to ensure compatibility - it's an organically grown mess on the desktop, where upgrades are easy and browsers relatively sparse. There are a wide number of mobile browser makers and every one of them has wide differences in markup rendering - their efforts at scripting engines will be less standardised, not more.
  
• How many hours of talktime are users willing to give up to fuel that funky sliding effect? How many pence will they pay for it and how many seconds will they wait while it loads? I can suggest an answer, but you can probably guess for yourself.

I have heard from a number of sources that mobile operator's backhauls cannot take many users using heavy data services. They survive off voice revenues, and a bit of SMS - they'd like to see loads of other data revenues but they won't do it if voice call availability or quality would suffer, because that is the cash cow. This is really a post on its own so I'll leave it here, but I do think that all of the Web/Mobile 2.0 crowd who want the operators to get out the way and just become a bit pipe are living on false hope. Just like their faith in mobile AJAX.

Fat clients and simple Wap pages will be here for a long time because they work, and they work in the mobile medium - you can't just do a quick mash up and make something work on a small screen with limited I/O potential. What replaces them, in a truly popular mass market sense, will be many years in the future and I don't think we're in a position to accurately judge that in today's bubble 2.0 market.