又是一年前端盛会D2，度过了非常充实的一天。感谢各位分享嘉宾和组织者辛勤的准备~还收了很多好看的贴纸hhh，晒下参会证和电脑背面~

接下来就是会议的具体内容啦，内容比较多，如有疏漏请各位看官批评指正~

大会的全部PPT官方已经放到GitHub上了，可以自行取用~ https://github.com/d2forum/14th

圆心致辞

前端这些年来，充满着变革和重塑，从应用上层逐渐深入到语言框架底层，对前端的要求也在不断变化，始终有着巨大的挑战和机遇。

五个挑战（去年也讲了五个挑战，不过内容有所不同~）

端侧渲染体系的重塑， 从PC时代到无线时代，再到未来的IOT时代，在渲染方面诞生了很多优秀的技术，RN, Weex, Flutter，小程序体系等。基于底层的渲染思路，Native的渲染，2D、3D性能体系，包括WASM集成到无线端来渲染，都带来了很多可能性。
2B中后台场景垂直领域的深度沉淀。 从2C场景到2B场景，以前由大量外包全栈支撑的中后台体系也在变为专业前端的主战场。中后台领域有框架、布局、组件、数据交换，庞大体系的运作（跨团队协作）等各种挑战，在技术上也有可视化，Web Excel, 编辑器，搭建，智能化等各种方向值得深入。不同域的体系下如何和后端体系打通，领域模型的贯穿等，都是需要探索与沉淀的。
从传统开发模式到云+端开发模式，云使业务体系平台化，接口化，在端侧效率化，业务化。前端关注到从页面到业务。Serverless一定是未来趋势，前端能力必须匹配未来技术要求。
前端智能化， 页面的构成，结构，标准化。这一块淘系的 imgcook 已经做得很不错了，在今年的双十一也有智能代码生成的大规模落地，可以了解一下~
语言底层的深入。 国内的语言与国际接轨，需要从底层做起，参与标准化的制定，促进JS语言的发展。最近贺老也加入了TC39（去年一直吐槽的class field可以当面跟TC39成员吐槽了😂），希望以后在标准化的制定上，能看到越来越多国人的声影。

上午- 语言框架专场

Let's work together on the future of JavaScript through TC39

讲师：Daniel Ehrenberg

终于见到了一直以来感觉很神秘的TC39成员。Daniel 还是很可爱的，分享精彩而流畅，经常引用《论语》来总结，看来还是对中国文化有一些了解的~

Daniel 给大家讲解了TC39的工作机制，一个新特性从提出到成为标准需要经历以下阶段，总体来看还是非常严谨的

Stage 0: strawman - 脑暴阶段，有什么想法都可以提出~
Stage 1: proposal - 讨论阶段，由TC39的成员发起一个正式的新特性提案，并与其他成员和社区进行讨论
Stage 2: draft - 草案阶段，需要包含两个实验性的具体实现
Stage 3: candidate - 候选阶段，基本已经准备实施，需要包含两个符合规范的具体实现
Stage 4: finished - 通过test262（新特性的测试仓库）的验收，发布到年度规范

然后介绍了目前几个推进到各个阶段的的特性，其中Stage4的应该马上就会出现在ECMAScript 2020的规范中，比如BigInt, Dynamic import, 还有呼吁已久的Optional Chaining（TS 3.7已经支持了~），其他的就不细讲，可以在这里看到TC39的工作进展，也可以提issue发表观点并与他们交流~

https://github.com/tc39/ecma262

JS语言在引擎级别的执行过程

讲师：周爱民

周爱民老师功力深厚，对JS的底层执行过程非常熟悉，而且已经有段时间没听过这种不夹杂产品介绍，纯粹探讨技术的分享了~回归语言本身，感觉很亲切。（虽然产品介绍的分享也很有收获，但是这类分享很难有时间详细讲解具体实现，只能是发个架构图，后面自己研究，这种纯技术的分享，可以着重于某块细节讲的很深入，听完就会立即学到一些以前可能不知道的内容，在技术上还是很有收获的~）

整体内容很偏底层，包括作用域，环境，执行上下文等一些基础概念，以及词法环境规范，属性描述规范，属性标识符规范等标准中的细节，平时工作场景中很难有机会深入了解这些内容，所以还是非常有收获的，PPT应该很快就会放出来，就不全部展开来讲了~讲个印象最深刻的地方吧

这段代码是老师PPT中的，当面试题应该能考倒绝大多数人~

const obj = {
  foo() {
  	return this;
	}
}

(obj.foo)() === obj // true
eval('obj.foo')() === obj // false

