Are you interested in comparing our libraries?

[anvaka]

Hello guys,

I'm trying to create a list of all known graph drawing libraries. Each library has its pros and cons. I thought it would be beneficial to give a list to developers and let them choose what suites best their needs.

If you are interested in contributing to this repository - I'll immediately give you full access. We need to come up with list of metrics which are most interesting.

What do you think?

To: @josdejong (@almende), @cpettitt, @maxkfranz (@cytoscape), @dhotson, @fkling, @jacomyal, @mbostock, @samizdatco, @strathausen and @uskudnik

[josdejong]

Sure we are interested (also pinging @AlexDM0 here).

I'm not sure whether it's a good idea to involve the makers of the graph libraries too much in creating this comparison, it should be an unbiased, objective comparison...

[jacomyal]

@josdejong The initiative coming from the maker of one of the compared libraries, it kind of makes sense to contact the others. But I agree, it would have been more interesting to see this idea appearing from a "simple" user.

[josdejong]

Ah, sorry, I didn't realize @anvaka is the creator of VivaGraphJS.

Edit: anyway, we should be aware of trying to keep everything as objective as possible.

[maxkfranz]

Like any software decision, it's driven by usecases. Thus, options could include:

• Eliciting users of each library for their real world usecases.
• Compiling and maintaining a feature list for each library -- probably the different types of graphs that can be drawn, as it seems to me your list is focussed on drawing.
• Classifying each library according to its highlevel capabilities or focus. For example, Arbor is really a force directed layout algorithm with hooks so you can write your own renderer etc, D3 is a generic SVG library for drawing, etc, etc...
• Collecting sets of pictures for each library. If you're primarily interested in drawing, then just show what each can draw. Alternatively, you could make live demos on JSbin.

Personally, I'm of the opinion that a developer should read the documentation and try out potential libraries for his usecase. Perhaps a plain alphabetised list without any descriptions or commentary is best.

[anvaka]

@josdejong, @jacomyal - VivaGraphJS was created just to learn javascript. I cannot undo it to become a "simple user" anymore. We cannot make metrics like stars count, commits count, number of bugs, license biased. There are more such metrics, By having authors of libraries collaborate, I'm sure we will produce unbiased comparison.

I firmly believe, that alternative choices will help developers find what suites best their needs, and will help authors to make their libraries better too!

PS: I do not want to "own" this repository: you have full control here as well.

[anvaka]

@maxkfranz makes sense. That text list is already available in the readme.

I'm thinking about making a master-details grid, where we list basic information about repositories. Master shows basic information:

• Library name
• Stars
• Forks
• Commits
• Issues
• When created/modified

When user clicks a row detail shows library classification, screenshots, links to live demos.

Here is a first prototype: http://anvaka.github.io/graph-drawing-libraries/ It does not yet have github oauth, so you need to be above github rate limit to see the metrics:

[yaph]

One thing that would certainly be interesting is comparing rendering performance using sample graphs of different sizes in different browsers. Also which drawing technology is used by the library is of interest depending on your use case, i. e. SVG, canvas, WebGL.

EDIT: Also what I find actually more interesting than stars or watchers is the date of the latest commit.

[josdejong]

@yaph, yes indeed what you are interested in is some measure of how active a project is, both qua development and qua user community.

The latest commit, latest release, and number of commits per week say something about how active the development is.

The number of stars, number of new/resolved issues per month, and number of questions on stackoverflow say something about how active the community is. But still I'm not sure what these numbers would really tell. I can imaging that a library with a complicated API gets way more questions and issues than one with a clear API that speaks for itself...

[anvaka]

Statistics API is also available from GitHub: https://developer.github.com/v3/repos/statistics/

I'm thinking about mix of online/offline data from GitHub. E.g. license information is not easily available, so I manually added it, and then merge it with online data: Demo

[anvaka]

Added basic examples for all libraries. "Basic" means the minimum amount of code to render a given graph. Graph is the same for all libraries.

Click on a row: http://anvaka.github.io/graph-drawing-libraries/#/all to see details.

E.g. sigma and vis

Please feel free to review/edit.

It was too hard to set up basic example for https://github.com/uskudnik/GraphGL So I had to remove it from the list. @uskudnik please feel free to provide an example if you want your library to be listed here.

[josdejong]

Nice job. Maybe the sigma example needs some refinement as it is unstable (the nodes continue to vibrate).

Maybe an extra column with an explicit link makes it easier to discover that the rows are clickable?

[anvaka]

Thank you @josdejong !

I followed an example on the sigma.js repository and tried to do it in a minimal possible way. @jacomyal do you see anything obviously missing here which would make this interactive demo more stable?

[anvaka]

@josdejong interesting idea with the link. How would you call it?

[josdejong]

@anvaka Some ideas for a name for this new column: "Example", "Usage", "Usage example", "Demo", ...

[anvaka]

Done. Thank you, @josdejong!

[maxkfranz]

Your demo table site looks like a great start. Some feedback:

(1) It can take some time to load the data. You may want to cache this periodically. Additionally, some sort of spinner or progress bar would be useful feedback to the user.

(2) It seems repo names are sorted based on organisation name. That's contrary to what a user would expect -- they're not interested in organisation names but rather lib names. I suggest eliding the organisation names completely for simplicity.

[anvaka]

@maxkfranz Thank you for replying to this initiative!

The data is actually cached on free Heroku app source code.

Cold start does look weird. Maybe we should add something like a progressive time out about loading, similar to gmail? E.g.

Loading...
Still loading... <-- (after two seconds)

What do you think?

As for naming - I don't have strong opinion about that. In my head repository name and the library name is the same. Let's see what other people think here.

PS: I've just added you to the collaborators list on this project

[anvaka]

Hi guys, if you are interested in seeing how your library rendering speed compares with other libraries, please visit the website.

If you know how to make your library run faster, please do it!

[strathausen]

Thanks for making this!

[anvaka]

@strathausen thank you for building dracula! I've added you to the collaborators here.

[jkryanchou]

👍