上星期我一直在思考Adobe为什么想要大力的推广Flash把它定位为移动设备的平台，它面临着一场艰苦的战斗，尤其是要把Flash应用编译成二进制文件来在iPhone上运行。Open Web标准似乎为今天的智能手机指明了更好的开发目标，但移动网络却显然还没有做好准备，而根本上的问题就在于可扩展性。
当开发者们谈论可扩展性的时候，他们通常想的只是怎样扩展。也就是说，当负载不断增加的时候，所开发的应用能不能有效的利用一切现有资源来满足需求？在这点上Web应用一直做的不错（只要有良好的编码），而且不断的技术进步使它们越做越好。
而移动设备投入进来后，开发者面临着一个全新的挑战。现在，他们考虑的应用需要缩小，要在移动设备上提供最接近于桌面应用的体验，却要同时面对低处理能力、屏幕分辨率、网络带宽和存储容量的挑战。这是一件棘手的事，不只是针对Java和Flash这样的运行时，对移动Web开发标准来说更是前所未有的挑战。
Google引领的全新移动Web开发标准
问题不只是小屏幕和各种古怪的输入设备，Web 2.0的推出进一步拉开了差距。在手持设备的浏览器仍在琢磨怎样才能正确显示HTML的时候，桌面浏览器却已经忙着以全新的方式扩大Web的角色，在这方面没有比Google做的更积极的。
例如Chrome浏览器，Google并不满足于跟上目前主流浏览器的发展脚步，所以他们拿出了自己的HTML引擎，在遵守网络标准的同时放弃了一些Web早期的传统想法。在最新的进展中，Chrome竟然可以把自己作为一个插件在低于兼容标准的IE 6中运行，此举引发竞争对手的大量争论。
同样至关重要的是Chrome的V8 JavaScript引擎，Google坦承如今的Web应用需要向外扩展，因此更应该从客户端那里多获取一些处理能力来减轻服务器的负担。Chrome的JavaScript表现激发了其他竞争对手不断的加速自己的JavaScript引擎。
不过Google并没有就此停步。它带来了Google Gears，进一步加速JavaScript并且可以将Web应用数据存储在本地客户端。最能体现Google 的"向外扩展"精神的是Native Client，允许浏览器通过网络执行原始的x86二进制文件。
Google的每一项技术都是改变桌面浏览器角色的一步。在Google的眼中浏览器不只是用于显示Web内容的瘦客户端，它是一个Web应用系统的积极参与者，能够与服务器共享用户界面、存储甚至数据处理工作。
移动浏览器跟不上脚步
我们可以说桌面Web应用已经快走到Web 2.5时代了，这是伟大的进展，但移动领域却大体上还处在Web 1.0的世界。相对于Chrome等桌面浏览器，如今的智能手机浏览器还像是小孩子的玩具。它们的确越做越好，但想要在手机上达到桌面浏览器的Web体验还仍然是一个遥远的梦想。
从HTML的渲染开始，移动设备的屏幕尺寸仍然是一个问题，虽然现代的网络标准已经让针对不同外形的编码工作变得更加容易，然而真正严格执行标准的手机浏览器却数量很少，WebKit技术可以提供一些帮助，然而即使执行WebKit的浏览器还存在不同程度的差异，更何况还有很多不用WebKit的手机。
JavaScript是另一个问题，比如我的黑莓手机的JavaScript性能就总是让人摇头。运营商们想必也不喜欢无休止的弹出"脚本运行出现问题"的消息框，因此很多手机在出售时JavaScript功能默认是关闭的。苹果的iPhone OS 3.0操作系统提升了JavaScript性能，但只能说是略有改善，你仍要面对在运行Flash或Java时处理能力不足的问题。Google的Gears技术可以用在Android操作系统上，但到哪里找到另一台Android手机呢？你需要好运气。
开发者可以支持两种移动Web开发标准吗？
总之，当桌面上的Web体验正随着技术改进不断的向外扩展时，移动的Web体验其实比起十年前的桌面好不到哪去。现代Web应用的开发中使用的客户端技术越先进，桌面Web和移动Web的差距就越大。
为了满足移动浏览器的需求，开发者需要思考如何缩减他们的应用，怎样重新使用最古老最基本的网络技术。不过，在很多时候这意味着要专门为移动的用户重写单独的界面。而结果是什么呢？桌面和移动，两个独立的开发轨道，这和WAP手机刚出现时的情况几乎没有什么不同。如果你喜欢的话可以称之为机会，但我要说这是一个潜在的浪费。
