转载

2015年JavaScript或“亲库而远框架”

JavaScript世界似乎进入了一个churn rate（流失率）的危机，框架和技术在以一种不可持续的速度被挤出和消失。不过我认为社会将会适应以及采取新的实践来回应这一现状。开发者将会把目标从整理框架（如Angular.js和Ember）转移到多种小型专用库混合体，以此来缓解生产的风险并解决来自外部竞争的不同问题。

流失

2014年过去了，作为一个JavaScript开发者很难满怀信心的去“挽回”一个特定的库或技术，即便是强大的Angular，似乎也因为最近的一些事情而动摇。

2014年10月的ng-europe会议上，Angular开发者团队透露了一个关于Angular 2.0路线图的重大更新。而最有争议的信息之一是NG2.0将与现有的Angular代码“向后不兼容”。事实上，几个关键的概念将在全新的体系结构中被弃用，Angular开发者需要有效的掌握全新的框架。

显然，这一举措令很多人感到不满。是对还是错？我们不太清楚，不过感觉上，Angular开发者在过去两年里的知识、实践和代码已经被任意的弃用了。更糟糕的是，替代品还不会马上出现——这应该是一年以后的事了，反对者认为，一旦Angular 2.0在2015年发布的话，那么开发者手中的新项目将经历“由生到死”的命运。

有很多不快的评论专门指向Angular和谷歌，有些是中肯的，有些或许并非如此。但最高得票意见之一的并不是关于Angular。它指向整个JavaScript环境，Reddit的othermike评论道：

我不明白，我不明白为什么有人认为这是一个好注意，这是很恐怖的，因为没有人有时间去理解它，当它以每三十秒的速度改变。

othermike所反映的问题也正是流失的问题，有太多的JavaScript框架都改变的太快了。

这种变化的速度是可持续的吗？

创新是伟大的，但是这种churn rate似乎过度了，当不能保证创新物的寿命时，不仅让开发者不可能做大，也加大了前期时间投入——掌握处理新框架和技术。程序员想要创造事物，并且要成为事物的主人。但是当花费大量时间去学习时，程序员该如何完成事情？又如何通过不熟悉的技术在黑暗中探索？

无需绝望

情况是糟糕的，但是人是聪明的，开发者有够足智多谋，而且编写新应用的需求不会让任何人放弃，那么我们需要做些什么呢？或许我们可以采取以下三个主要的经验教训：

以健康的怀疑态度对待新的技术。谨慎的将新的GitHub项目投入产品，等待一些事物被通用、错误修正以及被证明毫无疑问的成熟。
不要轻信于公司的支持。谷歌不是第一次对开发者所依赖的生态系统“釜底抽薪”。去问问那些使用Google的Web API的开发者就知道了。公司总会存在非理性的行为，他们的利益并不总是和你一致。
更倾向专门的库而不是整体框架。当你选择一个框架时，意味着你做了一个大的、长期的承诺。然而一旦框架被证明是错误的，你会失去很多，但是如果你从库中选择时，你可以替代一部分前端堆栈的同时保留其余部分。

库>框架？

在Angular争论的结果中，Reddit网站跟帖中有这么个问题：JavaScript开发者感觉更喜欢迁移到哪个技术？这里有r/javascript不得不说的：

React.js 和 Flux （一个只有视图 view-only 的库和事件驱动模块）
Ember.js（MVC框架）
Knockout.js （视图库）
Backbone.js （MVC框架）
Meteor（同构框架）
Mithril（MVC框架）
Ember（MVC框架）
不要框架，只需要一堆库就可以
Vue.js （视图库）
Breeze.js （数据库Model-only）
Ractive （视图库）

有趣的是这里有多少选项根本不是成熟的框架，而是专业的库——主要用于数据绑定的DOM。有人提出：“在没有整体框架，只有模块化组件的情况下去做一件事情会比较好。”他是这么说的：

我真的认为这是最好的答案。世上永远不会有一个完美的框架，因此你仅可以使用npm将相关的特征聚在一起。我发现这些小的组件的文档通常是很简单的，你不需要去等待下一个完整框架的发布。你简单的抛出一个问题，作者修复它，把它推到npm的同时不会打扰到其他组件。如果你发现自己不喜欢制模语言或错误处理，你不必考虑整个项目，只需要以自己的方式换掉目前的组件。

不知你的感受如何？通过使用小型库，让选择和混合成为可能。届时，当它们被取代时，我们可以使用相近的来交换前端堆栈。库不再是一个“非此即彼”的命题，如果你喜欢Angular的控制反转容器，但不喜欢其数据绑定。你完全可以从NPM中选择你喜欢数据绑定方式。你可以将你的遗留项目递增的迁移到新的技术中，而不是重新写一边。

更重要的是，当不同的问题被不同的库解答时，他们的解决方法可以直接比较。如果框架A用于X很好，用于Y很差，而框架B完全相反的时候，你会很困惑。不过如果库A和B都试着用于X时，它们会以一种直接的方式在独立部件和可衡量方面进行比较。

总结