Mike Rowehl: This is Mobility

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.