Show HN: GraphicsJS, New Powerful Free Open-Source JavaScript Graphics Library | Hacker News Reader

Show HN: GraphicsJS, New Powerful Free Open-Source JavaScript Graphics Library

graphicsjs.org

124 pointsandreykh43 comments

The speed and responsiveness of Canvas for complex visualisation (ones where there are a lot of objects) means it's often the better choice. However, libraries like d3 make working with SVG a lot easier.

I'm interested, why does SVG seem to de the default choice for web graphics? And is there something like d3 that makes working with Canvas more accessible?

D3 Version 4 has more utilities and examples of interactions with Canvas. Here's an example of a relatively small graph (~500 nodes, 10k edges) that SVG used to struggle with, but Canvas renders with ease.

http://bl.ocks.org/syntagmatic/954b31aa8b8beb91b30ccb0c9e57f...

Notice the nodes are draggable, an interaction supported by the new simulation.find https://github.com/d3/d3-force/#simulation_find

Wow, I didn't know D3 v.4 is so much better for Canvas, thanks for the link. However, this simulation runs horribly slow in FF and IE - I wonder where the fault is.

>I'm interested, why does SVG seem to de the default choice for web graphics?

Because SVG IS web graphics (emphasis on "web"). It lives on the DOM, it's objects have event callbacks, can be styled in CSS-fashion, have nested items, links, etc.

In contrast, Canvas is just a bitmap pane that you can draw own in an imperative way through a JS API -- and everything above that has to be programmed by you or a third party lib in an ad-hoc way.

SVG is many times slower than an optimized graphics library rendered on the canvas tag in 2d or webgl contexts. There are many libraries based on the canvas tag for graphics but not all of them are focused on doing visualizations but people still use them for these use cases all the time.

The most well known WebGL library is https://github.com/mrdoob/three.js/ Which has been used for many examples like this http://armsglobe.chromeexperiments.com/

But you could look at the libraries focused on 2d like these http://paperjs.org/ http://fabricjs.com/ But the larger 2d canvas libraries also have much of the same abilities. http://createjs.com/ - http://codepen.io/ianwhitfield/pen/BKOJmj https://github.com/pixijs/pixi.js - http://anvaka.github.io/ngraph/examples/pixi.js/06%20-%20Pac...

If you are just rendering vectors like an icon image, there is no harm in using SVG. If you want access to nodes on a page with a JavaScript library like jQuery, SVG is still the best option. For everything else SVG is not the most performant and is not able to deliver on many graphics abilities that the Canvas tag is capable of. I respect that in most visualizations it doesn't matter and it might be easier but it doesn't mean SVG is the best thing to use for all graphics.

As far as i know there are some issues with canvas text measurement and accessibility support. So it's just hard to use it for data visualization and infographics. Take a look at W3C accessibility graphics topic https://www.w3.org/standards/webdesign/graphics.html

