本次活动由 Rokid 主办。
- 时间：2018 年 12 月 9 日 13:00 - 19:00
- 地点：Rokid 杭州西溪一号22号楼
本期我们迎来了7位讲师为我们带来精彩的6场演讲。
主讲人介绍
刘哲轩，一个程序员。本科就读于威斯康星大学麦迪逊校区，硕士就读于佐治亚理工，毕业后在微软总部薅了几年资本主义的羊毛，现在广州奇志科技做开发。大学时期开始钻研前后端技术，强迫症癌晚期，吉他爱好者，仍在拓展能力和拓宽视野的路上上下求索。
内容
Mesh 的背景介绍、在 Mesh 里用 JS 能做什么、内核介绍以及从无人机应用出发, 连通更多的设备和服务。
一句话总结：一款可以控制无人机的移动端控制框架。
主讲人介绍
李桑，学业半途而废，早年混迹夜场，在酒吧调酒，后跑去深圳这个年轻的城市搞 Java 后端，莫名其妙的又搞起了前端，从一个野路子到爱上 coding，目前在前端累计了大量的 web 开发经验，Java 搞丢了不想 Node.js 也溜走。
内容
- Sequelize 介绍
- Sequelize 工作原理和 API 介绍
- 在实际系统中的应用场景
- 对 ORM 库的一些思考
一句话总结：前端工程师如何像后端拓展的心路历程。
主讲人介绍
陈锦辉，宋小菜前端架构师，早年搞 Java 后端，后转 Android/iOS 原生应用，直到遇到 Node/ReactNative，彻底投入大前端怀抱，目前专注前端（App/PC Web/微信生态链）的跨端工程运维体系搭建，以及跨前后端团队的数据聚合服务层架构，痴迷追根溯源，乐于探索布道新技术。
张伟林，宋小菜资深前端开发工程师，94 年 Coding Boy，霹雳迷，已手残的纸牌魔术师，喜欢神奇的东西，技术栈从上向下不断横向纵向贯穿，目前在寻找前后端大一统思想的路上越走越偏。
内容
- 宋小菜的业务背景介绍；
- 引出效率基建对于长链路 B2B 的重要性；
- 宋小菜的技术栈介绍；
- 从技术栈规划和演进引出团队前后端框架统一的必要性；
- 前端框架 Highway 的设计理念与资源发布；
- 从前端框架设计引出构建部署全家桶之后与后端框架对接/打通的重要性；
- Egg 框架的特点以及小菜的技术演进选型；
- Thinkjs/Express/Koa/Egg 几个框架的特点与我们的取舍；
- 后端框架 Cross 的设计理念与规划；
- 基于 Egg 做企业框架封装（考虑 GraphQL/RPC）和可能会遇到的问题；
主讲人介绍
吞吞/@legendecas/ShadowNode Member/YodaOS TSC Member/语言爱好者/喜欢猫/不救公主只顾瞎逛炸鱼/Coder
内容
- N-API 介绍
- 单次编译即可兼容不同版本 Node.js Runtime
- 从 NAN 到 N-API
- N-API 的实际应用
一句话总结：听完感兴趣的话就可以去读《Node.js 来一打 C++ 拓展》了。
主讲人介绍
陈传滨，一个热爱健身的前端，创业时期搞过 Java 后端，iOS 原生应用。现在专注于前端研发，喜欢制作自动化工具来提高工作效率，将单调的事情变得有意思。
内容
- Jarvis 介绍
- 遇到的问题
- Jarvis 解决方案
- Jarvis 实际应用
一句话总结：一款面向数据 API 的 Web SDK 生成工具。
主讲人介绍
贺师俊，网名 @hax，现就职于百姓网架构部；十多年来一直活跃在 Web 标准、前端开发和 JavaScript 社区，对 HTML 标准有微小的贡献。
精通 JavaScript，早在 ES4 时代就通过 es-discuss 邮件列表参与标准讨论并提交 issue，近年来则通过 GitHub 关注了几乎所有 ECMAScript 新草案的进展和讨论。尤其是最近富有争议的 optional chaining 和 class fields 提案，深度参与了讨论。Hax 给 Babel、ESLint、Webpack 等多个 JavaScript 生态中的重要项目提交过 issue 和 pull request，写过多个针对 ES 新特性的 Babel 转换插件，并是 Atom 编辑器 js-refactor 插件的维护者。Hax 做过大量 JavaScript 相关的分享，包括题为「JavaScript — The World’s Best Programming Language」的演讲。
内容
早在去年7月，tc39 已经批准 class field 提案到达 Stage 3，但浏览器厂商一直没有实现该提案，Babel 也只实现了 public field 而没有实现 private field。其中一个原因也许是因为争议性的 “#priv” 语法。最近，Babel 7 和 Chrome 终于实现了该提案，但是争议并没有因此停止。自从 ES Harmony 以来，我们还是第一次见到如此激烈的分歧。
作为中国 JS 社区的活跃分子，我通常都是向大家介绍 JS 新特性如何能更好的帮助我们开发者；我很不情愿将提案讨论中的争议性内容作为话题呈现给开发者，因为这对我们开发者来说没有什么意义，也并不能帮助 tc39 解决争议，还影响“和谐”。但是作为本次争议提案的反对者之一，我认为形势已经非常严峻 —— 这份提案已经接近 Stage 4，也就是正式标准；同时 tc39 最近的会议也已经拒绝所有的竞争提案，并决议停止寻求其他替代性方案；引擎厂商也即将实现和默认开启该特性。当使用该新特性的代码进入 production 环境，就意味着再也没有回头路。它很可能会成为 JS 永远无法摆脱的新的 “Bad Part”。而且本提案涉及语言的核心设施之一 class，影响烈度并非其他局部特性可比，我认为可能影响整个 JavaScript 生态。因此，我不得不将这场争议呈现给社区：
- 无论是寻求更广泛的社区反馈以提交给 tc39 和引擎厂商，还是说在最坏的情况下，让开发者做好准备;
- 至少我已经尽力了；
注意，在本次分享中，我会尽量保持客观，但作为提案的反对者，我不可能以全然中立立场叙述争议双方的观点，并且本次分享将涉及许多 JS 语法语义中的细节问题和一些对普通开发者来说相当陌生的概念。本次分享对于大家很可能将是一场痛苦的旅行。You have been warned!
一句话总结：https://github.com/tc39/proposal-class-fields/issues
