Archive

We’re excited to announce the release of Stately Studio 1.0, a major step towards our mission to make all app logic visually collaborative and accessible to your entire team.

➡️ Get access today

Stately is the visual software platform for app logic and workflows, and Stately Studio now enables you to collaborate on flows with your team with many new features:

We’re excited to announce the public beta of the Stately Editor! The Stately Editor is a tool for creating and editing state diagrams visually. We’ve received a lot of great feedback from the private beta testers, and now we’re delighted to share it with everyone.

Try the Stately Editor beta 🚀

Check it out on Product Hunt 😺

We’ve been busy.

After months of planning and hard work from the amazing Stately team, we’re excited to finally release the new Stately Viz.

State machines are awesome.

They're a really useful model for complex logic, workflows, processes, statuses, really anything that models state changes over time due to events, which happens to be most of your app logic.

They also happen to be one of the oldest models of computation, going back to at least the 1950s (when Mealy and Moore published their state machine concepts). In fact, computers and electronics really wouldn't exist without them; they're that fundamental.

State machines aren't new, and they also aren't special. In just about every modern programming language, you can use the built-in language control-flow structures, such as switch statements, to implement state machines.

Over quarantine, I've been slowly working on something that I've wanted to exist for a long time.

There are so many tools that help us inspect logs, events, and even state in our applications, and many of us rely on these tools to put the pieces together and make sense of what's going on in our application. But that's not the whole picture!

What I feel is important is understanding what can happen in any given state. We should be able to visualize the logic and behavior of our apps as they're running.

Launching Statecharts.io

It seems like every time some big software-related issue hits international news, there is almost always some state-oriented aspect that hints at how it was caused, and/or how it could have been prevented.

Last year, I wrote about the serious FaceTime eavesdropping bug and how it could be avoided by making implicit state machines explicit, or in other terms, just making sure that nothing unexpected can happen in any given state. And the recent Twitter hack was likely caused by some social engineering attack vector (humans, after all, are the weakest link).

Indeed, state machines are an important security model because if you can model every path of your system as a state machine and ensure that no path leads to an undesired vulnerable state, you can guarantee that your system is protected. But we'll save that for another newsletter issue.

Let's shift gears into something a little more humorous.

I want to talk about race conditions.

And I don't just mean race conditions in the software sense, but the issue of bias based on race and other factors in software, and how these human issues can affect something as small as a logical error, to something as big as how an entire application can adversely affect groups of people.

See, race conditions (in the software sense) and racial bias in technology are both related by fault of assumption. We assume that entities, whether it's humans or external services or other points of communication, will behave in a certain, specific way. Quite often, our assumptions are wrong. And when they're wrong, the software no longer behaves optimally for the users.

It's well-understood that machine learning models are only as good as their data. When the data is biased, so are the models. Recently, there was a federal study of top facial recognition algorithms that found "empirical evidence of bias", leading to greater inaccuracies based on race, as well as gender and age.

Welcome to the very first issue of the Stately Newsletter! I'm really excited to begin an open, thought-provoking discussion on how we manage state in the ever-evolving, modern software and web ecosystem.

Who am I?

My name is David (@davidkpiano). I created XState, so I'll share a lot of progress on XState and related tools here (there is a lot that goes on behind the scenes). I work at Microsoft, so I have to wear many hats in a few different languages (JavaScript, TypeScript, Python, C#, Scala, etc.) and work on different projects with all sorts of complex data- and state-related problems. I'm also passionate about animated, interactive user interfaces, so expect me to talk a lot about that, too.

But enough about me. This newsletter is about you. I want to have an open discussion with you about the state management problems you face in your day-to-day work. We'll be exploring all sorts of past research and new insights about different state concepts, techniques, tools, and more that will help you be productive.