I very much enjoyed reading this article, it explains a lot of the pain and calls out a lot of the current broken designs. While the conclusions are correct, I

I very much enjoyed reading this article, it explains a lot of the pain and calls out a lot of the current broken designs. While the conclusions are correct, I feel like they could be simplified. If you try to use the vocabulary of the broken system you will get complicated phrases like "denormalization engines" (which I very much hope does not catch on despite agreeing with it). Instead, if you look at correct systems - like Elm, Rx, Datomic.com , or https://github.com/amark/gun https://github.com/amark/gun (my own, obviously I am biased) you get less complicated ideas: - Event Driven. - Data Streams. - Data Flow. - Data Pipeline. - Reactive Programming. All of these, despite "FRP" itself being jargony, solve the majority of the article's complaints. Largely because the solution he comes to at the end is the same thing as FRP. Don't we wish we had all listened to Alan Kay now?