转载自：https://github.com/usablica/front-end-frameworks
最佳前端框架聚合，致力于高效和简易化的Web开发。
你可以在这里针对所有列出的前端框架进行比较。

Just Amazing！

Quick Start

Create a new post

1

$ docker exec -it [dockerName] hexo new "My New Post"

Edit with your favorite Markdown Editor

Type Type…

Commit and Push

1

$ git commit && git push

Enjoy

https://ferminyang.github.io

Github地址

https://github.com/postmanlabs/sails-mysql-transactions

##介绍
sails-mysql-transaction是一个Sails.js与MySQL连接的ORM适配器，支持事务和集群复制。这个适配器基本上包含了流行的sails-mysql适配器，并提供额外的API来执行围绕数据库事务的操作。 它还提供以负载均衡的方式从一组只读副本中读取数据。

安装

1. 在你的项目中的package.json文件中添加sails-mysql-transactions。不要在没有包含或安装sails的情况下直接执行install。
2. 如已经安装了sails-mysql，那它可能会干扰这个组件。将其从package.json中移除然后执行npm remove sails-mysql进行卸载。
3. 这个组件只有在sails已安装的前提下才可成功安装。如果此组件已正确安装，执行npm install sails-mysql-transactions --save或直接运行npm install，组件将会自动执行安装过程。

使用postinstall script进行安全安装

如果遇到npm install时由于安装顺序不稳定而导致问题，你可以将一下内容加入到package.json文件中，作为postinstall script of npm。这将确保此组件在sails已安装的前提下被安装。需要注意的是，你并不需要将sails-mysql-transactions作为一个依赖进行添加你的package.json文件中。

1
2
3
4
5

{
  "scripts": {
    "postinstall": "npm install sails-mysql-transactions"
  }
}

安装备注：

此包将会重写sails内置的由Postman维护的waterline组件。所以如果你需要重新安装或更新sails时，本适配器也需要重装。

快速开始

一个Sails的集成测试应用在本项目的tests/integration/app目录下，里面包含完整功能，只需要执行在test/integration/app目录下执行npm install即可。

Sails config/local.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

module.exports = {
  /* your other config stay as is */
  connections: {
    mySQLT: {
      adapter: 'sails-mysql-transactions',
      host: '{{your-db-host}}',
      user: '{{your-db-username}}',
      password: '{{your-db-password}}',
      database: '{{your-db-tablename}}',
      transactionConnectionLimit: 10,
      rollbackTransactionOnError: true,
      queryCaseSensitive: false,
      /* this section is needed only if replication feature is required */
      replication: {
        enabled: true,
        inheritMaster: true,
        canRetry: true,
        removeNodeErrorCount: 5,
        restoreNodeTimeout: 1000 * 60 * 5,
        defaultSelector: 'RR', // 'RANDOM' or 'ORDER'
        sources: { 
          readonly: {
            enabled: true,
            host: '{{replica-1-host}}',
            user: '{{replica-1-user}}',
            password: '{{replica-1-password}}'
          }
        }
      }
    }
  },
  models: {
    connection: 'mySQLT'
  }
}

在Controller中使用事务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

var Transaction = require('sails-mysql-transactions').Transaction;
module.exports = {
  create: function (req, res) {
    // start a new transaction
    Transaction.start(function (err, transaction) {
      if (err) {
        // the first error might even fail to return a transaction object, so double-check.
        transaction && transaction.rollback();
        return res.serverError(err);
      }
      OneModel.transact(transaction).create(req.params.all(), function (err, modelInstance) {
        if (err) {
          transaction.rollback();
          return res.serverError(err);
        }
        // using transaction to update another model and using the promises architecture
        AnotherModel.transact(transaction).findOne(req.param('id')).exec(function (err, anotherInstance) {
          if (err) {
            transaction.rollback();
            return res.serverError(err);
          }
          // using update and association changes
          modelInstance.someAssociatedModel.remove(req.param('remove_id'));
          // standard .save() works when in transaction
          modelInstance.save(function (err, savedModel) {
            if (err) {
              transaction.rollback();
              return res.serverError(err);
            }
            // finally commit the transaction before sending response
            transaction.commit();
            return res.json({
              one: savedModel,
              another: anotherInstance
            });
          });
        });
      });
    });
  }
};

