Eclipse Sprotty Is Officially Out of Incubation

We’d like to announce an exciting landmark for the Eclipse Sprotty project: the project team released version 1.0.0 this month. Eclipse Sprotty has officially concluded the incubation phase and is entering maturity. In this article, I’ll review the most relevant aspects of the project so far and outline what you can expect for the future.

Architectural Considerations Guided by User Experience

Jan Köhnlein and I started the Sprotty project at TypeFox in 2017. We laid the foundation of Eclipse Sprotty with a clear focus on visualizing and navigating models and data. We had years of experience with graphical tools based on the Eclipse Platform, but that experience was not always pleasant. Working with GMF had left us especially frustrated about the state of graphical modeling tools.

When we designed Sprotty’s core architecture, we took inspiration from web frameworks such as React. We decided to work with a virtual DOM based on Snabbdom. The resulting architecture (Figure 1) forms a circle with three main components:

1. The Viewer renders the model by generating SVG elements. It listens to user interactions and derives corresponding actions.
2. The ActionDispatcher decides who will consume the actions. If the actions are meant to have an immediate effect on the model, they are transformed to commands.
3. The CommandStack executes commands, which leads to modifications of the model. The new model is then submitted to be rendered. If requested, the transition from the previous state to the new state of the model is animated.

Figure 1: Core architecture of Sprotty with its three main components

This approach has proven its value, as we have been able to add many new features to the framework despite its relatively small core code size.

Numerous User-Facing Features Added Over Time

A considerable number of user-facing features have been implemented in Sprotty over time, including:

• Seamless diagram navigation with a mouse or trackpad
• Scroll bars with projections of important elements to support navigation
• Changes animate after automatic model updates
• Groups of elements can be focused by centering it and zooming in
• Feedback on mouse hover, selection, drag and drop is immediate
• Connections with different styles added, including Bézier curves and Manhattan (orthogonal)
• Fine-grained connection routing with handles
• Connection anchoring to different shapes (e.g., rectangle, ellipse, diamond)
• Highlight intersecting connection segments with gaps or “jumps”
• Specify layouts of composite elements with options fo
• Pop-up information boxes shown on mouse hover
• Show validation markers like errors or warnings
• Render buttons with handlers are invoked on click
• Show VS Code style command palette (type to search)
• Edit labels in-place by clicking into them
• Collapse or expand container elements in hierarchical diagrams
• Export diagrams to an SVG file
• Automatic layout with the ELK layout engine

Visualization-First Approach Minimizes Complexity

The overall framework is still hard to comprehend for many developers. This is due to the conceptual dependencies between the framework features, and it reflects the fact that a graphical tool with rich user interaction is a complex system in itself (Figure 2).

Figure 2: An example of a visual implementation of an electronic control unit used in the automotive 

The decision to restrict the core functionality of Sprotty to read-only visualization was deliberate, as we felt this would help minimize its complexity and keep it manageable. More importantly, both Jan and I regard text as a much stronger format for editing than graphics. For this reason, we have been promoting the approach of synchronizing a graphical view with a text editor (more on this later).

Nonetheless, it is fully possible to build graphical editors on top of Sprotty. In fact, there are two other Eclipse projects that do this: Eclipse GLSP and Eclipse Sirius Web. Both projects use Sprotty only for rendering diagrams and define their own ways to add a full graphical editing experience. While I still prefer generating diagrams automatically and editing the information elsewhere, I can fully recommend GLSP and Sirius Web for applications where full-blown graphical editing is necessary.

Built-In Protocol Simplifies Web App Integration

To simplify the integration with different kinds of web-based applications, Sprotty has a built-in protocol to transmit information between a client and a server part. The client is of course responsible for rendering the diagrams. The server typically has access to the source data from which the diagrams are derived. These data must be transformed into the diagram model of Sprotty so they can be processed by the client.

In the first years of Sprotty, we focused on Java-based server implementations. However, Node.js became more relevant as a server platform over time because cloud IDEs such as Eclipse Theia use Node.js in their backends. VS Code extensions, which are also supported by Theia, are also executed in Node.js. Moreover, reducing the number of different programming languages and execution platforms is beneficial for the long-term maintainability of a project, so using TypeScript consistently throughout an application is a plus.

Application-Specific, Text-Driven Diagramming

The Eclipse Foundation features two powerful frameworks for creating textual languages with formal syntax: Eclipse Xtext and Eclipse Langium. Xtext is the older project, with its origins in 2008, and is built with Java around the Eclipse Modeling Framework (EMF). Langium is conceptually similar to Xtext but is fully built with TypeScript and was started in 2021. Using these frameworks, you can implement text editors with rich support like validation, completion, navigation, and much more.

Sprotty can be combined with each of these language development toolkits to generate diagrams out of text content. This text-to-graphics transformation is fully application-specific, so the actual logic that determines which parts of the textual syntax are used to derive certain parts of the diagrams is custom-tailored. The generic integration takes care of synchronizing text changes with the diagram: the graphical representation is automatically updated and a short animation helps to follow the transition (Figure 3).

Figure 3: A state machine DSL (left) with an automatically generated diagram (right)

The Future Is Bright for Sprotty

The graduation of Sprotty into a mature project marks a new era for this open source framework. In the process of the graduation review, we have shown that Sprotty has an established and growing community and diverse multi-organization contributor activity using open source rules of engagement. This demonstrates that Sprotty is a safe choice for companies that want to develop web-based diagramming applications.

On the technical side, one change that will need to be made sooner or later is the switch to ECMAScript Modules (ESMs). This module system is being adopted by a steadily increasing number of web-based libraries and applications. It is clear that it will eventually fully replace the CommonJS module system currently employed by Sprotty.

The goal for all further development in the project is the long-term stability and reliability of Sprotty. In terms of features, the project team will continue to top off the user experience. This affects all aspects of the framework: running as a standalone graph visualization, using it as a basis for graphical editing, and the integration with application platforms, such as VS Code or Theia.