Mobile AJAX

I was about to be a big ball ‘o negativity, but I managed to stop myself. After not being nice about the whole Foleo thing earlier, I was going to go right off ranting about the whole Mobile AJAX thing, prompted by reading over the Mobile AJAX FAQ. But then I realized that’s wrong, I shouldn’t just rant all the time. Most of the time perhaps, but not all the time. Instead, I took a deep breath, calmed down, and examined why it is exactly that the mere mention of mobile AJAX normally makes the bile rise in my throat.

I don’t want to rail at Ajit and the other folks working on the FAQ, I know they’re trying to do something positive. So instead I’m trying to find a constructive way to contribute to the conversation. Why is it that I think the discussions about mobile AJAX are just too premature? Why do I consider them ‘dangerous’ even?

Way back in the deep dark depths of time I worked on a DHTML and Javascript project in a faraway galaxy called Rochester NY. I honestly don’t remember when it was, but I have to guess probably 1997. Long enough ago that there was a version of a browser that AOL was distributing that was different enough from whatever its original form was that it was considered a distinct browser. And it was important to pay attention to cause almost everyone was still getting online via AOL disks mailed to them. Very much pre-history. I don’t remember any giant lizards roaming around, but there may have been.

What we were working on was evaluating if the company could replace it’s desktop based relatively thin client installed application with the genuine thin client of a browser plus web app. The problem being that they wanted to do some relatively complex stuff for the day. DHTML, relatively heavy javascript processing, and they wanted it to look good and feel slick. We got it put together but it was a real pain to get working. Lots and lots of trial and error debugging, posting to mailing lists and news groups to find out what other tricks people were using, doing server side adaption to work around differences across IE and Netscape, and CSS really didn’t exist at all to speak of so styling was a real pain. The browsers were slow and clunky, it was relatively easy to crash them with simple stuff, IFRAMEs were even a relatively new advance. So DHTML and Javascript to do rich internet applications just left a bad taste in my mouth.

Then a few years ago, people started talking using the browser as a Javascript based thin client again and the hairs raised on the back of my neck. Why was this a good idea now when it was so horribly painful before? What makes DHTML and Javascript workable where it hadn’t been? The answer is maturity and scope of the standards and maturity and (relative) consistency of the browsers that implement them. It’s pretty difficult these days to take out a desktop browser with crappy javascript. The standard browser will cope with tons of junk thrown at it. It might not render anything, but it also won’t normally just disappear on you. You can use CSS to do styling consistently, and when you need to work around browser quirks you can do that within the browser itself.

The whole setup has led to common libraries of javascript that developers can reuse across projects so that not everyone has to deal with all the details at every level of the implementation stack. There are even some honest to goodness debugging tools like firebug to make a developers life easier and shed some light into the dark corners. AJAX on the wired web works cause the browsers are stable and mature enough to be considered a development platform. However ten years ago that wasn’t the case. Trying to build an app inside a browser was like trying to build on quicksand. And every once in a while even the quicksand would just up and disappear on you without warning.

So what’s happening now with mobile browsers? Over the last few years we’re seeing mobile browsers in significant numbers that support XHTML instead of WML, the browsers are starting to grow Javascript support, implementations are coming out based on existing desktop versions, and the network connections are getting fast enough to make a browsing experience pleasant. But even given all that we’re just at the start though. The very very very start. We can’t even get online validators to agree what is and is not valid mobile markup. And yet we think we can leapfrog to where the web is in terms of using the browser as a base platform for richer client development? All I can see that doing is setting us up for a whole bunch of pain and then a whole bunch of disappointment again. Haven’t we done that enough?

But I don’t just want to whine, so I tried to figure out what I could do to help set the framework properly for thinking about how to get us to that point if we decide we do want to be there. The Mobile AJAX FAQ says that most existing web based frameworks are too heavy to use on a mobile device (this should be counted as a warning sign by the way), but I’ve been fooling around with using prototype.js with the Nokia Open Source browser and generally found that the stuff worked. So I decided today to really dig at it and find out if I’m just being a naysayer without justification or if I would find an environment that was as unformed as the one that existed back in the day on the web.

The first thing of note was that the common pattern in AJAX programming of shipping around fragments of HTML instead of JSON if what you want to do is just update some portion of the display causes some issues right off the bat. The problem is with the carrier gateways, who will frequently try to “correct” problems they see like missing but required doctype declarations and elements. That’s really just an annoyance however, you can just always return your snippets with a content-type of text/plain (which is really more technically valid than text/html anyway, cause it’s not an HTML document on its own). Just something to keep an eye out for if you’re playing with this stuff.

Then I managed to do what I knew it should only take a bit of poking to do, I managed to find a nice simple one-liner of Javascript that takes out the browser on my E61:

