【IT168评论】去年，Facebook在移动设备上的App弃用HTML5技术，并且宣称使用该技术是公司创立以来最大的策略错误。身为指针性的网络应用平台及开发商，Facebook的决策和论点当然引起了广泛的讨论。究竟，以HTML相关技术为基础的客户端应用程序，和原生的技术相比起来各有什么优劣、应用时又需考虑那些因素呢?本回让我们继续探讨下去。

　　为前端应用程序赋予可移植性

　　即使在一开始，以HTML为用户接口基础的模式，是应用在用户以浏览器连上Web服务器的架构下，但是，因为具有不少好处，所以，渐渐也有不少人将这种方式应用在客户端(client)应用程序。

　　传统上，客户端应用程序都是以原生(native)的方式开发而成，使用操作系统或平台上原生的API、原生的用户接口组件，但是在应用以HTML为基础的技术之后，原生的部份主要只剩下启动的应用程序本身，绝大多数用户所接触到的接口部份，皆是以HTML为基础的技术(当然包括了JavaScript)所完成的。

　　为什么有愈来愈多的开发者对这种模式趋之若鹜呢?我想最主要的因素之一，便是这种模式在应用程序的前端提供了较好的可移植性。

　　很多年前，就有不少人预言，操作系统做为应用程序运行平台的特性，将会愈来愈不明显，接下来只会有一种主要的平台，那就是Web。这样的预言到了今天来看，几乎可以论断它的实现。即使不同的操作系统依然存在(但Windows平台也不若以往那般强势)，但是，人们对于操作系统的倚赖却愈来愈低，原因便是人们早就习惯在浏览器上连往各种不同的网络服务、使用各种应用程序。

　　以往，浏览器尚有大大小小的兼容性、标准化的问题，而到了今天，这些问题已经消除了许多。以Web做为一个共通的平台，在各种浏览器上呈现、运行，难度也降低很多。无论你使用什么平台，从手机、平板、到个人计算机，都有浏览器。即使仍然有若干细节性的问题，但我们应该可以说浏览器是目前最具可移植性的平台。

　　当你采用以HTML技术为基础的模式来开发客户端的应用程序时，即使提供启动应用程序本身还是原生的，但主要的应用程序仍然是在原生应用程序所内嵌的浏览器之中所运行。对于不同的操作系统平台，你只需要分别为它们做出原生的启动程序即可。

　　所以说，在Windows上，你可以用MFC做出一个启动程序内嵌浏览器的ActiveX控制组件;在Mac OSX上，你也可以用Cocoa也做个启动程序，接着内嵌WebView。无论是那一种浏览器组件，都连上相同的Web服务器端，都应用相同的HTML技术、运行相同的JavaScript程序。尤其在特定操作系统的影响力愈来愈低的今天，客户端应用程序的可移植性愈形重要，这种模式所提供的可移植性也愈来愈关键。

　　应用程序更容易修改与部署

　　除了提供更高的可移植性之外，许多软件开发者会考虑使用以HTML为基础的技术于客户端应用程序，是因为便于弹性的修改，以及动态的部署。

　　如果你开发过原生应用程序，就会知道，在你的原生应用程序部署出去之后，一旦日后因为像是臭虫的修正、功能的扩展等种种原因而改版，除了对原生应用程序做必要的修改之外，你还会需要面临重新部署到客户端的问题。

　　所以，很多开发者必须在他们的应用程序中加上自动更新的机制，无论是使用者手动检查、或是应用程序自动检查，都要能够检查是否有新的版本，并且下载新版本，接着予以更新。这无疑是个复杂的机制，而且你不见得能够确定客户端应用程序的确无误的完成版本升级的动作。当你的服务器端已经改版到新的逻辑，但客户端应用程序却没有时，就有可能引发一些不可预期的问题。 客户端应用程序也有可能好长一段时间都没有改版了，更新程序还得检查其版本和最新版本间的组态差异，才能正确将其更新。总之，这并不是一个容易处理的议题。

　　在过去产品更新周期长的时候，这个问题或许影响不那么大。但是，自从Web来到2.0的世代之后，产品改版的周期更加频繁。就像Facebook，你或许随时都可能发现到它又做了程度不同的功能修改。在这种情况下，客户端应用程序需要支持更频繁的更新模式，若是没有处理好，就会变得相当的恼人。举例来说，相信，许多人都不太适应iTunes的频繁改版，以及它的更新方式吧。

　　不过，当你使用HTML来做为客户端应用程序的基础时，应用程序可以说是随时从服务器上取得，随时都是最新的版本。在这种架构下，数据是在服务器上取得计算、产生HTML网页的逻辑则是在服务器上产生，再搭配浏览器上执行的JavaScript程序，提供一些动态生成的效果及互动方式。即使应用程序需要改版，也只需要部署到服务器端即可。除非客户端的启动程序需要修改，否则，只要在服务器端完成部署，客户端即可随时使用到最新版本的应用程序，不需要针对客户端的应用程序做任何的改版。

　　这么一来，对于想要频繁对应用程序改版(无论是问题的修正或是新功能的扩增)的开发者而言，此种模式便显得十分方便。

　　除了个人计算机上的客户端应用程序，可以藉此解决频繁改版的部署问题之外，对于像iOS平台上，也能提供一些额外的便利性。

　　因为在iOS App的上架规范下，每当你的应用程序要改版时，就得进行重新送审的程序，而重新送审的程序通常耗时颇长。这对于想要时常修改、调整App功能，尤其是用户接口部份的开发者而言，无疑会构成一大障碍。

　　不过，一旦采用以HTML为基础的模式来开发，送审的部份只是启动程序，日后有功能的修改，只要在服务器端修改，客户端所看到的、所使用到的，都会是最新的版本。而且，这样的修改不需要任何新版的客户端应用程序，而这也意味着并不需要重新将App送审、重新再等待一段冗长的流程。

　　以Web为中心，不需投入各种原生平台的开发

　　除了部署方便之外，当你采用HTML为基础的模式来开发客户端应用程序时，你所需要的开发技巧还是和Web应用程序设计一样，并不需要随着不同的原生平台，而使用该平台下的语言、应用程序框架、SDK及API等，只需要专注在相同的技术领域即可。

　　对于开发团队而言，也不需要招募太多技能组合的程序设计者，只需要以Web应用程序技术领域为主即可。不论是技术、平台、人、还有思维，一切依旧以Web为中心。在现今这种以Web程序设计为主流的开发世代来说，这可以说是一大优势。对于想要兼容网站使用者，以及特定客户端应用程序用户的网络服务来说，更是可以共享资源。

　　当Web应用程序开始流行在MVC的基本概念下，在前端大量倚赖JavaScript来动态呈现数据，同时运用Ajax方式至服务器端取得数据时，不同的客户端，无论是个人计算机浏览器、平板计算机浏览器、手机浏览器、或是平板、手机、个人计算机上的专用客户端应用程序，都可以共享服务器端上的所有服务，以及和客户端沟通的协议，唯一需要随着平台而改变的，仅有在客户端处理用户接口的部份而已。

　　以Web为中心的开发概念，可以将对多种平台的支持，都集中在单一的计算资源之下，这也是以HTML为基础的模式的好处。

　　正因为以HTML为基础的模式有这么多好处，才会有这么多的开发团队决定采用，当然也包括Facebook，而后来Facebook竟然放弃这种模式!下回中，让我们试着来将它和原生的应用程序再比较。