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?
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.
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?
- 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.
- 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.