开场前的花絮

这里就是一些会场的图片啦

签到处

给大家合影的小姐姐（征得小姐姐的同意）

会场布置

开场致辞

By 黄希彤（腾讯云技术总监）

主旨：知识是有半衰期的，获得安全感的唯一途径就是不断进步（引用王兴）。

嘉宾分享

一、The Future of Writing Javascript

By Nicolas Bevacqua

每一项新特性想要最终被纳入 ECMAScript 规范中，都需要经历 TC39 拟定的处理过程，共包含 Stage 0 - Stage 4 五个阶段

Stage 0：Strawman

以自由形式提交想法以推进 ECMAScript 发展的阶段，任何 TC39 成员，或者注册为 TC39 贡献者的会员，都可以提交。

Stage 1：Proposal

该功能的正式提交阶段

Stage 2：draft

草案是规范的第一个版本，与最终标准中包含的特性不会有太大的差别。草案之后，原则上只接受增量修改。

Stage 3：candidate

即将完成的候选阶段，需要具体实现和获得用户的反馈。此后，只有在实现和使用过程中出现了重大问题才会修改。

Stage 4：finished

已经准备就绪，该特性会出现在年度发布的规范之中。

JavaScript 的未来

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

二、初创公司前端工程体系建设

By 张云龙（全民直播 CTO）

1. 组件化开发与系统拆分

在代码层面分而治之（不要在乎用什么框架）
静态资源管理（内嵌，依赖，定位）
源代码 -> 构建工具 -> 资源表 -> 加载接口（同步，异步，预加载）
大型网站子系统拆分
直播间业务子系统，公共模块子系统，首页业务子系统 -> 构建出发布版

2. 持续集成，交付，部署

使用 Gitlab—CI（比如新推一个 feature 分支，会自动产生 feature-name.www.quanmin.tv 的测试环境）
前端工程多环境实现原理
a. 内网泛域名解析，把 *.www.quanmin.tv 解析到 gitlab-runner 机器上。
b. gitlab-ci 针对推送的 git 分支生成 nginx 配置文件
c. 随机选择一个系统可用端口，分配给 git 分支对应的应用，启动 nodejs server，监听此端口
d. nginx 反向代理，把域名代理给对应的app端口，实现多环境效果

3. 前端自动化测试

DOM 的 4 种差异（新增，删除，内容改变，样式改变）
Dolphin 自动化测试系统
a. 基于 page-monitor 项目建立页面差异对比
b. 通过设置 dom 基线建立 case，对比版本之间的 dom 差异，缩小人工的测试范围
c. 继承了行为录制，log 输出 diff，瀑布流分析的首屏分析等好用的功能

4. 看板，可视化你的进度（推荐使用物理看板）

看板原则：
可视化
显示在制作品
管理流动
电子看板的问题：
信息辐射成本高
容易形成【信息冰箱】
缺乏仪式感
定制性较差
推荐一本书 - 看板实战

5. 总结

创业不是要减少犯错的次数，而是要尽量减少犯错的成本。

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

By 迷渡

1. 动态语言如何进行快速计算

V8 中数字的表示

32位系统使用int30
64位系统使用int31

V8 中的数据类型

Object：

Array
Function
Date
RegExp
BooleanObject
StringObject
NumberObject

Primitive：
```
  Boolean
  String
  Number：
```
- Integer
- Int32
- Unit32

编译器优化

使用 typefeedback 做动态检查
一般而言，在编译阶段提前检查
检查之后，使用该类型作为动态类型
如果检查失败，去优化
去优化之后，可能会使用解释器运行中间码

未来方向

TypedArray
WebAssembly
SIMD

四、嘉宾致辞

By winter（程邵非，阿里巴巴前端技术专家）

1. 关于全栈

并不是说会 Nodejs，就是全栈了，在生产过程中的全栈，前后端都是要兼顾的。

2. 前端和客户端的深度整合

前端和客户端之前在大家的印象中，都是互相竞争的关系，但是我认为未来前端和客户端会有深层次的合作和整合。例如，Weex 中动画很慢的问题，我们就让前端丢一个动画包给客户端去实现，这个过程中我们就用了 2 个前端，3 个客户端的工程师（包括一个客户端 leader）去完成，之后效果非常好。

3. 阿里的 Node

我们要围绕 Node 做一些中间件，以及更好的服务 Node 相关的生态，为我们自己也为更多的开发者造福。

以上三点是 winner 主要想分享的点，具体内容并非原话。

下午场预告

因为下午有三个会场，以下的四个分享前两个来自第一会场（Web 前沿技术），后两个来自第三会场

五、WebGL-开启新的篇章（WebGL & Three.js 的探索之旅）

By 万波

能做什么？（可交互的产品展示，逼真的三维场景，沉浸式网站体验）

产品展示
品牌及营销类网站
应用（衣服搭配，虚拟装修）
游戏
webVR，webAR

一些疑问：

项目开发成本很高吗？（大约为2D网站两倍的时间）
性能如何？（移动端还不错，桌面端没问题。）
浏览器支持的怎么样？（桌面端 81.2%，移动端 74.7%，但是支持速度上升很快，王者荣耀的设备统计，95% 的设备支持 WebGL）

该怎么做？

从 WebGL 框架开始
- Three.js
- Babylon.js
- PlayCanvas
三位场景基本概念
- 场景：一个三维空间的容器
- 灯光：可以让物体被看见
- 材质：物体看起来的特质
- 相机：从不同角度会看到不同的面
三维物体的基本概念
- 几何体
- 网格
- 面
- 顶点
三位软件制作流程
- 创建场景
- 添加物体
- 设置材质
- 渲染出来
Three.js 能做些什么？
- 创建各种几何体
- 设置各种材质
- 设置各种类型的灯光
- 创建粒子效果
- 创建 WebVR
- 丰富的动画类型

