Dec27

2013 前端技术盘点

本文曾发表于2013年12月《程序员》,个人收集和一些拙见,难免有错误和疏漏,请各位补充。文中加粗的关键字不少,没有一一添加链接,Google一下即可找到相关资料。 2013年,尽管前端技术在无线领域受到了挫折,但这无法减缓其发展势头。在基础技术方面,规范和标准的发展、浏览器的快速演进为将来的Web应用打好了根基;随着网站规模的进一步变大,交互变得更复杂,大家更关注用新的开发模式来解决问题;更重要的是,经过多年积累,在前端工程实践上我们有了丰富的成果。本文将从多个角度介绍今年前端技术的发展,其中会穿插若干对前端发展的思考。 方兴未艾的规范和标准 自从HTML5推出后,W3C和各大浏览器厂商都在加紧推动规范发展和实现,尤其是手机浏览器对规范的支持程度,已成为国内浏览器宣传的卖点。对于W3C的正式规范,大多数都已经被现代浏览器实现,而我们更应关注快速发展中的Working Draft规范。它们不仅对实际开发有帮助,更重要的是它们代表了Web未来的发展方向。 Web Components规范定义了未来的HTML组件,其中最重要的部分是Shadow DOM和Custom Element,除此之外还包括HTML模板、HTML imports和Decorators。Shadow DOM能将组件的代码和使用者的代码彻底分离,通过在文档渲染时插入一颗DOM子树,但这子树并不在主DOM树中,因而外部的CSS无法直接影响Shadow DOM中的元素;当然,Shadow DOM能提供事件API、Javascript API、CSS API供外部控制。Custom Element则允许开发者自定义HTML标签,让页面更语义化的同时,还能为元素加入属性和方法,以提供特定的功能供外部调用。 WebDriver规范和 Selenium 2 WebDriver 自动化测试框架 API 十分类似,它取代了嵌入到被测Web应用中的Javascript,由浏览器直接支持的WebDriver,避免了Javascript安全模型的限制,还能利用操作系统级的调用来模拟用户输入。Firefox、IE、Opera 和 Chrome 都对其有一定支持,也能通过 WebDriver 完成 Android 和 iPhone 的移动web应用测试。 Webapp Working Group今年很活跃,前文提到的 Web Components 规范就是来自这个小组。它们今年的进展还包括 Push API、Streams API、UI Events 等规范。 W3C去年还成立了System Applications Working Group,目标是定义运行环境、安全模型和相关的API用来构建能与原生应用匹敌的web应用。他们在今年提出了一系列规范,其中比较重要的有:用来定义和引用Webapp的App URI规范;能定期唤醒应用的Web Alarms API;和系统短信服务通讯的Messaging API。 W3C所有规范都会公开发布,在 http://w3.org 上可以找到各个工作组的当前进展,你也可以订阅他们的邮件组。 除了W3C规范,另一个重点是 […]

trackback Tags: 评论 (12)

Dec11

中国velocity web性能与运维大会 – part 2

