腾讯 Web 前端大会 分享浅析 -- 主会场篇

原文连接

腾讯 Web 前端大会完美落幕。但愿你们能收获满满干货。博主负责大会部份的讲师的遴选。虽然我全程都没怎么听（基本都在安排展位和发微博），但我但愿经过选题的角度，以及PPT的内容，给你们分享一点思路和分享的导读。

TC39, ECMAScript, and the Future of JavaScript

nicolas

第一位讲师是在 Elastic Search 工做的 Nicolas Bevacqua，他同时也是知名书做者和博主。

他所分享的这个主题，是跟W3C的标准制定相关。对于大神们说，这个知识都已经有所涉猎，但对于新入行几年的新人来讲，可能相对陌生。Nicolas 出了与 ES6 有关的书籍，是这方面的专家，所以邀请他过来分享很是合适，也考虑到他是作英文分享，所以经过分享W3C标准制定流程、W3C标准的新特性这类知识性的分享，不会太艰涩难懂，但又对引发国内对W3C关注也起到必定的效果。毕竟国人在技术上，太过关注业务，大会仍是但愿经过引发你们对“标准”的关注，让愈来愈多的国人能花时间精力投身到“标准”的制定上去，比方说腾讯前端第一人“黄老师” Stone Huang 就是W3C中国信息无障碍社区组的主席。

本分享主要介绍的有，TC39是什么，以及他们制定规范的流程是怎么样的。关于这方面，我曾经阅读过一篇不错的介绍性文章《JavaScript(ECMAScript) 语言标准历史及标准制定过程介绍》，我就再也不赘述了。Nicolas 在分享的时候，只点到了TC39是制定标准的委员会，不过没提到的是其实每一个开发者都有机会成为一份子。另外，从Stage 0 到 Stage 4，整个标准制定过程从提案、审阅、算法规划、Polyfill到测试用例，这一切保证了整个流程的更加快速可靠。让W3C标准在这两年的进展一会儿加快了很多。Nicolas 还提供了比较有趣的故事就是，以前W3C都是用着老旧的Microsoft Word来建设文档，是后来使用了Github以后，让整个流程更公开快捷，因为扭转了W3C标准指定落伍的局面。Nicolas 本身还专门建了个网站，用来监察 W3C 标准制定的进展。TC39 proposals。

我以为最须要理解W3C的时候，是使用 Babel 的时候。由于 Babel 会经过不一样的 preset 或者 plugin 帮你去编译不一样的新特性。

Babel 的 plugin 经过只支持某一种特性的编译，而 preset 则是指一系列的 plugins 。所以咱们常见到 es2015, es2016 这些 preset，而偶尔会见到 transform-decorators-legacy 这一类 plugin。一般来讲，进入 stage4 的特性基本笃定能进入标准当中，通常能够经过 Babel 放心使用（不过不排除会有性能的问题），但以前的 stage，随时有可能回炉重作，所以要慎重使用。

分享最后稍微介绍了一些现代的前端工具，

npm，Javascript 包管理工具，战胜了 bower
webpack，JavaScript 打包工具，击败了 gulp，require.js
babel，JavaScript 编译工具
rollup，新一代 JavaScript 的打包工具，在类库开发中颇受欢迎
eslint，JavaScript 代码质量检查工具
prettier，JavaScript 新一代代码质量检查工具，大有取代eslint之势
node，JavaScript V8 运行环境

初始公司前端工程体系建设

a8dd1910gy1fgw4icrvcwj21kw0w0qfm

本分享有幸邀请到的是前端业内工程化的大神张云龙，以前是FIS的核心开发者，目前在全民主播担任CTO。办大会的时候，一直就想着要在主会场安排一场工程化的分享，必定要请张云龙过来分享，没想到愿望达成（擦当天太忙还没空跟他合照！！！）。

我一直是想推进业内前端工程化的，让全部程序员都由于工程化让性能优化、持续集成、测试部署、发布监控更为驾轻就熟。我看到的反面教材是当今国内的电影业，拍摄太过随意，彻底不讲流程，前期拍很差就由后期来擦屁股（详参《《择天记》收官在即，“5毛特效”背后的故事你不能不知道》）。但反观国外，电影已是一项成熟工业了，“工程化”作得很好，各方面都控制得至关规范，所以即便咱们有时候以为情节方面有缺陷，但整体来讲能达到所谓的6分“工业水准”，不至于强差人意，偶尔情节不错，也能来个8分9分的爆款。而国内电影因为“工程化”缺失，3分4分的脑残片、5毛特效片比比皆是。从国产电影这个反面教材，我深知若是让国内的页面水平也能保持至关好的工业水准，工程化是绕不开的一道槛。

