原文：Are you ready for the era of big data? 14 popular JavaScript based data visualization tools

俗话说，一图胜千言。图形化的信息可以让人们对数据有更加直观清晰的理解，让信息发布者更加高效地展示自己的核心内容。在前端开发中，如果缺少合适工具，制作数据可视化图表会十分复杂。然而随着数据可视化概念逐年火热，有较多优秀的图表开源库和制作工具脱颖而出。下面，我们就拿其中比较有名的 14个产品进行简要介绍。

AnyChart

链接：http://www.anychart.com/

AnyChart 是基于 Flash/JavaScript(HTML5) 的图表解决方案，它可以轻松地跨浏览器、跨平台工作。除了基础的图表功能外，它还有收费的交互式图表和仪表功能。它可以通过 XML 格式获取数据，该方式让开发人员非常灵活地控制图表上的每一个数据点，而当图表数据点数量偏大时，则可以采用 CSV 数据输入，减小数据文件大小和图表加载时间。

amCharts

链接：http://www.amcharts.com/

amCharts 是一款高级图表库，致力于对 Web 上的数据可视化提供支持。它所支持的图表包括柱状图、条状图、线图、蜡烛图、饼图、雷达、极坐标图、散点图、燃烧图和金字塔图等等。amCharts 库是一款完全独立的类库，在应用中不依赖任何其他第三方类库，就可直接编译运行。除了提供最基本的规范要素外，amCharts 还提供了交互特性。用户在浏览基于 amCharts 制作的图表时，用鼠标 hover 图表内容，可以与其进行交互，使图表展示细节信息，其中呈现信息的容器被叫做 Balloon（气球）。除此之外图表可以动态动画的形式被绘制出来，带来了了非常好的展示效果。

ECharts 在 github 上沉寂了数个月，想必很多小伙伴充满了各种疑问，ECharts是不是不维护了？你们以后是不是不做了？别着急，其实这几个月，我们的设计师、工程师一直厉兵秣马，加班加点，没有周末，没有女朋友地疯狂工作中。

终于，ECharts 的又一个重大版本即将出炉，在 ECharts 3 正式版发行前，我们选择了今天，12.3，一个能够隐喻我们一步一步从1.0到2.0再到3.0走来的日子，提前给广大用户带来 ECharts 3 的测试版。

那 ECharts 3 究竟会有哪些新的特征，我们用数月究竟在颠覆着自己的什么呢？接下来让我们一一为您道来：

焕然一新的面貌

焕然一新的面貌

从底层的技术架构到上层的外观展现，都进行了较大的升级。无需多言，请看下面的诸多例子。

原文：Defusing Race Conditions when Using Promises

网络时代，创建现代软件时其中一个很大的限制是所需要的数据往往在远程服务器上。应用程序在等待网络请求时简单地锁死是不现实（甚至不可能）的。相反，我们必须让应用程序在等待时保持响应。。

为此，我们需要写出并发的代码。当应用的某一部分正在等待网络请求的响应时，其他部分必须继续运行。 Promise 对于编写非阻塞型的代码是很不错的工具，而且你的浏览器就支持这个。

Promise 能让潜在可怕的异步代码变得非常友好。下面假设一个博客的文章视图这样从远程服务器加载一篇文章并显示它：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// Called from `componentWillMount` and `componentWillReceiveProps`:
ArticleView.prototype.updateArticle = function (props) {
    this.setState({
        error: null,
        title: null,
        body: null
    });
    ArticleStore.fetch(props.articleID).then(article => {
        this.setState({
            title: article.title,
            body: article.body
        });
    }).catch(err => {
        this.setState({ error: 'Oh Noes!' });
    });
};

注意：这个例子使用了 React，但是这个概念适用于绝大多数前端视图系统。

这样的代码是很优雅的。许多复杂的异步调用消失了，取而代之的是直接明了的代码。然而，使用 promise 并不能保证代码是正确的。

注意到我例子中引入的不易察觉的竞态条件了吗？

提示：竞态条件出现的原因是无法保证异步操作的完成会按照他们开始时同样的顺序。

