Lab notes #015 Writing about state management

This past week was spent researching and reminding myself of the core problems of building interactive apps and addressing state management problems.

• React I Love You, but You're Bringing Me Down
• Get in Zoomer, We're saving React
• The new wave of React state management
• Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)
• Past, Present, and Future of React State Management

I ended up pounding out a post on front-end state management in a day or two. This was much faster and more focused than my previous essay about the Broken Half of Interactive Programs. This tells me that I better understand the exact kinds of problems that are occurring for front-end developers and I'm better able to articulate them. Still not at a point where I can pitch it, but I think I have a bunch of work required to verify before I get to that point.

But I think it's not enough to be reminded of developer problems. Nowadays, it's well-known that developers will pay for services, but not necessarily for core languages and frameworks. This seems especially true for web developers because no one company owns the web as a platform, so the languages, frameworks, and tools for the web tend to be open-source projects.

It's important to find a problem people are willing to pay for in order to be sustainable and to influence how we build apps. When I look at pure researchers lament the current state of affairs in CS, they might be lauded as visionaries, but developers are motivated by what will get them and keep their jobs.

As a result, I'll also be looking for problems whose use cases fit the bill for a performant and easy-to-build interactive web app. A likely place to look is the market for internal tools and no-code. However, the valuable insights and ideas here are specific examples and use cases. For this, I do have an unfair advantage in bookface, where I can see what sorts of problems actual startups have that they're asking others for solutions. So instead of a to-do app or the made-up series of 7 GUIs, I can use these use cases as sample apps instead, because it's as Bret Victor suggests,

You can’t just improve coding. You need a broader mission. Everyone who’s improved coding, Papert, McArthy, Alan, has done it with a broader goal in mind, and the technology fell out of that.
https://futureofcoding.org/notes/bret-victor/dynamicland.html

I also started looking at whether anyone has done auto-differentiation on functions that operate on sets. It sounds like it might be useful for incremental joins for queries. However, a cursory search and discussion with ChatGPT make it seem like no one does this at all. It's perhaps because differentiating sets is ill-defined or not at all. As someone that's naive about the topic currently, it seems like it should be doable. But I think the hard part will be discovering what the chain rule for each typical operations, such as union, intersections, etc, on sets will be.