为什么 obj.foo 和 eval('obj.foo') 都返回了一个函数，但是执行结果不一样呢？

这就JS引擎搞的事情了~在执行时分为语句执行和表达式执行两种情况，参照下面这张图

语句执行，即 eval('obj.foo') 这样的，对于这种类型，返回结果中如果包含引用，会用GetValue把引用取出来然后去除，所以返回值中看不到引用
表达式执行，即 obj.foo这样的，返回结果中可以正常包含引用

所以 eval('obj.foo') 返回的结果中丢失了对obj的引用，this就只能指向全局作用域了~在浏览器中跑了一下果然如此

嵌套多级也是一样的，只要有引用，都会去除~下面的代码也印证了这个结论

这种细节还是很有意思的，虽然不是专门搞这个方向的话，对平时工作可能没有什么帮助，但是作为一个前端，如果能够掌握JS在引擎层执行细节，还是很锻炼内功的~

fibjs 模块重构 - 从回调到协程

讲师：陈垒

fibjs 与node一样，也是一套JavaSscript运行时，底层都用的V8引擎，区别是其内部用逻辑锁来替代回调来控制异步，这个思路还是很新颖的~

根据讲师贴出的性能对照，将FIBJS ORM模块用此方法重构后，性能上还是有很大提升的

不过其设计上不能与现有的node生态兼容，感觉对于外部用户来说还是缺乏些落地的动力
在知乎上看到了响马老师的回答，很多内容本次分享也都有提到，想对fibjs有更多了解的可以参考一下~

https://www.zhihu.com/question/26382154/answer/32723887

下午-工程化专场

前端工程下一站：IDE

讲师：上坡，吭头

IDE是今年阿里前端委员会定下的重要方向之一，经过大半年的建设，也取得了不少进展。整个IDE内核的技术实现是极其复杂的，看下下面这张架构图就明白了，每一块拎出来都是可以做很久的。

所以一小时的分享，在技术实现上就是点到为止了，如果对整体IDE的技术细节比较感兴趣的话，可以等会后讲师的PPT，下面也有几篇不错的文章可以参考~

下面主要想谈下我个人对Web IDE的看法，最开始发起IDE共建的时候，我以为是直接搞个在线IDE来替代现有的开发环境，以后开发所有项目就都用这个了，个人观点还是不太支持这种做法的，原因主要有以下两点

实现技术难度极高，底层都是基于一些开源项目（monaco editor, xterm.js等）做一些二次封装，但是将其整合起来，中间要踩的坑还是非常多，需要耗费大量时间精力
不能有效解决痛点，甚至增加痛点：Cloud IDE最主要的就是远程编码，构建，部署，省去了配置环境的复杂。但是在综合开发体验上，目前没有人会觉得开发大项目时使用Cloud IDE会比本地开发体验好，不仅重度依赖网络，而且性能也是个很大的问题。

后面发现其实共建的是IDE的内核，也就是 KAITIAN Framework（名字起的真的炫酷~)，然后各业务基于这套内核来封装自己的编辑器甚至整套IDE，比如支付宝小程序的IDE，淘宝开发者工具，imgcook的在线编辑器，阿里云的函数计算编辑器等，把底层编辑预览调试能力等抽出来统一维护，业务在上面定制专有逻辑，对于特定的业务场景来说还是很有价值的。

总之，作为一个技术人，能够参与这样复杂有挑战的项目，并最终实现出来，肯定是很有成就感的，希望日后自己也有机会参与这样的建设中~

Babel: Under the Hood

讲师： Nicolò Ribaudo

这位小哥还是个学生，年轻有为，讲的也非常棒~

Babel转化的核心链路：原始代码-原始AST -转化后的AST-转化后的代码

主要功能由以下几个包来实现：
@babel/parser 将源码解析生成 AST，会经历以下三个步骤

词法分析（Lexical analysis）：code to token，并进行token合法性校验，比如注释如果没有用// 或 /**/来写就会报错
语法分析（Syntax analysis)：token to AST，并进行基本的语法校验，比如分号问题等
语义分析（Semantic analysis)：会进行上下文相关的分析，如果有

@babel/traverse 以深度优先的形式遍历AST，并进行修改和转化
@babel/generator 根据AST生成新的代码
@babel/core Babel核心库，被很多babel配套设施依赖，用于加载 preset 和 plugin

@babel/template 采用 template 的形式，简化修改 AST 的过程
@babel/types 包含所有 AST 中使用的类型

然后还简单的讲解了一个babel-plugin的实现，内容是进行如下转化

// 转化前
const x = throw new Error("Err!") 
// 转化后
const x = (() => {throw new Error("Err!");})();

