第三届 FEDAY 回顾(2017)

这是我第一次参加 FEDAY 的活动,相比于其它的技术大会 FEDAY 的规模可能属于较小的类型,整场活动只有1个会场8个主题,但是给我的总体体验还是小而精的。除了一些我可能没太接触过的主题以外,大部分主题都让我觉得还挺有趣,或者了解到了一些新的东西。
8个主题里面关于前端工程化的有3个:
- 《Webpack打包机制及调试优化》- Alexey Ivanov
- 《链家工程化实践》- 教主(链家)
- 《让机器解放生产力 —前端开发必备工具》- Andrey Sitnik(PostCSS 作者)
有5个主题是关于框架和库的:
- 《谈项目中如何选择框架和库》- 张克军(豆瓣)
- 《如何用JavaScript做好一个大型应用》- 孟红伦(阿里)
- 《从Cycle.js谈函数式与响应式编程》- 叶俊星(美团)
- 《基于React Native的跨三端技术实践》- 刘威(京东)
- 《WebAssembly 在白鹭引擎中的实践》- 王泽(白鹭引擎)
说几个给我印象较深的主题。
1.《Webpack打包机制及调试优化》
来这次 FEDAY 主要想听的一场,是由一名俄罗斯的工程师带来的。因为我的英语听力本来就比较捉急,对于这场带有俄式口音的英文分享很多部分就只能意会了🤔。后半部分讲 Webpack 的优化是重点,提到了已经被讨论了很久的 tree-shaking、scope-hoisting ,唯一新的点是还在实验中的特性 pure module。
pure module 其实是对于 ES Module 的复合导出(re-exported)做了进一步的优化,这个优化主要会对于一些使用了复合导出的大型库效果比较明显。比如现在有一个叫 big-module 的库通过 index.js 导出了它的一些模块:
export { a } from “./a”;
export { b } from “./b”;
export { c } from “./c”;业务在使用这个库的时候,假如用到了其中的模块 a 和 b:
import { a, b } from "big-module";实际打包时候虽然只用到了 big-module 中的模块 a 和 b,但是 index.js 和模块 c 由于有可能有副作用也都会打包进去。而在 pure-module 模式下,上面的 import 可以理解为变成下面的形式:
import { a } from "big-module-pure/a";
import { b } from "big-module-pure/b";这相当于绕过了复合导出而直接获取实际的模块,index.js 和模块 c 不会被打包。具体的使用可以看这个官方给出的例子。
演讲中通过 tree-shaking、scope-hoisting、pure-module 等优化演讲者将一个 case 的 bundle size 缩小了几十倍,但是我觉得他给出 case 未免过于理想化,对于实际的工程而言优化效果应该并没有这么高。
2.《如何用JavaScript做好一个大型应用》
开始我以为这个主题会是关于工程化相关的,最后发现其实主要是讲 TS 的 😂。虽然平时基本没怎么接触过 TS ,但是整场听下来发现它在一些大型应用的场景下确实可以发挥很大的作用。
进行分享是来自钉钉的前端负责人,从一个业务中很常见的问题入手解释了 TS 在业务中发挥的作用。在一些复杂的业务场景下,一个数据模型有可能非常复杂。
比如一个获取用户信息的接口可能包含几十个字段,而且有些字段不是必有的(企业用户和个人用户的区别),在代码中如果有个地方少了个验证就有可能出错,很难保证数据的完整性。而通过 TS 将这些数据模型确定下来就可以由它在代码中开启类型检查,假如哪里对一个不是必有的字段少了判断它就会进行提示。
在此基础上,前端和后端还可以通过一个统一的接口类型描述文件生成相同的数据约定(在前端由接口描述文件自动生成 TS),这就可以防止掉很多在前后端约定上不统一带来的问题。
3.《WebAssembly 在白鹭引擎中的实践》
带来这场演讲的是白鹭引擎的首席架构师,可能是今天分享里面说话最有意思的,总带儿化音(代码儿、安卓儿)。由于游戏引擎和 WebAssembly 我都没接触过,所以这可能也是我听得心态最轻松的一场。
演讲主要介绍了 WebAssembly,以及白鹭引擎在使用 WebAssembly 过程中遇到的坑,讲了很久最后结论是大家日常前端开发中最好还是不要用它😓。
其实 WebAssembly 的卖点主要是两个,一个是它的性能好堪比 Native,另外一个是理论上可以将 C++,JAVA 等语言编译为 WebAssembly 来运行。白鹭引擎目前提供了基于 WebAssembly 的 2D 游戏开发环境,并且经过验证也确实带来了一定的性能提升。
在目前的普通前端工程中其实并没有太多可以使用到 WebAssembly 的场景,唯一一个演讲者提到的是图像识别,因为需要进行大量密集计算。也许在几年后的未来,当 WebAssembly 逐渐成熟起来之后才会得到更多的关注和应用。
在这场演讲中我印象比较深的是白鹭引擎在基于 JavaScript 开发时候关于性能的一些问题。一个是基于 JavaScript 是一门动态类型的语言的特点,下面的代码会影响 V8 的性能。因为 add 函数不是单态的(monomorphic),其参数类型在不同的调用中是不同的,需要在运行时不断判断参数类型。
function add(x, y) {
return x + y;
}
add(1, 2);
add('a', 'b');另外一点就是 JavaScript 中的 GC 是自动的,或者说是不可控的。这个的好处是开发者完全不用去关心什么时候进行 GC,都在语言层面自动帮你完成了。缺点是你无法保证一个可持续的高性能状态。因为在 GC 的过程中会使得整个 JavaScript 的执行暂停,在游戏中的体验就是过一阵就会突然有个掉帧。这也是为什么白鹭引擎想使用 WebAssembly 的原因之一。类似于 C 语言,在 WebAssembly 中是不支持 GC 的,需要开发者手动的操作内存。这对于开发者的要求更高,但是有助于保证稳定的高性能状态。
4.《让机器解放生产力 — 前端开发必备工具》
这一场是由 PostCSS 的作者 Andrey Sitnik 带来,讲的东西其实就是 lint 工具。包括 eslint、stylelint 以及一些其它方面可以使用 lint 工具的场景( 比如 English lint 帮助检查文档中的单词拼写)。
总体内容其实还蛮轻松的,主要给我带来的其实是一种思路上的转变。在 Andrey Sitnik 的演讲内容里所包含的不仅仅是说 lint 工具可以解决代码质量层面的问题,还有在实际工作层面的。
比如说演讲中提到 lint 工具对于新员工的意义以及对团队关系的帮助。新人在刚进入团队的时候往往写出的代码在 code review 时候要被打回去,说你哪里哪里写的有问题,可能写了10行代码9行都要改,这对于新人来说体验还挺不友好的。假如是 lint 工具来跟他提示说你哪里得改一下这就友好得多。
在老员工看到新人代码时候可能就觉得,哎这个新人怎么写的代码怎么这么烂,其实可能只是因为新人的代码和团队的代码风格不太一致而已,但是可能会导致对新人的评价降低。如果老员工看到的代码已经被 lint 工具修正了风格上的问题,可能实际再看到的问题就很少了。
总结
这次 FEDAY 虽然在组织上有些小插曲(中午的盒饭、迟来的 T 恤、略显匆忙的送书环节),但是内容上总体来说还是质量比较高的。另外时间和选址都不错(中午吃完饭去旁边的奥体溜达了一圈,空气真的好),期待明年再见啦👋。
