It’s been about a year since we’ve released Stately Studio 1.0, and a lot has happened. Stately Studio is essentially a visual software modeling tool that strives to make it easy to create, manage, and use state machines, no matter how complex they may get. Primarily, it served as a powerful set of devtools for XState (an open-source library for creating state machines, statecharts and actors in JavaScript and TypeScript). You could import XState code to a state diagram, modify it visually in an intuitive drag-and-drop canvas, and export to XState. Eventually, we added more export options: JSON, Markdown, Mermaid diagrams, and stories.

But Stately Studio has bigger ambitions than just being a suite of devtools for XState. We’ve frequently heard that these state diagrams are an important source of truth for critical app logic, serving as documentation for the entire team that stays up-to-date with your code. But a reliable source of truth for app logic is a need for all apps, not just those that use state machines directly.

That’s why we’re so excited to release Stately Studio 2.0, which aims to meet developers where they are, no matter which libraries, frameworks, or even languages they use. There are many benefits to modeling app logic with state diagrams and the actor model, and we want to enable developers to take advantage of those benefits to build more robust, feature-rich, and maintainable app logic faster.

The Stately team is very excited to announce a new feature we’ve been working on for quite some time! Join us in welcoming Stately Sky to the Studio. Lovingly built with PartyKit, Sky is our new serverless platform for running workflows within the Studio. With Sky, users may now run their statecharts as live machines in minutes, complete with XState v5 actors and multiplayer support.

It’s been a while since our last changelog update, so let’s get right to it!

You might have heard of “state machine” or “finite-state machine” before. If you look up state machine on Wikipedia, you’ll read that a state machine is described as a “mathematical model of computation,” followed by a bunch of symbols and computer science jargon that doesn’t immediately seem to apply to your team’s work.

However, state machines are really useful for describing almost any kind of logic, feature, user story, sequence, process, workflow, specification, and more.

State machines are great for modeling state in applications. However, we often need to persist and restore state across sessions - for example, when a user closes and reopens their browser. In this article, we’ll explore how to persist and restore state in XState so your frontend applications or backend workflows can pick up where it left off.

You can now open your machine in CodeSandbox or StackBlitz. These options show when you select either JavaScript or TypeScript export formats in the Code panel. When you open your machine in these external editors, it will be deployed as a demo app so you can jump quickly into prototyping and get an example of how to integrate your machine into your codebase.

Our team knew early on that users needed the ability to share machines in the Studio and build on each other’s work. We also needed the Studio to be an effective tool for teams to work together and share context. But how do we do that safely, making sure the right eyes were on the right machines? And how do we protect against accidental mishaps that have plagued devs since the dawn of the computer? Being a distributed dev team ourselves, we’ve shared these same pain points and decided to build a solution directly in the Studio. Enter Stately teams, our way to provide privacy and safety while allowing effortless collaboration.

The Stately team has had another busy week. The editor now has event schemas, and we’ve made many more improvements. Let’s dig in!

We’ve released many new features recently, but we’ve also made minor enhancements and bug fixes to improve your Stately experience.

As software architecture grows increasingly complex, developers and project managers often grapple with the challenge of visualizing and organizing application logic. This is where state machines and flows come into play. State machines are a powerful tool for modeling application logic, and flows are a great way to visualize and organize state machines. At Stately, we’re committed to making state machines and flows more accessible and easier to use.

But state machines, though powerful, have a learning curve that can be a bit intimidating. And then there’s the blank slate problem: where do you even start when modeling a flow? Furthermore, when flows get large, how can you apply broad changes in a more natural way while keeping the flow intact and logically correct? These are some of the challenges we set out to solve with our new experimental generative features.

New generative features​

In response to these challenges, we are thrilled to introduce two experimental beta features:

• The ability to generate a flow from plain text
• The ability to modify an existing flow from plain text