I too am disappointed by the lack of innovation around state management in applications. But I don't think this solves the problem.
A lot of developers think what we need is additional abstraction on top of the way data is stored and retrieved, to remove all the annoying CRUD boilerplate that goes into building an app. This seems to make sense because devs think in terms of simple examples like TODO lists.
But in a real production application with heavy scale, you need a lot of low-level control over precisely how state is managed. Tweaking a SQL query or table structure can be the difference between minutes of latency and milliseconds.
I'm not sure what the path forward is here, but I hope smart people keep thinking about it.
We've also seen that sometimes working at a lower level can actually make performance worse; there are cases where eg. describing something abstractly to a smart compiler gives it more opportunities to optimize
Personally I think a better way is "high-level with trapdoors", where you can pierce the abstraction if you really need to spot-optimize but higher-level code is the norm
> But in a real production application with heavy scale, you need a lot of low-level control over precisely how state is managed.
Very much this. "State is managed automatically!" can very quickly become "this frequent operation is automatically doing a huge amount of DB work which should actually be deferred until later"
A lot of developers think what we need is additional abstraction on top of the way data is stored and retrieved, to remove all the annoying CRUD boilerplate that goes into building an app. This seems to make sense because devs think in terms of simple examples like TODO lists.
But in a real production application with heavy scale, you need a lot of low-level control over precisely how state is managed. Tweaking a SQL query or table structure can be the difference between minutes of latency and milliseconds.
I'm not sure what the path forward is here, but I hope smart people keep thinking about it.