正如 Jake Archibald 所说，它们开始上线了！支持环境已经

• Safari 10.1。
• Chrome Canary 60 – 在chrome:flags中的实验性 Web 平台标志后面。
• Firefox 54 – 在about:config中的dom.moduleScripts.enabled设置后面。
• Edge 15 – 在about:flags中的实验性 JavaScript 功能设置后面。

有很多需要注意的奇怪问题，例如有意不支持的次要语法问题以及脚本执行顺序。

我们介绍了 Stefan Judis 的帖子，他确信我们会继续捆绑

仅仅因为我们可能很快就会在浏览器中获得对 ES6 模块的支持，并不意味着我们可以摆脱构建过程和正确的“捆绑策略”。

但有些人希望所有这些都不那么复杂，比如Pawel Grzybek

我希望从我的日常前端工作流程中抛弃的三件事：CSS 预处理器、JavaScript 编译器和模块打包器。

如果将嵌入式 Pen 放入可调整大小的容器中，它将流畅地调整大小以填充垂直和水平空间。没什么太不可思议的，但我在这里链接它是因为我认为在 Web 上提供用户可调整大小的事物的整个想法很有趣。有一个resize属性就是为此而设计的。

显然，浏览器认为在<textarea>上默认提供它是一个好主意。还有什么有意义的？也许是输入？也许是文本容器，以便用户可以选择他们喜欢的行长？也许这是另一种形式的主题？

主要目的是：无论如何你都在使用 npm，因此直接使用它来运行脚本可以消除依赖项（即 gulp/grunt/其他）并让你更接近你直接使用的工具。我可以看到 Graham Smith 的这个示例package.json文件会被人们高度引用，因为他们会自己尝试。

还记得 Damon Bauer去年在 CSS-Tricks 上介绍过这个，并提供了许多关于可能性的示例。

Felix Rieseberg 的一个极好的副标题：我如何学会停止担心并相信编译器。

我敢打赌，SCSS 的部分流行度是由于任何有效的 CSS 都是有效的 SCSS，因此你可以在现有的代码库中相当轻松地逐步过渡到 SCSS。TypeScript 也是如此

现代 JavaScript 是有效的 TypeScript，这意味着可以在不更改任何一行代码的情况下使用 TypeScript。这使我们能够通过尽早启用编译器和静态分析来使用“逐步类型化”，而无需暂停关键错误修复或新功能的工作。

而且，与 SCSS 一样，你也会从逐步过渡中获得即时收益。你会立即发现错误

… 人写的代码行越多，拼写错误属性、假设嵌套对象的父对象始终存在或使用非标准错误对象就变得越不可避免。

不过，最吸引我的是 TypeScript 对你的 IDE 的作用

TypeScript 了解哪些属性和方法在某些对象上可用，使你的编辑器也能做到这一点。之后，仅使用当前文档中的单词的自动完成系统会感觉很原始。

我相信我们都经历过的“正常”工作流程是设计发生，然后编码发生。一个健康的工作流程会在参与项目的每个人之间来回沟通，包括设计师和开发人员，但仍然：代码是最终产品。你通过设计来实现代码，而不是通过代码来实现设计。

仅仅一个月前，Sketch 43 将切换到 .JSON 文件格式的消息还是新闻。最终的发行说明很随意地发布了这个消息

修订的文件格式

但 Jasim A Basheer 正确地大肆宣传了它

… 它将从根本上改变未来几年设计工具游戏的发展方式。

“为第三方开发人员提供更强大的集成”的说法轻描淡写了。Bohemian Coding 的优秀团队做到了这一点——他们将 Sketch 的文件格式开放到一个简洁的 JSON 中，使任何人都可以创建和修改与 Sketch 兼容的文件。

继续阅读 →

前几天我正在观看Ade Oshineye 的采访，他在采访中讨论了他为 Google 的PWA 目录所做的工作，这是一个渐进式 Web 应用的展示。而且它非常棒！

它列出了许多现有的 PWA，你可以通过Lighthouse指标对其进行过滤——这是来自 Google 的一个审核工具，它会为 Web 应用评分，并使我们开发人员能够改进它们。

如果让我盲目猜测全球市场份额，我会猜错。我可能会忘记 UC 浏览器（这有点像 Peter O’Shaughnessy 文章的重点），它在亚洲非常流行。我会猜想 Firefox 略微领先于 Safari（事实证明 Firefox 的份额是 Safari 的一半），并且 Edge 到现在应该会超过 IE（也只有 IE 的一半）。

这适合在晚宴上作为谈资，但我不会以此为依据做出任何重大决策。唯一重要的统计数据是你网站的统计数据。

继续阅读 →

很少有事情比被要求通过电子邮件签署文件更令人讨厌，他们会告诉你打印它、签署它、扫描它并通过电子邮件发送回来。有一次我用 Photoshop 将我的签名添加到一个文档中，他们能够以某种方式识别出来，并让我经历了整个繁琐的过程。

我们正在使用高度复杂的计算机，难道我不能通过网络以某种方式签署此文件吗？是的，你可以！只要请求的公司正在使用eversign，就可以了。

继续阅读 →

Matt Rothenberg 编写了一个 Vue.js 教程，借鉴了 Shu Uesugi 2015 年的文章针对那些只掌握足够 jQuery 来勉强使用的用户的 React.js 入门。与 Shu 将 React 进行比较一样，Matt 没有花太多时间比较使用 jQuery 和 Vue 构建 UI 组件的方式，但这也没关系。它实际上与 React 文章中完全相同的 UI 组件（一个新的推文框），现在，两年后，在不贬低或否定 jQuery 的情况下，大多数人都准备直接使用新的框架。

请记住，我们也有指南！

模块，就像 JavaScript 中的这种语法

import { myCounter, someOtherThing } from 'utilities';

我们通常会使用 Webpack 来打包，但现在在 Safari Technology Preview、Firefox Nightly（带有标志）和 Edge 中得到支持。

它旨在支持渐进增强，因为你可以安全地链接到捆绑版本和非捆绑版本，而无需浏览器下载两者。

Stefan Judis 展示了

<!-- in case ES6 modules are supported -->
<script src="app/index.js" type="module"></script>
<!-- in case ES6 modules aren't supported -->
<script src="dist/bundle.js" defer nomodule></script>

不打包意味着更简单的构建过程，这很好，但放弃了 Webpack 之类的工具可以执行的所有其他很酷的功能，例如“tree shaking”。此外，所有这些导入都是单独的 HTTP 请求，在 HTTP/2 中可能影响不大，但仍然不是很好

Khan Academy之前在实验 HTTP/2 时发现了相同的问题。发送较小文件的想法对于保证完美的缓存命中率非常棒，但最终，它始终是一种权衡，并且取决于几个因素。对于大型代码库，将代码拆分为多个块（一个供应商和一个应用程序包）是有意义的，但发送无法正确压缩的数千个小文件不是正确的方法。

预处理构建步骤可能会继续存在。原生技术可以从中学习，但我们不妨利用两者擅长的方面。