11 ms·
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 an
by gecko 11y ago
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.
- estefan 11y agoOK cool. It's not all bad news then. 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.
- CmdrKrool 11y ago> For example, one of the things you have to do is to hide the low-level event loop. 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.
- draw_down 11y ago> 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. 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.
- jdcskillet 11y agoThis is just a high level thought : Will we eventually converge to the point where Flux will also provide an abstraction to the GPU to help speed up rendering? I know there are some tools in place now, but can we get to the point where the designer has no idea they are utilizing an underlying native GPU vs how the browser chooses to do the rendering?
- shoover 11y agoI am struggling with the GUI designer factor. Most of my career has been spent working on WinForms and WPF GUIs and a stack of different things under them. Visual designers are fantastic for tweaking layout, but lately the question I'm asking is whether it's really worth being forced into a particular way of retaining state in the UI and a particular edit/compile/test workflow. 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); But the way React/Om and Elm are integrating GUI construction into the flow of the program is looking awfully compelling. 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.