本周要点：Babel 正式发布 7.0 版本，CodeMirror 宣布新版本重构计划，React Fire 计划启动。
🗞 新闻联播
-
- 在经历了近 2 年、4K 次 commit、超过 50 个预发布版本后，Babel 7 终于正式发布了。这是一个大版本升级，带来了更快的速度、升级工具、JS 配置、配置覆盖、更丰富的配置项可控体积、JSX Fragment 支持、TypeScript 支持、新的提案支持等等。
2014.9.28 Sebastian McKenzie 提交了第一条
6to5(也就是 Babel 的前身) 包的 commit，当时的他 还是一个身在澳洲上学的高中生（如今已经在 Facebook 团队从事前端工程工作，链接里是他个人的成长经历），4 年的时间 Babel 已经毋庸置疑成为今天前端工程化的基础设施，而它的定位也早已不再是一个语法转译工具，发展出一整套周边生态，并且越来越多地参与到 ES 标准的建设中，让前端工程师们真正具备面向未来编程的能力。
-
- CodeMirror 是一个广为人知的运行在浏览器端的开源代码编辑器，如今团队正在重写中，新的版本将会提供更可靠的可用性、触摸屏支持、更现代的界面，同时在特性和性能上不输于现有版本。架构设计 上将基于
contentEditable来实现，以甩掉历史包袱，同时还会借鉴另一个更年轻的所见即所得的文本编辑器 ProseMirror 的思路。目前还处于原型阶段，同时号召社区的捐献。 基于 JavaScript 的源码编辑器由来已久（作为父集的富文本编辑器更是被很多人誉为天坑：为什么都说富文本编辑器是天坑？），在 WikiPedia 上还专设了一篇文章总结。如今风头正盛的可能要数微软出品的 VS Code 中使用的 Monaco Editor 了，当年初见 [Playground] 就被内置的 VS 中同款 Intellisense 智能提示惊艳到了，除此之外还有 AWS Cloud9 平台 御用 IDE 中内置的 Ace 编辑器，CodeMirror 身处的竞争环境还是相当激烈的，期待这一次会带来脱胎换骨的新体验。
另外一条 来自微软 VS Code 大神微博的八卦是，CodeMirror 的作者在 Github 上看到 Firefox debugger 被提了 PR 正在尝试切换到 monaco 于是悲愤地留言了，“我亲爱的用户你咋说不用就不用了，来看看我要发布的下个大版本很惊艳的说啊喂……”。
- CodeMirror 是一个广为人知的运行在浏览器端的开源代码编辑器，如今团队正在重写中，新的版本将会提供更可靠的可用性、触摸屏支持、更现代的界面，同时在特性和性能上不输于现有版本。架构设计 上将基于
-
Mozilla 发布了 Firefox Public Data Report，这是继两年前开始发布的 Firefox Hardware Report 后的一份面向公众的新的报告，呈现 Firefox 桌面用户如何使用浏览器和 Web 的数据，相比之前的硬件报告增加了用户活跃度以及用户行为方面的统计。
大数据时代数据的重要性不言而喻，浏览器厂商相比前端在数据采集上能力更强，Chrome 在去年宣布了 Chrome 用户体验报告，基于 Google 的 BigQuery 数据仓库开放了更加灵活的体验数据分析平台，方便开发者自己通过 SQL 挖掘有意义的数据洞见。相比之下国内浏览器厂商在开放数据这方面还有很多可以做，帮助开发者更贴近和了解用户，赋能 Web 开发者数据能力一起来提升 Web 体验。
React Fire: Modernizing React DOM
- React 大佬 Dan Abramov 又开新 issue 了，今年以来 React 团队工作重心放在 React 的基础优化上，随着这部分的工作行将尾声，开始思考 React DOM 下一个大版本将要长什么样子，于是启动一个号称 “React Fire” 计划。目前的计划是撤销过去一些设计上的错误，因为它们带来了无尽的后续的修复以及大量的技术债，同时考虑移除一部分事件系统的抽象，这些历史包袱一直没有动过，也是导致过高的复杂度和打包体积的原因。接下来的目标是让 React 更好地对齐 DOM 是如何工作的，重新检视过去的一些导致问题的有争议性的决定，让 React 更小并且更快。
- 具体的策略计划上，可以看到很多比较大的改动，应该是会带来一些不向下的兼容的。比如将
onChange迁移到onInput，将className迁移回class等，同时也可能会放弃掉一些对老版本浏览器的兼容性，采取差异化的支持策略，让 React DOM 更现代化。
📖 百家讲坛
- Service Worker Caching Strategies Based on Request Types
- PWA 在我们会使用 Service Worker 设置缓存策略，但并不是所有的资源请求都应该等量齐观，如针对资源如何做最佳的缓存策略？基于 URL 确定请求类型是一种办法，但是会对 URL 或者 mime 类型的文件扩展存在硬编码，除此之外我们还可以通过
Request.destination来决定请求的类型，实现起来可维护性更好。
- PWA 在我们会使用 Service Worker 设置缓存策略，但并不是所有的资源请求都应该等量齐观，如针对资源如何做最佳的缓存策略？基于 URL 确定请求类型是一种办法，但是会对 URL 或者 mime 类型的文件扩展存在硬编码，除此之外我们还可以通过
- Life of a pixel
- 来自 Google Chromium 团队大神 @巢鹏 的微博推荐，Google 大佬 Steve Kobes 做的 《Life of a pixel》 2018，里面详细介绍了 Chromium 如何将一个 html 文件到渲染到屏幕上，据说是 Chrome 组新人入职的学习资料。
🎤 焦点访谈
-
10 分钟的时间，快速了解 Flutter 是怎么来的，背后有些什么故事，相比现有的移动开发技术栈有什么区别，想要上手有哪些建议。
之所以注意到这个视频，是看到内网上关于 Flutter 的文章提及（外网版本：《闲聊 Flutter》）。让我们先从一条 twitter 聊起：Google 工程师 Eric Bidelman 说 一个有趣的事实，CSS Flexbox 使用率已经达到约 82%，而 Grid 的才 1%，我们可以看到 Chrome Platform Status 上的统计，2078 个属性中有 1510 个使用度不足 1%，这是 Web 确立的向下兼容的代价，在 PC 时代随着机器性能逐步过剩问题不大，而在移动为王的时代却会在碎片化的机型和系统下差距天壤之比，Web 开发部署成本低而 Native 性能更好功能特性支持度更全，于是社区开始了各种跨平台技术的探索。百度的吴多益大神以前有过一篇长文总结，信息量很大。从 Web 出发，一个很容易想到的出发点就是对 Webkit 做裁剪，抛弃掉沉重的历史包袱，也就有了 RN 以及后面的 Weex 等技术。
说回 Flutter，视频中 Eric Seidel 就介绍了 Flutter 的起源，他们之前在 Chrome 团队非常努力地针对 Web 的某些部分做一些流畅性的优化，决定尝试下做一个实验，试着打破 web 的兼容性要求，不断地砍掉向下兼容的那些历史包袱，然后通过基准测试对比发现，核心的跑分指标是之前的 20 倍，之后就沿着这个方向不断地演进出了 Flutter。当然发展到今天，Flutter 已经不能算是 web 了，从头构建的自定义的运行时、基于 Skia 的图形引擎、来自 Android 的文本渲染系统、Dart 语言和框架，意味着这已经是一个有别于 web 的全新的跨平台开发技术了。当然 Flutter 前面的路还有很长，也许顺着这条路还会有新的技术冒出来，拭目以待。
🛸 探索·发现
-
- 一个可以可视化展示任何 npm 包的各级依赖的工具。
🛰 天气预报
- 09.05 - 09.06 React Native EU 2018
- 09.20 - 09.21 Vue.js London
- 这次还特邀了 React 大佬 Dan Abramov 😎，不知会碰撞出什么火花
- 09.20 - 09.21 Google Developer Days China 2018，📍上海
- 09.29 - 09.30 React Boston
评论