Mobile web 2.0: AJAX for mobile devices – why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development – Part two



(Note: Originally I posted this document in two parts – but I have now combined it into one – with a logical break in the middle

also, there seems to be some problem posting comments – Pls feel free to contact me direct if you cannot comment


On Jan 1 2006, I published an article called Mobile web 2.0: AJAX for mobile devices – why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development

It created quite a stir .. and I am thankful for all the feedback. Specifically, I would like to thank C Enrique Oritiz , Thomas Landspurg , Paul Golding and Jan Standal(Opera) for their feedback.

Special thanks go to Paul Golding for brainstorming some of the ideas in this article with me.

I did not intend to write a follow-up – but the response warranted one. Clearly, I had not explained some views in detail while other concepts were being misunderstood. I strongly believe that the disruptive potential of AJAX in the mobile space is not fully appreciated.

This article(which I am calling Part II) will clarify some of the views I expressed before and also add new insights.

In keeping with my original article(which I am now calling Part I) , this article will focus on the impact of Ajax on mobile application development only (i.e. we are not discussing Ajax in general here).

In this article, we are going to discuss -

a) The limitations of the browsing model on mobile devices and how these are being overcome

b) The impact of Ajax on mobile applications development

c) The potential of Ajax/browsing model to enable applications which target a large customer base.

I welcome your comments at ajit.jaokar at or on this blog. Please feel free to use sections of this article but you should acknowledge the source as and link back to the article.



Consider the following scenario ..

Like most people, you keenly follow the commonwealth games currently being played in Melbourne .

However, UNLIKE most people, your favourite game is lawn bowling .

Lawn ‘what’ ? people ask you – since not many outside the commonwealth have heard of your game(For the 2008 Beijing Olympics, wikipedia caustically lists your game under the category of ‘Sports held as a demonstration, or of which the Olympic status is disputable’ ). So, you are glad that your game is at least being played in Melbourne. But the coverage sucks! The sexy games like swimming, boxing and athletics get all the fame and the glory.

You explain your plight to the friendly neighbourhood geek – who explains something called a ‘long tail’ to you. Apparently, you are it!

In most situations, 80% of the revenue comes from 20% of the products/services (depicted in red below). Thus, the remaining 80% of the products have low demand and low sales. These constitute the ‘long tail’ (such as lawn bowling). The principle of harnessing the ‘long tail’ argues that collectively, these low volume/low sales products can make up market share that equals or exceeds the few bestsellers – provided the distribution channel is large enough and the per unit production cost is low.


Now suppose we wanted to design a mobile application for the commonwealth games. The preparations would start many months ago. However, keeping the interests of your subscribers in mind, the designer would probably not focus much on the ‘lawn bowls’ section.

However, as a diehard lawn bowling fan, you want the whole works – blogs, polls, images, profiles, betting results and so on.

Can mobile web 2.0, Ajax and widgets help in this scenario? This article will show how.


The complete scope of this article is :

a) Can all mobile applications be implemented using browsing technology?

b) The possibilities of Mobile Ajax

c) The evolution of mobile Ajax and the significance of Opera’s announcement

d) Walled gardens, OpenGardens in context of the above approach

e) How does this approach contrast with Java Me, Symbian etc

f) Mobile gaming

g) Why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development

h) The response/evolution of Java ME

i) Conclusions


Before we start discussing mobile applications and Ajax, let us consider the question – Can all mobile applications be implemented using browser technology? In the PC/Internet world, the browser is fast becoming the universal client. However, there is a crucial difference between the PC world and the browser world.

In the PC world, we need one type of program to run a specific type of application (‘word’ to view word documents, ‘excel’ to view spreadsheets and so on). In contrast, we can use the browser to view any type of application(i.e. one client for many applications). This makes application development much more optimal and less susceptible to software running on the client(in this case the PC).

Following on – we consider the browser and mobile applications ..

With higher spec mobile devices, greater bandwidth etc let us consider the hypothetical question -

Can ALL MOBILE applications be implemented using browsing technology?

After all, the browser works well on the PC as a universal client – why not on the mobile device? A corollary to this question could be –

a) when would you be forced to develop an application on a mobile device which is NOT run through a browser? And

b) Are there some fundamental differences with browsing on a mobile device vs. browsing on the web?