插件的写法也很简单，就直接贴代码了~

export default function Plugin() {
  return {
    // 插件名称
    name: 'throw-expressions',
    // 插件选项
    manipulateOptions(opts) {
      opts.parserOpts.plugins.push('throwExpressions')
    },
    // 遍历 AST 并进行操作的方法
    visitor: {
      UnaryExpression(path) {
        const {node} = path;
        // 不是抛异常的表达式就不处理
        if(node.operator !== 'throw') return;
        // 基于模板生成新的 AST 结构
        const iife = template.expression.ast(`(() => {throw ${node.argument}})()`);
        // 替换原有 AST
        path.replaceWith(iife);
      }
    }
  }
}

最后推荐一个在线代码生成AST的网站，学习AST时很有用：https://astexplorer.net/

基于浏览器的实时构建探索之路

讲师：玄寂（玄字辈，一听就是大师的名号~）

玄寂老师读完这两篇文章，受到了些触动，开始了浏览器构建的探索之路~

现在某些项目的依赖包实在太大，尤其是一些中后台项目，项目刚搭起来，还没写页面呢，就先下个几百MB依赖，想起来这张广为流传的图

所以浏览器端的构建，概念上非常新颖，但确实是有场景和诉求的，玄寂老师将浏览器的实时构建实现的核心归纳以下几点并分别进行讲解~

设计资源⽂件的加载器
设计资源⽂件的编译体系
设计浏览器端的⽂件系统 - 借助了 BrowserFS
设计浏览器端的包管理：即浏览器端npm，实现了动态下发，依赖缓存，数据结构与浏览器文件系统桥接等

目前的探索产物是 Gravity，一套实现浏览器实时构建的事件流集合，可以跑通浏览器端构建 React 项目的 Demo，还是很牛逼的，如果能够在生产环境稳定使用，应该能够节省不少服务器资源。

不过个人觉得与现有的webpack工具链不兼容是个比较大的问题，比如css-loader, ts-loader这些很常用的，得重新建设一遍自己的工具链生态。在现场也进行了提问，玄寂老师的回答是，由于事件流机制的设计都是一样的，这些loader迁移起来也会很方便。

玄寂老师的blog上也有很多其他的优质内容，可以关注一波
https://github.com/pigcan/blog

Distributed Front-End Architecture

讲师 Ahmad Amireh

这场质量比较一般，讲师讲的时候有些紧张，可能准备不是特别充分，场面气氛有点尴尬~而且内容上其实就是在讲微前端，可能放在微前端专场会更合适一些。整个过程中没做太多记录，就不细讲了。

不过讲师本身还是很有才华的，写了个 happyPack的项目，用于优化webpack的构建速度的，star数也不少，有兴趣的可以参考一波~
https://github.com/amireh/happypack

夜场部分

和去年一样，今年D2也有着夜场环节，非常精彩~先来波圆桌会四巨头的照片

从左至右依次为

Hax贺老
西祠胡同创始人，fibjs作者响马老师
蚂蚁体验技术部大老板玉伯大佬
TC39核心成员 Daniel Ehrenberg
以及可爱的翻译小姐姐

在圆桌会之前还有三个很精彩的lightning talk, 依次为

海量节点树的高性能渲染，使用各种骚操作将海量数据下节点树的渲染性能提升了18倍，这套方案预计明年2月开源，可以期待一波~
阿里巴巴营销研究和体验中心的凌征大佬分享前端工程对营销业务的赋能。包括创意生成，图片实时渲染，字体渲染，视频创意生成及编辑等。最近也在参与营销相关工作，深知这其中每个模块对前端技术都非常有挑战，能够实现并在业务中顺利落地，为业务带来效果，是非常不容易的~
阿里南京研发中心的亨睿大佬分享黑科技录屏技术XReplay，可以7*24不间断录屏，清晰度极高，且大小只有MP4文件的1/200，节省了大量服务器存储资源。具体的技术实现涉及到各种算法专利，在内网上看到了一些相关文档，在这里不便于公开，后面会放在内网的语雀上供阿里的小伙伴们参考。

接下来讲讲圆桌会的内容~以QA的形式总结一下各位大佬在前端路上的各种思考及看法

Q：优秀前端都有什么特质？
A：像素思维（追求极致的还原度），充满好奇心，能与他人良好合作。善于读书，善于思考，实现自己的认知升级。关注基础知识及API的底层实现，不要做单纯的API Caller~