第一天晚上 最后一个session结束以后,还在问魏博士一些问题的时候,百姓网的人过来请他去参加晚上的一个交流沙龙,同时也邀请了我们。我看时间还早,就一起上了他们的大巴,在车上,我很累就睡了一会,结果一睁眼发现居然到石景山了。 到了咖啡店,大家先拿了一些东西各自吃完,然后轮番自我介绍,沙龙就开始了。我后面的一个隔断就坐着蒋博士,我看刘江老师站起来了,于是赶紧霸占了他的位置,一群人就开始围着他问起来。 最开始大家都会问一些技术问题,比如bigpipe的一些实现细节啦,pagelet的调用方式啦。他很惊讶我们在根本没有看到实现的情况下,就能提出一些细节性的问题,尤其是浏览器差异的问题,我们的一致答案是,因为经常都在处理这些问题,尤其是IE6的问题。然后我问他,facebook的用户,IE6占多少比例。他说之前应该在5%左右,最近经过一些推动,已经降到2%左右了。当知道国内浏览器份额和原因的时候,他连连惊叹,居然还有这么多的原因。 后面渐渐大家都比较放松了,话题也慢慢的聊开,他也会问我们一些国内互联网的情况。其实他们这类人最想知道中国互联网的状况,想找机会回来。因为已经在国外呆了这么多年,如果不想在大公司养老,回国就是他们的最佳选择了。有大公司的招牌,财富也积累的差不多了,中国又是一个正在成长的市场,到处都是机会。 快到结束的时候,百姓网还给他们的一个同事庆祝了生日,貌似这是他们的一项例行活动。他们现在只有10个技术人员,公司一共30人,规模很小,但是这次大会却给大家留下了比较深的印象。在第一天入场的时候给所有的参会者一瓶饮料,下午可以再领一瓶。饮料上有他们的广告,这样绝大多数人都知道了这是一个什么样的公司。他们的摊位也和其他赞助商不同,其他的都是广告视频+宣传册,几乎没有人停下来,而他们是一个叠杯子游戏,4秒以内可以赢一个鼠标,这样就吸引了很多人去玩,摊位背后的大海报浏览量应该不小。 第二天 第一个session是九点开始,于是我起了个大早,8点半就到达会场,抢了一个第二排的好座位。 卷土重来:服务器端JavaScript 这是老道在这次大会上的第二个session,主要讲的是nodejs这个服务端JS环境,因为我一半年前就用过nodejs,里面的概念都很熟悉,包括event loop的好处,服务端js能配合本地js,在一些比较老旧的浏览器上用服务端js直接返回数据,现代浏览器用客户端js等。 但是据我的使用,nodejs仍然是不稳定版本,之前我使用的时候,库特别少,而且接口不稳定,会发生比较大的变化。不知道现在情况如何了。 Facebook: 一个可持续发展的高性能网站 经过第一天facebook的两个很有内容的session以后,大家都对这个session充满期待,而实际上魏博士也没有让大家失望。前面两个sesssion主要是分别介绍了facebook的两套系统,而这个session说明了他们采用什么样的思路构建这样系统的,如何保证优化的可持续性。 他首先提出了一个观念:fast by default,facebook成长的速度很快,如何才能让它一直保持快速呢?答案是用一个小的团队,关注性能和前端架构,用架构来保证优化。 然后提出了性能优化的四个周期:系统架构 - 测量数据- 分析理解数据-优化。过去我们可能只关注最后的优化结果,而不关注数据的来源和分析,更不关注系统的架构。在08年的时候,扎克发现facebook很慢,于是成立了一个专门的20小组来解决这个问题,一个多季度以后,问题被解决了,同时他们还得到了一个结论:如果我们的系统不能保证优化,以后网站还是会变慢的。于是成立了一个3-4人的专门小组,来关注系统架构问题,直到现在。 系统架构主要包含三个重要的事情: 做一件事情只有一个办法 有清楚的最佳实践可以让工程师follow 开发的时候不用关心性能 其实就是让系统做好所有的事情,工程师只需要按照给定的方式去写代码,一定是最优的。 其中举了一个很有意思的例子:facebook的cookie曾经很大,大到居然有2K,对网站的速度影响很大,最终,他们将cookie精简到了400bytes,但是他们还发现,cookie就像野草一样,是拔不干净的,工程师永远会写新的cookie,找到他的时候,他说,我的项目很紧急,就要上线了,你让我上线以后再修改吧。但代码上线以后,他又会说,我现在还有很多事情要做,cookie这个事情我真的没法安排。 最后,他们在开发环境中部署了一个小程序:“cookie monster”,如果有人写了他们不认识的cookie,这个程序就会把cookie在传输的过程中直接删除,并且给页面返回一个消息“这个cookie很好吃,我吃掉了”。这样以后,工程师在发现问题的时候,就会主动来找他们,他们会告诉工程师如何使用服务端cookie来做同样的事情。 接下来就是让数据说话,其实就是将数据记录和分析系统化,报表自动生成,在上线以后进行分析。 最后是让所有人都参与优化,他们认为,速度是产品的一个目标,而不是额外的东西。因此所有工程师和产品团队都需要理解和关注这件事情,在新人培训时有专门的课程进行培训,在新产品上线之前,他们会进行指导,保证性能优化。 facebook的系统架构提醒了我,很多时候我们如果仅仅关注目的,和与之紧密相关的部分是不够的,只要底层架构优化了,一些上层的改变就是轻而易举的事情。 这个session以后,又是很长的广告时间,我趁机到会场外面找人聊聊天,接着发现魏博士也在,前一天晚上没有和他聊过,于是又获得了一些其他的信息,包括facebook前端系统的开发,测试,部署步骤等。内容比较多,我将在后面的blog中单独发出,欢迎订阅我的blog获得更新消息。 下午全是国内公司的交流,而且大多和前端关系不大,听了淘宝的商品详情页面的优化实践以后,就坐同事的车回公司了。 这次大会收获很超出我的预期,facebook的两位博士介绍的东西很实在,交流起来也很坦诚,问到一些具体的细节的时候,都能不厌其烦的一一告诉我们;Youtube的那个session也给我现在的实际工作带来了不少启发;Douglas和steve的session嘛,就当联系英语听力了罗。 如果你也参加了本次大会,或者你对上面的内容的细节有兴趣,欢迎在下面留下你的评论,或者follow我的twitter进行进一步交流。

