13 ms·

Flux is the new WndProc

532 points by gecko 11y ago

arijun 11y ago
Stemmed from this comment chain: https://news.ycombinator.com/item?id=10379199&goto=item%3Fid%3D10378684 https://news.ycombinator.com/item?id=10379199&goto=item%3Fid...
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?
- 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.
whatever_dude 11y ago
The writer really likes the word "idempotent".
- tobr 11y ago
  And uses it incorrectly. Idempotence is when f(f(x)) == f(x). React views take some props and/or state and return a component, so applying the view to its output would just give an error. I think the word he's looking for is "pure". EDIT: I was wrong - apparently "idempotent" can also describe a consistent relationship between the input and some state. In that sense, it's actually a very good description of how the input to a React view affects the DOM.
  - kgen 11y ago
    Well, even in Wikipedia, the definition is quoted as being different for CS vs the unary operation you describe. "In computer science, the term idempotent is used more comprehensively to describe an operation that will produce the same results if executed once or multiple times." Which is more that f(x) == f(x) == f(x) for the state affected by f.
    - tobr 11y ago
      Thank you for pointing this out, I was not aware that the word could be used this way. They are really quite different concepts.
      - matchu 11y ago
        I'm not sure that they are. You just need to model the concept of state as the function's input/output, as functional programmers are eager to do :) If we start in state x, then apply operation f, the resulting state is f(x). If we apply operation f again, we'll be in state f(f(x)). If f is idempotent, then state f(x) and state f(f(x)) are identical.
    - blt 11y ago
      They are analogous if you represent side effects like this: new_state = f(old_state, x) then an idempotent operation is f(f(state, x), x) == f(state, x) In the context of drawing windows: draw(draw(fbuf, wnd, x, y), wnd, x, y) == draw(fbuf, wnd, x, y) but this is of course false if you allow alpha channel transparency...
unoti 11y ago
The big idea from old school windows that is shared with Flux is the idea of little views that render themselves and manage their own state. In Windows we called those Controls or Window Classes. It is a good idea, and one worthy of preserving.
- 49531 11y ago
  This is what I think is important. A lot of Flux's ideas aren't new. Something doesn't have to be new to be good.
- gcb0 11y ago
  but on windows each had only their designated space. on react, if one widget mess up with another's DOM, all hell break lose. ...maybe similarly to silly applications abusing the under documented windows api to do thinks like have a special skin instead of the normal windows shell.
- Too 11y ago
  I haven't used a single GUI framework that doesn't have the concept of User Controls. It's not a big idea, it's the obvious thing to do.
  - unoti 11y ago
    If you've ever created a user interface in HTML, you've used something that does not have the concept of user controls. Let's say that I want to make a numeric entry user control for entering numbers on a touch screen. This control will be made up of a collection of built-in UI controls that will work together to do what I need: let's say a text field, a couple of up and down buttons, an always-visible keypad, and a little slider that lets us move between min and max. In most HTML-based systems, it's not a built-in or natural thing to have such a self-contained "User Control" that I can just plop in to my user interface in 25 different places and have it manage itself, and the interaction between its own sub-components. Django, for example, completely lacks such a concept (although TurboGears does have it). This is a first class concept in classic Windows programming, and also in Flux-- although it's missing from most web-based systems.
iMark 11y ago
I've only looked into iOS programming a little, but is this not similar to how views are handled there too?
jxm262 11y ago
This was an awesome read. We use React and Flux daily at work so I'm going to share this with coworkers. I'm a little confused on what the author's concern is though. > I’ve just felt…well, weird. Something seemed off Is there anything substantively wrong with the flux pattern or drawbacks?
- deleted 11y ago
  [deleted]
- toddsiegel 11y ago
  I agree. He does not say. That it's an old pattern is probably a testament to its strength. I am using React/Flux (Redux) as well. I generally love it and find it easy to write dynamic UIs and without making very many mistakes. Each React and Flux component is small, focused, testable, and easy to reason about. The only gripes I have are the small amounts of boilerplate I end up with. Redux cuts this down a lot over a homebrewed Flux implementation I wrote. Also, testing complex trees of components can be a bit of a drag.
- gecko 11y ago
  EDIT: I changed that paragraph; thanks for pointing out it no longer fit with the rest of the post. Original comment: The weakness of typing in the switch blocks. I'll alter that sentence a bit; it's a leftover from an earlier version of that article where I was going to focus very narrowly on how uMsg/wParam/lParam, like the way actions are usually done in Flux apps, are decoupled to the point where it's very easy to make typing errors. Then I described why I thought they were similar to begin with, and then axed most of the original post when the entire thing switched to showing how Flux is an old pattern we've done before. I'll see if I can tweak that sentence in a way that keeps the flow going.
  - DougBTX 11y ago
    Using TypeScript's user defined type guards instead of a switch looks promising here, inside the 'if' the actions are type checked.