Let’s consider point (b) first. To understand the differences between browsing on the web and browsing on a mobile device, we have to consider factors such as

a) Intermittent connections – Unlike on the web, the wireless network connection is relatively unstable and is affected by factors such as coverage (you lose the connection in a tunnel) etc

b) Bandwidth limitations – For example – even when 3G coverage is available, the actual bandwidth is far less

c) The need for data storage on the client: If the device has no (or little) local storage, all data has to be downloaded every time. This is not optimal given intermittent and expensive bandwidth

d) Finally, and most importantly – A local application provides a richer user experience – especially for applications such as games.

There are other factors such as limited user input capabilities, screen sizes and so on. Some of the above factors are getting better(for example coverage blackspots are decreasing) – but the overall user experience remains one of the most important factors.

Thus, the answer to our hypothetical question is – No. We cannot develop all mobile applications using the browser only. However, as we shall discuss below, the architecture of browsing applications is changing and the distinctions between the browsing and downloading applications are not as clear cut as before.

On one hand, local and native applications offer the advantage of a better user interface. However, they suffer from some significant disadvantages – in that the application has to cover a diverse range of devices, operating systems, screen sizes, user interfaces, multiple software releases etc. This leads to fragmentation(see more details below).


Inspite of the issues mentioned above, I believe that Ajax will lead to resurgence in browsing applications and will overcome many of the problems we now face because

a) The level of abstraction shifts to the browser. Browser based applications are relatively easier to update and can be used across operators. This leads to a greater target audience for the application. Developers could have access to a critical mass of customers to make application development worthwhile. The browser also reduces fragmentation by providing a universal client(i.e. one client to for all application types as opposed to a separate client for each application type)

b) Ajax is making the browser experience and data management capabilities better

c) Developers are supporting Ajax on the internet and by extension the mobile internet. Industry heavyweights are shifting their support to Ajax(for example IBM’s support for Open Ajax )

d) The concept of widgets is not new. It has been around for some time on the Mac. In this context, a widget is a downloadable, interactive software object that provides a single service such as a map, a news feed etc. Ajax provides a mechanism to implement widgets on browsers.

e) Finally, Ajax could foster the creation of the widget authoring market similar to Apple widgets or Opera widgets

The resurgence of browsing applications is not new. Other bloggers such as Russell Beattie have also spotted the same trend.

However, I believe that Ajax will take it one step further by providing a combination of richer experience, bigger target audience, data management capabilities and widget authoring capabilities.

In addition, the support of developers – both on the web and on the mobile internet – could lead Ajax to morph into a system with greater capabilities than we currently envisage.


Part one of the article was written in context of the Opera platform’s support for Ajax .

As per it’s definition, the Opera Platform comprises:

- Opera web browser running in full-screen mode.

- An AJAX framework for running multiple widgets/applications.

- Access to the phones native functionality through an abstraction layer

Opera already supports AJAX in the 17 million shipped mobile browsers in 2005. This means that – with the existing Opera browsers you can use desktop AJAX services such as GMail, Google Maps etc. This much is quite apparent and has been covered by other analysts before.

However, there is more to the announcement than merely support for Ajax.

The significant elements are

1) The Opera Platform is the first mobile AJAX framework. It also has a corresponding browser framework. However, unlike other frameworks such as Zimbra (zimlets) and Backbase it is fully designed for mobile devices – in the sense that it uses the same codebase on the browser and the mobile device. With minor configuration changes, the desktop/browser widget could also run on the mobile device Thus, from a developer’s perspective, there are more than one ways to monetise the widget(desktop, mobile and browser). This factor, coupled with the large installed base – makes the Opera announcement significant from the mobile applications development standpoint

2) Widgets could call other widgets. Complex applications could thus be developed from simple, browser based components

3) The Opera platform allows access to device APIs

To appreciate this concept, we have to consider the architectural drawbacks of the browser model (corollary ‘a’ as discussed above)

The browser model is document centric i.e. based on mark-up languages. In contrast, downloaded and native applications are application centric since they are based on a programming language.

To be really useful, any mobile applications development model must have the capacity to access data elements that are tightly coupled to the device itself. These include the telephony API, phone book, text messages, the messaging API, call records, the SIM card, the calendar, the Bluetooth stack, media player, the file system and so on.

Applications running on the phone can access these services through APIs. For most part, applications running on browsers could not access these functions(with the exception of a few proprietary solutions).

