...and so for those of us who aren't Windows developers, what learnings can we apply to flux to make it better?
I certainly think that we're going to see more migrations to RxJS (or Bacon or other relatives) from Flux (or in addition to Flux).
Personally, I've been preferring Cycle (http://cycle.js.org), which is directly RxJS-based, over React and Flux, but there are an increasing number of options and maybe no "perfect" answers just yet.
I prototyped a decent amount of UI in Cycle and thought that it was great. Using virtualdom with it was really enjoyable and a lot easier to reason about than what is seen in the typical JQuery-based RxJS/Bacon/Kefir examples. However, I found the interaction between exception handling in Cycle and RxJS to be strange at times... maybe I'm just not experienced enough with them yet, but I swear I had some swallowed exceptions that I could never track down. That being said, I feel that this is "the future" (standard disclaimer applies).
Currently I'm using Knockout.js for UI stuff at work and I've found that by maximizing the use of pure computed observables and minimizing mutation of observables (essentially, implementing unidirectional data flow) I can get pretty good results.
The great thing about Observables, though, is that even though exception handling is more complicated as you first learn it: it's a lot more consistent as you get used to it than the callback/event-handler world. That said, I do think Cycle swallowed exceptions it shouldn't have early on (especially without good browser dev tools support) and seems to be getting better at console.loggging them if not propagating them through observable streams as sometimes it should.
My fallback is still Knockout as well. It has served its role, with its very basic observables, very well over the years.
Pros to Cycle over React is that it is truly more "Reactive" in the best of ways, and in a way that is easier to work with (RxJS has a standard set of operators for building and composing reactive Observables that are shared with other platforms).
Cons to Cycle over React is that you lose "the Facebook effect". It's much more a project of love than of big enterprise and so it's a bit harder to learn and a bit more complicated at first glance. (That said, RxJS itself and all the Reactive Extensions libraries have gotten a lot of corporate love from companies as diverse as Microsoft and Netflix.)
http://reactivex.io is a great reference site to learn more about RX. http://cycle.js.org of course also has a very strong explanation of what is and how it expects to work.
Carbon moved the "giant switch statements" out of the views, inside the library (edit: maybe, even into the kernel. That way, application processes only would be woken up if they really had work to do). Controls had to tell the library what events they were interested in, and what function to call to handle them.
Advantage was that the system didn't need to fire zillions of events to controls that didn't do anything with them (for example, few controls respond to "mouse moved" events, but if the system doesn't know that, it has to send corresponding events to a top-level window, the control below it, the control in the control below it, etc.). That decreased power usage (at least in theory; code and data accessed could be closer to each other, decreasing cache misses, and there were fewer JSR-switch-do nothing-RTS cycles), and allowed for the system to introduce more high-level events (double-click, triple-click, "mouse entered", "mouse moved outside the area of the control", etc) without decreasing performance; disadvantage that registering the exact set of events one was interested in wasn't fun (especially because, in those days, one needed to pass universal procedure pointers to the Carbon library to register handlers)
If you have lambdas and reflection, the latter can be made free for programmers. So, I guess that is an area one could look at. I'm not sure the gains will be real in a system where the windows live in a browser window, though.
Nowadays, the event loop is still there under the hood, but it's abstracted away by the UI framework. You are left with independent views that can render themselves, but the raw event loop is exposed as higher level events raised by individual views (e.g., a single "Tapped" event instead of having to handle separate mouse/touch/pen/controller down+up events).
Apps often use some sort of message bus for communicating between non-UI components in a decoupled way, which may or may not re-use the UI thread's event loop. In general, you try to minimize what happens on the main loop, since it can lead to UI unresponsiveness. However, in XAML the main event loop is actually a priority queue, so you can put stuff into it at lower priority than regular input events[2].
1. https://msdn.microsoft.com/en-us/library/windows/apps/dn8946...
2. https://msdn.microsoft.com/en-us/library/windows/apps/window...
Disclaimer: I work at Microsoft, where we're using XAML to build the Windows Shell.
Quote (http://www.w3.org/TR/xhtml1/#why)
Document developers and user agent designers are constantly discovering new ways to express their ideas through new markup. In XML, it is relatively easy to introduce new elements or additional element attributes. The XHTML family is designed to accommodate these extensions through XHTML modules and techniques for developing new XHTML-conforming modules (described in the XHTML Modularization specification). These modules will permit the combination of existing and new feature sets when developing content and when designing new user agents.
Quote (http://www.w3.org/MarkUp/2004/xhtml-faq):
If your document is just pure XHTML 1.0 (not including other markup languages) then you will not yet notice much difference. However as more and more XML tools become available, such as XSLT for tranforming documents, you will start noticing the advantages of using XHTML. XForms for instance will allow you to edit XHTML documents (or any other sort of XML document) in simple controllable ways. Semantic Web applications will be able to take advantage of XHTML documents.
The old HTML behaviors would be achieved by XML stylesheets, rendering into HTML4 or XML events.
There were then a plethora of standards planned to augment XHTML with application level.
http://www.w3.org/standards/xml/components
Bindings in XForms for example, http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-ex...
This is off-topic, but I have a question about the Windows 10 shell. You previously said that the new XAML-based part of the shell is written in C++/CX. Why not C#? Is the performance and/or memory footprint of the .NET Framework still not good enough, even with .NET Native?
I'm not sure what single catchy word you want here, but that's not it.
Or maybe the poster is just being self-deprecating :p
Yah, sure its got a few new tricks, but in that regards its just another all that is old is new again. In that it basically serializes the CLR where as the old resource fork serialized the windows API.
For another example see the delphi DFM....
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.
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.
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.
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.
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.