jsprogrammer 11y ago
And Node is essentially the Windows message loop [0]. [0] https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Wind...
- amelius 11y ago
  Yes, phrased differently, asynchronous programming is like non-preemptive (cooperative) multitasking from the Windows 3.1 era.
Todd 11y ago
I've also observed this similarity. The msg is like the actionType, the wParam and/or lParam are like the polymorphic objects that you pass with your action. The dispatcher is also not the most efficient model, where every store is registered to listen to every event. This is a bit like multiple windows on an event loop. The difference is that in Windows, messages are almost always targeted to a particular window's handle (hwnd). This doesn't make sense in Flux, since it's more of an observer pattern. The logic of interpreting the meaning of an action is left to each store, which is really just a cache. The biggest problem I have with Flux relates to this polymophism. I use TypeScript where possible and this is the one place where it always breaks down. I understand the appeal of JS objects but the only way to ensure your Flux based system is stable is to have lots of unit tests around your actions and stores. Redux is a more straightforward take on caching. I can also use type annotations on the reducers and associated store structure, so this helps ensure structural consistency. It also solves the isomorphism problem of server side rendering because each request can get its own state. There is no out of the box solution for this with Flux, since stores are singletons by default. Minor nit: stores are just caches with observers. I'm not sure why they weren't just called caches.
- tracker1 11y ago
  I like how Redux is a pretty simple distillation of some flux concepts... In the end, I think it comes down to application scale. The "new" way of mutating models based on OO classes that tend to contain any given amount of logic tends to be much harder to reason with as you add features. More features means a linear to exponential growth in complexity and risk of side effects. With one-way workflows combined with immutable state, and idempotent components, it's much easier to log/replay/test any given scenario.
dustingetz 11y ago
The author does not understand React :( > React by itself doesn’t actually solve how to propagate changes It does actually - you update the state, then React propogates the changes for you through it's props mechanism. Flux is an extra layer of indirection over state changes if you need it: https://twitter.com/floydophone/status/649786438330945536 https://twitter.com/floydophone/status/649786438330945536 (edit: I regret my tone here, there is clearly ongoing work in this area and no widely accepted best practice yet) Flux is not message passing, React components do not redraw themselves, React components do not pass messages to each other, Flux only superficially looks like winapi because of the switch statement in that particular example. React provides the view as a function of state. winapi is nothing like that. React is a giant step towards functional programming. winapi is definitely nothing like that. edit: Windows -> winapi
- Aleman360 11y ago
  > React is a giant step towards functional programming. Windows is definitely nothing like that. Err, that's not entirely true for MVVM apps, where views are just declarative markup that are rendered (retained mode) based on logical state provided by data bindings. It's been like that ever since XAML was introduced in 2006.
  - dustingetz 11y ago
    MVVM makes ubiquitous use of mutable state which means model change listeners, callbacks calling callbacks etc, FP/React is about using immutable state to dodge all these problems by design. http://www.dustingetz.com/2013/09/12/comparison-knockout-angular-react.html http://www.dustingetz.com/2013/09/12/comparison-knockout-ang...
    - Aleman360 11y ago
      The point is that in both React and XAML apps, you (usually) don't write code to mutate the View. In your code, the View is just a declarative construct. There's nothing stopping you from making immutable ViewModels in MVVM, other than bad perf (which React would presumably also suffer from on larger apps).
jowiar 11y ago
As someone who has written several things with Flux and Flux-esque architecture, I see it as a step in the middle, rather than where things are ending. It's not a large step from Flux (Stores update themselves in response to actions) to Redux (Model the entire application as reducers on a sequence of Actions) to RxJS Observables. What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about, model, and simulate than 2-way data flow. Everything else is semantics.
- marknutter 11y ago
  > What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about It makes some things a whole lot "easier to reason about" (so sick of that phrase), but other things not so "easy to reason about", like, for instance, error handling. Getting my head wrapped around the fact that asynchronous errors had to live in their own stores and be handled in the same way as all other data passed to the view was certainly not "easy" to reason about and still doesn't sit right with me to this day. You make concessions with every pattern and there is no silver bullet.
  - jowiar 11y ago
    I'm not saying easy to reason about in the sense of "easy to learn because it isn't a change from how we used to do things", but rather, in that it allows one to easily answer: - What is the current state of things? - How did we arrive at the current state of things? - What should the UI look like given the current state of things? It means that we can say: "Thing A happened, then Thing B happened, then Thing C happened". And then conceptualize "what should things look like after that chain of events". I've found this to make errors a whole lot easier about, because I don't need to piece together the state when an error happens -- just fire an action that says "An Error happened", then the stores figure out how to act accordingly. It's just another action.
- wangii 11y ago
  couldn't agree more. React makes unidirectional data flow mainstream first time in the history. it's the important bit.
mpweiher 11y ago
A couple of corrections: 1) Mac OS X does not store a bitmap for every widget, that's iOS's architecture. It stores a bitmap for every window. Having a layer (GPU-stored bitmap) was only introduced once CoreAnimation was ported to OS X. It was and is optional. 2) OS X Views also have a -drawRect: method that works the same way. 3) In fact that's how MVC works. See http://blog.metaobject.com/2015/04/model-widget-controller-mwc-aka-apple.html http://blog.metaobject.com/2015/04/model-widget-controller-m... And react and frameworks like it just duplicated this, see http://blog.metaobject.com/2015/04/reactnative-isn.html http://blog.metaobject.com/2015/04/reactnative-isn.html In fact, when I first read about react (non-native), my first thought was "hey, finally they came up with a good equivalent of NSView + drawRect:
- mwcampbell 11y ago
  Isn't drawRect: working at a different level of abstraction than React? In React, the view function constructs a virtual DOM tree, which can contain links, buttons, form fields, tables, etc. The equivalent on OS X would construct NSControls or NSCells, or objects that ultimately got translated into those, rather than just drawing on a canvas.
  - mpweiher 11y ago
    I saw this as react choosing the obvious way to implement drawRect: inside a browser: painting with HTML. You could easily have a "graphics context" that accepts high-level objects, or a variant of drawRect: that creates subviews and then tells those subviews to draw themselves. I don't see this as being fundamentally/structurally different, though there is a slight difference in the implementation.
