第 1 章 客户端架构
今天，客户端开发显然需要在HTML驱动应用架构中更多地思考和投资。随着Web应用的发展，我们见证了从具有紧耦合模板逻辑以及繁重的后端处理的传统服务器端框架向松耦合的JavaScript的转变，实现任何时候不管是上线还是离线都能运行。
但是，这只是过去的重复吗？在20世纪八九十年代，我们不是已经经历了胖客户端时代（如图1-1所示）吗？
和20年前不同，浏览器—如今的客户端平台要强大得多，更不要说移动浏览器了。此外，如今的客户端能够通过浏览器和蜂窝网络报告各种有趣的数据，例如你所在位置的经纬度。
推动浏览器成为客户端平台的另一个因素是许多公司，包括Google、Apple、Mozilla和Microsoft，每周对它们的混合胖客户端技术平台进行数千种改进。
过去，建立严重依赖服务器的应用程序大有益处，这使核心的后端开发人员无须担心DOM操纵和CSS。如果开发人员能够获得与后端代码紧密相关的数据表格或者分页组件，生成兼容IE6到IE8的标记，就很了不起了（见图1-2）。
但是，这种自动生成的标记是要付出代价的，特别是在当今快速变化、分裂的浏览器世界。我们一直都需要灵活可控的标记。开放Web的变化比任何时候都快，用户界面不再允许服务器成为过去的陈腐观念和如前高速可伸缩的前端代码之间的瓶颈，开发人员从未像现在这样关心过浏览器的性能。标记的显示和异步资源的加载可能成就你的应用，也可能毁灭它。更轻快的前端等于更多的线索转化、更高的SEO排名和更低的数据中心成本。
1.1 了解HTML5
在HTML5和移动设备出现之前，前端（或者UI）开发人员不用关心用户界面后面的架构，眼前充满的是破解（Crack）和专利的插件。许多开发人员专注于支持IE6、Firefox、Safari等少数几种浏览器，他们编写清晰的语义标记，担心XHTML的有效性，偶尔也会导入JavaScript程序库，以创建一些漂亮的效果。
一旦开发人员处理完浏览器的问题和给定应用程序的缺陷，剩下的事情就几乎一样了。高级Web应用程序的架构主要在服务器上被管理。应用程序依赖于入站HTTP请求的速度以及标记显示到用户Web浏览器的速度。利用服务器端模板和组件框架，服务器解析模板，数据与常规的XHTML或者HTML标记交织在一起；对于Java，则可以使用JSP、Velocity、Tiles、GWT或JSF来实现；对于Ruby，可以使用ERB、HAML或者RedCloth，这样的框架还在不断涌现。每个服务器端Web框架都有一个附属或者可以选择的UI模板引擎，这就是过去十几年的UI开发方法，而现在应该考虑建立新一代Web应用的方法了。
你可能会问“为什么我们需要改变前端的生成方式？”或者“为什么我们要将所有代码移到浏览器中运行，而不是在服务器上运行？”因为Web浏览器正在成为一个平台。我们的应用程序现在存在于比其前辈的能力提高了几个数量级的平台（或者浏览器）上。Web应用程序就是这样。我们不再创建网站，而是用HTML5、CSS和JavaScript创建可靠的应用程序。如图1-3所示是HTML5标志。
现在，我们应该回头看看应用程序的构建方法，为客户端编程打下基础。开发人员必须了解，为任何应用程序构建一个可伸缩、稳固的用户界面需要的框架和方法。