服务于数据可视化的WEB前端架构探索

关于web前端架构的探索已经是这两年老生常谈的问题了，我之前也有两篇博客是关于这方面的思考：

在《关于新的前端开发模式的探索》这篇博客中，我表达了对『大前端』这种开发模式的赞同。同时也认为不同的项目应该按照实际的情况选择不同的前端架构，下面是摘抄的一段：

大前端的概念其实让前后端的分界线更加清晰，让后端程序员专注于数据，而不用像以往那样需要按照页面交互设计去吐数据。新的分界线一划分，让人感觉最明显的就是前端开发者有更加充足的power，不在局限于浏览器，能够真正的抛开技术限制去选择合适的开发模式，不管是webApp还是server-side template，这些都能够随心所欲的结合起来。

但是当web前端开发者能够独立的选择技术架构之后更重要的一个问题来了，那就是应该如何去选择合适的技术架构。不同的项目有它适合的架构，我这篇文章主要探讨的是数据可视化的项目应该选择何种web前端架构。三个月前我开始负责开发公司广告数据可视化的web前端项目，当时在开发之前就做了很多思考，也有在知乎上面提了这个问题：数据可视化的web前端开发采用什么样的架构比较合适？。下面摘抄两个回答：

其一：

这样想：如果把echarts去掉，直接把json显示到textarea里，跟最普通的web项目比，有什么差别吗？然后搞定之后，也只是把对textarea的赋值改成调用echarts api而已啊

其二

去年做了快一年的数据可视化，说不上架构，主要用HighCharts+DataTables两个库，解决图和表的这两种承载数据的展示容器。

前后端JSON通信没什么好说的。

搞数据可视化，数据量都不会小，如果带有实时操作的，后端需要做好预计算、中间量保存、运算结果缓存。否则稍微带交互操作拉取实时计算的数据就死翘翘。

单页应用体验会稍微好点，原因后面说。

数据可视化站点，和一般的富应用web站点没什么区别。

一个数据可视化站点的好坏，关键在于整个数据信息展示路径是否清晰。

例如： 1.从数据指标趋势、波动，用户可以得出一些关于这组数据的结论。 2.从结论，反过来观察指标趋势、波动，用户可以得出产生结论的原因。

数据可视化不是说上了饼图、折线图、柱状图就完事了，而是要能把这两条线给用户清楚的理出来。

绕远了，就前端架构来说，真没觉得有什么好说的，怎么弄都行。

前面提到单页应用体验稍微好，原因是这种数据信息流的站点，单页应用中的转场动画，可以稍微缓解用户在海量数据中的迷茫，帮助用户理解整个数据信息路径。

首先感谢回答我问题的朋友，给了我很多启发。然后关于这两点回答我说一下我的一些看法。对于第一个回答中说的：这样想：如果把echarts去掉，直接把json显示到textarea里，跟最普通的web项目比，有什么差别吗？的确我们可以把echarts想象为一个json的textarea，这样来思考的话似乎是更接近普通的web项目。然而哪怕是普通的web项目那也有很大的差异，也需要去选择不同的框架，采用不同的架构。比如说百度贴吧和一个后台管理系统也算是比较常见的传统的web项目，但是它们确有各自的特色，也需要考虑不同的架构。另外我认为对于我们来说数据可视化的核心并不是在它的图表，虽然这也很重要，但是庆幸的是有很多类似echarts，highcharts，d3这样的一些开源的图表库可以直接提供给我们使用。数据可视化web项目的核心其实是在图表之外的一些诉求，比如说数据在不同角度的呈现，需要不同纬度的对比，数据请求量大等特点。这些数据可视化站点的特点往往要求前端有更复杂的一些交互，更有特点的一些业务要求。echarts和highcharts再加上d3基本上已经能够满足我们对于图表的需求，但是数据可视化的web前端站点并不单纯的是一页PPT报告，在上面它需要承载数据更深层次的一个展现。可能你以为的数据可视化是这样的： qq20150906-1 但是实际上它是这样的： qq20150906-2 也有可能是这样的： qq20150906-3 比起像百度贴吧或者各类新闻站点那样的展示型网站来说，数据可视化的展示要求有更丰富更立体的展示效果，这样对交互的要求很高。其实就像是上面的第二个回答所说的：数据可视化站点，和一般的富应用web站点没什么区别。的确，正如第一个回答所说我们可以把图表替换为textarea，然后再去观察后其实它和很多的富应用web站点很接近。不过数据可视化的站点可以说算是富应用web站点中的一个子类，它所具有的特点我结合这个季度开发的项目归纳如下：

数据请求比较频繁，而且数据量比较大，有时候数据请求时长会比较长。
页面中表单偏少，但是有很多鼠标选择类型的交互，比如日期选择，条件过滤。
会有很多同类型的图表以各种组合形式出现。

对应这三个特点有如下的解决方案

使用SPA（Single Page Application）的开发模式
需要有合适的框架能够做好事件监听，前端模板渲染，能够方便快捷的处理前端的交互行为
能够优雅的实现组件的复用和嵌套，使得前端页面中各个元素组件化

通常如果选择使用了SPA的开发模式，那么选择一个可靠的前端框架是必须的，否则后期代码会越来越复杂，越来越难以维护。想要单纯的只使用JQuery这样的库来处理最后只会是陷入泥潭。那么选择一个能够满足后面两条要求的合适的前端框架就成为很关键的问题了。目前来说比较流行的前端框架有AngularJS，React，Polymer等。最后我选择了Polymer。没有选择AngularJS的原因是因为我认为它的特长是在处理有很多表单操作，有很多增删改查的管理系统。对于数据可视化更多是一个展现层面的系统它显得过于笨重了，另外它更侧重与MVC而不是组件化。React其实不错，但是鉴于JSX的入门成本，所以最后还是选择了侧重于组件化，基于WebComponents标准的Polymer。不过在框架的选择上没有绝对，用AngularJS或者React如何我也就不说了，毕竟也没有在这个项目中应用过。主要是谈谈使用Polymer时候的心得和发现的优缺点。

优点：

专注于组件化，能够很方便的实现组件的构建。包括组件的复用和组件直接的嵌套。组件之间能够实现样式的分离。
面向webComponents标准，组件的写法直观易学。
最近内部支持数据和视图的绑定，事件代理等也有比较好的解决方案。

缺点：

基于HTML import做组件化模块化，使得JS模块的复用也需要依赖HTML import，不便于和CMD等模块化方案结合。
兼容性要求比较高，无法应用于老版本的IE浏览器。

实际上个人觉得React的方式更加完美，但是考虑到代码的直观性和学习成本最终还是选择的Polymer。最后使用三个月的结果来看，感觉还不错，能够算是满意的一个框架。使用Polymer组件化的方案开发带来最优的体验是组件的复用变得更容易了，最要体现在两个方面。第一个方面是Polymer使得可以用MVVM的形式来更快速的开发一个组件，第二个方面就是可以使得组件直接的嵌套型的复用变得更容易了。关于第一个方面Polymer的使用在这我就不详细描述，主要说一下第二个方面，也是组件化中很关键的一点。这也是新一代web组件化开发和JQuery插件形式的组件化开发中更优秀的一点。JQuery插件中很少看到有互相嵌套的行为，都是比较轻量级的单一组件。但是在一个完善的组件化模式的开发中，上面图中的需求就可以如下图所示很方便的拆分为一个个的组件，最终嵌套在一起得到一个最终的结果： qq20150906-4 最后再感叹一下，不管是用Polymer等框架，还是直接用JQuery最后要实现这样的一个数据可视化的站点应该都是不成问题的。但是这正是web前端的可怕之处，因为能够花10个小时用原始的方法完成，导致停止去寻找能够话3个小时就能完成的更好的解决方案。这样也导致很多人认为前端开发简单。的确，有点web开发基础的开发者都能够开发出一个网页。然而这最终这样的方式会让前端强于简单也毁于简单。简单并不代表优雅，复杂也许蕴含更多智慧。期望未来在web前端开发者的不断探索中能够让前端开发变得越来越高效，越来越优雅！