amelius 11y ago
Stated more simply, React is just like "rebooting" your computer after you have changed the config files. It is, in this respect, quite ancient technology, except that the framework hits the "reset" button for you.
pducks32 11y ago
See I think Flux is too low-level. I think it's too hard to reason about from the top level. Not that the architecture is inherently bad—people are using it a ton–but that things get out of hand way to fast. Regardless I can't wait to see web development in a year!
- avodonosov 11y ago
  Let's try to predict what it will look like? My guess: Borland Delphi.
  - porker 11y ago
    I really hope so.
    - TimJYoung 11y ago
      Our product, Elevate Web Builder, is essentially that: Delphi for web development. http://www.elevatesoft.com/products?category=ewb&type=web http://www.elevatesoft.com/products?category=ewb&type=web
thewarrior 11y ago
Which is the best model to date for complex UI ? Cocoa + Interface Builder or XAML/WPF ? Have used Cocoa + Interface Builder and its quite a joy compared to web dev. EDIT : Has some thoughts on this : http://stackoverflow.com/questions/2442340/how-does-cocoa-compare-to-microsoft-qt http://stackoverflow.com/questions/2442340/how-does-cocoa-co...
- gecko 11y ago
  I mean, both of those get things right. XAML/WPF tries to make the interface cleanly human editable in code, but is incredibly verbose, and the "can be human editable" constraint ends up being "is only human editable" pretty quickly. Interface Builder is a lot more intuitive and powerful, but it's more of an all-or-nothing affair, in my opinion. Beyond that, though, they have way more in common than they do different. I'm not sure it makes sense to talk of one of them as a better model than the other, versus maybe a better implementation of the same workflow.
  - thewarrior 11y ago
    According to http://stackoverflow.com/questions/2442340/how-does-cocoa-compare-to-microsoft-qt http://stackoverflow.com/questions/2442340/how-does-cocoa-co... WPF is better.
    - kybernetyk 11y ago
      Well, as there's no Cocoa on Windows and no WPF on OS X it doesn't really matter. Also that SO post reads a lot like "I can't stand Interface Builder" (which is understandable if you aren't prepare to embrace it). I find the Cocoa model of not having to do anything with XML far better for my sanity. But then again I guess there are people who prefer XML artistry to drawRect overriding. :)
underwater 11y ago
WndProc is how the windows manager communicates with Windows UI code. Flux is how the UI communicates actions back to the data layer of the application. They're completely different.
hoprocker 11y ago
I love the correlation between modern in-browser development and programming early personal computers. It's akin to how digital logic abstracts away the tyranny of E&M physics, but several layers higher, and this time just between instruction sets/runtimes. ChromeOS is kind of making this leap, but I really wonder when web browser ASICs (or equivalent) will start popping up.
avodonosov 11y ago
In this line of reinventing the wheel of UI programming in web dev, I am waiting for Borland Delphi reincarnation.
danellis 11y ago
I share the author's feeling of déjà vu. I feel like I've seen this article already. It was a comment posted on HN earlier today. It's kind of fascinating how someone's comment can get promoted to someone else's blog post in a few hours.
- j_s 11y ago
  https://news.ycombinator.com/item?id=10379749 https://news.ycombinator.com/item?id=10379749
- jessep 11y ago
  Just to note, it is the original commenter's blog, not stolen. @gecko wrote "And the comment is now a blog post with more context for those who were lucky enough never to write raw Windows code" https://news.ycombinator.com/item?id=10380508 https://news.ycombinator.com/item?id=10380508
narrator 11y ago
So what is Angular then? Angular seems to me to be more like an ORM for the view where there's dirty checking of the model and then update events are dispatched to the external system which is the DOM instead of the DB. Is there something similar in the GUI toolkit world?
- draw_down 11y ago
  Hmm, KVO perhaps?
- wmeddie 11y ago
  Angular is very similar to the MVVM style of GUI programming that's popular in Microsoft's XAML-based libraries (e.g. WPF, Silverlight, WinRT and now UWP). Which I think is interesting because that's where they ended up. Modern windows programming doesn't involve writing WndProc functions anymore.
- est 11y ago
  > So what is Angular then Angular is Adobe Flex Builder reborn. In fact it's created by the same guy
pducks32 11y ago
Does anyone know of a good place to learn about these different approaches. I find this so fascinating.
ajsharp 11y ago
There are some great things going on in React / Flux, but the part that needs to be emphasized about Flux, that Facebook doesn't address explicitly anywhere, and that most people eager to always be on the cutting edge will never admit, is that this stuff was designed to solve problems for very complex applications. Complexity is relative, and the solutions that reduce complexity and friction in the development process for Facebook may increase it for another organization. That is to say, Flux / React et al is by no means simple. Not even a little bit. But it probably simplified a lot of things for the Facebook team. However, YMMV for your 6 person startup engineering team.
- davidrusu 11y ago
  I'm convinced the complexity comes from the language, Flux/React are actually quite simple and I can put the core architecture together in under 50 loc of Elm.
  - marknutter 11y ago
    The complexity comes from stitching everything together. You choose your router, your flux library, your build tools, whether or not to use JSX, whether or not to write your CSS with Javascript, which fancy new React specific testing and mocking library you need to use, how to organize your project, what best practices you should follow, what gotchas you will encounter because of Reacts relative young age as an OOP library, etc. You will always have to deal with complexity, it just depends on what kind of complexity you are willing to stomach. Some people prefer to deal with the complexity of stitching things together, other people prefer to have things stitched together for them and deal with the complexity of many abstractions. Both are fine choices, and we will debate endlessly with each other over which approach is the best approach. (hint: neither are).
- sim0n 11y ago
  Facebook's Flux is pretty verbose and can be difficult to setup but similar libraries like Redux are very simple if you have prior JavaScript experience. React is also pretty simple when compared to libraries like Angular.
sovande 11y ago
The big dispatcher switch in Flux is eerily reminiscent of how we used to program AWT widgets back in Java 1.0 days. This architecture was improved greatly in Java 1.1 with a delegation model. If the history is to repeat itself, as the OP so eloquent argues for, then, if you want to see where flux will be going in the next couple of years, start using knockout.js now and for once stay ahead of the curve.
jesstaa 11y ago
Also, Ruby on Rails is Flux.
antoaravinth 11y ago
What a great article. I was asking in my previous thread, what framework should I use React/Angular : https://news.ycombinator.com/item?id=10359497 https://news.ycombinator.com/item?id=10359497 Clearly from what I have heard from HN and from this blog post is React with Flux is just the old of doing web development today! Thats great!
geowa4 11y ago
I've never liked the comparison of Flux to functional reactive programming. It's really just good ol' object-oriented design. Actions are akin to the Command pattern and the Dispatcher feels like a Mediator. Passing callbacks instead of objects and making a mostly directed graph does not yield FRP. In my latest project, I used React with rx-react (https://github.com/fdecampredon/rx-react https://github.com/fdecampredon/rx-react) and RxJS. That combination definitely made for some FRP fun.

532 points by gecko 11y ago

Stemmed from this comment chain: https://news.ycombinator.com/item?id=10379199&goto=item%3Fid%3D10378684 https://news.ycombinator.com/item?id=10379199&goto=item%3Fid...

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?

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.

whatever_dude 11y ago

The writer really likes the word "idempotent".

tobr 11y ago
And uses it incorrectly. Idempotence is when f(f(x)) == f(x). React views take some props and/or state and return a component, so applying the view to its output would just give an error. I think the word he's looking for is "pure". EDIT: I was wrong - apparently "idempotent" can also describe a consistent relationship between the input and some state. In that sense, it's actually a very good description of how the input to a React view affects the DOM.
- kgen 11y ago
  Well, even in Wikipedia, the definition is quoted as being different for CS vs the unary operation you describe. "In computer science, the term idempotent is used more comprehensively to describe an operation that will produce the same results if executed once or multiple times." Which is more that f(x) == f(x) == f(x) for the state affected by f.
  - tobr 11y ago
    Thank you for pointing this out, I was not aware that the word could be used this way. They are really quite different concepts.
    - matchu 11y ago
      I'm not sure that they are. You just need to model the concept of state as the function's input/output, as functional programmers are eager to do :) If we start in state x, then apply operation f, the resulting state is f(x). If we apply operation f again, we'll be in state f(f(x)). If f is idempotent, then state f(x) and state f(f(x)) are identical.
  - blt 11y ago
    They are analogous if you represent side effects like this: new_state = f(old_state, x) then an idempotent operation is f(f(state, x), x) == f(state, x) In the context of drawing windows: draw(draw(fbuf, wnd, x, y), wnd, x, y) == draw(fbuf, wnd, x, y) but this is of course false if you allow alpha channel transparency...