Q：入行时和现在对前端的认知和思考，有没有发生什么变化？
A：前端始终跟人机交互息息相关，随着终端运算能力的提升，终端设备使用场景越来越复杂，前端对即时性，好玩性以及用户体验要求越来越高。

Q：带团队以来对个人有什么改变？
玉伯：带团队以来个人的改变其实不是很多，主要是从开源社区中汲取到很多经验。开源天然不是一个人在干活，通过社区运营的大型开源项目，本身就涉及到多人之间的协同。所以就以开源项目的方式运作实体团队，团队成员有问题可以通过类似提issue的方式来沟通解决，同时也像管理大型开源项目一样，非常注重内部交流及高效协同。

Q：如何始终保持对技术的热爱？
玉伯：技术的力量，是整个社会创新最大的动力之一。始终觉得行业很有意思，每隔一阵又会有很多想不到的惊喜
响马：觉得跟人打交道比较费劲。写程序本身就是放松的~
Danel：学习新事物，给出问题的解决方案，对事情保持好奇心。

Q：成长的关键点？
Hax：多年前发现Firefox中有个JS行为与标准不一致，就给Firefox提了个issue，竟然得到Javascript之父回复，非常惊讶。加入TC39也是很重要的事情（顺带又吐槽了class field😂)
玉伯：从上学谈起，到加入淘宝及支付宝，在all in 无线时代的坚守，到最终实现破局，中间有非常多的心路历程，强烈推荐看下这篇文章~详细讲述了玉伯的成长之路，个人觉得值得每一位前端同学阅读学习。
我的前端成长之路-玉伯

关于夜场的内容有位网友总结了一份只字不差版的，内容更加详细，也非常推荐阅读~
https://www.yuque.com/zhaishenking/ggn07n/uvdo44

最后来一波夜场大合照，欢声笑语中圆满结束本次D2~

总结

D2从创办至今，已经走过14个年头了，虽然只参加过去年今年两届，以及在网上零散地看过前几年的部分内容，但也从中真实感受到前端这几年来的高速发展，不断突破自我，拓宽边界，挑战未知的可能性。D2也办的越来越好，基本可以说是国内质量最高的前端会议了（当然我们蚂蚁的SEE Conf也很不错，不过有很多设计师的内容，不算是纯前端的大会），虽然票价比较贵（今年还比去年又涨了…），但就质量而言，还是轻松值回票价的~（这么硬的广告，还不快送我明年门票！）

从去年到今年，个人的最大变化就是结束了学生时代，正式成为一名阿里的前端工程师。”优秀的前端不是在阿里，就是在去阿里的路上“，这句话虽有调侃之意，但目前阿里在前端技术上的引领和突破确实明显优于其他公司。每年D2都能拿出各种新鲜的东西，并且并不是空造轮子，很多产品已经经过了千万乃至亿级UV的考验，是真正能够赋能业务，为其带来显著价值的。

个人而言，看到这些新鲜玩意，从去年的高呼卧槽，到今年的比较淡定，抽出更多时间精力去听听外部的分享，主要是部分内容都在内部宣传已久，已经有过相关输入了😂比如今天的微前端，IDE内核KAITIAN，XReplay等议题，在内部，这些项目的开发者们已经撰写了很多文档资料供大家参考了，甚至还可以直接看源码，一窥内部细节。只要肯付出时间研究，收获肯定是远远多于今天会上这一小时的~

说了这么多，核心观点就是：想提前了解，甚至亲身参与和打造这么多牛逼的产品，还不快加入我们！

下面是招聘时间~

关于我们：
我们是蚂蚁保险体验技术团队，来自蚂蚁金服保险事业群。我们是一个年轻的团队（没有历史技术栈包袱），目前平均年龄92年（去除一个最高分8x年-团队leader，去除一个最低分97年🙈）。我们支持了阿里集团几乎所有的保险业务。去年我们产出的相互宝轰动保险界，成为蚂蚁乃至整个阿里集团的明星产品，今年随着相互宝的用户总数破亿，蚂蚁保险的全线业务都在继续蓬勃发展。团队人才济济，清华、浙大、哈工大，博士硕士都有。还有社区活跃份子相学长，easymock作者chuangker。基本每周都有技术分享，技术氛围极好，技术交流多，业余生活也很丰富，来波团队各位帅哥美女的照片~

伴随着事业群的高速发展，团队也在迅速扩张，欢迎各位前端高手加入我们~我们希望你是：技术上基础扎实、某领域深入（Node/互动营销/数据可视化等）；学习上善于沉淀、持续学习；性格上乐观开朗、活泼外向。
如有兴趣加入我们，欢迎私信勾搭，或发送简历至邮箱：xingyan.hyx@antfin.com