工作原理

工作流程
- 顶点坐标（缓存起来 -> 矩阵化 -> 坐标转换 -> 图元装配 -> 显示）
- 光栅化（由顶点生成片元 -> 光栅化）
处理流程（分别处理创建流程）
我们需要储备的知识
- 了解常用 3D 软件
- 学习 Three.js
- 第三方类库
- 学习 WebGL
- openGL ES
- 线性代数，计算机图形学

六、一个前端工程师的机器学习之旅

By 邓鋆（yun，二声）（美登科技架构师）

未来的前端

多元输入
因人而异
信息层次丰富
AR / VR

五分钟搞懂机器学习

机器学习是不具体编程而使计算机找到解的过程。
传统编程与机器学习
- 发现需求（机器，人）
- 找到需求的规律（机器）
- 验证需求（机器）
- 准备数据（人）
- 运行（机器）
浅层学习（需要提前处理数据，不然效果很差）
深度学习（当数据出现偏向性时，容易产生有偏向性的过拟合，解决方法就是用更大量的数据去训练）

我们的尝试

我们想知道用户喜欢什么样的字体，具体做法：

数据采集
- 记录前端的任何动作（在 websocket 和 http2 的情况下，这样网络压力小）
- 在移动端的采集比例比较小
- 格式：纯文本
- 安全性（仅在有 TSL 证书的情况下采集）
数据处理，预测
- 整理成特征数据（csv）
- 训练
- 提供预测服务（跑单个数据几秒钟对用户是无法接受的，且当用户量大的时候对服务器负担极大。交给前端）
把预测功能对前端开放
- GPGPU with WebGL（前端 GPU 计算）
- 三个网络（当前两个网络都预测不了时，再使用最后一个网络）
  你要什么网络（偏见少节点）
  你不要什么网络（偏见少节点）
  全节点网络
把功能做到前端应用中
常用函数与网络结构
- softmax
- k-means
- t-SNE（降维方法）
- CNN（处理计算机视觉）
- RNN-LTSM
- Deep Q Learning
- Autoinput，Autooutput
一些奇奇怪怪的优化
- 预训练与组合网络
- 规则化调整与网络简化
实际业务
- 语义搜索
- 功能推荐
- 智能推荐
- 流失防止&转化
- 自动化兼容性测试
- 智能创作

关于创作，一个计算机网络创作，一个计算机网络判断是人创作还是机器创作，然后两个相互影响，最后一个越判断越准确，一个越创作越像人。

七、富途的工程化实践之路（组件与构建）

By 王运国（富途前端开发工程师）

历史问题

难以维护
质量堪忧
效率低下
交互各异

模块化和组件化

AMD 模块化规范
i18n 插件
标准化和灵活化

构建

require.js
gulp

问题：

构建耗时(15 - 20 分钟)
构建不可控(严重的依赖配置文件，构建可能会出错)
低效的缓存管理(因为全站只有一个版本号，所以每发一个版本之前的资源全部失效)
组件跨项目复用难

初步成型

组件项目化
构建变革
- require.js -> webpack (支持指定非目录寻址)
- 速度提升(1020s -> 300s，webpack 只打包，压缩和增量另外实现）
- 自己实现 webpack-amdi18n 插件

新的问题

构建环境差异 -> 使用 JenKins：
参数解析
拉取代码
安装依赖
构建
提交入库
人的不可靠性
开发者的困扰

组件 2.0

私有 NPM(registry.npm.oa.com)
命名空间 @futuweb
semver 语义化版本
去 jQuery，适配多框架
添加文档

展望

会有适应多框架的组件方案或工具出现吗？
会迎来比肩客户端工程化的方案吗？

分享者希望出现一款一统前端开发的大一统的工具。

八、解密实时协作文档

By 许海浩（石墨文档前端团队负责人）

编辑器介绍

富文本编辑器
- 开源编辑器：UEditor，Simditor
- 原理：利用contenteditable 特性以及 execCommand 接口
富文本编辑器使用场景
- 撰写博客，长文
缺陷：
- HTML 层级展现不严谨
- 不支持多人同时对同一版本编辑

如何满足多人协作？

设计一种代码层级的 text model 来表示编辑器的 HTML 内容

HTML 转化为 model 来存储并处理变化 -> Data
Data -> 转化为 HTML 进行显示

总结：支持协作的条件

编辑器的内容要与 Text Model 相互转换
Text Model 能够处理多人的改动

方案一：从头造轮子

参考对象：Google Doc，QUIP
原理：监听键盘事件，以 canvas 或其他方式来展现内容

方案二：借助开源（我们对选择）

参考对象：Etherpad
理由：市面上极少的，实现了 text model 与 HTML 互通的编辑器之一

Text Model 如何处理多人改动

关键点：Operational Transformation
借助 OT 算法的思想，使得 Text Model 能够：

与 HTML 的改动互相转换
处理多个改动的冲突

Operation

Operation 类型：
insert（插入）
delete（删除）
retain（保留）
Operation 长度：
Text Model应用到编辑器的机理：
从坐标为 0 的位置开始，依次执行 Operation

Transform - OT 算法的重要方法

当有两个基于相同版本的改动而生成的 model 时
我们可以改变一个model 将其转换为基于另一个modlel应用之后的model

总结：

以 Operation 来表示文档内容与更改
以 Transform 来解决多人改动的冲突

多端同步

流程图示

今天所有的分享到这里就结束了，手机电脑也都没电了，感谢大家看到这里。