A drawback of using statecharts is that it's pretty "far out" in terms of what might be normal for average coders. Most developers have only heard about state machines, maybe from the field of electronics or embedded systems, where it's crucial that things behave in well defined ways (and by and large they do just that). So usually developers need to learn new techniques to debug and refactor, but it also includes trying to figure out how statecharts fit in with the technology stack that's in use.
One big downside of it being a foreign way of solving problems is a steady stream of questioning the validity of using statecharts. Question the hypothesis that statecharts actually are beneficial. From managers, co-workers, and even Stack Overflow users: "why are you even doing it like this? A boolean is much simpler!". The aim of this site is to provide ample information to help out with answering those questions.
Another problem with statecharts being so foreign is that in order to use it efficiently in a particular technology stack, someone has to walk the path the first time, preferably someone with deep understanding of the technology stack, and of statecharts. This is happening already, and we try to list them on our resources page. We hope, with statecharts.dev to provide enough information to inspire more people with knowledge of various tech stacks, to consider how statecharts could help with the long term maintainability of codebases.
Coding up a state machine, or statechart can be somewhat intimidating, if you haven't done it before, and just like many other current "good practices" in the development community, at some point they were all "foreign" and were frowned upon; some still are in certain communities.
- Unit Tests; Static Typing
- Pair Programming; Pull requests
- Distributed version control; Feature branches; Any version control at all
- Functional programming; Event sourcing;
These techniques have all moved the software industry forward, but they also encountered a steady stream of questioning their validity, and someone took the job of figuring out how to employ a technique in a particular tech stack.
The thing is that unless you build an explicit state machine, an implicit one will be in there, no matter what. If you have an if (result == null) in your code, then your code has two states. It either does this, or it does that. That's essentially what a state machine is; there's no running away from this fact. The implicit state machine is simply a lot harder to maintain, a lot harder to "get right".