var str = ‘You survived!!’.replace( new RegExp( ‘xx([\u0001-\uFFFF]*?)xx’ ) );

That’s it, just looks like funked up Unicode handling in regular expressions. But something like that is in the prototype.js library to strip scripts out of inbound HTML fragments. I found a pretty significant bug in an existing browser implementation within about 3 hours of sitting down to try to do so, and it’s a fatal error. Imagine if what I was trying to get done was write an application and not just use an existing library to vet a browser implementation. I would probably be cursing the prototype library for being buggy, and I would be dead wrong. This isn’t a new browser, it’s a port of the existing WebKit code to the Nokia devices. That gives it a leg up in terms of maturity, but it certainly doesn’t account for everything. Here’s a link to my “crash the Nokia OS browser” page by the way if you want to try it out.

If we want all this stuff to work as a whole we really need to figure out how to make it less painful to develop the stuff. As someone who still primarily writes code for a living it still very much pains me to see the visionaries point everyone into what I know is just a meat grinder in terms of what the folks implementing these systems are going to have to deal with. I’m a tremendous fan of the mobile web, so I would love to see this stuff work. But there are a few iterations to go before we can realistically think about using something like AJAX for the average mobile web developer. In the meantime all it does is muddy the waters, causes confusion, and distracts from what the real goal should be – building killer applications that expand use of the mobile web to people who never found it attractive before.

That said, I love the idea that eventually we could end up with a rich mobile web environment that could surpass the wired web, that gives me the warm fuzzies. What do we need?

  • Would someone please finish the standards and get one consistent set of documents that everyone can develop to for mobile web content? Why isn’t this done yet? The wired web is an unorganized mess, the mobile web is ground zero after a nuclear blast. And it seems to be getting worse instead of better. Just when there started to be some unity around the XHTML format itself, now we have SVGt and FlashLite and compound document formats and XML widget descriptions. Any and all of which might save the world at any given moment, and may or may not be available in the next version of any given browser, and one of which will definitely obsolete everything it is that you could possibly be doing right now – we just don’t know which one. STOP IT ALREADY! One damn format, everywhere. Get it working. Get it shipped. Get it in the hands of users. Then lets talk about how to make your location enabled Javascript based widget run both in the browser and on the home screen.
  • If you want to drive faster maturity of your implementations you need to open source the whole thing and let others help you find the holes in your code. The Nokia OS browser I’ve been playing with is based on the Apple WebKit code used in the Safari browser, so this should also be a problem for Safari, right? Not as far as I can tell. There are some mentions of problems with Unicode expressions in WebKit, but that seems to be back around 2005, well before the firmware I have in this device should have gone into development. I assume this is something specific to the Nokia OS implementation.
  • What’s the equivalent to CLDC for Javascript/browsers/DOM? The Java environment specification requires a certain minimum amount of memory available to a Java process so that if a developer keeps under that they know their program will run without issues. As far as I know there’s nothing of the sort for ECMAscript/Javascript, is there? On limited devices like these the minimum application environment specification issue becomes a lot more important than on the desktop.
  • Lets figure out what really drove the web side to consistency and make sure we setup the same situation on the mobile end. There are some fundamentally different environment issues between the two. The internet operates in an open and end-to-end manner so that new servers and new clients can be used without having to change the network in the middle. Is that how the carriers are going to operate their networks when it comes to data services? How about the device manufacturers? What makes them install a heavier and more costly web browser when there are few rich mobile web apps and few users? Or what makes mobile web developers build rich mobile web apps when there are few devices that can access them? I think the Moto RAZR and it’s 8K page limit has proven to all that the mobile web isn’t going to roll on like a juggernaut with no steps backwards. What really locks the value chain in and makes sure that no device manufacturer would dare approach a carrier with a device that had a substandard browser? And makes the carrier care enough to validate the implementations coming in and push back when there are problems? Or what’s going to happen that makes it irrelevant if these things happen because there’s a different driver for the issue?

I spend a decent amount of time talking to independent mobile media property owners trying to evaluate their service evolution and what they can expect in the future. If we don’t get at least some of those questions answered we’re not really doing what we should be doing to grow the mobile web.

This entry was posted in Community, Open Source, ThisIsMobility. Bookmark the permalink.

