Last week, I pondered Adobe's big push to position Flash as a platform for mobile devices. It's facing an uphill battle, particularly when it's forced to compile Flash apps down to native binaries to get them to run on the iPhone. Open Web standards seem like a much better development target for today's smartphones -- but not even the mobile Web is a sure bet. The problem, in a nutshell, is scalability.
When developers talk about scalability, they're usually talking about scaling up. That is, when confronted with an ever-increasing load, can the application make efficient use of all the available resources to meet the demand? Web applications have always been pretty good at this (when they're coded properly), and modern advances are making them better.
[ Is unified mobile app dev a fantasy? InfoWorld's Paul Krill explores the debate. | Get the InfoWorld editors' 20-page "Mobile 2.0" Deep Dive PDF report, a hands-on look at the new generation of mobile devices ]
Throw mobile into the mix, however, and developers face a whole new challenge. Now their applications need to be able to scale down, too -- to deliver the nearest-possible equivalent to the desktop experience on devices that lack processor power, screen resolution, network bandwidth, and storage capacity -- all at the same time. That's a tough nut to crack -- not just for runtimes like Flash and Java, but for Web standards-based applications, too -- and it's getting harder all the time.
Google's brand-new Web
The problem isn't limited to small screen sizes and oddball input devices. Those were issues when the Web was mostly brochureware, but Web 2.0 presents a whole other challenge. While handheld browsers are still figuring out how to do HTML right, desktop browsers are busy scaling the Web up in brand new ways -- and none more aggressively than Google.
Take the Chrome browser, for starters. Google wasn't content with the pace of browser development from the current big players, so it came up with its own HTML engine, one that observes Web standards while discarding some of the legacy ideas from the early days of the Web. It's even gone as far as to implement Chrome as a plug-in for the less-than-standards-compliant IE6, a move that's sparked no end of debate among the competition.
As important as a standards-compliant rendering engine is, however, Chrome's V8 JavaScript engine is equally crucial. Google recognizes that scaling today's Web up means scaling it out -- by taking advantage of the client's processor resources to offload some of the application logic from the server. Chrome's blistering JavaScript performance has spurred the other players to follow suit with accelerated JavaScript engines of their own.
But Google hasn't stopped there. It has also brought us Google Gears, which further accelerates JavaScript and provides a means to store Web application data locally on the client. Taking the idea of "scaling out" to its ultimate, Google offers Native Client, a technology that allows the browser to execute native x86 binaries delivered over the Web.
Each of Google's technologies is another step in transforming the role of the desktop browser. In Google's vision, the browser isn't merely a thin client for displaying Web content; it's an active participant in the Web applications ecosystem, sharing UI, storage, and even data-processing chores with the server. We're already at Web 2.5 and counting.
Mobile browsers can't keep up
That's great if you're designing Web applications for the desktop, but mobile is still largely a Web 1.0 world. Compared to a modern desktop browser like Chrome, today's smartphone browsers are feeble toys. They're getting better, but the idea that you could have the same Web experience on a handset as on the desktop is still a pipe dream.
Take HTML rendering, just for starters. Handset screen sizes are still a problem, but modern Web standards have made coding for diverse form factors much easier -- if the browser follows the standards, that is. Good luck finding one that does! According to Peter-Paul Koch, even browsers that implement WebKit have varying degrees of standards compliance -- enough so that Koch claims "there is no WebKit on mobile." And what about the handsets that don't implement WebKit?
JavaScript is another problem. On my BlackBerry, JavaScript performance is abysmal. Carriers must not like that interminable "running script" message either, because many of them ship my handset with JavaScript disabled by default. And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase. You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java).
Gears technology is available on Google's Android OS, but good luck finding it on other smartphones. And Native Client technology is completely out of the question; it relies on properties of the x86 architecture for its security model, so it can't be ported to any current handset.
Can developers support two Webs?
In short, while the Web experience on the desktop is undergoing a technological transformation -- scaling out as it scales up -- the mobile browsing experience isn't much better than how desktop browsing was a decade ago. The more that modern Web applications take advantage of the new client-side technologies available in desktop browsers, the more the divide between the desktop Web and the mobile Web widens.
To meet the needs of mobile browsers, developers need to think in terms of scaling down -- falling back on basic Web technologies that won't tax the capabilities of low-powered devices. Too often, however, that simply means writing a separate UI strictly for mobile users. The result? Mobile Web applications are in pretty much the same boat as they were when the first WAP-enabled handsets appeared: two separate development tracks, one for the desktop and one for mobile.
Call that an opportunity if you want. I call it a waste of potential. So if it sounded like I was knocking Adobe last week, far from it; if Flash can solve the problem of scaling the Web, it would be a boon for everybody. Unfortunately, the mobile world seems determined to keep Adobe -- or anyone else -- from doing it.
This story, "The sad state of the mobile Web gets even sadder," was originally published at InfoWorld.com. Follow the latest developments in application development and mobile at InfoWorld.com.