unoti 11y ago

The big idea from old school windows that is shared with Flux is the idea of little views that render themselves and manage their own state. In Windows we called those Controls or Window Classes. It is a good idea, and one worthy of preserving.

49531 11y ago
This is what I think is important. A lot of Flux's ideas aren't new. Something doesn't have to be new to be good.
gcb0 11y ago
but on windows each had only their designated space. on react, if one widget mess up with another's DOM, all hell break lose. ...maybe similarly to silly applications abusing the under documented windows api to do thinks like have a special skin instead of the normal windows shell.
Too 11y ago
I haven't used a single GUI framework that doesn't have the concept of User Controls. It's not a big idea, it's the obvious thing to do.
- unoti 11y ago
  If you've ever created a user interface in HTML, you've used something that does not have the concept of user controls. Let's say that I want to make a numeric entry user control for entering numbers on a touch screen. This control will be made up of a collection of built-in UI controls that will work together to do what I need: let's say a text field, a couple of up and down buttons, an always-visible keypad, and a little slider that lets us move between min and max. In most HTML-based systems, it's not a built-in or natural thing to have such a self-contained "User Control" that I can just plop in to my user interface in 25 different places and have it manage itself, and the interaction between its own sub-components. Django, for example, completely lacks such a concept (although TurboGears does have it). This is a first class concept in classic Windows programming, and also in Flux-- although it's missing from most web-based systems.