p5.js (https://p5js.org/) meets the mark of "canvas but more accessible" for me quite often. A different agenda than d3 tho

SVG is the best vector graphics format out there? Most other popular graphics formats are raster.

One important reason I often use it: you can trivially bind click events and the like to SVG nodes. In Canvas you have to track x/y coordinates of a click and what it matches up to yourself.

People pick SVG because it looks sharp, has certain features that make development easier, and because they are hack developers who do not understand how performance graphics work.

So the simpler and better solution for [eg] icons or graphs is for idiots, and the Very Smart Developers are are all off building solutions that might, just might have utterly trivial perfomance gains at the expense of easily writable and modifiable code? Hmm.

Okay, so icons are a different use-case than "graphics" and in particular graphs, right? Font-awesome (as an example) and The Noun Project are excellent packages and ones that use SVGs to good effect.

Graphs, though? Graphs?

The sweet spot for SVGs is when you have relatively small data set sizes, need interactivity, and update the data very little. There's also the question of how competently different browser vendors handle SVG and animation--if you're on a nice desktop or laptop, it'll be great!

Once any of those things change, you need to start looking at using raster or GPU graphics. If your dataset updates frequently (say, faster than every few hundred milliseconds) or is large (say, larger than a few thousand points) or needs to reliably run on mobile devices or older workstations, the SVG approach will show issues pretty quickly.

Oh, and it's not trivial performance gains, unless you have your head so far up your ass that you don't watch how balls slow the average user's device and browsing experience is. Nor is it at the expense of easily-writable or modifiable code, unless you're a hack script-kiddie who cannot fathom how to modularize their code and write clear solutions to problems.

I'm not even going to apologize for this, because there is just so much garbage advice and bad practices going on in the frontend right now because some chucklefuck found D3 and has decided that it has solved all of their charting and drawing problems forever--and never notices how badly their cutesy demos perform in the wild.

>and because they are hack developers who do not understand how performance graphics work.

Nothing "hack" about vector graphics, and nothing about graphics that necessitates "performance" above all else.

We're not all making AAA games.

nothing about graphics that necessitates "performance" above all else.

Brzzt, wrong.

Computers are, at the end of the day, meant for crunching numbers. Graphics is perhaps one of the last pure workloads that is about crunching numbers--it's probably the best match of the advances of the last 20 years to a problem domain we could hope for.

If your code cannot quickly do graphics, you have failed to competently make use of the user's resources. You are bad and are wasting their time and power, and in the one place where that inefficiency isn't justifiable.

> We're not all making AAA games.

Sure but we're also not all running MacBook Pros or GTX1080 cards on Xeons, now are we?

There's this mindset that high-performance graphics somehow only benefits gamers and games, and that's wrong.

Especially in the (mostly single-threaded, highly-marshalled) graphics environment of the browser, it is really easy to write code that will choke older machines to death and murder mobile devices.

This can be done with a large chart dataset, a quickly updating visualization, or any number of other reasonable and normal and non-game use cases.

>If your code cannot quickly do graphics, you have failed to competently make use of the user's resources. You are bad and are wasting their time and power, and in the one place where that inefficiency isn't justifiable

Bzzt wrong. Nobody cares much about efficiency above a certain level. If they did we wouldn't be using your "efficient" canvas, where 30% of calls is JS overhead, but native code.

>Sure but we're also not all running MacBook Pros or GTX1080 cards on Xeons, now are we?

No, but we almost all are running multi-core PCs, laptops and phones that are perfectly capable to run SVG for most things people use it for.

Maybe not plots with 10.000 points, but then again those are just badly designed, the screen doesn't have 10.000 pixels horizontally or vertically to show them all at once anyway.

> Nobody cares much about efficiency above a certain level

This line of thinking is why web mobile experience is garbage.

> Maybe not plots with 10.000 points, but then again those are just badly designed, the screen doesn't have 10.000 pixels horizontally or vertically to show them all at once anyway.

300x300 scatterplot holds potentially 90K points. Even in the case of just 10K datapoints, sampling considerations may mean that it is simpler and more maintainable to just ship full-resolution data to the frontend to be drawn--an option that only exists if you can do so efficiently.

You're wrong on this mate.

Here is one more very important feature of GraphicsJS - Accessibility (508 Section) http://docs.anychart.com/7.11.1/Common_Settings/Accessibilit...

Disclaimer: I work at AnyChart.

I'm confused by "New" and 10,000+ customers. What part of it is new? Certainly getting 10k customers takes a lot of time.

10,000+ customers is about AnyChart. GraphicsJS is a rendering engine of AnyChart library and now it become to open source.

Thank you for clarifying.

Pardon me if I'm wrong, but I don't see Free/Open-Source anywhere on the website. It seems paid, proprietary everywhere.

This looks BSD-ish https://github.com/AnyChart/graphicsjs/blob/master/LICENSE

http://www.graphicsjs.org/eula/

it just changed from Apache yesterday https://github.com/AnyChart/graphicsjs/commit/ea38d3ac71a325...

Honestly, did somebody had to code the Bender [1] illustration manually? The source code [2] does _not_ make me any excited about the library, since it's essentially SVG wrapped in a prettier(?) syntax.

I would love to have a library that can "import" an SVG generated from, say, inkscape or Sketch and then allows to animate just a few parts of that vector -- this would be useful in this context too -- draw Bender, and simply move the eyes from JS.

[1] http://playground.anychart.com/gallery/7.11.1/Graphics/Bende... [2] http://playground.anychart.com/gallery/7.11.1/Graphics/Bende...

Looking at the source for the examples, I really can't see how that's practical to write. It may be fast but damn is that code gnarly.

The documentation doesn't help either - it's nasty generated stuff that simply enumerates the API interfaces without adding very much useful information.

For example, https://api.anychart.com/7.11.1/anychart.palettes.DistinctCo... - why would you want to attach listeners to palette colors? There might be a great reason, or those methods might just have been inherited from the base class, but the documentation is no to your understanding help whatsoever. The example is for the base class rather than the palette object.

This is actually a good example of bad documentation.

I might be confusing but palette can dispatch change event when you change particular palette item or whole items set.

Tried this library, it's... well, not that powerful, lacks documentation and is a cheap marketing grab for another, charting, library :/

D3, AnyChart and so on are for charting. GraphicsJS is for drawing graphics, and charting is just one of possible use cases - check out the demos http://www.graphicsjs.org. Docs: http://docs.anychart.com/7.11.1/Graphics

The animated ones eat a whole CPU, not a good sign.

How are they making this compatible with IE6?

IE 6-8 supports VML, so Graphics switch to VML if SVG is not available

more importantly, why?

China, India, Africa, Indonesia, Russia (regional government offices), for this and for many other countries IE6-8 is common case. It's just a fact.

It's a fact that can change.

Course it can and I hope it will)) Imagine how we like to fix bugs in IE6 considering today is 2016

Probably not going to happen anytime soon unless services stop working at all.

.. which will happen sooner if people stop supporting them.

Nope. Most modern browsers stopped Windows XP support.

Hell like that are able to run computers with 1G RAM.

Awesome work.

Thank you!

nice!

Reply on news.ycombinator.com