可用的事物操作列表：

1
2
3
4
5
6
7
8
9
10
11

route = function (req, res) {
  Transaction.start(function (err, transaction) {
    OneModel.transact(transaction).create(/* ... */);
    OneModel.transact(transaction).update(/* ... */);
    OneModel.transact(transaction).find(/* ... */);
    OneModel.transact(transaction).findOrCreate(/* ... */);
    OneModel.transact(transaction).findOne(/* ... */);
    OneModel.transact(transaction).destroy(/* ... */);
    OneModel.transact(transaction).count(/* ... */);
  });
};

除此之外，还有事务中实例方法上的更新，保存和关联操作，只要他们来自同一事务或通过事务进行包装（transaction.wrap(instance)）。

事务错误异常处理

如果您正在对来源于.populate的实例执行模型实例操作（例如save，destroy等），事务可能会失败。在这种情况下，在对实例进行操作之前执行transaction.wrap(instance)会修正此问题。
如果要选择性地拦截来自此模块的错误，请使用Transaction.AdapterError进行前后效果。
需要注意的是，此适配器会自动添加一个名为transactionId的列。 如果不想在特定模型上使用事务，则可以通过在模型中设置autoTK：false来禁用针对该实例的自动列创建。

支持只读副本

当提供一个或多个只读副本源时，可以使用以下API来访问来某一个自定义复制源的数据。这会将您的数据库工作负载分布在多个系统上。
Readonly模式仍然使用正常的非事务性连接集而不使用只读副本。

1
2
3
4
5

action = function (req, res) {
  OneModel.readonly().find();
  OneModel.readonly().findOne();
  OneModel.readonly().count();
};

支持在执行更新操作时获取变化内容

由于sails-mysql会在每次执行Update前进行SELECT查询，该查询可以用来比对数据更新前后的变化。.update的第三个参数返回一个数组，该数组的对象只包含已更改的字段及其原始值。

其他配置和功能

1. 当queryCaseSensitive设置为true时，会将waterline的大小写敏感度功能禁用。（标注：这是waterline-sequel的wlNext选项的功能）
2. 内置的waterline还提供了以下功能：
   • Model.<function:operate>().populateSome(Object<association:criteria>);允许你在一次调用中得到多个关联数据的内容，它的参数也接受数组形式。
   • Model的.populate方法允许以select: []形式作为查询参数之一。
   • Model的删除操作并不会在删除过程中先获取一遍完整数据模型。
3. 另外提供了一个可以新建基于模型属性实例的异步方法fromObject()。
   • 此方法允许将一个包含属性的对象或者回调函数作为参数。
   • 回调函数会返回错误对象以及模型实例对象。

1
2
3
4
5

OneModel.fromObject(attributesObject, function (err, instance) {
    if (err) { return Error; }
    // instance is the required object
});

贡献

你可以通过发起经过Travis CI测试通过的Pull请求来贡献你的代码。你需要使用npm install -d来安装本项目，并且在本地执行npm test，然后再发起Pull请求。

webpack 是一个模块打包器。

webpack 处理带有依赖关系的模块，生成一系列表示这些模块的静态资源。

为什么再造一个模块打包器

现有的模块打包器并不适用于大项目（如大的单页应用）。最重要的因素是，代码拆分和把静态资源无缝接入模块化。

尝试过扩展已有模块打包器，但无法达成下面所有的目标。

目标

• 把依赖树拆成可按需加载的块
• 让初始化加载时间尽可能地少
• 每个静态资源都是一个模块
• 模块化集成第三方库
• 尽可能地自定义打包器的每一部分
• 适合大项目

webpack 的特别之处

代码拆分

webpack 的依赖树中有同步和异步两种依赖方式。其中，异步模块将会被拆成一个新的块，并且在被优化后，生成一个对应的文件。

更多参考代码拆分。

加载器

webpack 本身只支持处理 JavaScript，但可以通过加载器来把别的资源转为 JavaScript。因此，每个资源都被当作一个模块。

更多参考使用加载器和加载器。

智能解析

webpack 有一个基本支持所有第三方库的智能解析器，甚至还支持带有表达式的依赖表述法，如 require("./templates/" + name + ".jade")。支持最常用的 CommonJs 和 AMD 这两种模块风格。

更多参考含有表达式的依赖表述、CommonJs 和 AMD。

插件系统

webpack 有一个很出色的插件系统，甚至大部分内置功能都是基于这个插件系统而来的。这个插件系统允许你根据需要来自定义 webpack，以及通过开源的方式来分发通用插件。

更多参考插件。

转载自：https://www.infoq.com/news/2014/05/facebook-mvc-flux

Facebook认为MVC无法满足他们的扩展需求，因此他们决定使用另一种模式：Flux。

在最近F8大会黑客之道：重新思考Facebook的Web应用开发，Facebook工程经理Tom Occhino说，由于他们“非常巨大”的代码库和庞大的组织，“MVC真的很快就变得非常复杂”，他们得出结论，认为MVC不适合于大规模应用。每次他们努力增加一项新特性时，系统的复杂性成级数增长，代码变得“脆弱和不可预测”。对于刚接触某个代码库的开发人员来说，这正成为一个严重的问题，因为他们害怕破坏什么东西，不敢动这些代码。其结果是Facebook的MVC正在土崩瓦解。

解决这个问题需要“以某种方式使代码结构化，使其更加可预测”。这已经通过Flux和React完成。Flux是一个系统架构，用于推进应用中的数据单向流动。根据Occhino所述，React是一个JavaScript框架，用于构建“可预期的”和“声明式的”Web用户界面，它已经使Facebook更快地开发Web应用。

Facebook软件工程师Jing Chen，补充说明MVC非常适合小型应用，但是当系统中有很多的模型与相应的视图时，其复杂性就迅速扩大，如下图所示：

根据Chen的说法，这样的程序将会非常难以理解和调试，特别是模型与视图间可能存在的双向数据流动，因此提出了以下Flux设计：

Store包含了应用的所有数据，Dispatcher替换了原来的Controller，当Action触发时，决定了Store如何更新。当Store变化后，View同时被更新，还可以生成一个由Dispatcher处理的Action。这确保了数据在系统组件间单向流动。当系统有多个Store和View时，仍可视为只有一个Store和一个View，因为数据只朝一个方向流动，并且不同的Store和View之间不会直接影响彼此。

Facebook React在GitHub的页面详细说明了Flux、Dispatcher和Store：

Dispatcher是中心枢纽，管理着Flux应用中的所有数据流。它本质上是Store的回调注册。每个Store注册它自己并提供一个回调函数。当Dispatcher响应Action时，通过已注册的回调函数，将Action提供的数据负载发送给应用中的所有Store。

随着应用程序的增长，Dispatcher变得更加关键，因为它将管理Store之间的依赖，以特定的顺序调用注册的回调函数。Store可以声明等待其它Store完成更新后，再相应地更新自己⋯⋯
Store包含应用程序的状态和逻辑。它们的角色某种程度上与传统MVC中的Model类似，但它们管理很多对象的状态，它们不是某个对象的实例，也不是Backbone集合。Store不只是简单地管理ORM风格的对象集合，它还为应用程序中的特定领域（Domain）管理应用状态。

Chen说，更重要的是在任何其它Action触发之前，确保数据层完成视图的更新。当前一个动作还未处理完时，Dispatcher能够拒绝Action。对于有其它副作用的动作，例如更新其它视图，这个设计非常有用。它让代码变得更简洁，新开发人员更容易理解也更容易调试。Flux帮助Facebook消除了一个聊天Bug，该Bug提示用户有新消息，但实际上没有。

在GitHub上可访问Flux TodoMVC教程及其源代码。

Facebook可以使用任何他们觉得合适的设计，但这个问题依旧存在。MVC适合大规模应用吗？毕竟，有那么多大规模网站。

更新 原文在英文站发布后，许多开发者在Reddit上评论Facebook的MVC。以下是一些评论，有些认为Facebook误用了MVC，而另一些则认为他们做了正确的事：

giveupitscrazy：
这毫无意义。
其一，他们的MVC图形绝对是错的。他们描绘了一个单一控制器处理多个模型，你几乎可以肯定会基于它们交互的Model或者逻辑分区来分离控制器。
很显然，他们所描述的这样一个程序无法工作，同时它也不是真正的MVC。
如果你比较他们的Flux图形和真正的MVC图形，你就会得出清晰的结论，对Web应用来说MVC没有任何内在问题。
balefrost：
并且⋯⋯事情是这样的⋯⋯他们的Flux图与你的MVC图非常接近。
他们重新发明了真正的MVC，然后决定给它一个新名字。哈哈！
hackinthebochs：
看起来这个架构将MVC变成了某种基于事件的东西。“Store”将它们自己注册到Dispatcher（可能是任何调用依赖关系），Dispatcher处理Action并确保正确的调用链。这样就将保证正确调用顺序的压力从Controller转移到Dispatcher和Store。这将减少改变行为所需的理解。
runvnc：
我刚扫了一眼，虽然我不认为自己对这个非常理解，但我理解和同意它的总体思路。

Reddit用户jingc09，通过她的评论，好像是Jing Chen，增加了一些回复：

jingc09：是啊，这是个复杂的幻灯片（那张有多个模型和视图并且双向数据流的片子），部分原因是因为MVC究竟是什么没有统一的认识，很多人对它有不同的观点。我们真正想讨论的是双向数据流，数据变化能向后循环并产生级联效应。

她还试图澄清Flux的Dispatcher不是MVC Controller：

我想澄清的一件事是，Dispatcher没有扮演Controller同样的角色。Dispatcher中没有业务逻辑，我们在多个应用中使用相同的Dispatcher代码。它只是一个中心枢纽，将事件分发给感兴趣的订阅者（通常是Store）。但在Flux中它是很重要的，因为它强制单向数据流⋯⋯

Wikipedia关于MVC Controller解释：

Controller能发送命令到Model去更新Model的状态（例如编辑文档）。它也能发送命令到相关的View去修改这个Model的View的展现（例如滚动文档）。

对此，Chen评论道：

Dispatcher不能做任何这些事，命令必须从其它地方（View、服务器响应和实时更新）传递到Dispatcher。https://github.com/facebook/react/blob/master/examples/todomvc-flux/js/dispatcher/Dispatcher.js 也许有助于说明这一点。

根据Reddit上的这些评论，关于MVC是什么以及应该如何实现，似乎有些混乱。

考虑到Facebook对MVC的处理，我们有两个观察：

1）第一张幻灯片似乎真的画了太多的Model和View，让人怀疑现实生活中真的有类似的情况吗？Facebook使用Flux解决的问题是一个有3个View的聊天应用。

2）在他们的MVC例子中，为何是View产生数据流，从而造成双向流动？同时，在Flux图中，为何是View产生Action？View不应该产生任何东西。View只是“视图”，没有别的。Facebook是在误用MVC吗？

转载地址：https://zhuanlan.zhihu.com/p/20002850
作者：sunnyzhou
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

前言

上次我写《前端工程师必知必会》已经是三年前了，那是我写过最火的文章了。三年了，我仍然会在Twitter上收到关于这篇文章的消息。

从2012年到现在，一篇文章都没发过让我觉得有点羞羞哒。三年是一段很长的时间，很多东西都发生了改变。2012年，我鼓励同学们去学习浏览器开发者工具和模块化；虽然有很多同学会觉得CSS预编译和客户端模板引擎并不靠谱，但我仍然想要说一说它们；还有JSHint，虽然有#getoffmylawn（滚出我的地盘）的警告，但依然无法阻止JSHint成为一个受欢迎的理念（准确的说，JSLint真的（只是）存在过）。

