Live data from Hacker News

Show HN: JavaScript Graphing Library Comparison

jsgraphs.com

101–110 of 117 posts

Re: Show HN: JavaScript Graphing Library Comparison

#101
post #92

What are the advantages of SVG or Canvas in that use case? Which one (SVG, Canvas) is principle faster on current browser with thousands of data points?

Canvas is faster, as it basically is just a bitmap, while an SVG chart with a million points would correspond to at least a million DOM elements.

3 years ago, I benchmarks it with thousands of lines: SVG was faster than Canvas in Internet Explorer 10, probably due their extensive long history with their VML legacy rendering. But SVG was a lot slower in Chrome and Firefox than Canvas probably due graphic card accelerated Canvas implementation. SVG wasn't supported in Android 2.3.x. From my experience back then working directly with raw-SVG in HTML5 wasn't a great experience SVG is based on XML after all. Working with raw-Canvas meant implementing a basic render loop myself which refreshes the area and the Text related API is a bit complicated and slow.

Re: Show HN: JavaScript Graphing Library Comparison

#102
post #92

What are the advantages of SVG or Canvas in that use case? Which one (SVG, Canvas) is principle faster on current browser with thousands of data points?

    Canvas
      * Bitmapped graphics
      * Immediate mode
      + Fast for simple things
      + Minimal drawing overhead
      - Interactivity has to be handled manually (e.g. by checking whether click coordinates coincide with a drawn button)
      - Animating things (usually) mean redrawing most of the canvas for every frame
      + Ability to manipulate pixels if needed
      * Everything is drawn manually

    SVG
      * Vector graphics
      * Retained mode
      + Fast for simple things
      - Everything that needs to be drawn has to exist in the DOM
      + Interactivity can be handled via events by the browser on every element if needed
      + Animating things (usually) just mean to manipulate that thing in the DOM
      - Limited ways of arbitrarily manipulating the composed result
      * Everything is drawn by the browser
      + CSS support
      + Sophisticated text rendering support
It's mostly a trade-off of what you want to do. The things marked with * above are not clear benefits or drawbacks.

For a chart that consists of axes, ticks, a plot and maybe a few other things I'd always go for SVG unless compatibility constraints force me to go to bitmap graphics. It just maps much better to vectors than to pixels, but there are limits, of course. Heatmaps often are better drawn via canvas, especially those where there are no discrete shapes but rather blurry blobs of colour.

Performance is a difficult topic and hard to compare, beyond simple things: In canvas (mostly) your only option of optimisation is to draw less, i.e. touch fewer pixels; with SVG being rendered and composited by the browser it often boils down to »don't move elements that don't have to move« to enable the browser to render less and not throw away every partially composited texture. In IE and Chrome SVG has quite great performance, in Firefox you have to be careful what you do. Uusally it scales well to a few hundred or thousand DOM elements, though, depending on what you do.

Re: Show HN: JavaScript Graphing Library Comparison

#103

Earlier quoted context omitted.

Canvas is faster, as it basically is just a bitmap, while an SVG chart with a million points would correspond to at least a million DOM elements.

3 years ago, I benchmarks it with thousands of lines: SVG was faster than Canvas in Internet Explorer 10, probably due their extensive long history with their VML legacy rendering. But SVG was a lot slower in Chrome and Firefox than Canvas probably due graphic card accelerated Canvas implementation. SVG wasn't supported in Android 2.3.x. From my experience back then working directly with raw-SVG in HTML5 wasn't a gre…

SVG performance in IE (since IE9) has really been and is stellar, indeed. Chrome caught up mostly by now and at least at work the difference between Chrome and IE for certain tasks is that Chrome spends more time rendering and IE spends more time JavaScripting. Firefox SVG performance has been disappointing, mostly and mobile browsers are often better off with canvas as well since performance is generally constrained there.

SVG performance in IE doesn't date back to VML, though. They just made hardware-accelerated rendering a major feature of their browser back then, while no one else was doing it properly. Similar to how Chrome started with JITting JavaScript to make it fast and everyone else caught up on that afterwards.

Re: Show HN: JavaScript Graphing Library Comparison

#104

Very nicely done! I am just about to choose a charting library and this will be a great help. Have you considered adding some sort of user rating system? I find myself kind of just wanting to know which one is most popular or highest rated (i.e. take some of the work out of choosing between 30+ libraries myself).

The things that people would most likely vote on are not really relevant. "I successfully made a simple chart based on the examples with this library" -> 5/5. If you need more than the examples, most people will have different backgrounds and requirements. What library they can best use depends on that.

Re: Show HN: JavaScript Graphing Library Comparison

#106
post #27

I always rely on Highcharts, probably the biggest library presented here. Fit all the case (except map maybe) and flexible enough to let you change everything if you or your designer want something very specific !

I tend to always go with FusionCharts[1]. And AFAIK, it offers way more charts and maps than any other library out there. 90+ chart types and 965 maps last time I checked.

It's extremely customisable and has tons of readymade fiddles[2] and business dashboards[3] for inspiration(ready copy). I recently used full code of one of their dashboards for my project. I've never failed to convert my designer's or PM's concept into exact same working code with FusionCharts. Highly recommended.

[1] http://www.fusioncharts.com/

[2] http://www.fusioncharts.com/javascript-chart-fiddles/

[3] http://www.fusioncharts.com/dashboards/

Re: Show HN: JavaScript Graphing Library Comparison

#107
post #105

Great work! Just what I needed (a while ago, but again soon I'm sure). There are so many options with JS graphing now, it can be a bit overwhelming just assessing the options and their capabilities.

It's no doubt a great work, but I kind of like this qualitative comparison more:

http://www.fusioncharts.com/javascript-charting-comparison/

Re: Show HN: JavaScript Graphing Library Comparison

#109

Very nice work. How about a graph type "arrow diagram" as a subtype of "drawing"? One thing I'm missing a bit in the list is GraphViz style diagrams.

Those are usually called "graphs" ;-) They are listed under "network" (of course there are lots of types or styles here, too).
Post reply on HN