Dear All, I waws about writing a gDoc to share with you with a few benchmarks of JS libraries, and soon I decided to refrain ... cause I already found a very welldone and comprehensive list done by Anvaka himself, author of Vivagraph on git
See his link here : http://anvaka.github.io/graph-drawing-libraries/#/all (and again, thank you Andrei!!) Il giorno venerdì 5 settembre 2014 00:45:25 UTC+2, David Bigelow ha scritto: > > I recall something about Alchemy.js adding support for adding nodes and > relationships maybe a binding to editing node data - it would be needed, I > do have concerns about SVG as the layer - D3 seems to bog down in some > browsers with larger contexts... have you looked at Go.JS? > > Dave > > On Thursday, August 28, 2014 5:29:14 PM UTC-4, Huston Hedinger wrote: >> >> Jim, >> >> Thank you for all of the positive comments about Alchemy.js! ;-)] >> >> >> gg4u, >> >> Your suggestions, d3.js, Sigma.js and Vivagraph.js are all great >> technologies. >> >> Alchemy uses d3 for layout, some data binding, and for its SVG renderer. >> We are using Vivagraph and Three.js for our WebGL renderer. >> >> Sigma.js is also great, and is the closest thing to Alchemy.js, offering >> a powerful framework, and a fairly high level of abstraction making it easy >> to get up and running. >> >> The mantra for Alchemy.js <http://graphalchemist.github.io/Alchemy> is >> that you should not have to write "any code" to get up and running with a >> Graph visualization app that has search, filtering, and editing >> capabilities. In fact, or last release opens up API end points for you to >> edit the graph and then POST the data back to the server or your client >> side app. >> >> We have definitely created a tradeoff early, which is that we don't >> expose lower level aspects of the applications. We do expose the data, but >> only through the API. The user can always play with the internals >> (although not reccomended!), with the knowledge that we will be creating >> more and more ways for users to interact with the Graph at every level of >> abstractions - configurations, accessing the data, and even accessing the >> DOM objects directly. >> >> We'd love more feedback and issue requests >> <http://github.com/GraphAlchemist/alchemy>! >> >> Keep up the good work with your startup! >> >> Huston >> >> >> >> >> >> >> >> >> On Wednesday, August 13, 2014 4:48:26 PM UTC-7, gg4u wrote: >>> >>> Hi Jim! >>> >>> Thank you for your feedback and post! >>> Interesting, and there is a real fast evolution for visualizing graphs >>> and, as you said, design scale. >>> >>> Alchemist is really new, released recently in June 2014; and appearantly >>> Keylines too. >>> At the time (2012), my choice was between D3, Sigma, and Vivagraph. >>> I think Vivagraph javascript library is perfoming quite good even with >>> node decoration (images on top of nodes) for desktop devices. For mobile >>> devices, it is better to visualize a relatively small subset of nodes. >>> Though, it offers good options for styling nodes and for tweeking the >>> graph animation; there is also webgl support (though for mobile handset is >>> a constraint). >>> >>> The page you probably saw at xdiscovery.com (despite not officially >>> released :P) is a showcase scenario for a mobile app we build >>> (LearnDiscovery for iOS); for the app, native coding was chosen cause JS >>> framework were not performing sufficiently well for mobile handsets with >>> large graphs and graph traversal. >>> I'd like to experiment this alchemy.js and keylines with node >>> decoration. >>> Not clear on their website, but keylines is commercial right? >>> >>> The features for filtering would be indeed very useful. >>> >>> Thank you for your informative posting. >>> By the way, sorry for my understanding of English language, but with >>> "unusually responsive on my iPad" >>> did you mean you found Viva working well or not on iPad, on >>> xdiscovery.com? :P >>> >>> Your feedback is real welcome, I would like to release an improvement >>> for the graph rendering: there have been quite a lot of trials for choosing >>> correct parameters in spring-force layout for heterogeneity in graph size. >>> It would be cool if some framework could adjust spring-force parameters >>> automatically in function of device and number of nodes: maybe Alchemist >>> does that? >>> >>> >>> >>> >>> Il giorno mercoledì 13 agosto 2014 23:27:19 UTC+2, Jim Salmons ha >>> scritto: >>>> >>>> And I would be remiss if I didn't mention that, judging by the number >>>> of GitHub notifications flying out of the Alchemy.js project that this >>>> project is under VERY active development and getting better and better. >>>> Alchemy.js is, to my mind, the most likely candidate solution to recognize >>>> the distinction and importance of "design scale" graph visualization vis a >>>> vis BigData graph visualization. >>>> >>>> Design scale visualization is what is needed for #GraphGist authoring >>>> as GraphGists become increasingly used as design documents and for >>>> exploratory prototyping in addition to its obvious current primary use in >>>> creating educational materials. >>>> >>>> Design-scale visualization is not about how many nodes you can show and >>>> move around, its all about expressiveness -- showing label-based subsets >>>> within bounding box, non-overlapping relations when more than one relation >>>> is displayed between two nodes, easy-CSS styling, etc. >>>> >>>> While I wish the good GraphAlchemist folks well as they move toward >>>> competing with folks like KeyLines and Linkurious in the BigDataViz space, >>>> I truly hope that Alchemy.js distinguishes itself by providing the BEST >>>> POSSIBLE GraphGist design-viz support available. In fact, if I were Neo >>>> Technology I'd be financially encouraging GraphAlchemist to do just that; >>>> ensure that Alchemy.js has SUPERB GraphGist design-viz support because >>>> GraphGists will increasingly be ultra-effective in consultative-selling in >>>> the enterprise space. (I don't expect Neo to do this for 'the rest of us', >>>> we'd just be the beneficiaries of Neo making its products more competitive >>>> in the enterprise space.) >>>> >>>> On Monday, August 4, 2014 5:08:49 AM UTC-5, Michael Hunger wrote: >>>>> >>>>> Hi Roman, >>>>> >>>>> d3 usually doesn't need middleware, just data. >>>>> >>>>> There is a library called alchemy.js which also works with d3.js in >>>>> the background. >>>>> >>>>> I wrote a single html page (+ javascript) demo console that you can >>>>> find (with sources) here: jexp.github.io/cy2neo >>>>> >>>>> Cheers, >>>>> >>>>> Michael >>>>> >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 2:21 PM, <r...@granul.at> wrote: >>>>> >>>>>> Dear Neo4j Users! >>>>>> >>>>>> I am considering to use a Javascript viewer for graph-exploration. >>>>>> >>>>>> All the exaples I foud (using D3 or sigma.js) use some kind of >>>>>> "middleware" in ruby or something similar. >>>>>> >>>>>> Is there an example that interacts directly with the neo4j-REST-Api? >>>>>> >>>>>> The only system I found that seems to do so is the neo4j-admin (with >>>>>> the use of D3). And the admin seems a bit too complex for a basic >>>>>> example. >>>>>> >>>>>> best regards >>>>>> roman >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Neo4j" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to neo4j+un...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