已经是2015年了，我想写一篇新的，但是当我坐下来开始动笔的时候，想到了两个事情。一，这些东西被称作“必知必会”可能有人会觉得不太公平——如果你已经觉得2012年的那篇文章如此，那本文也是一样的了。也许有同学会说，我们应该把 “足够应付业务需求的技能” 作为 “前端必须掌握的知识”，但考虑到前端行业里也有各种各样的工作可供选择，这么做也只能得到一个并不适合所有人的 “前端基础知识”。对于我来说，我需要的不是工作，我想要的是被邀请去做一份牛逼的工作。我想要的不只是去干活而已，而是想和一群牛逼的人一起做牛逼的事。我不想仅仅满足于用已有的知识来完成现在的工作，而是希望掌握更多的知识来解决未来将会面对的问题。

第二，我现在已经完全把Javascript作为我的核心了：CSS知识只有在必须关注性能问题时才会用到，其他场景已经用的越来越少。我知道有很多牛逼的前端同学并不是这样的，但我也意识到，关注JS的同学和关注CSS的同学之间的距离也越来越远。这可能需要在另起一篇文章来讨论，不过我想说的是，这篇文章中不会有介绍CSS技能标准的内容，因为我还远远没有达到能那么做的水平。

总之，就算这个技能列表并不适合你的前端工作，没关系，不要有压力，地球也不会爆炸。

Javascript

回想2009年，那时候当你知道 HTML5 在2014年才能用的时候，你是不是觉得这辈子基本上都用不到它了？如果是，那么你需要准备好接受进展缓慢但是已经趋于稳定的ES6了，它也是下一代的Javascript（现在叫 ES2015 了，嗯，这名字至少表示今年就能用了）。就我而言，ES6，额，ES2015 无疑是我个人现在最关注的 Javascript 内容。在 ES6 中将会出现一些比较大的变化：类，真正的私有，经过改进更易用的函数和参数设定，可导入的模块，等等等等。那些掌握和理解新的语法的同学以后将会在 JS 社区牛逼闪闪。相关阅读：

Understanding ES6，Nicholas Zakas 正在写的书。
BabelJS，一个可以把你写的 ES6 的代码编译成 ES5 并在现代浏览器中运行的工具。他们也有一个不错的介绍 ES6 的文档。
ES6 Rocks，里面有大量的文章探索 ES6 的特性，语义和缺陷。
你也许会问：那我需要成为一个 ES6 专家么？也许现在不需要，但至少你得和你的同事懂的一样多吧？或者比他们稍微多一点？当然，如果能在你的下一个新项目中作为一个娱乐性的技术尝试也是不错的，做好准备肯定没错的，因为我们永远不知道下一刻会发生什么。

先不说新的语言特性，使用回调和 promises 管理异步 Javascript 至少得背的滚瓜烂熟吧。浏览器端应用加载，以及应用间通信策略得形成一套自己的观点吧。而且你应该知道哪种框架最适合你，而不是现在还把时间花在理解各种框架的实现原理和该选择哪种框架上。

模块化和构建工具

毫无疑问，模块化是构建 Web 客户端应用的基石。回到2012年，关于使用哪种模块化（AMD/CommonJS）方案构建浏览器端应用还存在很多争论。而最近慢慢火起来的 UMD 则在保证代码可复用的前提下尝试避免这样的问题。 其实也没什么好争得，毕竟这俩玩意儿之间也就差几个字符吧？

我觉得类似这样的争论其实并不都需要有一个答案，这也是我觉得从2012年到现在我们发生的最大的转变，当然，也许只是我自己这么认为。因为我觉得与其说“我再也不用 AMD 了”之类的话，倒不如多去讨论 “在开发和打包过程中使用 CommonJS 和 npm 遇到的各种难题” 来的更有价值。

虽然很感激 RequireJS 曾经对模块化做出的贡献，不过现在我开始有点迷恋 webpack 了。 webpack 的构建配置比 RequireJS 更加易于理解，也更具访问性。通过它的热插拔特性和内置的本地静态服务器可以让发布更加便捷。它并不强制要求使用 AMD 或者 CommonJS – 两个它都支持。它还实现了一大堆加载器，用来完成常见的繁琐工作。 Browserify 也值得去了解一下，不过我个人认为它比 Webpack 落后很多。一些靠谱的朋友告诉我说 systemjs 也是这个领域的竞争者，不过我还没有用过，而且它的文档烂的我连看都不想看。不过我觉得它的好基友 jspm (包管理器)比较有趣，jspm 可以让你从各种包管理服务器加载你需要的各种组件，(组件必须是符合 ES6, AMD, CommonJS and globals 规范的)，包括 npm, github 等，但是我对于这两个玩意的合体还是有点不太理解。啊，还有，虽然我说了这么多关于模块化之外的内容，但我从来没想过放弃 AMD，我们边走边看吧。

