JS框架称得上层出不穷，几乎每周都有新的框架与广大用户见面。在今天的文章中，我们将立足于逆向思维，考虑如何断定一套JS框架不符合实际需求。作为一名JavaScript架构师、培训人员及导师，我经常面对这样一个问题——你最喜欢的框架是什么？或者哪款框架最为出色？而我给出的两个答案往往令提问者感到意外。就目前而言，我个人最偏好的框架是React JS。但如果要为企业选择一套框架，我给出的答案则是Angular 2.0。
不过大家更应该问的恐怕是“为什么要准备两个答案？”或者更进一步探究，“我们该如何完成框架的选择过程？”下面，我将向大家共享一些使用框架的实际感受。为了公平起见，首先聊聊我个人的一点选择倾向。
我个人更偏爱以下几套框架：
- React JS
- Angular 2
- Angular 1
- Ext JS 5或者6
- Ext JS 4
而如果要为大型企业推荐框架，那么答案会稍有不同：
- Angular 2
- Angular 1
- Ext JS 5 或者6
- React
- Ext JS 4
考虑到这些前提，下面我们具体思考接下来的问题。
由谁来使用框架？
在我所效力的企业当中，大多数员工都属于Java程序员。这意味着JavaScript及其各类衍生版本都能够为大家所快速熟悉及掌握。然而尽管各框架之间存在相当程度的共性，但也仍有不少差异需要强调。目前，Ext或者Angular 2的发展势头可能更好，这是因为它们能够以更贴近Java或者C#的方式产生效果，从而吸引更多相关开发者的加入。
学习曲线是否陡峭？
那么在前面提到的框架中，其各自需要耗费多少时间进行学习？要找到答案，我们还需要考虑以下几个问题：
- 能否购买支持服务以解答技术疑问？
- 说明文档是否清晰明确？
- 框架流行程度如何？
- 团队中是否已经拥有相关专家？
- 这套框架是否拥有公开Slack频道？
- 框架开发者们是否关注企业客户的需求？
说到这里，Ext JS与Angular 2的优势应该已经显现出来了，而这也正是我总结个人最爱的两个选项的具体方式。
框架是否提供良好的约束机制？
我还记得当初VB 1.0刚刚面世时，每个人都兴奋地高呼“看看它的构建与运行速度有多快”，并以此作为选择的理由。
没错，VB允许大家采取任何能够达到目标的代码编写方式。但历史经验告诉我们，只要框架本身仍然提供部分结构，那么用户仍有可能编写出糟糕的代码，而且这类蹩脚成果的比例与框架所提供的结构量存在正相关。
在与多位开发者合作时，有些人可能要求其他成员重视代码结构而不只是“能跑就行”。
立足于这一问题，Angular 2再次脱颖而出，而Ext则处于垫底位置。尽管Ext提供所谓MVC及MVVM机制，但其无法保证开发者编写的代码成果与其设计模式相匹配。在MVC当中，我甚至不确定编写者是否清楚自己在开发些什么东西。
行业标准
为了让Ext的运作效果更贴近桌面开发环境，其能够生成HTML并利用其布局机制控制各元素在屏幕上的显示位置。前面提到的其它框架皆全部利用CSS实现布局控制。Ext的优势在于，我不需要了解HTML或者CSS即可实现理想的显示效果。但弊端则是，如果我希望尝试一些Ext支持能力之外的效果，则将面临巨大障碍。另外，使用HTML与CSS则会让屏幕渲染时长大幅增加，特别是在组件存在三层以上嵌套的情况下。
另外，Ext利用特殊的类定义机制让JavaScript看起来更像是Java及C#。这不禁令人担心，随着ECMAScript标准的演进与其自有类似机制的推出，Ext选择的作法未来还是否能够得到广泛支持。
Ext还采用专门的构建流程。虽然这能够规避构建中的大部分阻碍，但大家可能会问，“为什么不采用gulp、grunt或者npm脚本之类的标准？”
尽管Angular 2主要使用TypeScript，但Angular 2与Ext间的区别在于：1）尽管强烈推荐，但大家并不一定需要使用TypeScript；2）TypeScript只负责实现部分功能，且实际效果与ECMAScript标准类似。因此，Angular 2的发展前景明显要更为光明。
在这方面，另一款值得关注的框架为React JS。其应用构建流程全部采用行业标准，但这款单元测试框架并不允许大家在测试中使用Karma。
可测试性如何？
毫无疑问，我个人要求全部框架都具备单元测试能力，因此Ext JS 4直接被淘汰出局。大家可能会强调，MVC能够用于测试控制器，但这是MVC的功能而非由Ext自身实现。
在另一方面，React的测试能力最出色，这也是我支持它的原因所在。但我认为它仍然不太适合由企业客户选择，因为其学习周期太长而且说明文档不太完善。
调研工作
好了，到这里各原则性问题已经相当明确，但问题在于我们要如何提前做好准备？大多数具体信息往往要在员工实际使用某套框架后才会出现。
最好的办法就是听听框架老用户们的意见。在测试框架中，我的起步工作就是“我能在互联网上找到多少与该框架相关的信息？”而第二个问题则是，“该框架流行程度如何？”最后，我会联系这款框架的反对者，听听他们对其做出的负面评价。
如何判断一套框架不符合实际需求？
现在说回标题——要想选出一套错误的框架，大家应当听信销售人员的忽悠、别问任何问题，同时忽略一切之前提到的考量因素。
然后为自己的冲动懊悔不已……
原文标题：How Not to Choose a Framework
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
