I think once we see react components converge across web + native we'll start to see more cross-platform tooling and designers springing up. I think things are looking pretty bright. Arguably the key insight the react team had was to treat the browser as a dumb output... and then realise that the DOM could just be one of many outputs.
I did just wonder whether in the GUI world there was a major pattern that people were using today that Flux should be using instead. But apparently not.
When I step back and look at the broader life cycle of projects, very little time is spent in the visual designer. Is that because visual designers are just that powerful or does it speak more to the relative weight of other development factors dominating projects, at least the ones I work on, and admit a possibility that the designer may be worth giving up in trade for other gains in other areas like interactivity (e.g. F# REPL) or a different conceptual model (e.g. React-style functional components)?
I surely wouldn't want to write big WinForms/WPF GUIs in normal imperative style:
var f = new Form();
var p = new Panel();
var b = new Button();
b.Text = "Go";
b.Click += ...
p.Add(b);
f.Controls.Add(p);
I'm interested in hearing more perspectives on the tradeoffs between having visual designers and constructing the GUI in code, assuming an acceptably powerful syntax or model for constructing it.
That also goes for old components. When you have thousands of components, how do you update the model? Well, you avoid strict typing and look to query languages instead. Rather than every component sharing a type, each component internally defines what it needs.
Move to the dispatcher, the data fired off by actions needs to fit the stores that are listening. A common type requires everything to be completely in sync. I think it's worth considering how a query language could fit here, such that a listener can query the payload for what it needs from a message. A flexible object/JSON blob are a reasonable way to pass messages with an eye for that in the future.
I look at the messages to be the start to a distributed application architecture. So I can have messages that target remote services. Eg "turn on living room lights". And similarly, messages from the server, "living room lights are now on." It's a nice way of tying local APIs and remote services together. Have them all communicate with the same messages.
That is a big difference. I think we should pay more attention to things like who-owns-what when we're thinking about the structure of our applications. It's a bit glib to, as the author of the piece does, say "oh well there's diffing here, and Windows had diffing too, so they're the same". Differences like this, well, make all the difference.
This is the very point at which you cross from a library into a framework.
Not to take away from anything else you said, I wonder if this evolution isn't just the latest step in a neverending oscillation around this pivotal point.
I'd also note that we know that this style of design scales amazingly well. You can build and maintain applications as complex as Word, Myst, Netscape, and so on indefinitely. So we definitely know that this design has some historical precedent of working really well, and we're probably not way off track.
That in turn means I think we can answer the "what learning can we apply" by looking at what worked well historically.
For example, one of the things you have to do is to hide the low-level event loop. That's what frameworks like OWL and MFC did very early on, and I think what frameworks like Reflux are trying to do now. You even have some of that in the form of observers and so on in Flux itself. But I think that getting those types of things standardized, and a bit higher-level, will help a lot. I suspect, although I don't know, that ES5 was a bit of a blocker on getting that in Flux earlier, and suspect that Babel's pervasiveness will let that situation start changing, but that's entirely a guess.
We also know that, for the overwhelming majority of apps that are actually written, having a GUI designer building on the underlying framework (e.g. Interface Builder, VisualAge's form designer, etc.) can both decrease development time and reduce bugs, and we know that such tools work best with certain patterns in how callbacks work in the underlying framework. Specifically, you want one-to-many observers, strongly typed events that can be exposed and described via reflection, etc. So I'd hope that implementing that kind of thing in Flux can be done in a forward-looking way from the beginning, rather than getting bolted on later. More generically, designing the framework with an eye towards making it tooling-friendly is probably a really good way to future-proof things from the beginning.
I guess we'll see as we move forward. Each situation is a little different, so while there are parallels, it's hardly a slam-dunk that things will go exactly the same. But I do think that keeping an eye towards tooling is a really logical way to look forward and learn from the past.