我觉得如果要停止对模块化和构建工具的争论，形成统一的模块化系统，并且在这个系统里面，任何项目的代码都可以共享，而且还不需要 UMD 这样额外的补丁工具，我们还有很长的路要走。理想状况下，ES6 modules 的到来会解决这些问题，不过在这一天到来之前，类似 UMD 之类的转换器会填补这些空缺，不过貌似这样做我们又把事情变得复杂了，好像我们也总喜欢把事情弄得复杂。

与此同时，前端开发人员也需要对构建工具，各种模块化系统有自己的见解和知识储备。不管是好是坏，根据 Javascript 现在的进度，你的模块化策略会对你的项目有比较大的影响。

测试

客户端的代码测试变得越来越普遍，最近也诞生了一些新的测试框架： Karma，Intern 。我发现基于 promise 的 Intern 的异步测试方法相当优雅。不过可能是因为习惯，我大多数情况下还是用 Mocha 写测试用例。

测试的主要障碍其实是前端开发者的代码编写方式。我在2012年发表过一个关于《编写可测试的Javascript》下载地址的演讲，紧接着几个月后又发表了一篇]相关的文章。

测试的第二大障碍是工具。Webdriver 是一个艰难而巨大的工作。目前在各个浏览器端做持续集成的 UI 自动化测试基本上是不可能的，更不用说移动端了。我们仍然停留在局限于某一小部分浏览器和设备上做轻量级的自动化功能测试，尽我们所能去研究怎样快速，低成本的进行这种测试的阶段。

如果你对如何改进代码的可测试性感兴趣的话，那么唯一一本最值得看的书是 Working Effectively with Legacy Code （中译版：《修改代码的艺术》。作者 Michael Feathers 定义了“遗留代码”的概念：任何未经测试的代码都是遗留代码。在测试领域，最基本的要素就是上面这句话，尽管你可能不这么认为。

流程自动化

你首先会想到 Grunt，这也是理所当然的。而 Gulp 和 Broccoli 的自动化构建方式也别具匠心。我没用过Broccoli，只玩过Gulp，我也开始意识到Grunt对于依赖其他服务的复杂任务的自动化工作存在局限性，尤其是当这种任务每天需要运行上千次的时候。

Yeoman是在我写完2012年的那篇文章仅仅45天之后发布的，我承认当时我并没有及时去尝试一下。不过最近我开始启动一些新项目，这些新项目有两个特点
a) 这些项目都是从零开始
b) 尝试用一些不同的技术方案，试图通过这种方式找到 Bazaarvoice（提供第三方点评服务）上第三方 JS 应用的规范化的开发方式。
Yeoman 在这两方面做的都很好。一个简单的 yo react-webpack 命令就可以为你初始化好你的项目，然后各种你想要的玩具也都应有尽有：生成测试用例，本地静态服务器，hello world 入门程序，等等等等。如果 React 和 webpack 不是你想要的，也许你会在 Yeoman 的 generators（项目生成器）里面找到一个你想要的，当然，自己自定义一个这样的构建包也是比较容易的。

鉴于 Yeoman 只是一个在项目开始时才会用到的构建工具，并且鉴于我们并不是总是做新项目，所以大多情况下了解一下就够了。除非，你也想去规范整个项目开发过程，那么它可能会更有价值一点。

Broccoli 已经得到了 ember-cli 的采纳，我觉得他们的配对可能会有一个新名字，这样在未来才比较方便和 Grunt /Yeoman 对抗。而 Grunt 和 Yeoman 的开发进度也放缓了，所以未来会发生什么，我们还是静观其变吧。

代码质量