20 Responses to Mobile AJAX

  1. Finally, someone confronting reality as it is and NOT as someone else wants it to be.

    I had exactly the same response when I read the Mobile AJAX FAQ… those guys where not there when DHTML was around. I was and suffered like you through all the browser issues.

    Mobile browsers are not the same as their desktop cousins. The quicker people confront reality the quicker we’ll make some real progress.



  2. Bryan Rieger says:

    Hi Mike,

    Thanks for the feedback.

    There is indeed a long way to go (largely for all the reasons you mentioned above) before mobile ajax becomes a mainsteam reality – but the FAQ is a starting point for now. Anything that get’s people seriously talking about how to make this stuff work is progress.

    A lot was learned from the previous mistakes of desktop browsers (yes Peter – I was there for the first coming of DHTML) years ago, hopefully we don’t have to repeat that entire painful process with mobile browsers.



  3. Ajit Jaokar says:

    thanks Mike. Yes, we will learn from this and like Bryan says, its a starting point. I think that the past may not always be an indicator to the future though – think Mobile Widgets and Offline browsing for instance – which I expect may mean that while some lessons from the past may be applied to the future, the future of the Mobile Web may be quite different in many aspects. We will take your comments on libraries on board in subsequent versions. kind rgds Ajit

  4. Rich LaBarca says:

    Mike – I came to pretty much the same conclusion after AJAXWorld. Mobile browsers are just too heterogeneous and device specs too diverse – you just have to keep things serverside until we get some standards in place.

    SoonR is the golden child of mobile AJAX, and soon the Webkit Widgets will be flashed about as well. OK, they’re both compelling apps, but they’re so damn unrealistic if you want to be portable – like a shiny piece of candy you can only have if you put these blinders on. I’ll withhold judgment on the S60 webkit widgets for now – maybe they’ll put some CLDC-type specs in place when they’re released.

    Bryan and Ajit – it’s great to get people talking, but it’s more important to get the guys who develop the browsers talking at this point. And even when I say “people” I mean seasoned mobile developers – not the people just jumping in.

    There are so many people just starting to figure out how to do this mobile development thing, if we’re going to be educators, we must make sure we temper their expectations accordingly. Right now, if you get 30 mins to talk on ways to develop for mobile devices, given the lack of practicality for mobile AJAX, it should probably take up less than a minute of that time.

  5. Pingback: » Mobile AJAX - Online computer & internet network security

  6. George says:

    Tested the link on N73 (import version with Asian character support if that matters). It killed the Webkit based browse…

  7. miker says:

    Thanks George!

  8. Pingback: mobile ajax » Blog Archive » Mobile Ajax FAQ

  9. raddedas says:

    Mike you are definitely a better man than I. That’s a very well balanced post pointing out the failings of the FAQ and the implementations whilst providing some positive feedback. I usually have my head stuck halfway through a wall after reading this stuff so can never manage to commit to something positive.

    I definitely share your pain on the early DHTML, btw.

  10. Pingback: Little Springs Design » cookies and AJAX

  11. Pingback: Mike Rowehl: This is Mobility » Blog Archive » The Path to Progress

  12. Pingback: Mike Rowehl: This is Mobility » Blog Archive » Nintendo DS Opera Browser

  13. Lars says:

    Hi Mike:

    “STOP IT ALREADY!” had me laughing out-loud.. 8-)

    I’m someone who does ‘not’ write code for a living, therefore not at all qualified to wander into that – obviously important – part of this conversation.

    However, starting in 2004 the operators here in Japan insisted on Flash as a default pre-install, so their menus would look fancy, which has allowed CP’s to deploy browser-based contents/apps with the relative comfort of knowing ‘no matter what handset, chances are pretty good it’s gonna work..’

    Of course there are limitations to such a bold blanket statement, and I do hate to over-simplify, but the main point would indeed validate your further conclusion to “Get it working. Get it shipped. Get it in the hands of users.”

    It’s not a matter of If but When and as always more importantly How..!


  14. Pete Ferne says:

    FWIW your test page gives me “you survived” in the S60 webkit browser preinstalled on my N95 and in Opera 8.65 on the N95 and on a 6630. The preinstalled browser on the 6630 gives me nothing but doesn’t crash (no js support). Which is curious, maybe the webkit bug has been fixed? Or maybe there’s a particular problem with the E61 build? Either way, yuk.

    Hopefully projects like will help.

  15. miker says:

    Yea, the N95 has it fixed, but all the previous versions seemed to have it, both N-series and E-series from what I’ve seen. The 6630 uses the services browser, which doesn’t have the problem anywhere as far as I can tell. There’s a services browser on the e61, and that doesn’t have the issue. Just the webkit based one.

  16. Pingback: Mike Rowehl: This is Mobility » Blog Archive » Mobile Browser Testing

  17. Pingback: Mike Rowehl: This is Mobility » Blog Archive » iPhone Tools and Services at AdMob

  18. Pingback: Mike Rowehl: This is Mobility » Blog Archive » Mobile Web from the Perspective of a Javascript Developer

  19. Pingback: Day of JS Event

  20. Pingback: Mobile Ajax FAQ - mobilepulse mobile trends

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">