All code in any code-base should look like a single person typed it, no matter how many people contributed. — idiomatic.js

fecs 是以百度前端代码规范为目标的前端代码风格套件，套件包括 htmlcs、csshint、lesslint 和 jformatter，此外还有社区的相关开源模块 cssbeautify、csscomb、fixmyjs 和 esformatter：

显而易见，fecs 不仅能检查 HTML/CSS/LESS/JavaScript 代码的规范问题，而且还能修复代码的规范问题。

代码检查

fecs-check

代码的检查，目前主要是以百度前端代码规范（JS/CSS/HTML） 的检查为首要目标，同时根据 EFE 的技术规划，为 Less 代码规范 的检查带来了 lesslint。

背景：

MVC是一种架构设计模式，它通过关注点分离鼓励改进应用程序组织。在过去，MVC被大量用于构建桌面和服务器端应用程序，如今Web应用程序的开发已经越来越向传统应用软件开发靠拢，Web和应用之间的界限也进一步模糊。传统编程语言中的设计模式也在慢慢地融入Web前端开发。由于前端开发的环境特性，在经典MVC模式上也引申出了诸多MV*模式，被实现到各个Javascript框架中都有多少的衍变。在研究MV*模式和各框架的过程中，却是“剪不断、理还乱”：

1. 为什么每个地方讲的MVC都不太一样？
2. MVP、MVVM的出现是要解决什么问题？
3. 为什么有人义正言辞的说“MVC在Web前端开发中根本无法使用”？

带着十万个为什么去翻阅很多资料，但是看起来像view、model、controller、解耦、监听、通知、主动、被动、注册、绑定、渲染等各种术语的排列组合，像汪峰的歌词似的。本篇希望用通俗易懂的方式阐述清楚一些关系，由于接触时间有限，英文阅读能力有限，可能会存在误解，欢迎讨论和纠正。

最近因为遇到一个float相关的bug，又跑去撸了一遍css标准。然后发现，它确实比其他属性复杂好多，既不像inline-block那样单纯的完成并排显示，又不像绝对定位那样彻底的脱离文档流而不影响别的元素。它唯一单纯的就是，真的是唯一可以实现文字环绕显示的属性。

但是唯一单纯的特点却并不是很招人待见，相反，大家更习惯使用float去完成其他的功能，比如横排展示和自适应分栏布局。

很多人这样用着，只是因为一堆现成的文章告诉他们可以这样用，但是到底为什么可以，以及用的时候要注意什么问题却并不是所有人都知道，结果就是，一时的“便利”，为日后的维护埋了一堆的坑。

这篇文章打算通过将目前一些成文的浮动元素的特点与CSS规范中的具体描述对应，来加深大家对float属性原理的理解。并在后面通过一个bug实例，说明使用这个属性时要注意的问题。

浮动元素的业界公认特点

float属性被设置为非none的元素：

1. 元素被视作块级元素，相当于display设置为"block"；
2. 元素具备包裹性，会根据它所包含的元素实现宽度、高度自适应；
3. 浮动元素前后的块级兄弟元素忽视浮动元素的而占据它的位置，并且元素会处在浮动元素的下层（并且无法通过z-index属性改变他们的层叠位置），但它的内部文字和其他行内元素都会环绕浮动元素；
4. 浮动元素前后的行内元素环绕浮动元素排列；
5. 浮动元素之前的元素如果也是浮动元素，且方向相同，它会紧跟在它们后面；父元素宽度不够，换行展示；
6. 浮动元素之间的水平间距不会重叠；
7. 当包含元素中只有浮动元素时，包含元素将会高度塌陷；
8. 浮动元素的父元素的非浮动兄弟元素，忽视浮动元素存在，覆盖浮动元素；
9. 浮动元素的父元素的浮动兄弟元素，会跟随浮动元素布局，仿佛处在同一父元素中。

目前实现的很多应用都是直接对应上述特点实现的。但是很多人在看过这些描述以后，并不知道它的结论从何而来，无据可循，怎会安心？为了解决大家的疑虑，下面我会将上面的九条与CSS规范做一一的对应。