Well, first, I'd note that React and Flux are already learning from the past. For example, I absolutely think there are tons of similarities between WM_PAINT and React's DOM diffing, but there are also major, major differences. A really key one being that React effectively handles the rendering tree directly, and can therefore do high-level manipulation and performance work on it, whereas Windows paint messages forced the windows themselves to handle all of their state diffing and painting issues. This makes the React part of Flux a lot closer to things like WPF, or retained-mode 3D graphics. (In fact, it wouldn't shock me if that were the actual inspiration for React's DOM work, and that the rest of this is more covergent evolution.)

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.