JavaScript 疲劳症

前些天，我在喝咖啡时遇到一个同行朋友。

Saul：最近怎么样？

我：疲劳。

Saul：家里的事？

我：不，是Javascript。

更准确地说，我指的是React和随之而来的Javascript生态系统。

对于新手来说，不妨看看Pete Hunt问的为什么React压得初学者喘不过气：

太多菜鸟被react的学习曲线压得喘不过气。为什么呢？

如果你用过React，你就会跟Vjeux有同样的经历：

设置一个js项目太他X难了，这简直要杀了我。上次花了我一整晚时间。

React社区中有个主要的问题，挫败了初学者，也阻碍了专家。

太多工具

刚过去的这个工作季度，我们很痛苦地开始了三个新项目。我之所以说“痛苦”是因为每个项目都需要依据范围和需要做关于工具的决定。

最终，这问题在于：选择了React （和固有地 JSX），你就已经不知不觉地选择了在创建任何东西之前都需要处理一堆令人费解的构建工具、样板、linter（检查代码风格/错误的小工具）和时间片。

样板和生成器不是答案

Yeoman和Plop可以减少你做项目过程中复制粘贴的工作量。

然后，从来没有也不可能有一对一的匹配生成。

在规模足够大的项目中， 从一个应用移植特性和改进到其余应用是极其困难的，因为通用代码没被抽象成一个独立可更新的依赖关系。

当生成器是解决重复代码的好办法时，那么更好的办法就是把它抽象到一个更简单的API里。

否则，生成器本身就会因为可能用例的排列而成为一个令人困惑的逻辑不清的应用，永远处在跟它创造的应用保持相关的竞争中。

我有用过几个生成器的第一手经历，包括我自己的evolution/wordpress。

太多API 太多配置

这种情况的例子可见于Mark Dalgleish杰出的react-fetcher, 诸如Redux, React Router, Webpack之类的库， 而React生态系统通过下移他们的体系结构基础给用户已经很大程度上以简洁的API为代价选择了离散模块化，从而损害了开发者的总体体验。

单单而言，API是小的，但是即使不到一小把也会产生一堆对于一个人而言几乎不可理解的代码。

即使包含在一个“模板”项目中，被生成器scaffold，或者被隐藏在一个finalCreatteStorev3SeriousThisTime.js文件，我们创建了一堆让WrodPress插件难堪的连接。

更多抽象 更少代码

当然，这些API是基于更小的、解耦的、可测试的和因此更高质量的库的需要。

然而，我需要介于连接依赖性和生成模板之间的一个抽象中间观点。

抽象对减少有关工作原理的认知负荷是必要的，因此你才能专注于创新。

跟代码行斗争

在任何大规模项目的背后都会有大量的代码。

应用开发者不必成为库基础的专家，只需要使用它就够了。

所以，检测工具应该越小越好。

来看看这个草草罗列的替代方案清单：

• 提供一个自认为是对的且作者认可的整合API或者库给理论上90%的用例。（就多数而言，单单去掉用于React+Router+Redux的模板就是很大的提升。）

• 发布类似于Babel预置(例如，es2015, react等)的用例预置。

• 充分利用文件夹和文件命名的惯例以自动发现面向应用的路径、操作、测试等。（这对于测试（比如Mocha）和服务公共的assets已经很常见，但每个项目或多或少需要一个unicorn配置。）

• 社区驱动的快速应用开发（RAD）工具会延缓对明确配置的需求，直到范围固定。

直到生态系统的大部分采用了简洁的API、规范及努力为终端用户大量减少实现细节时，抽象工具才可能是我们的唯一出路。

RAD工具

按照上面的Twitter线程, 很多人理所应当地认为没有万能的解决方案。

然而，如果我们仅以建原型为目的开始，潜在的抽象关系就不重要了。

相应地，Vjeux 以开发快速原型设计的工具来挑战社区，甚至以定制为代价。

同时，我意识到一些现在可以用来快速开始下个项目的选择：

• budo

• nwb

• prot

• rackt-cli

• rwb

Javascript已经从限制性的、单一的框架转移到模块化、避免模板的库。

很快地，我相信它会稳定于快速发展和定制中间。

事实上，我的一个朋友意识到了同样的新兴模式：

2016 会发展出一个项目、工具和语言特性方面的真正统一的结合，把最好的包/工具/模板融合到更多的样式化项目中。——Matt Keas在State of the Union.js提到

令人激动的2016就在眼前！:)