You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JavaScript world seems to be entering a crisis of churn rate. Frameworks and technologies are being pushed out and burned through at an unsustainable speed. But I think the community will adapt and adopt new practices in response. Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn and to allow solutions to different concerns to compete separately.
Obviously, this post has big red ‘opinion’ stickers over it. But hear me out.
很显然，这是一篇『意见贴』。不过，请听我说完。
Churn
流失率危机
At the close of 2014, it’s difficult as a JavaScript developer to back a particular library or technology with confidence. Even the mighty Angular, which seemed set to establish itself as the One True Framework of Single Page Applications, looks destabilized by recent events.
In case you haven’t been paying much attention to the <ng-community>, October saw the 2014 ng-europe conference, where the Angular developer team revealed significant updates about the roadmap for Angular 2.0. One of the more controversial revelations was that NG2.0 would be backwards-incompatible with existing Angular code. In fact, several key concepts would be shelved in favour of a brand new architecture. Angular developers would effectively have to get to grips with an entirely new framework.
如果你还没关注过 ng 社区，那么看看 2014 年 10 月份的 ng 欧洲会议吧，在这个会议上，Angular 开发团队透漏了 Angular 2.0 路线图。其中最具争议的变化是 NG2.0 不再向后兼容已有的 Angular 代码。不仅如此，一些关键概念将被搁置，转而开发一个全新的架构。事实上，Angular 开发者将必须再次学习一个新框架。
Understandably, this has upset a lot of people. Rightly or wrongly, the perception was that the knowledge, practices and code that Angular developers had worked so hard on over the last two years had now been arbitrarily deprecated. Worse, the replacement wasn’t even around the corner – it was supposed to be twelve months away. New projects, the naysayers felt, were effectively going to be ‘born to die’ once Angular 2.0 was released in late 2015.
I honestly didn’t think it was possible for the Angular team to do anything in the 2.0 release that would turn me off. All of the talk of offline first capabilities and dropping support for old browsers to make way for new things sounded great.
This is a mess. The syntax looks like hot shit, and the huge gap between this and 1.3 means those of us with real jobs where projects live for years and years have to back off. I can’t tell my boss that we’re going to build something incredible, but that we need to plan for a code only, no new features rewrite in 18 months.
There’s a lot of umbrage in that thread directed towards Angular and Google specifically – some of it fair, some perhaps less so. But one of the highest upvoted comments wasn’t about Angular at all – it was targetted towards the whole JavaScript environment:
As many others here have observed, fashionable webdev now is beyond a joke; I’m seriously glad I got out of it when I did. Once you’re forced to actually deal with this nonsense you either run screaming for the exits or go insane. It’s not even fragmentation, it’s fragmentation cubed. I’ve lost count of the number of MVmumble frameworks I’ve seen pitched as “a framework using Foo, Bar and Baz”, where Foo turns out to be a event library you’ve never heard of with 3% usage share, Bar is a templating library you’ve never heard of with 2% share and Baz is a databinding library you’ve never heard of with 1%, making the combination useful to… I dunno, the author, maybe, for the next five minutes until he switches to a new set of libraries.
I don’t understand. I don’t understand why anyone thinks this is a good idea. I’ve seen code produced by people using this stuff, and it’s just unbelievably awful, because nobody has time to understand anything when it changes every thirty seconds.
Othermike’s issues seem to me really to be issues of churn. There are just too damn many JavaScript frameworks, and they’re changing too damn fast too.
Two years ago, JavaScript was ablaze in its own Renaissance, fuelled by a move towards more modern, more standardized browsers (i.e. not Internet Explorer) and the discovery of Node.js as a technology for powering front end build tools. All manner of new technologies came forth. As little as twelve months ago is seemed a fait accompli that the modern web would be dominated by Backbone.js (maybe using Marionette), with Grunt as a task runner, Require.js and Handlebars-based templating. Yet six months later, these technologies had all apparently been replaced, if the blogosphere was anything to go by – now, it was all about Angular, Gulp and Browserify. And then suddenly this stack seems questionable too.
I’m frankly overwhelmed of being exposed to new technologies.
noname123 - HackerNews
坦率地讲，不断地接触新技术让我不知所措。
noname123 - HackerNews
Innovation is great, but this kind of churn rate seems excessive. It’s just not possible for developers to make large, upfront investments of time in getting to grips with new frameworks and technologies when there’s no guarantee of their longevity. Programmers want to program – they want to build things, and be masters of their craft. But how can we get anything done when we’re spending most of our time learning? How can we feel like craftsmen when we’re scrabbling in the dark with unfamilar tech?
Once, corporate sponsorship or the backing of a large organization might have provided a beacon. We could look at a framework built by Google, Adobe or Microsoft, and believe that their support meant a long lifespan and careful stewardship. After the crises of Flex and Silverlight, that time is past.
曾经，企业赞助或大型组织的支持是指路明灯。如果 Google、Adobe 或 Microsoft 建立了一个框架，我们相信它们的支持意味着长生命周期和严谨的管理制度。但是，自从 Flex 和 Silverlight 也出现了危机之后，这种信任已经一去不复返。
It’s not just the prospect of our tools being deprecated that’s worrying, though. It’s the idea that we might make the wrong bet; get in bed with a technology only to discover that something new and substantially better is coming over the horizon. If it’s now ‘obviously’ a non-starter to use Grunt, or Backbone, or Require, who’s to say that it won’t be ‘obviously’ a non-starter to use whatever tech we’re considering today six months’ down the line?
So the situation is difficult. But people are clever, developers are resourceful, and the demand to write new apps isn’t going to let anyone give up. So what are we going to do?
Treat new technology with healthy scepticism. Be wary about pushing that cool new Github project into production. Wait until something is commonly used, has lots of bugfixes and is generally proven beyond doubt to be mature. Wait until the inevitable horror stories (all technologies have horror stories) and tales from the trenches about the use of X or Y in production.
Be less trustful of corporate backing. This isn’t the first time Google have pulled the rug out from under the feet of developers reliant on its ecosystem. Go ask anyone who’s had to deal with their web APIs. Companies act in irrational and self-harmful ways all the time. And their interests may not always be the same as yours.
不要相信企业的支持。Google 对开发者所依赖的生态环境釜底抽薪已经不是第一次了，不信去问问使用过 Google Web API 的人。企业总是扮演非理性和自残的角色，而且它们的兴趣点并不总是和你一样。
Prefer dedicated libraries to monolithic frameworks. When you choose a framework, you make a large, long term committment. You sign up to learn about the framework’s various inner workings and strange behaviours. You also sign up to a period of ineffectiveness whilst you’re getting to grips with things. If the framework turns out to be the wrong bet, you lose a lot. But if you pick and choose from libraries, you can afford to replace one part of your front end stack whilst retaining the rest.
React.js with Flux (a view-only library and an eventing module)
Ember.js (a full MVC framework)
Knockout.js (view-only library)
Backbone.js (full MVC framework)
Meteor (full isomorphic framework)
Mithril (full MVC framework)
Ember (full MVC framework)
‘No framework; just lots of libraries’
Vue.js (view-only library)
Breeze.js (model-only library)
Ractive (view-only library)
React.js 和 Flux 一个纯粹的视图库和一个事件模块
Ember.js 一个完整的 MVC 框架
Knockout.js 纯粹的视图库
Backbone.js 完整的 MVC 框架
Meteor 完整的框架，Angular 的同构体
Mithril 完整的 MVC 框架
Ember 完整的 MVC 框架
没有框架，只有大量的库
Vue.js 纯粹的视图库
Breeze.js 纯粹的模型库
Ractive 纯粹的视图库
What’s interesting is how many of the options aren’t full-fledged frameworks at all, but specialized libraries – mostly for data binding to the DOM. One person suggested “no monolithic framework but modular components that do one thing well”. Here’s how one person responded:
在这些选择里，有趣的并非是那些大而全的框架，而是那些小而专的库 - 特别是 DOM 数据绑定。有人建议说『不要选择大而全的框架，而是选择用心做好一件事的模块化组件』。下面是某人的留言：
I really think this is the best answer. There will never be a perfect framework so you can just hack the most relevant features together using npm. I find the documentation of these small components is often really simple. Any problems and there’s no waiting for the next release of the entire framework, you simply throw up an issue, the authors fix it, push it and then bam it’s on npm for everyone else and no other components have been disturbed.
If you find you don’t like the templating language or error handling, you don’t have to rethink the entire project, you just hot-swap the component for another and you’re on your way again.
I feel this way too. By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded. New projects can replace only the parts that matter, whilst core functionality whose designs are settled – routing APIs, say – can stay exactly the same between the years.
我也认同这种方式。通过使用小而专的库 -- 组件目的明确而且接口简单 -- 如果某个库不再合适，我们可以重新挑选和组合，替换掉前端技术栈的不合适部分。在新的项目中，可能只是替换了相关的部分，而核心功能 -- 路由 API -- 则可以保持不变。
Libraries stop being an all-or-nothing proposition. What if you like Angular’s inversion of control containers, but hate its data binding? No problem – you can just choose what you like from NPM and get going right away. You can move your legacy projects (read: the ones that make your employer money) to new technologies incrementally, rather than rewriting everything, providing you stick to good practices and wrap those libraries carefully.
What’s more, when different problems are answered by different libraries, their solutions can compete directly. If Framework A does X well and Y badly, compared to Framework B’s great Y and shaky X, you’re stuck. But if Library A and B both try and do X, they can compete in a direct fashion in discrete and measurable ways.
更重要的是，由于不同的问题是由不同的库解决这是你就完蛋了的，所以这是你就完蛋了它们的解决方案可以直接竞争。如果框架 A 的 X 功能很好但是 Y 功能不好，框架 B 的 Y 功能最好但是 X 功能不稳定，这时你就完蛋了。但是如果库 A 和 框 B 都尝试解决功能 X，它们就可以以一种独立的、可衡量的方式竞争。
tl;dr
文长慎入
The churn rate of front end JavaScript technologies is problematic
People are starting to feel burned out and alienated by the pace of change
The answer might be to eschew monolithic frameworks in favour of microlibraries
前端 JavaScript 技术的流失率是有问题的
人们开始感觉精疲力竭，厌倦了变化
答案可能是避免大而全的框架，青睐小而专的库
Of course, we’ll see how much of this actually happens in 2015. It’s entirely possible that Angular’s dominance will remain stable despite the wailing and gnashing of teeth – it is, after all, popular for a very good reason. If so, Angular’s position could be secured in an industry looking for standards and stability amongst the turbulence of the last two years. It’s also possible that another monolith might take Angular’s place. An informal combination of React, Flux and Browserify seems the obvious candidate.
Whatever happens, it’s hard to see the technology slowing down. Let’s see what happens. Come tell me what you reckon on Twitter. (Note: due to popular demand, I have now enabled comments on this blog. So get typing!)
The State of JavaScript in 2015
JavaScript 2015 预测
DEC 1ST, 2014
2014 年 12月 1 日
The JavaScript world seems to be entering a crisis of churn rate. Frameworks and technologies are being pushed out and burned through at an unsustainable speed. But I think the community will adapt and adopt new practices in response. Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn and to allow solutions to different concerns to compete separately.
JavaScript 似乎陷入了开发者流失率危机。新的框架和技术层出不穷，以不可持续的速度燃烧着开发者的热情。不过我认为社区会适应并接受这些新的实践。我相信开发者会放弃大而全的框架（例如 Angular.js 和 Ember），转而整合众多小而美的库，以降低开发者流失风险，并且让这些解决方案在不同的关注点上独立竞争。
Obviously, this post has big red ‘opinion’ stickers over it. But hear me out.
很显然，这是一篇『意见贴』。不过，请听我说完。
Churn
流失率危机
At the close of 2014, it’s difficult as a JavaScript developer to back a particular library or technology with confidence. Even the mighty Angular, which seemed set to establish itself as the One True Framework of Single Page Applications, looks destabilized by recent events.
到 2014 年年底，作为 JavaScript 开发者，已经很难再有耐心去支持某个特定的库和技术。即使强大如 Angular -- 一个真正的单页应用框架 -- 也因为最近的事情而动荡不安。
Let me explain.
让我稍微解释一下。
In case you haven’t been paying much attention to the
<ng-community>, October saw the 2014 ng-europe conference, where the Angular developer team revealed significant updates about the roadmap for Angular 2.0. One of the more controversial revelations was that NG2.0 would be backwards-incompatible with existing Angular code. In fact, several key concepts would be shelved in favour of a brand new architecture. Angular developers would effectively have to get to grips with an entirely new framework.如果你还没关注过 ng 社区，那么看看 2014 年 10 月份的 ng 欧洲会议吧，在这个会议上，Angular 开发团队透漏了 Angular 2.0 路线图。其中最具争议的变化是 NG2.0 不再向后兼容已有的 Angular 代码。不仅如此，一些关键概念将被搁置，转而开发一个全新的架构。事实上，Angular 开发者将必须再次学习一个新框架。
Understandably, this has upset a lot of people. Rightly or wrongly, the perception was that the knowledge, practices and code that Angular developers had worked so hard on over the last two years had now been arbitrarily deprecated. Worse, the replacement wasn’t even around the corner – it was supposed to be twelve months away. New projects, the naysayers felt, were effectively going to be ‘born to die’ once Angular 2.0 was released in late 2015.
这些变化打蒙了很多人。不管正确与否，Angular 开发者在过去两年中努力学习的知识、实践，以及编写的代码，现在已经被肆意抛弃。更糟糕的是，对于这种情况尚没有有替代方案 - 12 个月后才会出现。反对者认为，一旦 Angular 2.0 在 2015 年末发布，现在的新项目将不可避免地难逃一死。
There’s a lot of umbrage in that thread directed towards Angular and Google specifically – some of it fair, some perhaps less so. But one of the highest upvoted comments wasn’t about Angular at all – it was targetted towards the whole JavaScript environment:
业界对 Angular 和 Google 也有有很多不满 -- 有些是合理的，有些则不是。奇怪的是，投票最高的评论居然与 Angular 无关，而是直指整个 JavaScript 生态环境：
Othermike’s issues seem to me really to be issues of churn. There are just too damn many JavaScript frameworks, and they’re changing too damn fast too.
在我看来，Othermike 的问题其实就是客户流失。有太多该死的 JavaScript 框架，而且，它们也变化的太他妈的快了。
Two years ago, JavaScript was ablaze in its own Renaissance, fuelled by a move towards more modern, more standardized browsers (i.e. not Internet Explorer) and the discovery of Node.js as a technology for powering front end build tools. All manner of new technologies came forth. As little as twelve months ago is seemed a fait accompli that the modern web would be dominated by Backbone.js (maybe using Marionette), with Grunt as a task runner, Require.js and Handlebars-based templating. Yet six months later, these technologies had all apparently been replaced, if the blogosphere was anything to go by – now, it was all about Angular, Gulp and Browserify. And then suddenly this stack seems questionable too.
两年前，JavaScript 王者归来，这是因为浏览器（例如非 IE 浏览器）变得更现代化、更规范，以及新技术 Node.js 的出现丰富了前端构建工具。然后，新的技术开发不断涌现。在 12 个月前（也许更短），占主导地位的还是 Backbone.js、任务驱动器 Grunt、模块加载器 Require.js 和模板引擎 Handlebars。然后，半年过去了，这些技术已经被明显取代，变成了 Angular、Gulp 和 Browserify 的天下。突然之间，Web 开发的技术栈似乎问题重重。
Is this pace of change sustainable?
这种变化是否还会持续？
Innovation is great, but this kind of churn rate seems excessive. It’s just not possible for developers to make large, upfront investments of time in getting to grips with new frameworks and technologies when there’s no guarantee of their longevity. Programmers want to program – they want to build things, and be masters of their craft. But how can we get anything done when we’re spending most of our time learning? How can we feel like craftsmen when we’re scrabbling in the dark with unfamilar tech?
新技术很赞，但是流失率似乎过高。当新框架和新技术的寿命无法保证时，让开发者预支大量的时间来学习是不可能的。程序员想要的是编写程序，创造东西，并且成为技艺精湛的大师。但是，如果把大部分时间都花在了学习上，我们还能得到什么呢？当我们在没落的技术泥沼中挣扎时，对于工匠精神，我们还能作何期许？
Once, corporate sponsorship or the backing of a large organization might have provided a beacon. We could look at a framework built by Google, Adobe or Microsoft, and believe that their support meant a long lifespan and careful stewardship. After the crises of Flex and Silverlight, that time is past.
曾经，企业赞助或大型组织的支持是指路明灯。如果 Google、Adobe 或 Microsoft 建立了一个框架，我们相信它们的支持意味着长生命周期和严谨的管理制度。但是，自从 Flex 和 Silverlight 也出现了危机之后，这种信任已经一去不复返。
It’s not just the prospect of our tools being deprecated that’s worrying, though. It’s the idea that we might make the wrong bet; get in bed with a technology only to discover that something new and substantially better is coming over the horizon. If it’s now ‘obviously’ a non-starter to use Grunt, or Backbone, or Require, who’s to say that it won’t be ‘obviously’ a non-starter to use whatever tech we’re considering today six months’ down the line?
令人担忧的不仅仅是工具被弃用的前景，还包括错误的选择：我们选择了一项技术，然后欣然入睡，等到一觉醒来后，却出现了更好的新技术。作为一名老手，我们今天认为 Grunt、Backbone 或 Require 是最佳选择，但是谁能保证这些技术在 6 个月后依然是最佳选择呢？
It’s not hopeless
并非没有希望
So the situation is difficult. But people are clever, developers are resourceful, and the demand to write new apps isn’t going to let anyone give up. So what are we going to do?
局面是如此的艰难，但人是一种聪明的动物，开发者更是足智多谋，编写新应用的需求也不允许任何人就此放弃。那么，我们该怎么办呢？
I think there are three key lessons we can adopt:
我觉得，有 3 个关键的实践可以借鉴：
Treat new technology with healthy scepticism. Be wary about pushing that cool new Github project into production. Wait until something is commonly used, has lots of bugfixes and is generally proven beyond doubt to be mature. Wait until the inevitable horror stories (all technologies have horror stories) and tales from the trenches about the use of X or Y in production.
对新技术持善意的怀疑态度。引入 Github 上那些惊艳的新项目到生产环境时，要保持谨慎，直到它们被广泛使用、被修复大量错误、被确凿证明是成熟的、被其他项目踩坑填坑无数后，再做考虑。
Be less trustful of corporate backing. This isn’t the first time Google have pulled the rug out from under the feet of developers reliant on its ecosystem. Go ask anyone who’s had to deal with their web APIs. Companies act in irrational and self-harmful ways all the time. And their interests may not always be the same as yours.
不要相信企业的支持。Google 对开发者所依赖的生态环境釜底抽薪已经不是第一次了，不信去问问使用过 Google Web API 的人。企业总是扮演非理性和自残的角色，而且它们的兴趣点并不总是和你一样。
Prefer dedicated libraries to monolithic frameworks. When you choose a framework, you make a large, long term committment. You sign up to learn about the framework’s various inner workings and strange behaviours. You also sign up to a period of ineffectiveness whilst you’re getting to grips with things. If the framework turns out to be the wrong bet, you lose a lot. But if you pick and choose from libraries, you can afford to replace one part of your front end stack whilst retaining the rest.
首选小而专的库，次选大而全的框架。当你选择一个框架时，你做出的是一个大大的、长期的承诺。是的，你需要学习这个框架的各种内部工作原理，接受这个框架的各种怪诞行为，有时还要忍受无限期的拖延。如果这个框架最终被证明是错误选择，你就损失惨重。但是如果你是从库中挑选，你可以替换前端技术栈的一部分，同时保留其他，这样代价要小得多。
I think this third practice is already underway.
我相信你已经在应用这 3 个实践了。
Libraries > frameworks?
库 > 框架？
In the aftermath of the Angular controversy, another Reddit thread asked what technologies JavaScript developers felt like migrating to.
在有关 Angular 的争议发生后，社交新闻站点 Reddit 发起了另一篇话题 JavaScript 开发者期望迁移到哪些技术。
Here’s what r/javascript had to say:
下面是这篇话题的留言：
What’s interesting is how many of the options aren’t full-fledged frameworks at all, but specialized libraries – mostly for data binding to the DOM. One person suggested “no monolithic framework but modular components that do one thing well”. Here’s how one person responded:
在这些选择里，有趣的并非是那些大而全的框架，而是那些小而专的库 - 特别是 DOM 数据绑定。有人建议说『不要选择大而全的框架，而是选择用心做好一件事的模块化组件』。下面是某人的留言：
I feel this way too. By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded. New projects can replace only the parts that matter, whilst core functionality whose designs are settled – routing APIs, say – can stay exactly the same between the years.
我也认同这种方式。通过使用小而专的库 -- 组件目的明确而且接口简单 -- 如果某个库不再合适，我们可以重新挑选和组合，替换掉前端技术栈的不合适部分。在新的项目中，可能只是替换了相关的部分，而核心功能 -- 路由 API -- 则可以保持不变。
Libraries stop being an all-or-nothing proposition. What if you like Angular’s inversion of control containers, but hate its data binding? No problem – you can just choose what you like from NPM and get going right away. You can move your legacy projects (read: the ones that make your employer money) to new technologies incrementally, rather than rewriting everything, providing you stick to good practices and wrap those libraries carefully.
小而专的库避免了『要么全有要么全无』的问题。你喜欢 Angular 的控制反转沙箱，但是讨厌它的数据绑定？没问题 -- 你只需要从 NPM 选择你喜欢的库就可以。你可以渐进地迁移（那些让你的老板赚钱的）遗留项目到新技术项目，而不需要重写任何东西，这样你就可以保持良好的实践，专注于封装这些库。
What’s more, when different problems are answered by different libraries, their solutions can compete directly. If Framework A does X well and Y badly, compared to Framework B’s great Y and shaky X, you’re stuck. But if Library A and B both try and do X, they can compete in a direct fashion in discrete and measurable ways.
更重要的是，由于不同的问题是由不同的库解决这是你就完蛋了的，所以这是你就完蛋了它们的解决方案可以直接竞争。如果框架 A 的 X 功能很好但是 Y 功能不好，框架 B 的 Y 功能最好但是 X 功能不稳定，这时你就完蛋了。但是如果库 A 和 框 B 都尝试解决功能 X，它们就可以以一种独立的、可衡量的方式竞争。
tl;dr
文长慎入
Of course, we’ll see how much of this actually happens in 2015. It’s entirely possible that Angular’s dominance will remain stable despite the wailing and gnashing of teeth – it is, after all, popular for a very good reason. If so, Angular’s position could be secured in an industry looking for standards and stability amongst the turbulence of the last two years. It’s also possible that another monolith might take Angular’s place. An informal combination of React, Flux and Browserify seems the obvious candidate.
当然，我们会在 2015 年看到真正会发生哪些事情。尽管开发者又哭又叫咬牙切齿的，Angular 继续保持它的霸主地位也完全有可能 - 毕竟它很受欢迎。如果是这样的话，Angular 将结束近两年来 Web 开发在寻找标准和稳定的过程中所带来的混乱。不过，也有可能是另一个庞然大物取代 Angular 的位置。React、Flux 和 Browserify 的非正式组合是很强劲的候选者。
Whatever happens, it’s hard to see the technology slowing down. Let’s see what happens. Come tell me what you reckon on Twitter. (Note: due to popular demand, I have now enabled comments on this blog. So get typing!)
无论发生什么，技术进步的脚步不会放缓。让我们拭目以待。请在 Twitter 上告诉我你的预测。（注：应大家要求，现已开通这篇博文的评论功能。所以有什么感想，也来说说把！）
Posted by Jimmy Breck-McKye Dec 1st, 2014 JavaScript, front-end development, industry, opinion
Jimmy Breck-McKye 发表于 2014 年 12 月 1 日
标签：JavaScript, front-end development, industry, opinion
The text was updated successfully, but these errors were encountered: