Web前端技术趋势：HTML5仍不宜用做生产

通过这段时间国内(百度，淘宝，新浪)及国外(Facebook，Youtube，Yahoo)各大公司的集中自曝，咱们能够从中总结出2010 Web前端技术的一些趋势。总的来讲，随着后端技术(存储，并发，分布式)的成熟，各大公司已经把重点从后端架构调整/建设转移至前端(TTI时间，快速发布，带宽利用率)。但做为明星技术的HTML5/CSS3，都未正式成为各公司的考虑重心，虽有所尝试，但在关键功能上，均未成为主力。这也W3C对当前HTML5/CSS3标准现状的表述：“不适宜用做生产环境”一致。
　　基本概念
　　Web前端技术的范围
　　1. 编程语言/技术(HTML，JavaScript，CSS等)
　　2. 跨浏览器兼容性/支持(JS Framework，CSS Library)
　　3. 网络传输性能(并行下载，带宽利用率)
　　4. 浏览器渲染时间/性能(TTI即用户可交互前等待时间，JS执行性能)
　　今年就我我的的感受，Facebook无疑又成为了技术上的明星，在你们还在感慨其对于PHP的重大改进HipHop(Blocked inside 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 timer functions。这些方案自己没有什么特殊的，大部分均可以顾名思义，须要解释一下的多是link controller，其含义是将标准的HTML LINK请求转换为Ajax请求(经过绑定click事件)。Facebook的难得之处是提供了这一整套完整的解决方案，最大程度上保证了网站的可用性。
　　效果：
　　提升了10%-30% 的网站传输时间，并提升了20%-30%的服务端页面渲染速度。
　　使用范围：
　　45%的Facebook页面使用了此项技术。
　　PageCache
　　简单的说，就是将访问过的页面缓存在客户端。但咱们知道，做为Facebook这样交互性很强的网站，须要保障用户能尽早的得到更新后的信息，而不是给用户展现一个毫无心义的过时页面。
　　Facebook设计了一个框架来识别一个页面是否来自于缓存(猜想：页面首次加载完毕后将全部Ajax的Callback和Result缓存在本地。Facebook页面是基于Ajax获取页面内容，参见BigPipe)，若来自于缓存，经过Ajax来更新所需更新的模块(猜想：经过JS预先定义本页面所需更新的div Id及对应的callback handler，并在页面下载时同时下载下来)。
　　其提到了三种更新类型：增量更新，用户复写(例如用户在页面上回复了一则评论)及跨页更新(例如在消息详细页面将一则消息标识为已读，需将首页的未读消息数进行更新。)。核心思路仍是依据Ajax进行更新。具体思路为：
　　增量更新：只要页面来自于缓存，即更新全部预约义的需增量更新的模块。
　　用户复写：经过HistoryManager记录用户操做并在cache页面读取后重放全部被标记为“replayable”的操做。
　　跨页更新：经过服务端Database API发送信号至客户端将过时缓存标识为invalid(不清楚如何实现。也许是DB端提供一个开放的webservice，客户端经过Ajax持续访问此API来得到此信息)。得到了缓存过时信号后，经过Ajax更新须要更新的信息。
　　Facebook顺带提到了一个更新Ajax内容避免页面变化/闪烁的小技巧，就是先将需更新的地方设置为blank，而非直接更新其内容。
　　效果：
　　加速了10倍的网站响应时间并节约了20%的服务端页面渲染成本。
　　BigPipe
　　此项技术经过将页面分割为各个Pagelets的方式，将整张页面的获取/渲染变成了并行的方式(感受很是像iframe sets，但Facebook使用Ajax实现。)。此项技术是Quickling和PageCache的基石。此技术包含了服务端/客户端两方面，在先后端均打破了以往页面的渲染形式。
　　实现细节：
　　Pagelet的Response为JSON格式，包括id,css,js,content,onload等属性及相应内容，收到后会经过预约义好的JS function来进行渲染。
　　Pagelet提供的高级功能：Pagelet的继承，Phased Rendering(猜想：依据规则渲染，也就是依据Pagelet的Response进行渲染)，跨Pagelet依赖(数据依赖，显示依赖，JS依赖)。
　　BigPipe的三种模式：
　　一次渲染模式：即普通模式，支持搜索引擎，用来支持那些不支持JS的客户端。
　　管线模式：即并行模式，并行请求，并即时渲染。
　　并行模式：并行请求，但在得到全部请求的结果后再渲染。
　　效果：
　　提升了2倍的页面响应时间。
　　YouTube面临的问题
　　天天2Billion的访问。每分钟上传35小时的内容。可YouTube须要即时播放视频!越快越好。
　　YouTube解决方案
　　1. 将JS引用位置从页首移至页尾。
　　2. 直接嵌入Flash Player(YouTube以前使用JS来加载Flash Player)。经过页尾的JS来判断客户端的Flash版本(或不支持Flash)，来替换预先嵌入的Flash Player或内容(若是须要的话)，用来支持特定的客户群。
　　效果：页面渲染时间从～400ms下降为～200ms。Flash播放时间从～1200ms下降为～1100ms。
　　3. 预加载视频链接： 经过使用JS建立Image引用视频内容来与解析DNS并预开启一个connection供以后使用。
　　效果：创建视频链接的总时间从～260ms下降为～180ms。
　　4. 提供简化版： 这个很无聊，就是提供一个简版。
　　效果：页面加载时间从～1750ms下降为～1100ms。
　　5. UIX Widget系统：延迟加载非关键内容。其实整段没什么新意，大部分省略，无非是经过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_... 自行观赏。
　　Taobao
　　还在讨论一些什么时候使用Ajax，什么时候不使用的问题。略过不提。有兴趣的能够移驾http://ued.taobao.com/blog/20... 自行观赏。
　　相反的，淘宝的精益测试却是引发了个人兴趣，出自微软的淘宝员工鹤云讲述了淘宝是如何进行CI(持续集成)的。有一些经验例如代码覆盖率测试也给人一些启发。感兴趣的同窗可移驾至http://www.infoq.com/cn/prese... 观赏。
原文来自：http://tech.it168.com/a2010/1...
转载于猿2048:➮《Web前端技术趋势：HTML5仍不宜用做生产》