The opera platform is a browser based programming environment that abstracts the native device APIs through a set of Javascript APIs and thus provides developers access to the low level functions on the device from the browser


This is VERY significant and has the possibility of creating richer browser based applications.

Knowing what we know now about Ajax, widgets etc – lets return back to the example of ‘lawn bowls’.

The power of Ajax lies in it’s ability to create widgets at the desktop level. Using the Opera platform approach, the same widget could be used for the mobile device. These widgets have the ability to harness revenue from the long tail. In the commonwealth games scenario, it should be possible to create a low cost widget catering for the lawn bowls fans. These widgets could run on the desktop browser as well as the mobile browser(using the Opera approach outlined above). There in lies the significance of the Ajax approach!

One would argue that this approach is not a purely browser based approach (because the client in this case needs some form of ‘software’ running locally). Note that – the platform approach is not the same as using a plug-in because a plug-in can be downloaded. In contrast, the platform is a part of the device itself and is installed by the manufacturer.

I agree that this approach is not ‘pure’. However, developers will have to deal with few (perhaps less than ten) such platforms as opposed to the ‘hundreds’ of variants that they have to currently contend with (see notes below).

Nor is this approach ‘open’ – in the sense that an application programmed on one platform will only run on that platform.

Nor is it ‘endorsed’ by OMA as far as I know. The whole issue is still also too early for the mobile operators since it has yet to flow up from browser vendors to the device manufacturers and only then to the operators. However, the W3C mobile web initiative may also be a standards body in this case in collaboration with OMA.

Finally, the approach is still not ‘rich’ enough for certain types of applications such as games( see more on games below).

Nevertheless, it’s a huge step forward because we now have a much more uniform playing field across operators.

Historically, popular technology has often morphed depending on industry support. Take the humble old ‘SQL‘ . Every vendor(such as Sybase, Informix etc) – introduced a procedural version of SQL (PLSQL in case of Oracle). SQL and PLSQL are a contradiction in terms because SQL is set based (and thus by definition not procedural) whereas PLSQL is procedural.

However, ‘procedural’ SQL exists because there was an industry demand (read developer support) behind it. We are witnessing the same phenomenon here with Ajax.

Originally, I had a logical break here since the article was getting very long. But based on initial feedback, I have included it all here. If you have reached this far – I hope you like the rest enjoy! …

d) Walled gardens, OpenGardens in context of the above approach

e) How does this approach contrast with Java Me, Symbian etc

f) Mobile gaming

g) Why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development

h) The response/evolution of Java ME

i) Conclusions


Now, to my favourite topic – walled gardens and open gardens.

There are two types of walled gardens – firstly the extreme case – like ‘3‘ – which blocks access outside their sites completely – and there is not much you can do about that (but I don’t give that model a lot of time to survive either!)

However, the other case is an operator like Vodafone .

Vodafone live IS a walled garden(and I have no problems with that) BUT Vodafone itself places no restrictions to accessing the web from the browser.

The overall approach outlined above based on Ajax could be a way to overcome the walled gardens problem because the lowest common denominator shifts to the browser (and hence it is cross operator).

Indeed, current browser technology is also cross operator – but with the Ajax based approach as outlined above, for the first time, we have the opportunity to create compelling applications and have access to device APIs from the browser through the platform. Thus, this approach increases the target audience for any given application.

This means, if the browser experience is improved – we could write browser based apps for most operators- which could access a much larger user base


The Ajax/platform led approach closes the gap between browser based applications and downloaded applications. Thin client applications will always be impacted due to the need to remain connected in a mobile environment. But in spite of that, the user interface is improved, access to the device is possible – most importantly – the potential target audience increases and development cost decreases.

AJAX has better deployment models and leans more towards open source (since AJAX components are open-source). Java (MIDP) is more deployed and better specified (for now at least). Symbian/WinMobile offers more phone integration, but is not portable and completely proprietary. Adobe Flash is another interesting alternative, but unlike the other technologies has already proved to work with AJAX on the desktop. Hence its an enhancer and not only a competitor to AJAX.


In Part One, I used the example of mobile gaming. I used porting price statistics from a source which I quoted in the article. Thomas Landspurg has been kind enough to send me updated statistics which he believes are more accurate. According to Thomas

