API优先的Web框架Synth，以及社区的不同声音
在近期Google的AngularJS会议上，Synth浮出水面，它是一套基于Node.js构建的API优先的Web应用框架。
自Synth被披露以来，在一个半月的时间里，其GitHub项目从1星增长到了超过500星。但Synth的创造者Jon Abrams表示，更广泛的开发者社区依旧对该框架感到迷茫。
Jon Abrams表示，Synth项目不同于传统Node.js Web框架。它的设计目的，是简化后端资源的创建过程——这些资源可以在加载AngularJS视图的时候自动预加载。
Synth的特性包括在页面加载的时候预加载Angular模型数据、预加载HTML视图，以及一套简化的项目结构——前端代码放在“前端”文件夹里，后端代码（Node的代码和包）放在“后端”文件夹中。
Abrams对预加载做了详细说明：
自动预加载数据的特性，将解决加载特定Web视图的时候，出现数据呈现延迟的问题。
许多人可能还记得Twitter最早切换到单页面应用（SPA）架构时的情况。如果点击某个链接，在线跳转到一条特定的Tweet时，该单页面应用首先进行渲染，然后经过一阵延迟后，该条Tweet才最终呈现出来。
如果当时Twitter能够使用Synth，那么这条Tweet将在页面渲染完成后即刻呈现，因为使用Synth后将无需发送获取数据的API请求。
预加载特性得益于在Synth的API处理函数中增加的对“承诺”特性的支持。由于API处理器不再需要与Express响应对象直接对话，Synth复用了API处理器。现在，当请求某个特定Web视图的时候，API处理器将发挥作用，而不是只有当相应的API被调用的时候才调用这些处理器。这将有助于减少移动Web应用中常见的高延迟问题。
Synth还希望通过使用特定的方式创建文件夹和命名函数，来简化新的RESTful API资源创建的过程。Synth扫描资源文件夹查找.js（或.coffee）文件，而后基于它们所处的文件夹的名字，生成API。要创建备忘录资源，开发者应该创建一个同名目录，然后在资源路径中的某个文件里，声明一份用于特定HTTP方法的请求处理器——可以通过指派一个导出函数来完成。
对于Synth，来自开发者社区的反应混合了不同的声音。Abrams表示，AngularJS社区的反馈非常正面，特别是在Twitter上。然而，随着他的Synth演讲最近登上了Hacker News的首页，Abrams发现一些人对于Synth旨在解决的问题产生了混淆。
芬兰的Cybercom公司的软件设计者Panu Horsmalahti对于命名函数评价道：
从我的经验来看，记忆能够对功能产生影响的新的命名约定，让一切变得更困难而不是更简单。我们可以创建一份有趣的Demo效果——展现创建这样的Demo有多“容易”和“快捷”，但是一旦我们对应用进行扩展，一切将变得更为混乱，而这个时候或许命名约定将开始遇到限制。
此外，当我们拥有这些在任何地方都将创建功能的命名约定时，学习代码基变得更加困难。
其他评论者甚至质疑Abrams的思维能力。软件工程师Richard Bishop表示：
任何时候，当我看到“某些服务器特别用于一些客户侧框架”，我都会感到作者失去了理智。
浏览器只不过是个客户端。所有针对浏览器的框架只不过（应该是）为了创建动态浏览器应用而生的抽象。如果我们需要创建服务器端的框架，而且特别用于与客户端框架配合工作，那么这其实代表着一种信号：我们应该停下了想一想，到底是哪里出了错误。
Abrams回应道：
我知道这个想法很疯狂。我喜欢疯狂的想法，越疯狂越好。
但对于浏览器仅仅是个客户端这一点，我并不同意。如果我们愿意，可以把它当作客户端对待，但我们也可以走另一条路：客户端代码可以由相同的服务器提供，该服务器能够访问客户端应用的数据。而这正是Synth的设计目的。
Synth尚停留在Beta版本，而且正处于积极开发中。因此它还离应用到产品中还有一段距离。InfoQ读者可以通过其GitHub项目（以及子项，例如synth-api）为这个开源项目做出贡献。