Unidirectional user interface architectures

What a fantastic overview of the past, present and future of UI flow and structure! There is a real need to step back and consider the available architectures and to build forward to a more natural and synergistic solution like Cycle.js.org.

I Really like the third diagram in the Nested Dialogues section and where it says "The wiring of Observables between layers of Dialogues is a data flow graph". This reveals that interactive event flow is primary and is what drives a UI, weaving through components like the nervous system does in the human anatomy.

In the diagram we are looking at an emerging and clear way of defining app flows and structures. There is potential here for a drag and drop IDE editor where the over all app can be architected and generated.

I fully agree (on the visual editor)! It's a great property of Cycle.js apps that there is a one-to-one trivial map (isomorphism to be more precise) between the program source code and a data flow graph, so I wish I had time and resources (or hope someone eventually does) to build a tool where you can work in both code or data flow graph. I'm interested in the data flow graph as a "minimap" (think Sublime Text), not as a replacement to actual code (I dont think we can get rid of code just yet).

Can something like a basic `cycle.js` be built using node streams? I once listened to a podcast with timoxley, where he said, that node streams are basically very similar, but while streams have flow control built-in, FRP libraries give more functionality out of the box. But I think more and more streaming modules are getting added constantly to npm, so eventually I can get to the same feature set using a collection of streaming modules. Does that make sense?

maybe check: https://blog.risingstack.com/functional-reactive-programming...

The overview is really great, but I think you only scratched the the surface. With ambitious task to cover such a broad topic, it's hard to go into all details in one post w/o making it unreasonably long. So great work on bringing attention to this topic.

I feel some need for code examples as well [as other commenters], but I'm afraid the post would be bloated with them. Maybe, it's worth expanding that into a series of posts - one per architecture/approach.

Another idea to improve expressiveness of the post would be to draw e.g. ol'good MVC pattern for comparison. But since your article is targeted for people familiar with the subject, that piece of advice might be not very useful.

As for conclusion, I think I cannot completely agree. It seems for me a little like a "silver bullet" solution. On top of that, looking at charts, I can think about a potential problem. Proposed solution requires a lot of internal wiring, which can result in a bunch of glue code.

I think that different solutions suit different application patterns. E.g. ones go well with -bacon and cheese- unconnected models/stores, the others benefit from centralized data hub.

You've started a really interesting topic, but we need to go further. We can benefit more from a deeper analysis.