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似乎过度了，当不能保证创新物的寿命时，不仅让开发者不可能做大，也加大了前期时间投入——掌握处理新框架和技术。程序员想要创造事物，并且要成为事物的主人。但是当花费大量时间去学习时，程序员该如何完成事情？又如何通过不熟悉的技术在黑暗中探索？
无需绝望
情况是糟糕的，但是人是聪明的，开发者有够足智多谋，而且编写新应用的需求不会让任何人放弃，那么我们需要做些什么呢？或许我们可以采取以下三个主要的经验教训：
在Angular争论的结果中，Reddit网站跟帖中有这么个问题：JavaScript开发者感觉更喜欢迁移到哪个技术？这里有r/javascript不得不说的：
有趣的是这里有多少选项根本不是成熟的框架，而是专业的库——主要用于数据绑定的DOM。有人提出：“在没有整体框架，只有模块化组件的情况下去做一件事情会比较好。”他是这么说的：
我真的认为这是最好的答案。世上永远不会有一个完美的框架，因此你仅可以使用npm将相关的特征聚在一起。我发现这些小的组件的文档通常是很简单的，你不需要去等待下一个完整框架的发布。你简单的抛出一个问题，作者修复它，把它推到npm的同时不会打扰到其他组件。
如果你发现自己不喜欢制模语言或错误处理，你不必考虑整个项目，只需要以自己的方式换掉目前的组件。
不知你的感受如何？通过使用小型库，让选择和混合成为可能。届时，当它们被取代时，我们可以使用相近的来交换前端堆栈。库不再是一个“非此即彼”的命题，如果你喜欢Angular的控制反转容器，但不喜欢其数据绑定。你完全可以从NPM中选择你喜欢数据绑定方式。你可以将你的遗留项目递增的迁移到新的技术中，而不是重新写一边。
更重要的是，当不同的问题被不同的库解答时，他们的解决方法可以直接比较。如果框架A用于X很好，用于Y很差，而框架B完全相反的时候，你会很困惑。不过如果库A和B都试着用于X时，它们会以一种直接的方式在独立部件和可衡量方面进行比较。
总结
不过无论发生什么，我们都很难看到技术的脚步会慢下来。如果您对此有自己的看法，欢迎留下您精彩的评论！
英文链接：点此进入
原文链接：http://www.csdn.net/article/2015-02-03/2823816
流失
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时，它们会以一种直接的方式在独立部件和可衡量方面进行比较。
总结
- 前端JavaScript技术的流失率是有问题的
- 人们开始疲惫于改变的步伐，被迫疏远
- 答案可能是“亲库而远框架”
不过无论发生什么，我们都很难看到技术的脚步会慢下来。如果您对此有自己的看法，欢迎留下您精彩的评论！
英文链接：点此进入
原文链接：http://www.csdn.net/article/2015-02-03/2823816
【2015年JavaScript或“亲库而远框架”】相关文章
2. 2015年的JavaScript：Angular之类的框架将被库取代
3. TIOBE 2015年1月编程语言排行榜：JavaScript成大赢家
4. TIOBE 2015年2月编程语言排行榜 JavaScript达历史最高
5. TIOBE 2015年4月编程语言排行榜：JavaScript排名第六
9. 2015年4月出炉的 21个免费的 JQuery 前端功能插件
10. RedMonk 2015年1月编程语言排行榜：进击的Swift！
本文来源：https://www.51html5.com/a3797.html
﹝2015年JavaScript或“亲库而远框架”﹞相关内容
- TIOBE 2015年3月编程语言排行榜 F#排名达到11
- 原生体验挡不住！JavaScript开源跨平台框架NativeScript
- JavaScript开源跨平台框架NativeScript
- 2015前端框架何去何从
- RapydScript：将特定代码转换成JavaScript的预编译器
- JavaScript大师Nicholas C. Zakas谈TypeScript
- CoffeeScript 已死，CoffeeScript 万岁！
- 2012年3月编程语言排行榜：JavaScript语言的回归
- TIOBE 2014年7月编程语言排行榜:JavaScript排名第9
- 2014年8月TIOBE编程语言排行榜单：JavaScript排行第十