iMark 11y ago

I've only looked into iOS programming a little, but is this not similar to how views are handled there too?

jxm262 11y ago

This was an awesome read. We use React and Flux daily at work so I'm going to share this with coworkers. I'm a little confused on what the author's concern is though. > I’ve just felt…well, weird. Something seemed off Is there anything substantively wrong with the flux pattern or drawbacks?

deleted 11y ago
[deleted]
toddsiegel 11y ago
I agree. He does not say. That it's an old pattern is probably a testament to its strength. I am using React/Flux (Redux) as well. I generally love it and find it easy to write dynamic UIs and without making very many mistakes. Each React and Flux component is small, focused, testable, and easy to reason about. The only gripes I have are the small amounts of boilerplate I end up with. Redux cuts this down a lot over a homebrewed Flux implementation I wrote. Also, testing complex trees of components can be a bit of a drag.
gecko 11y ago
EDIT: I changed that paragraph; thanks for pointing out it no longer fit with the rest of the post. Original comment: The weakness of typing in the switch blocks. I'll alter that sentence a bit; it's a leftover from an earlier version of that article where I was going to focus very narrowly on how uMsg/wParam/lParam, like the way actions are usually done in Flux apps, are decoupled to the point where it's very easy to make typing errors. Then I described why I thought they were similar to begin with, and then axed most of the original post when the entire thing switched to showing how Flux is an old pattern we've done before. I'll see if I can tweak that sentence in a way that keeps the flow going.
- DougBTX 11y ago
  Using TypeScript's user defined type guards instead of a switch looks promising here, inside the 'if' the actions are type checked.

