Creating interactive diagrams on the Web is not straightforward, and requires a lot of care in an area with which few developers are familiar. Both libraries take care of the basic infrastructure of your app (embedding into the webpage, user interactivity, connecting objects, graph data model, styling, and more), while providing you with the flexibility to dive in and customize whatever you need, at the complexity you are comfortable with.
The most fundamental difference between the two libraries is perhaps the most basic - the way they surface your diagrams to your webpages. JointJS uses SVG rendering (<svg> tag), while GoJS relies on HTML Canvas element (<canvas> tag). Each approach has its own pros and cons, and each library does its best to offer similar performance to the other. (Both libraries also enable you to export your diagrams to the other format.)
HTML Canvas has two fundamental limitations. First, it is raster-based - it represents its content as a bitmap. This means that the graphical data may lose quality when enlarged in the browser (or when shown on Retina displays), and that text may become blurry due to rasterization. Second, the Canvas element acts as a black box - it is inaccessible to screen reader technology, and difficult to debug and test for developers.
Meanwhile SVG - a vector-based image representation - addresses both of those limitations. The graphical content and text are handled on-the-fly by the browser, which means that vector images and text are guaranteed to be crisp at any resolution. Additionally, all content is automatically expressed as code within the webpage DOM, which makes it immediately available for quick development, debugging, and testing.
Here is a quick overview of the features of the rendering engines used by JointJS (SVG) and GoJS (HTML Canvas). Continue reading for detailed explanations.
* Image quality may be reduced when zooming using browser tools without notifying GoJS.
** Virtual rendering needs to be activated in JointJS to achieve high performance for extremely large numbers of objects.
Developers like to say that “writing code is quick and easy… but making it work is slow and difficult.” Being able to debug code easily is of utmost importance for being able to deliver a working piece of software faster.
SVG rendering, used by JointJS, has an inherent advantage here - all visible elements are automatically added to the webpage DOM. The neat part? Front-end developers already know how the DOM works and how it can be manipulated by their usual tools. This inherent transparency of SVG has far reaching positive implications for JointJS - quicker debugging, more meaningful testing, and easy application of your own look-and-feel via CSS.
None of this is applicable to HTML Canvas. Everything happens inside a single element which does not communicate anything about its inner state - a black box. It is true that GoJS tries to answer this fundamental limitation with various workarounds - for example, returning copious error messages to the browser console, emulating some CSS animations, etc. However, those can still only be implemented by developers with expert-level knowledge in GoJS.
First, debugging of JointJS can be immediate. Changing a value in a single SVG element in developer tools changes the visible output instantly. Similarly, running a method in the browser console returns an answer immediately. Doing the same in GoJS is dramatically slower because it requires re-generating the whole HTML Canvas element or littering the code with copious logging statements. Such decoupled processes are painful for developers.
Second, easier debugging of JointJS also translates to easier testing. Working with DOM elements means that manual and automatic tests written for JointJS can be more meaningful - with clearly delineated inputs and transparent expectations for the output state of the diagram (which is easily read from the state of the DOM when a test is finished). Meanwhile, once an HTML Canvas is drawn it is difficult to get anything useful back from it.
In the words of Johanna Juszak, Product Manager at ConSol: “Some of the JointJS+ alternatives seemed to be easier to use for our developers with Java background at first glance, but when we tried to implement something which did not come out of the box, it was complicated. In addition, design and styling would be hard because oftentimes it was canvas-based.” Using JointJS for development is easier and faster than using GoJS.
Additionally, SVG offers out-of-the-box accessibility support - in contrast to Canvas where accessibility is an extra consideration which needs to be implemented separately from the rendering logic. The reason is that in SVG, the rendered objects (and crucially, the text and hyperlinks within them) are automatically part of the webpage DOM, meaning that assistive technologies can traverse them as they normally do with HTML tags.
JointJS enhances this general advantage of SVG where appropriate. No extra work is required to support basic accessibility of custom-defined elements. Furthermore, JointJS provides the flexibility to add ARIA attributes to all diagram contents, and to make SVG elements activated or focused in the same way that standard HTML elements can. It is also easy to specify accessible title and description nodes for all SVG elements in your diagram.
Meanwhile, the Canvas object is a black box to assistive technologies. In order to support accessibility, developers are expected to provide a fallback object with a textual description of the scene being rendered - but GoJS does not help you with generating it at all (in fact, it leaves you with the unhelpful message “This text is displayed if your browser does not support the Canvas HTML element.”).
If SVG offers better graphics, development experience, and accessibility than HTML Canvas, then are there even any advantages to using Canvas? The general answer is that “while SVG provides better performance with a larger surface or a smaller number of objects, Canvas provides better performance with a smaller surface or a large number of objects.”
The above might be true for pure SVG, but it is not as much of a problem for JointJS. The library offers virtual rendering via a smart asynchronous algorithm which avoids rendering objects outside of the area visible to the user and updates as the user scrolls, pans or zooms. When this mode is used, JointJS is capable of rendering diagrams with extremely large numbers of objects almost as well as GoJS with no noticeable performance hit.
It is difficult to compare the price of the two libraries, because they come with different license agreements. Importantly, JointJS+ does not restrict the way you use your license. Meanwhile, GoJS charges extra for the right for you to distribute the application for more than 3 years, to host it on more than 1 domain, and to use the library for more than 1 application.
An additional difference between the two libraries is the fact that the standard JointJS+ license gives you access to unminified code, unlike the license for GoJS. This enables you to understand JointJS+ code and modify it to suit your specific needs, if necessary. Importantly, this also means that you can audit JointJS+ code more efficiently if your domain requires your applications to comply with stringent security requirements.
Both JointJS+ and GoJS come with a year of free updates. Additional subscriptions to receive updates and/or to have access to support can be purchased for both. In the case of GoJS, these two are combined as one add-on, while JointJS+ offers them separately for more flexibility (with a choice of 48- or 72- hour maximum response time for dedicated support). So let us now take a closer look at the communities and support of the two libraries.
An active (and ideally free) community is a strong asset for developers trying to find their way around any new technology. That is why both JointJS and GoJS are active across a number of channels. Both libraries have a fairly active community on StackOverflow - JointJS and Rappid (old brand name of JointJS+) are tagged in 686 questions with about 76% answered, while GoJS is tagged in only 415 questions with only about 64% of them answered.
Both libraries also monitor their GitHub Issues. JointJS has an edge on this support channel, with 662 of these conversations in total (95% of them closed), while GoJS had only 135 (though with 100% of them closed). Additionally, JointJS has an active GitHub Discussions forum, while GoJS promotes their GoJS forum - with the important caveat that asking questions is a paid feature.
* By “discussion forum” we mean GitHub Discussions for JointJS and GoJS Forum for GoJS.
Both libraries also offer paid support plans. A JointJS support subscription gives you direct secure access to developers via teleconferencing, email, and a ticketing system with short response times. Meanwhile, a GoJS support plan allows you to post questions on the public forum and to reach out via email. Always consider your preferred communication channel and the secrecy with which you need to handle your code.
* By “discussion forum” we mean GitHub Discussions for JointJS, and GoJS Forum for GoJS.
** Posting questions on the public discussion forum is already free for JointJS.
Seeing something in action is perhaps the best way to learn how it works. That is why both libraries have large collections of demos, and keep expanding them as they add more functionality.
If you prefer a structured approach to learning, then both libraries also offer a tutorial path. JointJS has a clear advantage here, with a dedicated tutorial section on their webpage holding over 30 lessons starting from a basic hello world implementation and progressively enhancing it with additional features. GoJS only offers a barebones tutorial of two pages which act more like an index of individual features of the library.
Ready to dive in and see the two libraries for yourself? JointJS has an advantage here - it started as an open-source project, and its developers are still committed to bringing basic diagramming functionality into the free JointJS repository, keeping only the more advanced plugins behind the paywall. Meanwhile, GoJS has no free tier. Therefore, it is fair to say that JointJS is a free and open source alternative to GoJS.
The free tier of JointJS includes the Geometry package (for calculations on SVG shapes and their interactions), the Vectorizer package (for dealing with SVG transformations and text), the DirectedGraph layout, a suite of tools to work with Links and Elements (e.g. highlighters, automatic routers, and UI tools), and a collection of standard diagram shapes. For additional functionality, JointJS can be seamlessly extended by a paid tier called JointJS+.
Both JointJS+ and GoJS come with a free 30-day trial period which includes full support from the two respective developer teams. Nevertheless, you may get farther with JointJS+ during those 30 days (thanks to the free JointJS foundation) since you do not necessarily have to start from scratch as you always must with GoJS.
JointJS and GoJS are in an arms race to approach feature parity with each other. In 2023, both libraries come with basic UI elements including element palette, model/view inspector, context menu, tooltip or minimap. They also both offer control interactions (e.g. keyboard shortcuts, copy/paste, undo/redo, scroll, zoom, pan), as well as object layout algorithms - for example layered (flowchart), tree (orgchart), grid (table) and force-directed.
Both libraries come with collections of basic diagram shapes (elements and links) as well as shapes for BPMN. They also support export to SVG, HTML Canvas, PDF, and PNG/JPEG.
In addition to those features (and to the free JointJS features), the paid JointJS+ tier comes with a library of additional ready-to-use UI elements (e.g. toolbar, inline rich text editor, SVG path editor), tools for creating presentation slideshows from your diagram, export/import of shapes to/from Visio, as well as a collections of advanced shapes for VSM.
Meanwhile, GoJS focuses on providing additional out-of-the-box diagram shapes and niche object layout algorithms (e.g. packed, treemap). However, these additions are offset by a lack of any extra UI elements or tools.
To sum it up, JointJS offers more advanced interactive elements and more export and import functionality, while GoJS focuses on offering a larger library of pre-made shapes and layouts. Since properly replicating the interactive functionality of JointJS in your app would prove more difficult than merely creating additional shapes and/or layouts of GoJS, we believe that JointJS gives you a better foundation for your application.
In some cases, the choice of JointJS is obvious, including:
Let us recapitulate what we discussed in the article. Here is a side-by-side comparison of the features of JointJS and GoJS:
Thank you for investing several minutes of your time to research which one of the two leading diagramming libraries would better suit your needs. Since you were so thorough with your exploration, we would like to extend to you an invitation to our no-commitment 30-day trial. It will allow you to experience the advanced JointJS+ diagramming library for yourself and explore how its features can be seamlessly integrated with your project.