# Best JS libraries to help build visualisation components of RDF (using Sveltejs) **URL:** \ **Category:** General Discussion\ **Created:** [January 4, 2020, 12:42pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548 "2020-01-04T12:42:12Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\ **Post date:** [January 4, 2020, 12:42pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/1 "2020-01-04T12:42:12Z")
At last I’m playing with RDF and building Svelte components to visualise it! But what libs to use? **Much of this will help choosing JS libs for any use case, but I’ll explain with my use case in mind.** * * * **UPDATE:** for now I’ve settled on [graphy.js](https://github.com/blake-regalia/graphy.js) for the following reasons: - seems capable at a usefully low level (for me) and well designed for the real world (supports streams and set opertations for example, with SPARQL like filters in development) - good balance between features and library size (at 360K overhead for my needs it’s bigger than [Rdfjs/fetch](https://github.com/rdfjs-base/fetch) but still much smaller than more capable alternatives: `rdflib.js` 606K, `LDFlex` + `Comunica` adds 1.4M) - well documented and supported, and being developed extended - complies with [RDF/JS](https://rdf.js.org/) standards * * * Having failed to get rdflib working inside a Svelte component (see [issue #381](https://github.com/linkeddata/rdflib.js/issues/381), but this is not the only blocker) I’m looking at other libs for fetching RDF resources and parsing them for visualisation, so easy iteration and query of a triple store is important. Later I might want to write RDF back. There are several candidates that on scanning the repos look good. Any recommendations? I’d like advice for which will be easiest to iterate over returned triples in order to generate data for visualisation components. The ones I’ve found are: - [GitHub - rubensworks/rdf-dereference.js: Dereference any URL for its RDF contents](https://github.com/rubensworks/rdf-dereference.js) (and related rdf-parse.js) - [GitHub - blake-regalia/graphy.js: A collection of RDF libraries for JavaScript](https://github.com/blake-regalia/graphy.js) - [GitHub - rdfjs-base/fetch: Wrapper for fetch to simplify sending and receiving RDF data](https://github.com/rdfjs-base/fetch) - [GitHub - ontola/rdfdev-js: Utilities for working with RDF/Linked Data in JavaScript / TypeScript](https://github.com/ontola/rdfdev-js) - [GitHub - antoniogarrote/rdfstore-js: JS RDF store with SPARQL support](https://github.com/antoniogarrote/rdfstore-js) - [rdf-ext · GitHub](https://github.com/rdf-ext) - I have a note of an old comment from Tim on this suggesting it is a bit low level (lacking ‘each’ etc.) EDIT: There’s a handy [Comparison of RDFJS libraries](https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries) from the w3c, of some of these and some not mentioned. The above was posted earlier on the Solid chat [here](https://gitter.im/solid/chat?at=5e0f801f3062aa3e8ded8c48), which added the following for consideration: - [GitHub - LDflex/LDflex: A JavaScript DSL for querying Linked Data on the Web](https://github.com/LDflex/LDflex) - [VincentTunru / tripledoc · GitLab](https://gitlab.com/vincenttunru/tripledoc/) I missed both of those because I had them filed under Solid/rdflib’ rather than as generic RDF libs. But now I see there is a generic and Solid specific version of LDFlex. Tripledoc depends on solid-auth-client, might be suitable, I’m not sure but I’ll probably steer clear of it to keep things ‘svelte’ 😉 and stay generic as possible, at least for now. * * * Following responses on the Solid chat and seeing that rdfjs uses w3c specified types I’m liking that and also the stream support of graphy.js so I’ll start with those, but would still like to hear of any alternatives and opinions on all these options from anyone. Thanks. Note: related to an earlier discussion of visualisation libraries, which lead me to focus on D3 for now ([Visualisation libraries in JavaScript](http://forum.solidproject.org/t/visualisation-libraries-in-javascript/2372)). * * * ## UPDATE Here are some example Svelte components, one using each of Comunica/LDFlex, rdflib.js, Rdfjs and graphy. Very simple, but may help you get started: > **[GitHub - happybeing/svelte-with-rdf-libs-webpack: Getting RDF libs to work with Svelte (using...](https://github.com/happybeing/svelte-with-rdf-libs-webpack)** > > Getting RDF libs to work with Svelte (using webpack) ---
**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\ **Post date:** [January 4, 2020, 1:12pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/2 "2020-01-04T13:12:54Z")
**graphy.js** is looking promising. I already like that it supports streaming and seems to have good docs, and it looks likely to become the default set of parsers for [rdfjs](https://rdf.js.org/dataset-spec/), see this github discussion: > > > Now that graphy.js is \[fully spec-compliant (and has been for some time)\](https:…//github.com/rdfjs/N3.js/issues/186#issuecomment-558278960), I think we should strongly consider making it the default parser of RDF/JS. There was definitely a point to an arms race many years ago, when I created N3.js, and it was able to pull off a performance difference of 2 magnitudes compared to the state of the art. Not only has that gap disappeared nowadays (thanks to a much faster V8, it seems), but also, graphy.js is simply much faster. In fact, I think the best I could achieve with N3.js is to be as fast as graphy.js; I see few options to get much better. And frankly, I wouldn't have the time anymore either. > > That said, a couple of questions perhaps to understand the implications of switching to graphy.js. > > \- I noticed that spec-compatible parsing is not the default, in the sense that one would have to pass the options \`{ validate: true, maxStringLength: Infinity }\`. Are there severe performance consequences of doing so? (I haven't seen any.) Is \`maxStringLength\` nothing more than a safety guard? > - Could it be made the default? > - The reason I insist on spec-compatibility, is that we want to avoid downstream code having to deal with invalid RDF; e.g., writers should be able to trust that a \`NamedNode\` has a valid \`value\` rather than having to check it. > > \- One of the reasons for the performance difference seems to be the use of sticky regular expressions. Back in the days (🦕), I remember having to make the decision with N3.js as well, but there as insufficient support for it (only Firefox if I remember correctly). Now we have it, and it seems to be faster than always chopping off the beginning of the string, like N3.js does. However, what has also stopped me in the past, is the fact that sticky regexes cannot be set to start a a certain point, whereas with chopped-off strings, you can force to start at the beginning and fail fast. > - Are there any bad cases for graphy.js? Like for instance, if I had a Turtle file like \`"a", "here come a million characters"@en\`, would it search very far to find the language tag after the first string? I understand such examples are probably artificial, I just want to understand if there are any downsides to the sticky bit. > - Could you imagine any other downsides to sticky? > > \- Are there in general any disadvantages of the graphy.js parsers that you know about? > - Any worst cases? Any undesirable properties? > > \- Has graphy.js been well-tested for arbitrary stream buffer boundaries? Basically all tests in https://github.com/rdfjs/N3.js/blob/b2ff96d35ed586fce1a02c567fb3ba9c10272598/test/N3Lexer-test.js#L155 that match \`/streamOf/\`. I would adapt them to graphy.js, but it doesn't have a separate lexer (likely another source of performance gains). Some of those tests are only the result of crazy usage like with LOD Laundromat files, i.e., very hard to imagine all special cases and possible splits. \[This one\](https://github.com/rdfjs/N3.js/pull/151/files) stands out in particular. > > \- Graphy is not an ES6 module, and thus not supporting tree shaking, so code would still be unnecessarily large in several cases, which would especially hurt browsers. Would you consider implementing that? (Or otherwise partitioning the code, for example through specific include paths?) > - Related to this question: how is code size compared to the state of the art? > - I understand there is some replication across different parser implementations. That \_should\_ be gzipped away, but might not be if the minifier assigns different names (very likely). However, even if gzipped away, it is \[actual code size that determines performance these days\](https://instagram-engineering.com/making-instagram-com-faster-code-size-and-execution-optimizations-part-4-57668be796a8). > - Is it meaningful to reuse more (I can't imagine it hurting performance badly in most cases, and let's not reuse where it does)? > > I think that's all for now, some more questions might pop up. Thanks in advance for your insights. ---
**Author:** ![jeffz](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/jeffz/32/600_2.png) [@jeffz](https://forum.solidproject.org/u/jeffz)\ **Post date:** [January 4, 2020, 5:37pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/3 "2020-01-04T17:37:57Z")
My [RDF-Easy](https://github.com/jeff-zucker/rdf-easy) is a possible alternative. It currently uses rdflib but I will probably change it to use communica or graphy.js at some point. You do need to know some SPARQL to use it, but if you understand RDF, SPARQL is not much more to learn on top of it. ---
**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\ **Post date:** [January 9, 2020, 6:50pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/4 "2020-01-09T18:50:18Z")
I had a few problems using different RDF JS libs with Svelte so I made a repo with some working examples. Here are some example Svelte components, one using each of Comunica/LDFlex, rdflib.js, Rdfjs and graphy. Very simple, but may help you get started: > **[happybeing/svelte-with-rdf-libs-webpack](https://github.com/happybeing/svelte-with-rdf-libs-webpack)** > > Getting RDF libs to work with Svelte (using webpack) EDIT: There’s a handy [Comparison of RDFJS libraries](https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries) from the w3c, of some of these and some not mentioned. ---
**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\ **Post date:** [January 15, 2020, 5:48pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/5 "2020-01-15T17:48:45Z")
New example: Svelte built visualisation of RDF using d3-force is online! Uses separate Svelte components to: - load RDF (using graphy) - map RDF to objects for visualisation - display using d3-force on HTML Canvas Live here: [https://svelte-rdf-vis.now.sh/](https://svelte-rdf-vis.now.sh/) Code: [https://github.com/theWebalyst/svelte-rdf-vis](https://github.com/theWebalyst/svelte-rdf-vis) ---
**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\ **Post date:** [January 16, 2020, 6:01pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/6 "2020-01-16T18:01:36Z")
**UPDATE:** for now I’ve settled on [graphy.js](https://github.com/blake-regalia/graphy.js) for the following reasons: - seems capable at a usefully low level (for me) and well designed for the real world (supports streams and set opertations for example, with SPARQL like filters in development) - good balance between features and library size (at 360K overhead for my needs it’s bigger than [Rdfjs/fetch](https://github.com/rdfjs-base/fetch) but still much smaller than more capable alternatives: `rdflib.js` 606K, `LDFlex` + `Comunica` adds 1.4M) - well documented and supported, and being developed extended - complies with [RDF/JS](https://rdf.js.org/) standards ---
**Author:** ![Smag0](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/smag0/32/310_2.png) [@Smag0](https://forum.solidproject.org/u/Smag0)\ **Post date:** [April 5, 2020, 7:36pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/7 "2020-04-05T19:36:07Z")
About svelte [https://www.wired.com/story/javascript-framework-puts-web-pages-diet/amp](https://www.wired.com/story/javascript-framework-puts-web-pages-diet/amp) ---
**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\ **Post date:** [April 5, 2020, 8:09pm UTC](https://forum.solidproject.org/t/best-js-libraries-to-help-build-visualisation-components-of-rdf-using-sveltejs/2548/8 "2020-04-05T20:09:22Z")
Nice find @smag0. > Harris says Svelte is best suited for cases where performance and file sizes are particularly important, such as apps that run on smart TVs or low-power devices That much is true but Svelte is my favourite framework for other reasons: - easy to learn - doesn’t get in the way - works with anything - encourages good design - knowledgeable friendly, helpful community - and most of all it is fun! I think every project can learn from this. It will thrive if it is not just capable, but easy to learn and fun to use. Aspiring to those should be as high a priority as anything else, and I’ve realised this is what I’m driving at with VisLab [vlab.happybeing.com](http://vlab.happybeing.com) I think few get this, and even less can achieve it. @jeffz is definitely one, and that makes him an incredible asset to Solid. I’d like to see that recognised and his solutions promoted as a model. I’m going to try my best to emulate it but I don’t think it’s easy.