当我第一次听见 WebAssembly 消息的时候就觉得它非常酷，我迫不及待地想要开始尝试使用它。然而当我不久之后开始使用 WebAssembly 的时候 ，它给我我最大的感受却是令人泄气。这篇文章的目的就是让你避免这些令人沮丧的部分。
你可能并不需要React router
你可能并不需要 React Router
如果你现在恰好在工作中使用了 Facebook 的类库 React.js，你可能会注意到浮现在 React 社区中的一些误解。其中之一就是断言 React 只是 MVC 框架中的 V（视图）部分。为了让你在开发网页应用中像一个框架那样使用它，你需要将 React 混合其他类库一同使用。但实践上来说，你很少机会看见 React 开发者会使用 MVC 中的控制器与模型。因为基于组件的 ui 架构正在稳步占领前端社区的主流，现在已经越来越少有人会去使用 MVC 结构了。
另一个误解是 React Router 库是来自于 Facebook 的官方路由解决方案。而事实上 Facebook 里的绝大多数的项目甚至都没有使用它。说到路由，实际上在相当庞大的一部分网页应用的用例中，使用一个小而定制的路由会让整个应用变得更好。在你明确地将这个主张归类为异端邪说之前，请允许我向你展示，如何在不到50行代码的情况下实现一个功能完备的路由解决方案。
要闻：flexbox
在 css3.0 中 flex 突出一个莽。解决了css多年的尴尬症–人们能把人送上太空，却依然无法在页面上做出垂直居中这种简单的事。而需要各种 hack 简直让人爆炸。而现在有了 flex 想水平居中就水平居中，想垂直居中就垂直居中。
【译】vuex基础：指引与解析
重要提醒：vuex 的 api 在我写这篇文章的时候已经有了大幅的改动提升。现在 vuex 更加完善地与vue集成在一起。我也应用了新的 api 到原来的概念，写了一篇 新的教程在 vuex 的官方文档中。
这篇文章还会让你非常深入的了解——为什么 vuex 如此重要，它是如何工作以及它如何让你的应用变得更好，更易于维护
gulp watch error (ENOSPC)
解决方法
在终端中输入
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
gulp watch error (ENOSPC)
这周在工作的时候，需要同时启动两个项目。都是用 gulp 做自动化监控，自然不可避免的需要使用到 gulp 的 watch 方法。结果就报标题所示的错误
gulp watch error (ENOSPC)
谷歌一番发现倒也是个挺常见的问题，官方 github 的issues历里也有相关的问题。
原因：
讲道理，这是倒不是 gulp 的问题，而是 linux 系统的问题。与系统的文件系统有关。
一开始我以为跟文件描述符有关， 简单来说，就是每个文件打开的时候都会有一个文件描述符，而 liunx 中操作文件依赖文件描述符，理论上，文件描述符应该随着文件打开而增加，上限应当与内存大小有关。
但实际上 linux 会对文件描述符的数量做限制，总的数量上一般限制为系统内存的10%，在单个进程上也会限制默认值一番是1024。这是为了保证这一资源不会被单个进程消耗殆尽。
在 gulp watch 执行过程中涉及大量的文件操作。比如 scss，babel 对 css，js 文件的预处理编译，输出到开发文件夹中，监控文件的改动等等。随着开发文件的增加，所需的描述符也会增加。
不过实际上并不是，或者说并不直接是。一方面，gulp watch 那小小数量的文件并不足以引起默认的文件描述符的上限；另一方面，看回解决方法，我发现问题不是在文件描述符，而是更高一层的抽象，fs.inotify。
fs.inotify
是 linux 中专门处理文件监控的文件系统事件监控框架。即为文件的增删改查提供响应事件，就像gulp watch 所做那样。但是 inotify 更底层提供比gulp watch 更丰富的事件响应。实际上 node 的 fs 包内相关的方法就依赖 inotify 来实现。而 gulp watch 无疑依赖于 fs 包。inotify 设定文件监控数量的默认值要远比文件描述符要小，更关键的一点是：
inotify 不像 文件描述符，按文件数量计算。inotify 中监控文件增删改查都会导致计数的增加，所以当我们频繁的进行开发的时候，gulp watch 不断监控响应，inotify 就被快速消耗了
end
所以说修改 fs.inotify.max_user_watches 的上限就好了……
