5 ms·

...and so for those of us who aren't Windows developers, what learnings can we apply to flux to make it better?

by estefan 11y ago

tedunangst 11y ago
Have a look at the Windows design some more? It's pretty extensively studied and documented. A "this is like that" article is a hint that if you wanted to learn more about this, you could also learn more about that.
- estefan 11y ago
  Anyone can bitch about the latest tech because there's very little new under the sun. It's far more constructive to suggest improvements. Like the adage "give me solutions not problems".
  - jsprogrammer 11y ago
    A well-defined problem defines the solution. A solution without a problem is worthless.
  - Someone 11y ago
    In Mac OS (1984), controls were different from windows. Advantage was that controls were more light-weight, disadvantage that one couldn't build a control out of smaller controls (at least, the system did not support that). Its event loop also was extremely rudimentary. If you got a mouse click event, you would have to make a system call to find out what window it was in, then a system call to find a control, etc. If the OS had a real kernel and memory protection, that would have killed performance. 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.
- Aleman360 11y ago
  Specifically, look into how XAML apps work on the Universal Windows Platform [1]. Windows application development moved past Win32 about ten years ago with the initial version of XAML (Windows Presentation Foundation). 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/dn894631.aspx https://msdn.microsoft.com/en-us/library/windows/apps/dn8946... 2. https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.core.coredispatcher.aspx 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.
  - pjmlp 11y ago
    XAML is great, that is what XHTML should have become if browser vendors played ball. Oh well.
    - nerraga 11y ago
      Source? I always took XHTML to be an effort to make html into a stricter more parse-friendly format. Xhtml lets you use an xml parser to pull apart a page rather than having to deal with some kind of markup tag soup (which also makes it a great target for tooling within an IDE). XAML is concerned with layouts and binding in ways that, I don't believe, were ever intended for Xhtml. I could be wrong but they've always seemed to be worlds apart.
      - pjmlp 11y ago
        That is what many that didn't bother to learn the specification thought. Quote (http://www.w3.org/TR/xhtml1/#why 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 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 http://www.w3.org/standards/xml/components Bindings in XForms for example, http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-examples http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-ex...
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.
WorldMaker 11y ago
Windows development has been increasingly moving to ReactiveX and ReactiveX-style observables as the "best practice" way of handling time and change. (I certainly encourage new Windows projects to take a good, long look at ReactiveUI.) 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 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.
- muraiki 11y ago
  Yes, when I first read about Flux (which was after I learned RxJS) I kept thinking that you are essentially writing by hand things that could be generated automatically. It's like going from nested callbacks in early Node.js to Go. :) 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.
  - WorldMaker 11y ago
    Yes, exception handling with Observables, just like with Promises, gets to be a bit more complicated, especially as browser Dev Tools haven't quite caught up to them yet. (With Promises native to ES2015 that's getting fixed and native Observables are tentative for ES2016 or ES2017 which would be great. Also, now that Promises are native, I'm really hoping for a big Node push towards more Promise-friendly APIs.) 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.

...and so for those of us who aren't Windows developers, what learnings can we apply to flux to make it better?

by estefan 11y ago

...and so for those of us who aren't Windows developers, what learnings can we apply to flux to make it better?

Have a look at the Windows design some more? It's pretty extensively studied and documented. A "this is like that" article is a hint that if you wanted to learn more about this, you could also learn more about that.

estefan 11y ago
Anyone can bitch about the latest tech because there's very little new under the sun. It's far more constructive to suggest improvements. Like the adage "give me solutions not problems".
- jsprogrammer 11y ago
  A well-defined problem defines the solution. A solution without a problem is worthless.
- Someone 11y ago
  In Mac OS (1984), controls were different from windows. Advantage was that controls were more light-weight, disadvantage that one couldn't build a control out of smaller controls (at least, the system did not support that). Its event loop also was extremely rudimentary. If you got a mouse click event, you would have to make a system call to find out what window it was in, then a system call to find a control, etc. If the OS had a real kernel and memory protection, that would have killed performance. 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.
Aleman360 11y ago
Specifically, look into how XAML apps work on the Universal Windows Platform [1]. Windows application development moved past Win32 about ten years ago with the initial version of XAML (Windows Presentation Foundation). 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/dn894631.aspx https://msdn.microsoft.com/en-us/library/windows/apps/dn8946... 2. https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.core.coredispatcher.aspx 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.
- pjmlp 11y ago
  XAML is great, that is what XHTML should have become if browser vendors played ball. Oh well.
  - nerraga 11y ago
    Source? I always took XHTML to be an effort to make html into a stricter more parse-friendly format. Xhtml lets you use an xml parser to pull apart a page rather than having to deal with some kind of markup tag soup (which also makes it a great target for tooling within an IDE). XAML is concerned with layouts and binding in ways that, I don't believe, were ever intended for Xhtml. I could be wrong but they've always seemed to be worlds apart.
    - pjmlp 11y ago
      That is what many that didn't bother to learn the specification thought. Quote (http://www.w3.org/TR/xhtml1/#why 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 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 http://www.w3.org/standards/xml/components Bindings in XForms for example, http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-examples http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-binding-ex...

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.

WorldMaker 11y ago

Windows development has been increasingly moving to ReactiveX and ReactiveX-style observables as the "best practice" way of handling time and change. (I certainly encourage new Windows projects to take a good, long look at ReactiveUI.) 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 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.

muraiki 11y ago
Yes, when I first read about Flux (which was after I learned RxJS) I kept thinking that you are essentially writing by hand things that could be generated automatically. It's like going from nested callbacks in early Node.js to Go. :) 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.
- WorldMaker 11y ago
  Yes, exception handling with Observables, just like with Promises, gets to be a bit more complicated, especially as browser Dev Tools haven't quite caught up to them yet. (With Promises native to ES2015 that's getting fixed and native Observables are tentative for ES2016 or ES2017 which would be great. Also, now that Promises are native, I'm really hoping for a big Node push towards more Promise-friendly APIs.) 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.