The price/binary (of porting) is around 300 to 600 (but most of the time between 500 to 600). But we have around 80 different binaries for 250 supported handsets, including the different languages…..But this is only for a single technology (typically Java) and a common version for this technology. This does not include a Brew version for instance. One of the big cost factor is the support of MIDP1.0 handsets. Another view is that you can add from 100 to 150% to the development cost as porting costs….

Again, this might change a lot depending of the game (2D/3D) the type of content, etc….

I am not an expert on gaming – and Thomas is. Hence, I am grateful for these stats.

However, isn’t it a pity that mobile applications have been reduced to games/ entertainment in most cases?

Where are the applications(i.e. useful mobile applications such as ‘find my nearest’ etc) – as opposed to games?

And as regards mobile games themselves, I am not the only one who feels that the current state of affairs is fundamentally broken.

As per the article Games elite tackle fragmentation

At present, mobile games development is hamstrung by the fact that one game needs to be tweaked potentially hundreds of times for different handsets. These devices all implement Java differently and have a variety of screen sizes, keyboard lay-outs and user interfaces. The cost and time implications are enormous.

Its the ‘hundreds of times’ which is significant.

A thriving industry undeniably exists in game porting .. so .. the basic principle is valid. If WORA (Write once run anywhere) were true, it should be relatively cheap to ensure that the game runs across devices and across operators – but it’s not!. In fact, companies like babel media derive a significant part of their income from ensuring that mobile games conform to standards set by publishers and operators.

Finally, it’s critical that games developers have a viable business model – without which the industry can’t survive and there can be no innovation. This is especially true of small developers who need a viable per unit cost of development , access to distribution channels and the possibility to make a decent return(i.e. margins that they can build a business with).

These factors are much more important than a pretty face(a ‘rich’ interface).

The browser model as outlined above provides the ability to overcome these issues which currently plague the gaming industry.

Currently, we have a ‘rich’ interface at the expense of a revenue model. I believe that it’s not necessary to have a rich interface to develop a successful mobile game. In fact, successful games can be developed using very basic technology such as SMS . Increasingly, casual games are becoming significant

Mobile gaming is different from console/PC gaming and applying concepts from PC/console gaming to mobile gaming(such as the necessity of a rich interface provided by native applications) – would be missing the point. It’s far more important to foster a revenue model and / or community – both of which are possible via the browser model.


This headline got considerable attention from my last article(Part One). Lets put this statement in perspective – I said ‘replace as the preferred platform for mobile applications development’ – which is not the same as ‘it will replace’ – the operative word being ‘preferred platform’.

Let me elaborate more using an example.

My first job, fresh out of college, was as a software developer. At college, we learnt ‘C’ programming and UNIX. Our project team at my first job often had lunch together and the topic of conversation was often the same. It was started by the team leader, a veteran of many years of software development. He was obsessed about ‘Is AS400 the VAX killer or is VAX the AS400 killer?’(In other words – which platform is better). I would listen fascinated as technical arguments flowed back and forth.

When someone would care to listen to me – I would ask ‘What about Unix?’. ‘Oh – those are PC systems Ajit’ was the dismissive reply I often received – and off they would go on with AS400 vs. VAX.

Just a few years on – things have changed dramatically.

Both the VAX/VMS and the AS400 are still around – but by no means are the preferred modes of application development – in the sense that if you wanted to develop a new application – you are unlikely to think of these as your first choice. However, note that they have not been ‘replaced’ by newer applications. Also, note that its not a technology issue but rather a commercial issue.

In retrospect, the whole issue was like ‘Dodo vs. Dodo’ – la Spy vs. Spy from the Mad magazine

Hopefully, this should clarify that I mean browsing/ AJAX will be the preferred mode of development and not the only mode of development.


Enrique has pointed out that Sun/the Java community process is trying to address this problem through MSA and MIDP3 .



I believe that if our industry has a patron saint – it should be Jerry Macguire (Show me the money!) . The revenue model is the key. Any technology or application that enables the players in the value chain to make money will thrive.

Ajax, mobile web 2.0 and widgets reduce time to market, encourage innovation and enable a larger target market. By potentially having the ability to develop for the web and the mobile browser at the same time, widgets offer a better value proposition to developers. If widgets can ‘call’ other widgets – powerful applications could be developed from simple components

