Do Modern Frameworks Still Need State Management Libraries?

[oleksii-shepel]

Over the last few years, frameworks have gained powerful new primitives:

• Signals
• Resources
• Server Components
• Reactive Stores
• Fine-grained reactivity
• Streaming rendering

As a result, many applications can be built without introducing a dedicated state management library at all.

This raises an interesting question:

Do modern frameworks still need state management libraries?

For simple applications, the answer may increasingly be "no."

But as applications grow, new challenges appear:

• coordinating asynchronous work
• sharing state across features
• tracking execution lifecycles
• handling cancellations and retries
• managing real-time updates
• coordinating multiple data sources
• maintaining predictable application behavior

Perhaps the question is no longer:

"How do we store state?"

but instead:

"How do we coordinate application behavior?"

In many cases, state itself is relatively simple. The complexity comes from everything happening around it.

For example:

• loading data
• synchronizing changes
• reacting to external events
• coordinating user actions
• handling failures
• managing concurrent operations

These problems are often only partially addressed by framework-level primitives.

So what remains after signals, resources, and modern reactivity solve the basics?

• Do we still need stores?
• Do we need workflow management instead?
• Is execution tracking becoming more important than state tracking?
• Are streams and actors better suited for modern applications?
• What problems are still unsolved by today's frameworks?

What do you think?

If modern frameworks continue to become more reactive and capable, what responsibilities should remain for state management libraries?