如果你像我一样，一看见违反代码规范的代码时就开始抓狂，那么 JSCS 和
ESLint 就是老天赐给你的礼物，而2012压根就没这些玩意。他们都提供了自定义代码规范的方式，并且可以在代码提交前对你的代码做自动化校验。这让我想起了…

Git

从2012年到现在，github 的使用流程并没有发生很大的变化，比如在 pull request 页面连个分支名都没有（只是恶搞一下）。

你应该非常清楚和流畅地使用功能分支（feature branches）, 使用 rebase 合并别人的代码干活，使用交互式 rebase 命令和 squash 合并提交记录，或者尽可能细颗粒度的划分项目内容，避免引起代码冲突。另一个可用的 Git 工具是钩子，具体而言，就是你可以在 push 前，commit 前，执行你的各种测试用例，检查代码质量。你可以自己写钩子，也可以使用 ghooks ，由于 ghooks 使钩子工作变得非常简单，所以你简直没有理由不用它。

客户端模板

这可能是我在2012年的那篇文章中写的最烂的内容了，某种意义上的“烂”。客户端模板还是很有价值的，而且它已经被内置到 ES2015 里面了，这不仅仅只是一件好事而已。这些年也有一些惨重的教训，不少团队把所有的渲染工作全部丢到浏览器端去做，结果产生了严重的性能问题，所以 “在浏览器端渲染生成所有 HTML” 的做法理所当然的被摒弃了。 而更为聪明的做法则是，把 HTML 生成放在服务器端，或者通过预编译的方式，先将模板做为静态资源储存起来，在需要时快速的编译成 HTML，需要更新时也可以直接在客户端更新模板。

这里会有一些新的展望，不仅是对我自己，也是对所有人，当你在考虑性能问题时，也许没必要把自己完全限定在浏览器范围内。所以，这又让我想起了……

Node

听说你懂 Javascript，那么我觉得你也应该懂 Node，至少在遇到 Node 问题是能帮得上忙的，如果连忙都帮不上，那也至少深入研究一下吧：Node 的文件系统，流，服务器，完全不同于前端的一些开发模式等等。对后端敬而远之只会限制我们前端的发展潜力。

即使你的真实生产环境中后端不用 Node，当你的工作被后端限制或阻碍的时候，Node 也是一个非常有用的工具。最起码，你也应该熟悉怎么去初始化一个 Node 项目，怎么用 Express 搭建服务器设置路由，怎么使用请求模块代理请求。

最后

感谢 Paul, Alex, Adam, Ralph 对本文的 Review，感谢他们毫不吝啬的指出我的不足之处，并给我提了很好的意见。

就这样，祝你好运。也许，三年之后我们会再见。

原文链接: A Baseline for Front-End ‘JS’ Developers: 2015

外刊君推荐阅读：

• Understanding ES6
• You Don’t Know JS
• 2015前端组件化框架之路

转载自：https://github.com/foru17/front-end-collect

在前端路上摸索前行，在这里分享自己长期关注的前端开发相关的优秀网站、博客、以及活跃开发者。欢迎更新，以下各排名不分先后顺序。

自己 RSS 长期订阅了一些IT 和技术相关博客，这里是我Feedly 输出的opml，可直接导入一些RSS 阅读器:
https://github.com/foru17/luolei-dotfiles/blob/master/feedly.opml

====

前端收集图谱

此部分为@jikeytang 贡献

• clone https://github.com/hjzheng/front-end-collect
• cd front-end-collect
• bower install
• 放入你喜欢的web容器,访问index.html即可
• 你也直接可以访问: http://get-set.cn/front-end-collect/
• 支持Chrome, Firefox and IE10&11以上浏览器

聚合&&周报订阅

专业博客

注:此处活跃度为博客更新频率，原创度指的是作者原创或者翻译的文章所占博文比例。请尊重原创，大量转载其他网站资讯的网站和聚合类网站不做推荐。

中文博客

国外博客

活跃微博

开发者博客

微博微信流行后，明显感觉到写博客的人还是越来越少了，下面推荐的这些开发者属于在网上比较活跃的，或者博客积累了大量优质资源的。

国内开发者

国内开发者一块欢迎大家 Fork提交推荐，最好能推荐一些在前端界较活跃的的开发者。