trackback Tags: 评论

Dec10

中国velocity web性能与运维大会 – part 1

这周二、周三是中国velocity web性能与运维大会,一位同事因故不能参加,于是我代替他参加了本次会议。 会议在西四环的世纪金源酒店,第一天早上是九点半开始第一个session,因为对路况预测不够,早上八点半才从甘家口出门,一路堵车很厉害,九点二十才到达会场。而此时门口排队check in的人还很多,把酒店楼梯都塞住了,场面比较混乱。不过幸好排了不到几分钟队后,一位会务MM说,因为会议快要开始了,大家可以现在先入场。 第一个session是steve的WPO产业已经到来,其实就是一个开题演讲,因为大会所有的主题就是围绕着web性能来说的。 而接下来的三个session就是赞助者的广告时间罗,淘宝、基调网络、网宿轮番上台。 Facebook网站的Ajax化、缓存和流水线 上午最后一个session,是facebook蒋博士的“Facebook网站的Ajax化、缓存和流水线”。在主持人用英文介绍完他,他thank you以后,第一句话就是“其实我能说中文的”,把全场都逗笑了。整场也逗是用中文进行演讲,理解起来毫不费力。 他首先介绍了一个很重要的衡量网站用户体验的指标:TTI(time to interact),也就是页面主体部分加载完毕的时间。有了这个指标以后,他们可以将有限的资源优先分配到对用户体验有利的部分上。 Facebook网站的用户行为统计也是他们做性能优化的数据基础,他们的用户往往要一口气访问十几个甚至几十个页面,而且往往在3-5个页面以后会回到自己的个人主页。 接下来主要介绍了三个用来加速facebook的前端技术:quickling,pageCache,bigpipe。 quickling技术是一个使用异步请求代替页面跳转的技术; pageCache就是一个自动将页面缓存在客户端的技术,只有结合quickling的无刷新技术才能实现。 bigpipe是一个采用流水线串行处理技术,将所有页面非核心部分,通过ajax异步传输到客户端的技术。 quickling quickling技术用异步请求代替页面跳转以后,服务端不用拼接整个页面,而是只传送页面中改变了的部分到浏览器,不但服务器压力减轻了,而且传输量也减少了。数据显示,使用了这个技术以后,加载时间降低了10-30%,生成时间降低了20-30%。 pagecache pageCache技术会将页面缓存在客户端,做缓存往往要面对实时性和数据一致性的挑战。比如说,如果cache了某个页面,等用户回来的时候,这个页面上的内容已经被其他用户改变了,cache的页面就不是实时的了;或者用户在cache的页面上进行了一些操作,下次再访问这个页面的时候,如果再使用cache中的页面,数据就不一致了。 为了解决实时性,facebook增加了一个服务端的事件回调,如果发现本地页面和远程页面不一致,就刷新缓存;为了解决数据一致性,在客户端发生的任何操作都会被记录下来,下次返回到这个页面的时候回放操作。 bigpipe bigpipe会对页面所有非核心部分进行异步流水线处理,这时候TTI就派上用场了,bigpipe处理的是与TTI无关的模块,这些模块可以异步加载,为了不加重服务器的负担,facebook没有采用并行加载,而是采用了流水线式的串行加载。同时,创造了一个编程模型,可以很方便的创建和添加一个模块到页面上。 上午这个最后的压轴还是很精彩的,会后还有很多人围着蒋博士请教一些细节问题。facebook的这些手段其实在我们的产品中也有零散的用到,但是完全没有这样成体系,有一套基础架构和前后端统一的框架来保证。 下午第一场是Douglas的“更好的使用javascript”,都是大家熟知的一些东西,如果你看过老道的书,就会发现这些东西在他的书里都有。 YouTube的前端性能改进:逐步增强与超越 第二场是Youtube Alex的“YouTube的前端性能改进:逐步增强与超越”,他主要介绍了四个东西: 把js放在底部(确切的说是合理的位置) 预加载video连接 产品方面,采用了lightweight version来照顾一些网络情况不好的用户 UIX widget系统 比较有意思的是后面两点。 lightweight version 轻量版本这是一个从产品方面做出调整,来满足产品的性能要求的一个手段,youtube将原来160K的页面瘦身到18K,保证网络情况不好的用户能顺利加载。 而如何找到这些用户呢?两个手段:通过ip地理分布定位;通过客户端js代码判断加载速度定位。 UIX widget系统 这是一个UI组件框架,主要思想是: 基于行为 统一的事件处理,整个UIX widget只有一套事件,挂载在document上 class matching,js通过class找到要渲染的DOM元素,将他们渲染成widget 随时注册,渲染组件。 这和百度内部的一套UI框架思想有些类似。不过如果进行统一的事件管理,一般来说,这样只适合页面上几乎没有第三方脚本代码的产品,我不知道Youtube是否已经解决了与第三方脚本兼容的问题,而会后Alex给我的答案是,Youtube中几乎没有第三方代码,他们可以放心的接管所有事件。 下午的第三个session是Yahoo的构建Yahoo下一代Mail,但是我的笔记本没有电了,跑到墙壁的角落去蹲着充电,很多要点听的不是很清楚。只是发现Yahoo mail也实现了一套前后端模板统一技术,和公司内部的一些想法不谋而合。 静态网页资源的管理和优化 下午最后一个session是facebook魏博士的“静态网页资源的管理和优化”,这个session介绍了一个全方位的静态资源管理系统,这个系统中他们会将产品中的所有静态资源进行智能化打包。 什么是“智能化打包”呢?开发产品的时候,我们往往要进行模块化开发,比如说个人主页上有很多个模块:搜索框,广告,推荐好友,提醒模块等等,这些模块有自己独立的js文件和CSS文件,在上线的时候我们要把这些文件打包到一起。这个系统能帮工程师自动打包这些静态资源。 […]

trackback Tags: 评论 (4)

Oct30

百度前端技术交流会

敝公司前端技术交流会第一次对外开放,有幸被邀请成为嘉宾上台交流。 我分享的主题是:百度前端基础平台分享。提前放出Keynote下载 //update@10.31 根据 @catchen 的建议,把keynote放到了slideshare上。 另外,Q&A环节里面,有一个问题:你在开发这个基础平台时,最先要考虑的是什么? 我的答案:需求,公司产品线的需求。技术方案不是第一要考虑的,所有技术方案都应当基于产品线需求来设计。就像pm做决策一样,不是用户嚷嚷要什么,就应当要给什么,而是要深入分析产品线特点,站在通用的角度上去考虑,我应该提供什么。我的keynote的每一个部分都是从公司现状讲起,然后到设计,到解决方案。没有现状和需求谈设计和方案是没有什么意义的。看着Yahoo,google的方案,自己山寨一套,不考虑公司情况,也一定是不适用的。 基础平台,没有最好,只有最适合。

trackback Tags: 评论 (16)