经过这段时间国内（百度，淘宝，新浪）及国外（Facebook，Youtube，Yahoo）各大公司的集中自曝，我们可以从中总结出2010Web前端技术的一些趋势。总的来说，随着后端技术（存储，并发，分布式）的成熟，各大公司已经把重点从后端架构调整/建设转移至前端（TTI时间，快速发布，带宽利用率）。但作为明星技术的HTML5/CSS3，都未正式成为各公司的考虑重心，虽有所尝试，但在关键功能上，均未成为主力。这也W3C对当前HTML5/CSS3标准现状的表述：“不适宜用作生产环境”一致。

基本概念

Web前端技术的范围

1. 编程语言/技术（HTML，JavaScript，CSS等）

2. 跨浏览器兼容性/支持（JS Framework，CSS Library）

3. 网络传输性能（并行下载，带宽利用率）

4. 浏览器渲染时间/性能（TTI即用户可交互前等待时间，JS执行性能）

今年就我个人的感觉，Facebook无疑又成为了技术上的明星，在大家还在感慨其对于PHP的重大改进HipHop(Blockedinside China mainland)的时候，今年Facebook又在前端技术方面给大家带来了惊喜。

Facebook面临的问题

500M（Million）注册用户，50%每天至少访问一次，用户平均每日在线时间为5小时25分钟。带宽及服务器压力均很大。

Facebook的解决方案

Quickling

Facebook提出了一个新名词Ajaxify，顾名思义，就是将传统的POST/GET转换为Ajax请求。优点显而易见，首先减少了不必要的HTML传输，只请求和渲染页面需要更新的部分，这就相应减少了所需传输的内容加快了内容送达至用户的时间。并且也减少了服务端对HTML的不必要的渲染。Facebook也提到了可以减少session的重复load/unload。

使用Ajax也许不是什么新鲜的新闻，大家拒绝这项技术的原因可能很大程度基于SEO的需求。解决方案也很简单，将Ajax只是作为提高用户体验的手段，而不是浏览网站必须的方法，即可解决SEO的问题（P.S.Facebook不需要SEO）。

一些实现细节：

整套方案包括：Link Controller, HistoryManager, BootLoader, Busy Indicator,CSS Unloading, Permanent link support, Resetting timerfunctions。这些方案本身没有什么特殊的，大部分都可以顾名思义，需要解释一下的可能是linkcontroller，其含义是将标准的HTMLLINK请求转换为Ajax请求（通过绑定click事件）。Facebook的可贵之处是提供了这一整套完整的解决方案，最大程度上保证了网站的可用性。

效果：

提高了10%-30% 的网站传输时间，并提高了20%-30%的服务端页面渲染速度。

使用范围：

45%的Facebook页面使用了此项技术。

PageCache

简单的说，就是将访问过的页面缓存在客户端。但我们知道，作为Facebook这样交互性很强的网站，需要保障用户能尽早的获得更新后的信息，而不是给用户展示一个毫无意义的过期页面。

Facebook设计了一个框架来识别一个页面是否来自于缓存（猜测：页面首次加载完毕后将所有Ajax的Callback和Result缓存在本地。Facebook页面是基于Ajax获取页面内容，参见BigPipe），若来自于缓存，通过Ajax来更新所需更新的模块（猜测：通过JS预先定义本页面所需更新的divId及对应的callback handler，并在页面下载时同时下载下来）。

其提到了三种更新类型：增量更新，用户复写（例如用户在页面上回复了一则评论）及跨页更新（例如在消息详细页面将一则消息标识为已读，需将首页的未读消息数进行更新。）。核心思路还是依据Ajax进行更新。具体思路为：

增量更新：只要页面来自于缓存，即更新所有预定义的需增量更新的模块。

用户复写：通过HistoryManager记录用户操作并在cache页面读取后重放所有被标记为“replayable”的操作。

跨页更新：通过服务端DatabaseAPI发送信号至客户端将过期缓存标识为invalid（不清楚如何实现。也许是DB端提供一个开放的webservice，客户端通过Ajax持续访问此API来获得此信息）。获得了缓存过期信号后，通过Ajax更新需要更新的信息。

Facebook顺带提到了一个更新Ajax内容避免页面变化/闪烁的小技巧，就是先将需更新的地方设置为blank，而非直接更新其内容。

效果：

加速了10倍的网站响应时间并节约了20%的服务端页面渲染成本。

BigPipe

