D3，数据驱动的媒体思维

媒体在手工的时候思维方式是受限的，就好比你2岁的时候要过河，假使思考层面你知道径直走过去是最快的，但你必须在旁边等个大人（互联网技术）借力过去。因此你的思维方式就会转变为怎么去借力和沟通了...

NID信息设计  

d3js.org/ 

一开始知道 D3.js  这个网页前端 Javascript 语言类库，还是从一个从前在爱范儿写作的网友的实习经历看到的。他写了自己在纽约时报的实习经历，提到了这个著名报纸的图表编辑部门的各种工作流程，包括D3.js的开发及应用。当时只是觉得这个应该是众多前端绘图库的又一个版本，但机缘巧合下开始拿起来使用过之后，才发现全然不是这么回事。

与其说这是一个绘图的js类库，不如说是一个给数据穿“衣服”的类库。如果你用绘图导向的思维，从一条线到另一个圆的“目的”出发，然后找数据来绘制它来的话，那么用 D3.js 来帮忙就会相当别扭。你找不到画线的第一个点，也找不到第二个；也找不到for循环，函数的来龙去脉也是相当模糊的。大量的内嵌函数在随处使用，再加上 Javascript 是一个弱类型语言，各种参数传递非常不明确，对象绑定的函数执行方式，其执行周期也很难以捉摸。最后，你找不到一个绘图类库，例如 Processing 对 Java 语言的再处理那样，包装终极的绘图入口，即，绘图函数（例如叫做 draw 或者 render）。

这是因为这压根不是绘图类库。在用它瞬间描出一个几千行数据的文件的点状分布图之后，我的一个感受就是这个根本就是一个web版本的R语言（一种以对数组、矩阵数据为操作对象的统计语言），还更好的利用上了HTML5的优势，让对数组进行操作的过程能动起来，更好的交互起来，同时效率又高，代码优雅、简洁。

当然，问题就是如果没有较为长期的数据处理经验，就会难以理解其数据整体操作为导向的语句编写。这使得其对于一般的没有统计、数据处理背景的程序员来说，也是较为晦涩的。

从另一个角度来说，也只有有实际的每日高强度的数据处理、展示需求，再加上具有优秀的开发人才，才能催生出这样的类库。关于这一点，网上也能找到很多纽约时报的图表部门的文章。但当你真的直面对方的工作成果，零距离的接触其中最优秀人材的编程贡献的时候，那种距离感才是真真切切的。

纽约时报严格说目前还是一个纸媒，中国国内能有这样的技术人材的积累的报纸，没有。

更深刻的来说，不是技术的积累没有，而是连对数据的处理的重视度达到那样的高度的都没有，技术从来是为目的和需求而服务的。事实上，在web和互联网之前，在以出版纸面内容为主的时代，如R语言等统计技术和工具就已经是报道可信、有价值的分析内容的不可缺少的基础，国内呢，还是书生意气、刀笔风流。

某种角度来说，真正承接起新一代信息、数据处理服务的媒体，在国内是直接就转移到了新生的互联网公司。如百度、腾讯等的前端部门，最近2、3年也作出了不少很有说服力的作品。从其前端技术的外溢，即开源出来的各种类库，也能看到决心很大。如百度团队推出的 EChart  服务及其基础的 ZRender  类库。

可是，ZRender  类库说的是数据驱动的方式，但实际还是很老实的下到了实际的绘图层。每个绘图的控件就如一个个车轮子、车架子，等着你去装起来，然后以绘图的思维为目的来把数据给喂进去。这跟我看到D3 之前的想法是一样，不客气的说，还是业余的“非数据处理专家”的程序员的总结。不过，也没办法，新生的互联网公司的年轻的程序员们在没有更多的媒体案例经验的情况下实际在做的就是纽约时报本来是图表部门的更加业务为导向，而不是单单是基础技术抽象层的工作。制造工具的人也没有太丰富的数据可视化经验。

当然，你要啥自行车呢，能出图来就可以了，优雅、效率不要管，哪怕效果也不用管，最不济，我们招多点码农。

确实，不单码农可以再招多点，事实上让美编、设计师加班加点用人工的方式来绘制，在国内也还是常态，报纸们到现在也还是那么干的。至于数据的准确度、时效性、人工在无意义的重复上的耗费，就隐藏在所谓的传统媒体江河日下了的叹息中。

有了前后、内外的对比之后，我更大的感受是，所谓的互联网公司会成为超级巨无霸的媒体、传统媒体完全完蛋等极端的看法其实没有意义。更加现实的可能是，无论是互联网公司还是传统媒体都会分化出更加适合这个时代的数据驱动的分析、处理、展示部门，这在纽约时报上的子站等尝试上看也是这样的，国内站在远远的那边，但接近的速度越来越快。

如果要做比喻的话，就是在一个信息处理的战场上，中国的传统媒体还是拿着大刀长矛、满脸勇字去冲杀，而中国的互联网公司已经开始拿着自己造的汉阳造在一枪枪的开着前进，美国的领先者则是拿着为了堑壕战这个最残酷的形态而设计的汤姆逊机枪在战斗。

github上被赞数千的国人的项目，多起来吧。