The biggest factor in favour of Ajax today is the support of small application developers. Developers who stand to make money from widgets. Widgets which could potentially have a large target audience.

In mobile Ajax, Java ME has a credible option. While Java ME is looking to address some of these drawbacks – I believe that the momentum behind Ajax will lead to the emergence of a virtuous (and disruptive!) cycle which will cause Ajax based mobile applications be a credible alternative to Java ME.

Let me conclude with an observation.

At forumoxford (Oxford university’s next generation mobile applications panel – which I chair) , Walter Adamson asked me this question ‘And who bought the last round of “browser only” PCs? Noone, including you.’

That’s true. I didn’t buy a ‘browser only’ PC at that time.

But the point is – NOW I would.

Already, my email, calendar and other applications are on the web. Using Web 2.0 applications like the writely, I can store all my documents on the web.

All I need is a browser. One client to rule them all!

Thus, today I would use a ‘brower only PC’ – would you?

What does that say about mobile applications ?

Image source:


  1. NGWeb2006 Presentation – Mobile Web 2.0

    이번 NGWeb2006 행사에서 발표했던 Mobile Web 2.0 자료를 올려두었습니다. 필요하신 분들은 받아가시기 바라며, 이번 발표와 관련된 다양한 의견들을 주시면 감사하겠습니다. 사실 개념적인 정리

  2. Mobile web 2.0: AJAX for mobile devices

    Sometimes it feels like Ajax is nothing short of spackle. You know, that putty like substance that can patch just about anything? Well, if some folks have their way, we might very well see Ajax replacing J2ME and XHTML in…

  3. MAJAX instead of J2ME, FL and XHTML?

    Inspite of the issues mentioned above, I believe that Ajax will lead to resurgence in browsing applications and will overcome many of the problems we now face because
    a) The level of abstraction shifts to the browser. B…

  4. Brian says: is a very good mobile web 2.0 service.

  5. Vandana says:

    You mention that an application can read the following details of the device: “any mobile applications development model must have the capacity to access data elements that are tightly coupled to the device itself. These include the telephony API, phone book, text messages, the messaging API, call records, the SIM card, the calendar, the Bluetooth stack, media player, the file system and so on.”
    Question is that is this true for a j2me application also? Can my app know the model name of the phone? Can it know the cell number also?

  6. Nicho Wong says:

    I don’t think Mobile Ajax could become a prefered way of mobile development. It could simplify some of the work but could not create serious interesting and attractive game. Take a look of what’s happening in the PC platform one could understand. I think SilverLight may have the capability to win finally on more and more popular WMx platform phone device. For Java alone, take a look of what the library support and what the Mobile Ajax support, you will get the answer.

  7. Congratulations your prediction is now a reality.
    ItsNat, a Java based Web Application Framework focused on AJAX brings Web 2.0 capabilities (AJAX, COMET, server-sent events…) to the following mobile browers:
    Opera Mini 4, Opera Mobile 8.6, NetFront 3.5, Minimo 0.2, IE Mobile 6 (Windows Mobile 6), iPhone/iPod Touch/iPhone SDK, Android, S60WebKit (S60 3rd), Iris 1.0.8 and QtWebKit embedded (Qt 4.4)
    I agree with you the mobile world is repeating the desktop history, the mobile web will replace most of the mobile applications (mostly JavaME) as in desktop.

  8. Nicho Wong says:

    You are totally misunderstanding. Mobile web by AJAX will NEVER replace JavaME. Only Silverlight will, a kind of flash like application

  9. mathiastck says:

    The iPhone has presented us a wonderful opportunity to compare native clients with ajax applications. (Not quite the same as comparing J2ME and Ajax, but siilar).
    At first Apple only allowed AJAX applications, they promoted them heavily, and some great AJAX apps were created. The browser on the iPhone is very strong, and still sees record use.
    Then Apple released the app store, which has also seen record use and adoption. I’m betting AJAX games saw a real drop in usage, and creation.
    Both AJAX and Native apps thrive on the iPhone.
    I’m interested in how the Palm Pre plays out. Like the iPhone, they are encouraged applicatiosn to be developed using standard html and scripting. They seem to have a richer platform for it though, with more offline ability, and better tie in to device services.
    I’m hoping that later on they will add a JVM, or the ability to run Android applications, or native code. No need to rush that though, better to get it right.