什么是Babel?

The compiler for writing next generation JavaScript.

官网是这么说的，翻译一下就是下一代JavaScript 语法的编译器。

作为前端开发，由于浏览器的版本和兼容性问题，很多JavaScript的新的方法都不能使用，等到可以大胆使用的时候，可能已经过去了好几年。Babel就因此而生，它可以让你放心使用大部分的JavaScript的新的标准的方法，然后编译成兼容绝大多数的主流浏览器的代码。

在升级到了Babel6.x版本之后，所有的插件都是可插拔的。这也意味着你安装了Babel之后，是不能工作的，需要配置对应的.babelrc文件才能发挥完整的作用。下面就对Babel的presets和plugins配置做一个简单解析。

Read More

AirbnbJavaScriptStyleGuide() {
/*
 * Airbnb JavaScript Style Guide
 * 用更合理的方式写 JavaScript
 */
}

Read More

ESLint

The pluggable linting utility for JavaScript and JSX(可组装的JavaScript和JSX检查工具)

ESLint 与 JSLint、JSHint等 区别:

JSLint:

JSLint是其中最老的工具。在2002年 Douglas Crockford开发了该工具，根据其经验，强制使用js语言中精粹的部分。如果你同意这些精粹，JSLint能成为一个好的工具。JSLint的缺点是不能配置和拓展。你根本不能禁掉需要特性，并且很多缺少文档。

JSHint:

作为一个可配置的JSLint版本，JSHint被开发出来。你可以配置每个规则，将其放到一个配置文件中，这样在大项目中可以容易使用。JSHint对每个规则有好的文档，所以可以准确知道每个规则的作用。将其集成到编辑器也是简单的。

ESLint:

ESLint是比较新的工具。它被设计的容易拓展、拥有大量的自定义规则、容易的通过插件来安装。它给出准确的输出，而且包括规则名，这样可以知道哪个规则造成了错误。ESLint文档多少有些混乱。规则容易查找，以及被分为逻辑组，但是配置指南在有些地方容易弄混。然而它可以在一个地方提供链接去编辑集成、插件和样例。

JSHint是严格和不可配置的，而JSHint缺少拓展机制,ESLint不仅可以进行代码风格的检验，而且可以检查代码中的bug和其他问题。而且SLint对ES6支持的最广泛。

Read More

工欲善其事必先利其器，在此给 Web 开发人员推荐几款优秀的开源文档生成工具，希望能对大家有所帮助。

Read More

以下是八项网络发展趋势，该趋势将2018年对整个行业产生巨大影响：

自网络出现以来，一直处于不断发展的状态。Mosaic和Netscape Navigator在早期推广互联网方面功不可没。从那以后，每年都会出现一些新概念、新想法和新趋势，纵然其中有好有坏。

从这些年来的变化和趋势中，我们能得到一个重要教训：成功往往是与把握变革的浪潮有关，而不会随之而来。您可以通过探索未来的趋势，并在他人之前将适用于您的东西结合在一起来实现这一点。

Read More

Read More

Read More

一个合格的前端开发需要那些知识储备？

Read More

Front End Library

• JavaScript Library
• Css Library

Read More

Yeoman

要启动一个项目，最先要做什么？当然是搭建一个目录结构，新建一个带项目名字的文件夹，再新建一个app文件夹，里面要有common，css，img … 对了，还要有test文件夹写单元测试，嗯 ~ 大概长这样子吧

File Structure

ProjectName/
├── app/
│    ├── src/
│    │    ├── common/
│    │    │    ├── app.js
│    │    │    ├── directives.js
│    │    │    ├── filters.js
│    │    │    ├── services.js
│    │    │    └── controllers.js
│    │    ├── css/
│    │    ├── img/
│    │    ├── js/
│    │    ├── lib/
│    │    └── module/
│    │          ├── header/
│    │          └── footer/
│    │                ├── js/
│    │                └── view/
│    ├── dist/
│    │    ├── css/
│    │    ├── js/
│    │    └── html/
│    └── index.html
│                 
├── test/
│    ├── unit/
│    ├── e2e/
│    └── karma.conf.js
│
├── node_modules/
│
└── package.json

等等！NO！NO！ 我们说好的自动化呢？这样子太low了！

怎么确定自己的目录结构是合理高效的呢？在团队协作中，（幻想一下）身为架构师的你怎么保证团队立项是合乎规范的呢？那些配置文件呢，也要一个个建立吗？为了解决这么low的行为，这时候 YEOMAN 出现了！

Read More