此项技术通过将页面分割为各个Pagelets的方式，将整张页面的获取/渲染变成了并行的方式（感觉非常像iframesets，但Facebook使用Ajax实现。）。此项技术是Quickling和PageCache的基石。此技术包含了服务端/客户端两方面，在前后端均打破了以往页面的渲染形式。

实现细节：

Pagelet的Response为JSON格式，包括id,css,js,content,onload等属性及相应内容，收到后会通过预定义好的JSfunction来进行渲染。

Pagelet提供的高级功能：Pagelet的继承，PhasedRendering（猜测：依据规则渲染，也就是依据Pagelet的Response进行渲染），跨Pagelet依赖（数据依赖，显示依赖，JS依赖）。

BigPipe的三种模式：

一次渲染模式：即普通模式，支持搜索引擎，用来支持那些不支持JS的客户端。

管线模式：即并行模式，并行请求，并即时渲染。

并行模式：并行请求，但在获得所有请求的结果后再渲染。

效果：

提高了2倍的页面响应时间。

YouTube面临的问题

每天2Billion的访问。每分钟上传35小时的内容。可YouTube需要即时播放视频！越快越好。

YouTube解决方案

1. 将JS引用位置从页首移至页尾。

2. 直接嵌入Flash Player（YouTube之前使用JS来加载FlashPlayer）。通过页尾的JS来判断客户端的Flash版本（或不支持Flash），来替换预先嵌入的FlashPlayer或内容（如果需要的话），用来支持特定的客户群。

效果：页面渲染时间从～400ms降低为～200ms。Flash播放时间从～1200ms降低为～1100ms。

3. 预加载视频连接： 通过使用JS创建Image引用视频内容来与解析DNS并预开启一个connection供之后使用。

效果：建立视频连接的总时间从～260ms降低为～180ms。

4. 提供简化版： 这个很无聊，就是提供一个简版。

效果：页面加载时间从～1750ms降低为～1100ms。

5. UIXWidget系统：延迟加载非关键内容。其实整段没什么新意，大部分省略，无非是通过Ajax在页面渲染完后再来动态加载非关键内容。比较特别的是利用JS的事件冒泡，在最上层用一个handler来处理各种事件（优点不详。。也许只是代码比较简洁集中吧），通过CSS来标识和识别对应的handler。

Yahoo Mail

Yahoo如何构建下一代的Mail系统？答案就是通过YUI3。Yahoo的技术绝对是最优的，其已经将web前端技术发展到一个非常成熟的地步，照顾到web的方方面面（数据压缩，模块化，高效CSS，非阻碍式JS加载，静态内容提供，利用浏览器cache等等），所以也鲜有创新了。某种程度上来说，Facebook的一些所谓创新也不过是后知后觉，Yahoo早已考虑并实现了这些方案，只是也许不是那么有针对性而已。

Baidu

感觉整体倾向于组织结构介绍及一些比较过时的内容。如有兴趣可移驾至http://v.youku.com/v_show/id_XMjE5OTM0NTA4.html 自行观赏。

Taobao

还在讨论一些何时使用Ajax，何时不使用的问题。略过不提。有兴趣的可以移驾http://ued.taobao.com/blog/2007/12/20/d2-2/ 自行观赏。

相反的，淘宝的精益测试倒是引起了我的兴趣，出自微软的淘宝员工鹤云讲述了淘宝是如何进行CI（持续集成）的。有一些经验例如代码覆盖率测试也给人一些启发。感兴趣的同学可移驾至http://www.infoq.com/cn/presentations/hy-tabao-lean-test 观赏。

新浪博客

也是一些组织架构，开发方式的内容。介绍了一下新浪自己的JS框架。并无太多亮点。有兴趣的移驾http://v.youku.com/v_show/id_XMjE5OTYzMTI4.html 自行观赏。

原文地址：http://www.cnblogs.com/pandora/archive/2010/12/12/1904032.html

建议继续学习：

1. 2010网页设计趋势    (阅读：6360)
2. 2011年手机产品设计趋势（1）：精致实用的界面    (阅读：3795)
3. web设计趋势与潮流    (阅读：3344)
4. 2011年手机产品设计趋势（2）：推送    (阅读：2168)
5. 2011年网页设计发展趋势    (阅读：1841)
6. 2010年过去了，我写篇日志留点印记    (阅读：1831)
7. 2011年手机产品设计趋势（3）：硬件与应用    (阅读：1858)
8. 个人之势与门户之势    (阅读：1807)
9. 移动互联趋势观察    (阅读：1652)
10. 我的2010,2011    (阅读：1492)