一些社区

企业官方博客

在开头我的 Feedly 订阅 opml 文件里比较全面。

书籍

=======

线上的一些翻译版好书

关于

======

本 repo 会 不断更新，感谢推荐和分享新资源的朋友。

StackOverflow地址

http://stackoverflow.com/questions/15316363/how-to-display-length-of-filtered-ng-repeat-data

问题描述

楼主有一个数组，包含了许多对象（JSON格式）。以下假设为数组的内容：

1
2
3
4
5
6
7
8
9
10

var data = [
  {
    "name": "Jim",
    "age" : 25
  },
  {
    "name": "Jerry",
    "age": 27
  }
];

接下来通过以下方式展示：

1
2

<div ng-repeat="person in data | filter: query">
</div>

在这里，通过一个输入框执行查询来筛选显示的内容。
楼主需要在另一处显示当前人员的数量，例如：Showing Persons。

楼主想要达到的目的是当一个用户搜索人员时，数据根据搜索条件显示，显示当前人员总数的Showing…persons一并变化。但是现在不行。这里总是显示所有人员的总数而不是被筛选后的数值。那么问题来了，如何才能获取被筛选数据的总数呢？

最佳解答

针对Angular1.3+

使用alias表达式（文档：Angular 1.3.0，往下翻找到Arguments章节）：

1
2

<div ng-repeat="person in data | filter:query as filtered">
</div>

针对Angular1.3之前版本

将结果赋值给一个新的变量，（例如：filtered）然后再用。

1
2

<div ng-repeat="person in filtered = (data | filter: query)">
</div>

显示结果的个数：

1

Showing {{filtered.length}} Persons

查看类似的例子。

• 1.http://www.codecast.me/
  

• 2.http://jsbin.com/
  

Github地址

https://github.com/rchampourlier/generator-gulp-ng-fast

##介绍
这是一个基于yeoman的生成器，用于生成一个基于一个Angular应用的最佳实践的推荐模式。它以Jessie Evangelista编写的generator-gulp-ng组件为基础，附加了针对Coffeescript、Less和Jade的支持，提供了更……加快速的开发模式。
使用Gulp吧！(JS构建工具有足够的说服力！)，还有Bower和NPM。

生成的目录结构

app/
  components/
    app_service.js
    app_service_test.js
  main/
    main.html
    main_controller.js
    main_controller_test.js
  app.css
  app.js
  app_controller.js
  app_controller_test.js
  index.html
bower_components/
node_modules/
.bowerrc
.gitignore
README.md
bower.json
gulpgile.js
karma-unit.js
package.json

功能

• 遵循建议的AngularJS项目结构的最佳实践。
• 所有应用目录内的Coffee/JS文件均被编译和拼接，置入build/app.js文件中。
• 所有除了index.html之外的应用文件夹内Jade/HTML文件均被拼接和编译，置入 build/templates.js文件，且被加载至AngularJS的templateCache。
• 所有应用目录内的Less/CSS文件均被拼接置入build/app.css文件。
• 所以在bower_components文件夹内的JS文件均被拼接至build/lib.js文件。
• 所有在bower_components文件夹内的CSS文件均被拼接至build/lib.css文件。
• index.jade/index.html文件被编译且复制到build/index.html文件中。
• 一个运行在9000端口的静态web服务器，支持livereload。
• 当任一在build文件夹内的HTML, JS或CSS文件发生变动，浏览器将会自动刷新。
• 当关联文件发生变化时，Karma测试运行器会自动执行单元测试。

先决条件

• node.js http://nodejs.org/
• npm http://www.npmjs.org/
• bower http://bower.io/
• gulp.js http://gulpjs.com/
• karma-cli http://karma-runner.github.io/

用法

npm install -g generator-gulp-ng-fast
mkdir my-app && cd my-app && yo gulp-ng-fast
npm install
npm install -g karma-cli
bower install
gulp
karma start karma-unit.js

然后打开浏览器访问http://localhost:9000开始干活。

支持

如有问题或疑问请至https://github.com/rchampourlier/generator-gulp-ng-fast/issues