==============接上篇 Preload：有什么好处？（上）=================

译者注：上文讲到了利用 Preload，我们可以做到哪些事情，从这里继续～

响应式加载（RESPONSIVE LOADING）

因为 Preload 是一个链接，遵循规范它应有 media 属性（目前 Chrome 还未支持，不过很快就可以了）。这个属性可以启用资源的条件加载能力。

它又有什么用处呢？举个例子，你的网站的初始视窗，对于 PC／宽屏设备展示可交互的地图版本，而对于手机／窄屏设备则展示静态的地图版本。如果你擅于加载性能优化，会想到在特定设备只加载其中一个版本的资源，而不是所有资源。而要做到这样唯一的办法就是使用 JS 去动态地加载资源。但是这么做，会使得资源对于 preloader（译者注：上文提到过的浏览器内部的预加载器）不可见，因此会使得资源的加载时机稍微滞后，不但影响了用户的视觉体验，还对站点的 SpeedIndex  得分有着负面影响。

所以我们该怎么做，才能让浏览器尽早知道所需加载的资源呢？没错，就是 Preload！

我们可以使用 Preload 提前加载这些资源，并且使用 media 属性，做到只加载需要的资源：

原文：https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/

作者：Yoav Weiss

译者按：网络优化一直是译者长期研究的方向，除了近期热门的 HTTP/2 之外，还是要关注浏览器在加载策略上的一些改进，从不同层面提升用户的访问体验。prefetch 这些 HTML5 的新特性，虽然很新鲜，但并未在生产环境中得到广泛使用，其中的原因是什么？preload 有什么改进？本文将娓娓道来~

========================译文分割线===========================

Preload（规范）是一项新的 Web 标准，旨在提升性能，让 Web 开发者对加载的控制更加粒度化。它让开发者有自定义加载逻辑的能力，免受基于脚本的 loader 所带来的性能损耗。

几周前，我在 Chrome Canary 提交了对 preload 的支持，解决了一些 bug，预计将在四月中旬合入 Chrome 稳定版。但 preload 到底是什么？它有什么用处？对你有什么好处呢？

上个月在千里码刷题的时候，碰到了比较有意思的一道题—— 隐写术。既然感觉有意思，又很久没有玩过 canvas，所以今天结合这两块内容带大家探索一下。

隐写术算是一种加密技术，权威的 wiki 说法是“ 隐写术是一门关于信息隐藏的技巧与科学，所谓信息隐藏指的是不让除预期的接收者之外的任何人知晓信息的传递事件或者信息的内容。” 这看似高大上的定义，并不是近代新诞生的技术，早在 13 世纪末德国人 Trithemius 就写出了《隐写术》的著作，学过密码学的同学可能知道。好了，说了这么多，隐写术到底是什么技术，让我们看一个例子。

下面是一张看似普通的图片，但其中却藏有另一个肉眼无法识别的图像哦。

原文：https://blog.risingstack.com/react-js-best-practices-for-2016/

作者：Péter Márton

译者按：近几个月 React 相关话题依旧火热，相信越来越多的开发者在尝试这样一项技术，我们团队也在 PC 和移动端不断总结经验。2016 来了，这应该是 React 走向成熟的一年，不管你是新手，还是已经对 React 有所了解，是时候总结一下最佳实践了，让我们看看国外的开发者总结了哪些好的实践吧~

========================译文分割线===========================

2015 可以算是 React 之年了，关于其版本发布和开发者大会的话题遍布全球。关于去年 React 的发展里程碑详情，可以查看我们整理的 React 2015 这一年。

2016 年最有趣的问题可能是，我们该如何编写一个应用呢，有什么推荐的库或框架？

作为一个长时间使用 React.js 的开发者，我已经有自己的答案和最佳实践了，但你可能不会同意我说的所有点。我对你的想法和意见很感兴趣，请留言进行讨论。

如果你只是刚开始接触 React.js，请阅读 React.js 教程，或 Pete Hunt 的 React howto。

背景

为什么是 React？

React 今年在国内特别火，一时间虚拟 DOM（Virtual DOM）等酷炫概念一下刷新了很多前端开发同学的三观，关于性能优劣的争论也在知乎上看到不少。不得不说 React 解决了一些前端项目开发的痛点，而我最近的一年多的工作重心，都在兴趣部落这样一个基于兴趣社交的 web 产品上，有很多感同身受的地方。兴趣部落这个产品从初期只有移动端的 2、3 个页面，发展到现在 50+移动页面，加上 PC 版的最近上线，中间经历了从 2-3 人的小项目到 10+人团队的大型前端项目的巨大转变。这个过程中除了人员相对业务的线性增加，代码量、维护成本也是以指数速度增长的，很快代码臃肿、难以维护与测试等问题就凸显出来。虽然内部经过一些轻量的重构优化，但开发模式还是与高度的迭代节奏很不匹配。这时候，React＋Webpack 的组件开发模式让我眼前一亮，暗下决心要让这样的先进开发模式推广到项目团队，好东西一定要让大家有所受益，而不仅仅是技术的尝鲜、摆设。

快速的移动 Web 开发模式，是我们团队一直在探索的一项内容。今天给大家介绍一种高效的开发方式，在开始内容前，我们先了解与分析一下目前主流开发模式的现状（本文聚焦响应式 Web 开发，这里主要指页面重构的工作）。

原文：http://www.html5rocks.com/en/tutorials/tooling/synchronized-cross-device-testing/

作者：Addy Osmani

译者按：在突如其来的移动热潮下，web 开发者似乎回到了早期兼容或 hack 各种浏览器的暗黑时代。唯一不同的是，现在不是兼容浏览器而是兼容设备，这比起在同一台 PC 上兼容不同浏览器要痛苦得多，另外由于终端尺寸的差异，涉及的兼容性问题会显得更加复杂。因此，跨终端的同步化测试工具是急切需要的，这意味着工作效率的成倍提升！感谢 Addy 大神的文章，给出了这个领域的多个选择，希望对大家有所帮助，遇到问题可以微博交流（@碧青_Kwok）~最后，与往常一样，转载请注明出处: )

一年前，我发过一篇关于跨文档通信方案的文章 《iframe 跨域通信的通用解决方案》，提供了一种基于创建 iframe 与轮询 window.name 的方案。

一年后，很高兴地带来彻底改造的新版本。实际上新方案已经用了很久了，一直没有时间抽象出来，最近终于挤时间分享出来了！~

原文：http://coding.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/

作者：Addy Osmani

译者按：本人第一次翻译外文，言语难免有些晦涩，但尽量表达了作者的原意，未经过多的润色，欢迎批评指正。另本文篇幅较长、信息量大，可能难以消化，欢迎留言探讨细节问题。本文主要关注 V8 的性能优化，部分内容并不适用于所有 JS 引擎。最后，转载请注明出处: )

此方案已有新版本, 请查看 《iframe 跨域通信的通用解决方案-第二弹!（终极解决方案）》。本文章可做技术学习供继续交流。

一、背景

在这个 Web 页面越来越丰富的时代，页面通过 iframe 嵌入其他的页面也越来越常见。但由于浏览器同源策略的限制，不同域之间属性和操作是无法直接交互的，所以在这个时候，开发者多多少少需要一些方案来突破这些限制。跨域问题涉及的地方也很多，如文档之间的消息通信、ajax 请求、Cookie 等，本文讨论的是 iframe 和父页面的消息通信。