raspasov

The Oxford dictionary definition of a Minimum Viable Product (MVP) is:

An early, basic version of a product (such as a piece of technology, a computer program, etc.) which meets the minimum necessary requirements for use but can be adapted and improved in the future, esp. after customer feedback;

Here's a proposed improved definition:

An early, basic version of a product (such as a piece of technology, a computer program, etc.) which meets the minimum necessary requirements for use by its creators and customers; 

I think in practice, in order for a product to qualify as truly viable often requires the people who build it to use the product at least as much as any other person. This is especially true for great software. Think about the best software products you use every day: your favorite mobile maps application, favorite music app, or email client. It would be almost impossible to imagine that the people who build the products are not active users of the same apps!

Now think about a bad software product that you might encounter briefly or you are forced to use: a poorly designed electronic kiosk with 1000ms lag on every interaction, or a hospital electronic system. I think there's a high chance that the people building them rarely use them, or not at all.

CRDTs by themselves guarantee convergence. 

They do not guarantee consistency of reads unless we can somehow guarantee that all writes have been processed.

Use one (and yes, only one) atom to store the state. 

From my experience with React(Native) in the last ~6 years, keeping all the app state in one atom is a good thing.

I don’t use React context or any frameworks or patterns like FRP. I just pass props down from the root. All data management is simple, and easy to reason about. That way you avoid state inconsistencies and hard-to-reason-about bugs. I almost never run into performance issues.

If you do get performance issues, selectively add a useState hook to a component that is being updated multiple times per second. That’s when I run into the bugs and “what the hell” moments. It’s almost inevitable with multiple source of truth, and it gets exponentially worse the more sources of truth I add. 

I believe concurrent mode is trying to solve a problem that a very big app might have. Dozens/hundreds of components, all developed by separate teams, where each component is doing its own state management and they want to avoid any and all state centralization (think the FB website, not even the mobile app, because there’s only so much visible on the screen in any one moment on mobile). If your app is not of this size, I’m not sure if you’d see a benefit.

One thing that CLJS does have going for itself is efficient immutable data structures. When you're using plain JS, you have to choose to use immutability. It's not the default. You get a situation where you have 10 teams working on the same frontend app, some are using Immutable.js and doing efficient rendering, some are using plain JS arrays/objects and re-rendering everything on any and every change. It’s a mess.

Concurrent mode might help a case like that.