一、Vue 3.0
在11月14日-16日于多伦多举办的 VueConf TO 2018 大会上，尤雨溪发表了名为 “ Vue 3.0 Updates ” 的主题演讲，对 Vue 3.0 的更新计划、方向进行了详细阐述。目前该演讲的 PPT 也已上传至 Google 文档，感兴趣的可点此查阅。
可以看到，Vue 3.0 将会：
1、更快
- Virtual DOM 完全重写，mounting & patching 提速 100% ；
- 更多编译时（compile-time）提醒以减少 runtime 开销；
- 基于 Proxy 观察者机制以满足全语言覆盖及更好的性能；
- 放弃 Object.defineProperty ，使用更快的原生 Proxy ；
- 组件实例初始化速度提高 100％ ；
- 提速一倍/内存使用降低一半。
2、更小
- Tree-shaking 更友好；
- 新的 core runtime: ~10kb gzipped
3、更易维护
- Flow -> TypeScript
- Decoupled Packages（解耦包）
- 编译器重写
4、更易于原生
- 自定义 Renderer API
5、让开发者更轻松
- Exposed reactivity API
- 轻松识别组件重新渲染的原因
- 改进 TypeScript 以支持 w/TSX
- 改进警告追踪
- Experimental Hooks API
- Experimental Time Slicing Support
- 支持 IE11
PPT 地址：Vue 3.0 Updates
5号凌晨，尤雨溪公布了 Vue 3 源代码。
二、Flutter
1. 简介
Flutter 是 Google 的移动应用 SDK，用于在极短时间内在 Android 和 iOS 平台上创建高质量的原生体验。Flutter 可以和既有代码相容，世界各地的很多开发者和组织都在使用它，并且它是免费和开源的。
2. 用处
对于应用的用户来说，Flutter 可以让他们体验到美观灵活的 UI。
对于开发者来说，Flutter 降低了创建移动应用的门槛。它加速了移动应用的开发，降低了兼顾 Android 和 iOS 应用开发的成本和复杂性。
对于设计师而言，Flutter 可以确保精确地实现设计意图，而无需降低保真度或被迫进行妥协。在设计师的手里，Flutter 还可以作为一种高效的原型设计工具。
Flutter 针对在 Android 和 iOS 上运行的 2D 移动应用进行了优化。
如果您的应用强烈需要表达出品牌个性，Flutter 会非常适合。不过，即便您想要打造的应用看起来像是股票平台那样复杂，也可以使用 Flutter 来构建。
Flutter 可以构建功能齐全的应用，包括使用摄像头、地理位置、网络、存储、第三方 SDK 等。
3. 对象人群
Flutter 适用于希望快速构建精美的移动应用，或者希望用一套代码库覆盖更多用户的开发者。
Flutter 也适用于需要领导移动开发团队的开发管理人员。Flutter 可以让开发管理人员打造一个统一的移动应用开发团队，以便更快地开发更多功能，同时将相同的功能部署到 Android 和 iOS 版本的应用中，并降低维护成本。
虽然设计师群体不是 Flutter 最初的目标受众，但 Flutter 也适用于那些希望将原始设计意图高保真地传递给所有移动用户的设计师。
说到底，如果您想要漂亮的应用，令人愉悦的动效和动画，以及富有个性和身份感的 UI，那您就是 Flutter 的目标用户。
三、Serverless
1. 概念
我们把 Serverless 拆解为 server 和 less 两个单词，从字面上推断词意即为“少服务器的，亦或是无服务器的”。当然这并非指应用架构中是没有服务器资源的，而是通过 Serverless 这种服务形态，用户在使用对应的服务时，不需要关心或较少关心服务器的硬件资源、软件资源、稳定性等等，这些通常已经由云计算厂商提供设施、服务和 SLA 保障，完全托管给云计算厂商。而用户只需要专注自己应用代码本身，上传执行函数到相应云计算平台，按照函数运行的时长按量付费即可。当前比较成熟的 Serverless 云产品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute。
2. 架构
如上文的描述，Serverless 架构由两部分组成，即 Faas 和 BaaS。
FaaS（Function-as-a-Service）即为函数运行平台，用户无需搭建庞大的服务系统，只需要上传自己的逻辑函数如一些定时任务、数据处理任务等到云函数平台，配置执行条件触发器、路由等等，完成基础函数的注册。
BaaS（Backend-as-a-Service）包含了后端服务组件，它是基于 API 的第三方服务，用于实现应用程序中的核心功能，包含常用的数据库、对象存储、消息队列、日志服务等等。
Serverless 其实是通过事件驱动的，当一个任务被触发时，比如 HTTP 请求，API Gateway 接受请求、解析和认证，传递对应参数给云函数平台，平台中执行对应回调函数，配合 DB、MQ 等 BaaS 服务在特定容器中完成计算，最终将结果返回给用户。函数执行完成后，一般会被 FaaS 平台销毁，释放对应容器，等待下一个函数运行。
3. 优缺点
讲完 Serverless 的基本架构，我们来谈谈它的优点和缺点。
根据 Serverless 的特性，我们可以总结出以下优点：
同样，Serverless 是一把双刃剑，它也有一些缺陷需要我们了解，以便取长补短：
- 云厂商强绑定 当你决定使用公有云的 Serverless 产品时，它们常常会和厂商的其他云产品相绑定，如对象存储、消息等等，这意味你需要同时开通其他的服务，将导致你的应用与平台强绑定，迁移成本剧增。
- 不适合长时间任务 云函数平台会限制函数执行时间，如阿里云 Function Compute 最大执行时长为 10 min，如果你的任务时间超长，那么你需要拆分编排你的函数执行流程，并在一个函数执行结束时唤起另一个函数执行。这将增加编码的复杂度，而且花费上可能高于购买一个长时间运行的实例。
- 冷启动时间 函数运行时，执行容器和环境需要一个准备的时间，尤其是第一次启动时时间可能会较长。对一个 HTTP 请求来讲，可能会带来响应时延的增加，产生性能毛刺。
- 调试与测试 由于本地环境和平台运行环境的差异性，开发者需要不断调整代码，打印日志，并提交到函数平台运行测试，会带来一些开发成本和产生一些费用。
4. 应用场景
结合以上的优缺点，实践中我们可以发掘 Serverless 的落地场景，目前阶段 Serverless 主要适合以下的应用场景：
- 定时任务 通过时间触发对应的函数任务，完成开发者业务逻辑的处理。
- 数据加工 通过事驱动件机制，在特定的条件下触发，对系统的日志进行整合，或者对多媒体文件进行加工等等。
- 低频请求 用户可以按照频次付费，而无需构建一个应用来应对这些必要的但是量小的请求。
- IoT 物联网场景下，大部分是用户对设备的操控，用户对时延的容忍度较高，也是典型的事件触发且低频场景。
- 认知计算 适用于某些 AI 场景，如聊天机器人。
5. 结语
目前，国内 Serverless 的发展还处于早期阶段，一些配套和服务处于待完善阶段，而且大型成功案例较少。但这并不妨碍我们对技术革新的热衷，站在前端工程师的角度看，Serverless 的持续发展，在将来可以使前端更加容易的使用 Node.js 等语言搭建一个完善的应用，只需关注前后端的业务逻辑本身，而较少关心底层庞大的软硬件系统和运维知识。未来也可能给前后端工作流程带来一定变革，比如更统一的技术栈、设计规范和数据结构；更高的开发效率——应用搭建、联调时间的缩短，促使 Web 前端工程师向 Web 应用工程师进化转型。
四、WebAssembly
1. 定义
WebAssembly 或者 wasm 是一个可移植、体积小、加载快并且兼容 Web 的全新格式
2. 例子
当然，我知道，即使你看了定义也不知道WebAssembly到底是什么东西。废话不多说，我们通过一个简单的例子来看看WebAssembly到底是什么。
上图的左侧是用C++实现的求递归的函数。中间是十六进制的Binary Code。右侧是指令文本。可能有人就问，这跟WebAssembly有个屁的关系？其实，中间的十六进制的Binary Code就是WebAssembly。
3. 编译目标
大家可以看到，其可写性和可读性差到无法想象。那是因为WebAssembly不是用来给各位用手一行一行撸的代码，WebAssembly是一个编译目标。什么是编译目标？当我们写TypeScript的时候，Webpack最后打包生成的JavaScript文件就是编译目标。可能大家已经猜到了，上图的Binary就是左侧的C++代码经过编译器编译之后的结果。WebAssembly与JavaScript很实际的一个性能对比。几乎稳定的是JavaScript的两倍。
4. 什么时候使用WebAssembly？
说了这么多，我到底什么时候该使用它呢？总结下来，大部分情况分两个点。
- 对性能有很高要求的App/Module/游戏
- 在Web中使用C/C++/Rust/Go的库
举个简单的例子。如果你要实现的Web版本的Ins或者Facebook， 你想要提高效率。那么就可以把其中对图片进行压缩、解压缩、处理的工具，用C++实现，然后再编译回WebAssembly。
