Permalink
Find file Copy path
965dbe9 Dec 11, 2018
1 contributor

Users who have contributed to this file

141 lines (85 sloc) 7.46 KB

第八期杭州 NodeParty 回顾

活动说明

本次活动由 Rokid 主办。

  • 时间:2018 年 12 月 9 日 13:00 - 19:00
  • 地点:Rokid 杭州西溪一号22号楼

演讲主题

本期我们迎来了7位讲师为我们带来精彩的6场演讲。

《Mesh: 来一起用 JavaScript 开发无人机应用》

Slide | YouTube

主讲人介绍

刘哲轩,一个程序员。本科就读于威斯康星大学麦迪逊校区,硕士就读于佐治亚理工,毕业后在微软总部薅了几年资本主义的羊毛,现在广州奇志科技做开发。大学时期开始钻研前后端技术,强迫症癌晚期,吉他爱好者,仍在拓展能力和拓宽视野的路上上下求索。

内容

Mesh 的背景介绍、在 Mesh 里用 JS 能做什么、内核介绍以及从无人机应用出发, 连通更多的设备和服务。

一句话总结:一款可以控制无人机的移动端控制框架。

《一个应该了解的 ORM 库》

Slide | YouTube

主讲人介绍

李桑,学业半途而废,早年混迹夜场,在酒吧调酒,后跑去深圳这个年轻的城市搞 Java 后端,莫名其妙的又搞起了前端,从一个野路子到爱上 coding,目前在前端累计了大量的 web 开发经验,Java 搞丢了不想 Node.js 也溜走。

内容

  • Sequelize 介绍
  • Sequelize 工作原理和 API 介绍
  • 在实际系统中的应用场景
  • 对 ORM 库的一些思考

一句话总结:前端工程师如何像后端拓展的心路历程。

《如何基于 Egg/React 设计企业级的前后端 Framework》

Slide | YouTube

主讲人介绍

陈锦辉,宋小菜前端架构师,早年搞 Java 后端,后转 Android/iOS 原生应用,直到遇到 Node/ReactNative,彻底投入大前端怀抱,目前专注前端(App/PC Web/微信生态链)的跨端工程运维体系搭建,以及跨前后端团队的数据聚合服务层架构,痴迷追根溯源,乐于探索布道新技术。

张伟林,宋小菜资深前端开发工程师,94 年 Coding Boy,霹雳迷,已手残的纸牌魔术师,喜欢神奇的东西,技术栈从上向下不断横向纵向贯穿,目前在寻找前后端大一统思想的路上越走越偏。

内容

  • 宋小菜的业务背景介绍;
  • 引出效率基建对于长链路 B2B 的重要性;
  • 宋小菜的技术栈介绍;
  • 从技术栈规划和演进引出团队前后端框架统一的必要性;
  • 前端框架 Highway 的设计理念与资源发布;
  • 从前端框架设计引出构建部署全家桶之后与后端框架对接/打通的重要性;
  • Egg 框架的特点以及小菜的技术演进选型;
  • Thinkjs/Express/Koa/Egg 几个框架的特点与我们的取舍;
  • 后端框架 Cross 的设计理念与规划;
  • 基于 Egg 做企业框架封装(考虑 GraphQL/RPC)和可能会遇到的问题;

《N-API: 下一代 Node.js Native Module API》

Slide | YouTube

主讲人介绍

吞吞/@legendecas/ShadowNode Member/YodaOS TSC Member/语言爱好者/喜欢猫/不救公主只顾瞎逛炸鱼/Coder

内容

  • N-API 介绍
  • 单次编译即可兼容不同版本 Node.js Runtime
  • 从 NAN 到 N-API
  • N-API 的实际应用

一句话总结:听完感兴趣的话就可以去读《Node.js 来一打 C++ 拓展》了。

《Jarvis——前后端对接解决方案》

Slide | YouTube

主讲人介绍

陈传滨,一个热爱健身的前端,创业时期搞过 Java 后端,iOS 原生应用。现在专注于前端研发,喜欢制作自动化工具来提高工作效率,将单调的事情变得有意思。

内容

  • Jarvis 介绍
  • 遇到的问题
  • Jarvis 解决方案
  • Jarvis 实际应用

一句话总结:一款面向数据 API 的 Web SDK 生成工具。

《关于 class field 的神秘话题》

YouTube

主讲人介绍

贺师俊,网名 @hax,现就职于百姓网架构部;十多年来一直活跃在 Web 标准、前端开发和 JavaScript 社区,对 HTML 标准有微小的贡献。

精通 JavaScript,早在 ES4 时代就通过 es-discuss 邮件列表参与标准讨论并提交 issue,近年来则通过 GitHub 关注了几乎所有 ECMAScript 新草案的进展和讨论。尤其是最近富有争议的 optional chainingclass 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


现场照片

1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg