javascript 图表_选择JavaScript图表库时要考虑的13个因素

朴灿烈づ我的快乐病毒、 2023-02-22 03:41 6阅读 0赞

javascript 图表

Before starting your search for a charting library, you need to know that creating good data visualization (dataviz) is a huge time investment if you are planning to build a serious application. Having clear answers to questions like what exactly your dataviz is going to achieve, on which devices will it be used, how much time you have to build the application etc. will help you make the best use of guidelines mentioned below.

在开始搜索图表库之前，您需要知道，如果您打算构建一个认真的应用程序，那么创建良好的数据可视化(dataviz)是一项巨大的时间投入。 对于诸如dataviz将要实现的确切功能，将在哪些设备上使用，构建应用程序需要多少时间等问题，有了明确的答案，将有助于您充分利用下文所述的准则。

## 跨浏览器兼容性 **(**Cross Browser Compatibility**)** ##

Whether you need a charting library that's compatible with all browsers or just modern browsers depends on your target audience. If you are building for government or for enterprise clients, there's a very good chance that they are still using older versions of IE. So charting libraries that only work with modern browsers might not be a good choice.

是否需要与所有浏览器兼容或仅与现代浏览器兼容的图表库取决于目标受众。 如果您是为政府或企业客户而建，则很有可能他们仍在使用旧版本的IE。 因此，仅对现代浏览器起作用的图表库可能不是一个好选择。

It's a pain to handle cross-browser compatibility issues, and I believe the library you choose should do it for you.

处理跨浏览器兼容性问题很痛苦，我相信您选择的库应该为您做得到。

## 跨设备兼容性 **(**Cross Device Compatibility**)** ##

Will your application be used primarily on desktop or are you targeting mobile users as well? If it's just for large screen viewing, most of the charting libraries will work for your dataviz component, but if you want to ensure a consistent experience across hand-held devices as well, the charting library you choose should be responsive. This is becoming increasingly important because of changing user habits in recent times.

您的应用程序将主要在台式机上使用还是要针对移动用户？ 如果仅用于大屏幕查看，则大多数图表库都可用于您的dataviz组件，但是如果您也要确保跨手持设备的一致体验，则选择的图表库应具有响应性。 由于近来用户习惯的改变，这变得越来越重要。

## 输入数据格式 **(**Input Data Format**)** ##

Although JSON (JavaScript Object Notation) is gradually becoming the standard format especially when it comes to charting libraries, there are still many cases where you'll have to deal with XML. If you need XML data for your dataviz, it will be good to know whether your charting library supports it.

尽管JSON(JavaScript对象表示法)已逐渐成为标准格式，尤其是在绘制图表库时，但是在许多情况下，您仍必须处理XML。 如果您的dataviz需要XML数据，那么最好了解您的图表库是否支持它。

## 可定制性 **(**Customizability**)** ##

This, for me at least, is the biggest decision factor. Is the charting library flexible enough so that I can make it do what I want, or will it just look good on defaults and you are on your own if you try to customize it?

至少对我而言，这是最大的决策因素。 图表库是否具有足够的灵活性，以便我可以使其按自己的意愿进行操作，或者它在默认值上看起来很好，如果您尝试自定义它，则您可以独自工作吗？

There are hundreds of things that I like to play around with like adding custom shapes, configuring legends, attaching events (click, hover, key press), leveraging drill-down of data, and applying themes etc. If you want to create a beautiful design, it'll be good to have a library that is easily customizable so that you can mold it according the design of your application.

我喜欢玩几百种事情，例如添加自定义形状，配置图例，附加事件(单击，悬停，按键)，利用数据的向下钻取和应用主题等。如果要创建精美的图形设计时，最好具有易于自定义的库，以便您可以根据应用程序的设计对其进行建模。

## 可用图表范围 **(**Range of Available Charts**)** ##

This one is a no brainer. Whatever dataviz you want to create should be part of the library. But it's not so easy as various charting libraries have collective packages in which similar charts are grouped like maps, widgets and stock charts. So depending on the use case you might want to go for a particular chart type only, or you can get a complete bundle.

这是没有道理的。 您要创建的任何dataviz都应该是库的一部分。 但这并不是那么容易，因为各种图表库都具有集体包装，其中将相似的图表分组为地图，小部件和股票图表。 因此，根据用例，您可能只想使用特定的图表类型，或者可以获得完整的捆绑包。

If you want to compare different charting libraries based on range of available charts, you'll find [this resource][] very helpful.

如果您想根据可用图表范围比较不同的图表库，您会发现[此资源][this resource]非常有帮助。

## 学习曲线 **(**Learning Curve**)** ##

Some data visualization libraries like D3.js have a steep learning curve. No doubt D3.js is very powerful, but if you are running on a tight deadline or using a charting library for the first time, I would not recommend that.

一些数据可视化库(例如D3.js)的学习曲线很陡。 毫无疑问，D3.js非常强大，但是如果您在紧迫的期限内运行或第一次使用图表库，则不建议这样做。

On the other hand, if you are getting started in dataviz and have lots of time on your hands for experimentation, you should by all means try libraries that are beautiful but require some time investment.

另一方面，如果您刚开始使用dataviz并花了很多时间进行实验，则应该尝试使用漂亮但需要一些时间投入的库。

## 与代码其他部分的兼容性 **(**Compatibility With Other Parts of Code**)** ##

Imagine you are a PHP or ASP.NET ninja and are not familiar with JavaScript very much. Wouldn't it be great if you can build charts without writing any JavaScript code? Some libraries have free plugins and wrappers that generate the required JavaScript and HTML code for you, which is then used to render charts on a browser page. Examples [here][] and [here][here 1].

假设您是PHP或ASP.NET忍者，并且对JavaScript不太熟悉。 如果您不编写任何JavaScript代码就可以构建图表，那不是很好吗？ 一些库具有免费的插件和包装，可以为您生成所需JavaScript和HTML代码，然后将其用于在浏览器页面上呈现图表。 [这里][here]和[这里的][here 1]例子。

## 性能 **(**Performance**)** ##

Performance is dependent on many factors like size of library, memory usage while rendering, garbage collection and number of [browser repaint cycles][]. I value performance very highly, but optimizing only for performance is not always the best idea. This might sound contradictory so let me explain my point with an example.

性能取决于许多因素，例如库的大小，渲染时的内存使用量，垃圾回收和[浏览器重绘周期的][browser repaint cycles]数量。 我非常看重性能，但是仅针对性能进行优化并非总是最好的主意。 这听起来可能是矛盾的，所以让我用一个例子来解释我的观点。

Let's assume you are building a dashboard which will be used on local intranet. Do you think using the library with smallest package size makes sense here? In this case I'll choose a library that comes out best based on other factors discussed here. Saving on library size will be the least of my concerns.

假设您正在构建一个仪表板，该仪表板将在本地Intranet上使用。 您认为使用最小包装尺寸的库在这里有意义吗？ 在这种情况下，我将根据此处讨论的其他因素选择效果最好的库。 节省库大小将是我最不关心的问题。

## 出口 **(**Exporting**)** ##

This point is not applicable for every use case, but only for cases like reports and dashboards. If you are building a dashboard for business audience, your users might want to export charts to PDF or images. It will be better that the charting library you choose support export feature out of the box. Common export formats to look for are JPEG, PNG, PDF and SVG.

这一点不适用于每个用例，仅适用于诸如报告和仪表板之类的用例。 如果要为业务受众构建仪表板，则用户可能希望将图表导出为PDF或图像。 您选择的图表库最好支持开箱即用的导出功能。 常见的导出格式为JPEG，PNG，PDF和SVG。

## 设计与互动 **(**Design and Interactivity**)** ##

Design is more than just look and feel of a chart. It should not only look good (themes, color scheme), but it should have meaningful interactivity. For example, if you are building a pie-chart, clicking a pie should pull it out (or add border on circumference) by default. Custom code should not be required for that. Clicking a legend icon in multi-series line chart should toggle the visibility of related data plot.

设计不仅仅是图表的外观。 它不仅应该看起来不错(主题，配色方案)，而且还应该具有有意义的交互性。 例如，如果要构建饼图，则默认情况下，单击饼图应将其拉出(或在圆周上添加边框)。 为此，不需要自定义代码。 单击多系列折线图中的图例图标应切换相关数据图的可见性。

## 定价和许可条款 **(**Pricing and Licensing Terms**)** ##

Most of the libraries now give away their source code when you buy a licence, but that doesn't mean you are free to do whatever you want. It's important to know what all permissions you'll need for your project and buy a relevant license. Terms and pricing varies depending on factors like number of users, type of application (SaaS, intranet, web) and number of servers.

现在，大多数库在您购买许可证时都会提供其源代码，但这并不意味着您可以自由地做任何您想做的事情。 了解项目所需的所有权限并购买相关许可证很重要。 条款和价格因用户数量，应用程序类型(SaaS，Intranet，Web)和服务器数量等因素而异。

## 支持 **(**Support**)** ##

If you are building an application, dataviz might not be your core strength. So when you face a problem, you might need some external support to solve it. Support can come in many forms like personal, forum or community sites like StackOverflow. If you are on a tight schedule you would not want to wait for an answer on StackOverflow. Personal support or dedicated forum would be very useful in this case.

如果要构建应用程序，dataviz可能不是您的核心优势。 因此，当您遇到问题时，可能需要一些外部支持来解决。 支持可以有多种形式，如个人，论坛或社区网站(如StackOverflow)。 如果您的日程安排很紧，则不想等待StackOverflow的答案。 在这种情况下，个人支持或专门的论坛将非常有用。

In case of popular libraries, most of the answers to general questions are easily available. But I've faced dead ends couple of times while testing edge cases. If you think you might need dedicated support, I would recommend buying a charting component instead of using an open source solution (given it meets all other requirements).

对于流行的图书馆，大多数常见问题的答案都很容易获得。 但是在测试边缘案例时，我几次遇到了死胡同。 如果您认为您可能需要专门的支持，我建议您购买图表组件，而不要使用开源解决方案(前提是它满足所有其他要求)。

## 开源的 **(**Open Source**)** ##

I love open-source, but I believe it's not the right solution for everything. Especially when it comes to charting solutions, there are tons of tiny open open-source libraries available on GitHub. But be careful before you try to implement one of those in your project.

我喜欢开源，但是我认为这并不是解决所有问题的正确方法。 尤其是在制图解决方案方面，GitHub上有大量微型开源开源库。 但是在尝试在项目中实现其中之一之前，请务必小心。

A friend of mine once used a small open-source library in his commercial project because he liked few of its features. After one year he got stuck when he attempted to implement some advanced features. When he tried to contact the creator, he came to know that the project was long abandoned. I am sure that's not going to happen with huge open-source projects like D3.js, Google Charts or morris.js, but it's better to consider the possibility rather than repenting later.

我的一个朋友曾经在他的商业项目中使用过一个小型开源库，因为他不喜欢它的某些功能。 一年后，当他尝试实现一些高级功能时，他陷入了困境。 当他尝试与创建者联系时，他知道该项目早已被放弃。 我确信在D3.js，Google Charts或morris.js之类的大型开源项目中不会发生这种情况，但是最好考虑这种可能性，而不是以后再悔改。

Here's a very good article that answers when a [commercial library makes sense over an open-source one][].

这是一篇很好的文章，当[商业图书馆对开源图书馆有意义][commercial library makes sense over an open-source one]时，就会做出回答。

These are all the factors that I think are important to know in order to make an informed choice. If you think I missed some factors, mention them in the comments.

这些都是我认为重要的因素，以便做出明智的选择。 如果您认为我错过了一些因素，请在评论中提及它们。

> 翻译自: [https://davidwalsh.name/13-factors-choosing-javascript-charting-library][https_davidwalsh.name_13-factors-choosing-javascript-charting-library]

javascript 图表

[this resource]: http://www.fusioncharts.com/javascript-charting-comparison/
[here]: http://www.fusioncharts.com/extensions/
[here 1]: http://www.highcharts.com/component/content/article/14-articles/2-third-party-implementation/
[browser repaint cycles]: http://paulirish.com/2011/viewing-chromes-paint-cycle/
[commercial library makes sense over an open-source one]: http://www.codeproject.com/Articles/581146/8-reasons-to-choose-commercial-library-instead-of
[https_davidwalsh.name_13-factors-choosing-javascript-charting-library]: https://davidwalsh.name/13-factors-choosing-javascript-charting-library