jsprogrammer 11y ago

And Node is essentially the Windows message loop [0]. [0] https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Wind...

amelius 11y ago
Yes, phrased differently, asynchronous programming is like non-preemptive (cooperative) multitasking from the Windows 3.1 era.

Todd 11y ago

I've also observed this similarity. The msg is like the actionType, the wParam and/or lParam are like the polymorphic objects that you pass with your action. The dispatcher is also not the most efficient model, where every store is registered to listen to every event. This is a bit like multiple windows on an event loop. The difference is that in Windows, messages are almost always targeted to a particular window's handle (hwnd). This doesn't make sense in Flux, since it's more of an observer pattern. The logic of interpreting the meaning of an action is left to each store, which is really just a cache. The biggest problem I have with Flux relates to this polymophism. I use TypeScript where possible and this is the one place where it always breaks down. I understand the appeal of JS objects but the only way to ensure your Flux based system is stable is to have lots of unit tests around your actions and stores. Redux is a more straightforward take on caching. I can also use type annotations on the reducers and associated store structure, so this helps ensure structural consistency. It also solves the isomorphism problem of server side rendering because each request can get its own state. There is no out of the box solution for this with Flux, since stores are singletons by default. Minor nit: stores are just caches with observers. I'm not sure why they weren't just called caches.

tracker1 11y ago
I like how Redux is a pretty simple distillation of some flux concepts... In the end, I think it comes down to application scale. The "new" way of mutating models based on OO classes that tend to contain any given amount of logic tends to be much harder to reason with as you add features. More features means a linear to exponential growth in complexity and risk of side effects. With one-way workflows combined with immutable state, and idempotent components, it's much easier to log/replay/test any given scenario.

dustingetz 11y ago

The author does not understand React :( > React by itself doesn’t actually solve how to propagate changes It does actually - you update the state, then React propogates the changes for you through it's props mechanism. Flux is an extra layer of indirection over state changes if you need it: https://twitter.com/floydophone/status/649786438330945536 https://twitter.com/floydophone/status/649786438330945536 (edit: I regret my tone here, there is clearly ongoing work in this area and no widely accepted best practice yet) Flux is not message passing, React components do not redraw themselves, React components do not pass messages to each other, Flux only superficially looks like winapi because of the switch statement in that particular example. React provides the view as a function of state. winapi is nothing like that. React is a giant step towards functional programming. winapi is definitely nothing like that. edit: Windows -> winapi

Aleman360 11y ago
> React is a giant step towards functional programming. Windows is definitely nothing like that. Err, that's not entirely true for MVVM apps, where views are just declarative markup that are rendered (retained mode) based on logical state provided by data bindings. It's been like that ever since XAML was introduced in 2006.
- dustingetz 11y ago
  MVVM makes ubiquitous use of mutable state which means model change listeners, callbacks calling callbacks etc, FP/React is about using immutable state to dodge all these problems by design. http://www.dustingetz.com/2013/09/12/comparison-knockout-angular-react.html http://www.dustingetz.com/2013/09/12/comparison-knockout-ang...
  - Aleman360 11y ago
    The point is that in both React and XAML apps, you (usually) don't write code to mutate the View. In your code, the View is just a declarative construct. There's nothing stopping you from making immutable ViewModels in MVVM, other than bad perf (which React would presumably also suffer from on larger apps).

jowiar 11y ago

As someone who has written several things with Flux and Flux-esque architecture, I see it as a step in the middle, rather than where things are ending. It's not a large step from Flux (Stores update themselves in response to actions) to Redux (Model the entire application as reducers on a sequence of Actions) to RxJS Observables. What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about, model, and simulate than 2-way data flow. Everything else is semantics.

marknutter 11y ago
> What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about It makes some things a whole lot "easier to reason about" (so sick of that phrase), but other things not so "easy to reason about", like, for instance, error handling. Getting my head wrapped around the fact that asynchronous errors had to live in their own stores and be handled in the same way as all other data passed to the view was certainly not "easy" to reason about and still doesn't sit right with me to this day. You make concessions with every pattern and there is no silver bullet.
- jowiar 11y ago
  I'm not saying easy to reason about in the sense of "easy to learn because it isn't a change from how we used to do things", but rather, in that it allows one to easily answer: - What is the current state of things? - How did we arrive at the current state of things? - What should the UI look like given the current state of things? It means that we can say: "Thing A happened, then Thing B happened, then Thing C happened". And then conceptualize "what should things look like after that chain of events". I've found this to make errors a whole lot easier about, because I don't need to piece together the state when an error happens -- just fire an action that says "An Error happened", then the stores figure out how to act accordingly. It's just another action.
wangii 11y ago
couldn't agree more. React makes unidirectional data flow mainstream first time in the history. it's the important bit.

mpweiher 11y ago

A couple of corrections: 1) Mac OS X does not store a bitmap for every widget, that's iOS's architecture. It stores a bitmap for every window. Having a layer (GPU-stored bitmap) was only introduced once CoreAnimation was ported to OS X. It was and is optional. 2) OS X Views also have a -drawRect: method that works the same way. 3) In fact that's how MVC works. See http://blog.metaobject.com/2015/04/model-widget-controller-mwc-aka-apple.html http://blog.metaobject.com/2015/04/model-widget-controller-m... And react and frameworks like it just duplicated this, see http://blog.metaobject.com/2015/04/reactnative-isn.html http://blog.metaobject.com/2015/04/reactnative-isn.html In fact, when I first read about react (non-native), my first thought was "hey, finally they came up with a good equivalent of NSView + drawRect:

mwcampbell 11y ago
Isn't drawRect: working at a different level of abstraction than React? In React, the view function constructs a virtual DOM tree, which can contain links, buttons, form fields, tables, etc. The equivalent on OS X would construct NSControls or NSCells, or objects that ultimately got translated into those, rather than just drawing on a canvas.
- mpweiher 11y ago
  I saw this as react choosing the obvious way to implement drawRect: inside a browser: painting with HTML. You could easily have a "graphics context" that accepts high-level objects, or a variant of drawRect: that creates subviews and then tells those subviews to draw themselves. I don't see this as being fundamentally/structurally different, though there is a slight difference in the implementation.

amelius 11y ago

Stated more simply, React is just like "rebooting" your computer after you have changed the config files. It is, in this respect, quite ancient technology, except that the framework hits the "reset" button for you.

pducks32 11y ago

See I think Flux is too low-level. I think it's too hard to reason about from the top level. Not that the architecture is inherently bad—people are using it a ton–but that things get out of hand way to fast. Regardless I can't wait to see web development in a year!

avodonosov 11y ago
Let's try to predict what it will look like? My guess: Borland Delphi.
- porker 11y ago
  I really hope so.
  - TimJYoung 11y ago
    Our product, Elevate Web Builder, is essentially that: Delphi for web development. http://www.elevatesoft.com/products?category=ewb&type=web http://www.elevatesoft.com/products?category=ewb&type=web

thewarrior 11y ago

Which is the best model to date for complex UI ? Cocoa + Interface Builder or XAML/WPF ? Have used Cocoa + Interface Builder and its quite a joy compared to web dev. EDIT : Has some thoughts on this : http://stackoverflow.com/questions/2442340/how-does-cocoa-compare-to-microsoft-qt http://stackoverflow.com/questions/2442340/how-does-cocoa-co...