云龙大神选的这个题仍是蛮有实用价值的，毕竟在大公司工做的人是少数，很多开发者仍是在中小企业里工做的，没有专门的人负责帮你搭建好全部的工具。所以，云龙大神选的这个“初创公司”的切入点，不只直接与他当前工做的经验相关联，也能引发在座许多开发者的共鸣。

分享开篇就先点出了讲者自身所处的业务环境与团队规模，业务复杂，但团队不大，所以得出来但愿工程化提升效率的同时，却面临很多现实问题的尴尬局面。

而后做者开始直接抛出解决问题的方案。我先把总结放上来：

• 前端架构：组件开发 + 子系统拆分
• 持续集成：基于 Gitlab-CI 环境 及 GitFlow 开发规范
• 系统测试：基于 Dom-Diff 的自动回归检查系统。
• 敏捷开发：物理看板

前端架构：组件开发 + 子系统拆分

这里提到的与架构相关的是组件化开发，同时点出其背后的核心概念，即“分治”。这部份提到一个有意思的点，即是服务端模板里也用到了组件化的方式。以下图，经过资源表来管理静态资源，require 引入 js/css， widget 引入组件（多是html加上js/css?）。这是以往不用Node开发后台的方式。而以如今咱们常见的 Node + Webpack + React，则是直接在服务器运行JavaScript 生成 HTML 字串再吐出来。有点惋惜是的可能因为篇幅和时间关系，具体技术细节并无展开，仍是很但愿能够对比一下两种方式在SEO、维护效率、性能（QPS每秒查询率）等方面一些数据的比较。

image

持续集成

持续集成一言以蔽之，就是键帮你将测试部署都跑通，有条件的团队能够弄一下，极大地提升生产效率。云龙大神这里是以Gitlab作例子，我以前也写过一篇文章，是以Github作例子，但愿你们在作开源项目的时候也能极大提升效率（Deploy Using Travis-CI And Github Webhook — webpack doc as an example ）。

前端部署多个环境也是蛮有意思的，这个应该在Node开发的时候比较有帮助，而单纯是页面，用Fiddler, Charles一类的代码软件，也能够达到一样的效果。

至于ESlint嘛，我建议若是能够在IDE里集成最好在里面先集成了，而后在commit的时候检测，能够在集成机里省掉这一步。

系统测试

分享里的思路，看起来是基于云龙大神以前的一个开源项目page-monitor。还没使用过，但愿有人能够写写对比的文章，对比一下这个思路跟基本测试方案的优劣。

敏捷开发

云龙大神这里分享的物理看板，是我以为最有意思的地方。在一直提倡电子化的今天，从新使用物理看板，在外人看来是难以想象的。分享中点出了电子看板的一些问题：

• 信息辐射成本高
• 容易造成『信息冰箱』
• 缺少仪式感
• 定制性较差

而物理看板有这样一些优点：

• 易于建立、易于变动、易于观察
• 有极强的信息辐射能力，了解彼此工做
• 有一种特别的仪式感，是一种特别的团队社交形式
• 白纸黑字，写下时间的承诺
• 方便追踪进度问题

我以为其实采用哪一种方式没什么问题，但我以为可以从采纳的方式中，不断优化项目的开发效率，积淀中一套好的牙慧管理方式，才是最好的方案。不过随着公司规模的不断增加，电子化好像是没法逆转的趋势，由于电子化了，之前的数据能够保存下来，后续可用各类数据、算法进行分析。期待云龙后面在团队不断扩张中关于敏捷开快这一块的演进。

面向前端开发者的 V8性能优化

a8dd1910gy1fgw4icrvcwj21kw0w0qfm

谜渡大神此次分享的内容有很多的难度，我特地找他推荐了几篇V8入门级的文章，让你们先读一下。有问题，能够到TFC大会互动群里提问。平时前端开发者主要只是关注写好本身的JavaScript就好了，但对JavaScript背后的引擎好像比较陌生。但愿是次分享能够给你们带来有关JavaScript引擎优化的相关知识，使得往后写JavaScript代码的时候，可以更容易让引擎进行优化。

• JavaScript V8性能小贴士
• V8专题

若有谬误，恳请斧正!