gecko 11y ago
I mean, both of those get things right. XAML/WPF tries to make the interface cleanly human editable in code, but is incredibly verbose, and the "can be human editable" constraint ends up being "is only human editable" pretty quickly. Interface Builder is a lot more intuitive and powerful, but it's more of an all-or-nothing affair, in my opinion. Beyond that, though, they have way more in common than they do different. I'm not sure it makes sense to talk of one of them as a better model than the other, versus maybe a better implementation of the same workflow.
- thewarrior 11y ago
  According to http://stackoverflow.com/questions/2442340/how-does-cocoa-compare-to-microsoft-qt http://stackoverflow.com/questions/2442340/how-does-cocoa-co... WPF is better.
  - kybernetyk 11y ago
    Well, as there's no Cocoa on Windows and no WPF on OS X it doesn't really matter. Also that SO post reads a lot like "I can't stand Interface Builder" (which is understandable if you aren't prepare to embrace it). I find the Cocoa model of not having to do anything with XML far better for my sanity. But then again I guess there are people who prefer XML artistry to drawRect overriding. :)

underwater 11y ago

WndProc is how the windows manager communicates with Windows UI code. Flux is how the UI communicates actions back to the data layer of the application. They're completely different.

hoprocker 11y ago

I love the correlation between modern in-browser development and programming early personal computers. It's akin to how digital logic abstracts away the tyranny of E&M physics, but several layers higher, and this time just between instruction sets/runtimes. ChromeOS is kind of making this leap, but I really wonder when web browser ASICs (or equivalent) will start popping up.

avodonosov 11y ago

In this line of reinventing the wheel of UI programming in web dev, I am waiting for Borland Delphi reincarnation.

danellis 11y ago

I share the author's feeling of déjà vu. I feel like I've seen this article already. It was a comment posted on HN earlier today. It's kind of fascinating how someone's comment can get promoted to someone else's blog post in a few hours.

j_s 11y ago
https://news.ycombinator.com/item?id=10379749 https://news.ycombinator.com/item?id=10379749
jessep 11y ago
Just to note, it is the original commenter's blog, not stolen. @gecko wrote "And the comment is now a blog post with more context for those who were lucky enough never to write raw Windows code" https://news.ycombinator.com/item?id=10380508 https://news.ycombinator.com/item?id=10380508

narrator 11y ago

So what is Angular then? Angular seems to me to be more like an ORM for the view where there's dirty checking of the model and then update events are dispatched to the external system which is the DOM instead of the DB. Is there something similar in the GUI toolkit world?

draw_down 11y ago
Hmm, KVO perhaps?
wmeddie 11y ago
Angular is very similar to the MVVM style of GUI programming that's popular in Microsoft's XAML-based libraries (e.g. WPF, Silverlight, WinRT and now UWP). Which I think is interesting because that's where they ended up. Modern windows programming doesn't involve writing WndProc functions anymore.
est 11y ago
> So what is Angular then Angular is Adobe Flex Builder reborn. In fact it's created by the same guy

pducks32 11y ago

Does anyone know of a good place to learn about these different approaches. I find this so fascinating.

ajsharp 11y ago

There are some great things going on in React / Flux, but the part that needs to be emphasized about Flux, that Facebook doesn't address explicitly anywhere, and that most people eager to always be on the cutting edge will never admit, is that this stuff was designed to solve problems for very complex applications. Complexity is relative, and the solutions that reduce complexity and friction in the development process for Facebook may increase it for another organization. That is to say, Flux / React et al is by no means simple. Not even a little bit. But it probably simplified a lot of things for the Facebook team. However, YMMV for your 6 person startup engineering team.

davidrusu 11y ago
I'm convinced the complexity comes from the language, Flux/React are actually quite simple and I can put the core architecture together in under 50 loc of Elm.
- marknutter 11y ago
  The complexity comes from stitching everything together. You choose your router, your flux library, your build tools, whether or not to use JSX, whether or not to write your CSS with Javascript, which fancy new React specific testing and mocking library you need to use, how to organize your project, what best practices you should follow, what gotchas you will encounter because of Reacts relative young age as an OOP library, etc. You will always have to deal with complexity, it just depends on what kind of complexity you are willing to stomach. Some people prefer to deal with the complexity of stitching things together, other people prefer to have things stitched together for them and deal with the complexity of many abstractions. Both are fine choices, and we will debate endlessly with each other over which approach is the best approach. (hint: neither are).
sim0n 11y ago
Facebook's Flux is pretty verbose and can be difficult to setup but similar libraries like Redux are very simple if you have prior JavaScript experience. React is also pretty simple when compared to libraries like Angular.

sovande 11y ago

The big dispatcher switch in Flux is eerily reminiscent of how we used to program AWT widgets back in Java 1.0 days. This architecture was improved greatly in Java 1.1 with a delegation model. If the history is to repeat itself, as the OP so eloquent argues for, then, if you want to see where flux will be going in the next couple of years, start using knockout.js now and for once stay ahead of the curve.

jesstaa 11y ago

Also, Ruby on Rails is Flux.

antoaravinth 11y ago

What a great article. I was asking in my previous thread, what framework should I use React/Angular : https://news.ycombinator.com/item?id=10359497 https://news.ycombinator.com/item?id=10359497 Clearly from what I have heard from HN and from this blog post is React with Flux is just the old of doing web development today! Thats great!

geowa4 11y ago

I've never liked the comparison of Flux to functional reactive programming. It's really just good ol' object-oriented design. Actions are akin to the Command pattern and the Dispatcher feels like a Mediator. Passing callbacks instead of objects and making a mostly directed graph does not yield FRP. In my latest project, I used React with rx-react (https://github.com/fdecampredon/rx-react https://github.com/fdecampredon/rx-react) and RxJS. That combination definitely made for some FRP fun.