5 ms·

WPF was ahead of its time when it was released in 2006. It might have been the first to use data bindings and popularize the MVVM pattern. Web UI frameworks wer

WPF was ahead of its time when it was released in 2006. It might have been the first to use data bindings and popularize the MVVM pattern. Web UI frameworks were barely in existence and webpages typically didn't have that desktop-y/SPA feel. WPF was king for a while until web took over.

DaiPlusPlus 5y ago
Declarative data-binding wasn't anything new in WPF: it significantly postdates ASP.NET WebForms which had declarative data-binding, though, yes: the web doesn't count because web UIs aren't stateful in-memory on the server. I feel MVVM is an anti-pattern: it necessitates long-lifed mutable instance state (the object of the class of your view-model) which is much harder to reason about (for example, try updating a bunch of properties in response to another property getting updating), but for me, the worst part is the inability to differentiate or identify the source or origin of new data that appear in a property setter: it's very difficult to determine if a TextBox TextChanged event came from a user-initiated action, was set by another method in the class - or was a knock-on property change - because a property setter doesn't have an EventArgs parameter. This can cause ViewModel event-handlers to get caught-up in infinite-loops or at the very least sending large amounts of inconsequential and unnecessary event-messages around and invoking (potentially expensive) property-setters and getters. I still agree that MVVM was a huge improvement over simply subclassing widgets and windows like we do in WinForms, VB6, Delphi, and JWT/Swing - but all MVVM brings you is separation between UI and Business/Domain in name-only; your ViewModels are still inevitably going to end-up with dozens of new properties bound to sone arbitrary presentational XAML attributes. XAML alone is a decade past it’s time. It’s hugely verbose and is filled with so many gotchas (wanna bind a bool property to a control’s visible/hidden state? Not without an extra 50+ chars of binding params and value-converters). XAML also falls for the pitfall of assuming a GUI can always be modelled as a strict hierarchy of containers and controls. Overall, XAML feels like what the Microsoft of the mid-to-late 1990s wanted to turn HTML into. ——— I hope I don't sound like another React fanboy (and I personally use Redux, not React)- and I'll argue that modelling state as a history of immutable, almost serialized, state trees is fantastic for so many things - especially typical database/business application work, but it's also utterly inappropriate for so many other kinds of applications (like, you wouldn't serialize the entire state of a raster image of HTML <canvas>, or re-run an append-only list of drawing instructions (like PostScript/Windows Metafile) for Canvas 2D context or even WebGL - BUT overall the Reflux/Redux/React design of a strict one-way flow of data and state brings so much clarity and makes it easy to see how different components (even in an abstract sense) interact with each other: they don't! It really does force you into a better way of thinking about program code, state and flow. —— Not that it matters: Microsoft has completely dropped the ball on keeping the Win32 desktop dev-story alive. WinForms is uncool and terrible but there is no faster alternative for putting together a quick simple form in an EXE. If you use WPF you’d still be trying to get MahApps working, ----- > Web UI frameworks were barely in existence and webpages typically didn't have that desktop-y/SPA feel. WPF was king for a while until web took over 2005-2006 was after the start of "Web 2.0" and after AJAX had been established - but mostly: when Firefox had already been out for 2-3 years and for that companies that were willing to go all-in on Firefox for their users, they really could have have desktop-quality SPAs made using Firefox's massively superior support for modern CSS techniques that IE6 had avoided for over 5 years at that point - can you imagine Google not releasing a Chrome update for 5 years? So it was IE6's fault that better SPAs weren't around on the Internet - but it was also IE6's fault that so many companies had the 1990s near-equivalent of an SPA: ActiveX-heavy intranet sites that only worked in IE6. That point amuses me.
- acemarke 5y ago
  Hi, I'm a Redux maintainer. I'm always interested in hearing examples of Redux being used without React :) What are you using it for? Any particularly interesting problems you're solving with it, or pain points you've run into?
  - DaiPlusPlus 5y ago
    In .NET at least, I find the Redux design works better when Action objects are allowed to contain Delegates/Funcs to perform their state-mutation (state-progression?) instead of forcing a separation of Actions and Reducers.
    - acemarke 5y ago
      Hmm. I realize that the .NET world is different than JS, but that _is_ an anti-pattern for Redux usage - separation of "what happened" from "how the state is updated" is absolutely intentional: - https://redux.js.org/style-guide/style-guide#model-actions-as-events-not-setters https://redux.js.org/style-guide/style-guide#model-actions-a... - https://redux.js.org/style-guide/style-guide#put-as-much-logic-as-possible-in-reducers https://redux.js.org/style-guide/style-guide#put-as-much-log... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/#reducers-in-actions https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
      - DaiPlusPlus 5y ago
        > separation of "what happened" from "how the state is updated" is absolutely intentional In most projects I've worked on using Redux or Redux-style patterns (which, I'll admit is not a large number), keeping the separation didn't improve things, instead it added to more "fiddliness" and yo-yoing between files in the editor/IDE - this is especially the case when a project is iterating through changing project-requirements, especially for trivial actions/reducers. This only applies to cases where actions had a 1:1 mapping to reducers - and the bundled funcs were strictly pure-functions too, of course. But I stress that I'm not a Redux expert (blame my lack of experience) so I appreciate that I almost certainly have done something wrong, so I'd love to be able to have a Redux expert on-call who I could just ping on Slack and pose a very domain-specific question to and ask "what is the Redux-way(TM) of doing this?" instead of having to try to go through the very abstractly written (often past the point of comprehension) pages of official documentation, blog articles and the like and hope I'm doing things correctly (especially in non-JavaScript environments). ---- Obviously the biggest barrier to the adoption of the Redux-pattern in non-JS environments is other languages' syntactical hostility to immutable objects, especially immutable object construction. In OOP-family languages like C#, Java, etc it really is a significant burden to have to both define primary constructors and the logic for reconstituting an entirely new state-graph for actions that only make 1 small, tiny deeply-nested change.... across multiple deeply-nested objects. The next major burden is the extra workload involved to change all of the above when project-requirements change regularly. There are also associated problems with having to normalize the state-graph and how to handle back-references (as true immutable objects cannot have back-references to parent objects unless you add another layer of wrappers over the state graph, and now you see the problem...!). Also, remember that statically-typed languages are not going to get anything like JavaScript's spread-operator for a long, long time. It sounds horrible (if not being complete heresy), but having state exposed as read-only to components/consumers, while allowing state mutation in-place by actions, does result in a drastic simplification of logic (I can't really call them "reducers" at this point), while you do lose the "free" Undo/Redo bonus you gain much faster performance. The important thing is the strictly one-way flow of data within the application, which is preserved, as is determinism: replaying the same actions from the same initial state will still result in the same end result state. (I'm not strongly advocating for the above, I'm just saying that to non-Redux-experts like myself, compromises can and do have perceivable value; after-all, we aren't all working on the official Facebook mobile app).

DaiPlusPlus 5y ago

Declarative data-binding wasn't anything new in WPF: it significantly postdates ASP.NET WebForms which had declarative data-binding, though, yes: the web doesn't count because web UIs aren't stateful in-memory on the server. I feel MVVM is an anti-pattern: it necessitates long-lifed mutable instance state (the object of the class of your view-model) which is much harder to reason about (for example, try updating a bunch of properties in response to another property getting updating), but for me, the worst part is the inability to differentiate or identify the source or origin of new data that appear in a property setter: it's very difficult to determine if a TextBox TextChanged event came from a user-initiated action, was set by another method in the class - or was a knock-on property change - because a property setter doesn't have an EventArgs parameter. This can cause ViewModel event-handlers to get caught-up in infinite-loops or at the very least sending large amounts of inconsequential and unnecessary event-messages around and invoking (potentially expensive) property-setters and getters. I still agree that MVVM was a huge improvement over simply subclassing widgets and windows like we do in WinForms, VB6, Delphi, and JWT/Swing - but all MVVM brings you is separation between UI and Business/Domain in name-only; your ViewModels are still inevitably going to end-up with dozens of new properties bound to sone arbitrary presentational XAML attributes. XAML alone is a decade past it’s time. It’s hugely verbose and is filled with so many gotchas (wanna bind a bool property to a control’s visible/hidden state? Not without an extra 50+ chars of binding params and value-converters). XAML also falls for the pitfall of assuming a GUI can always be modelled as a strict hierarchy of containers and controls. Overall, XAML feels like what the Microsoft of the mid-to-late 1990s wanted to turn HTML into. ——— I hope I don't sound like another React fanboy (and I personally use Redux, not React)- and I'll argue that modelling state as a history of immutable, almost serialized, state trees is fantastic for so many things - especially typical database/business application work, but it's also utterly inappropriate for so many other kinds of applications (like, you wouldn't serialize the entire state of a raster image of HTML <canvas>, or re-run an append-only list of drawing instructions (like PostScript/Windows Metafile) for Canvas 2D context or even WebGL - BUT overall the Reflux/Redux/React design of a strict one-way flow of data and state brings so much clarity and makes it easy to see how different components (even in an abstract sense) interact with each other: they don't! It really does force you into a better way of thinking about program code, state and flow. —— Not that it matters: Microsoft has completely dropped the ball on keeping the Win32 desktop dev-story alive. WinForms is uncool and terrible but there is no faster alternative for putting together a quick simple form in an EXE. If you use WPF you’d still be trying to get MahApps working, ----- > Web UI frameworks were barely in existence and webpages typically didn't have that desktop-y/SPA feel. WPF was king for a while until web took over 2005-2006 was after the start of "Web 2.0" and after AJAX had been established - but mostly: when Firefox had already been out for 2-3 years and for that companies that were willing to go all-in on Firefox for their users, they really could have have desktop-quality SPAs made using Firefox's massively superior support for modern CSS techniques that IE6 had avoided for over 5 years at that point - can you imagine Google not releasing a Chrome update for 5 years? So it was IE6's fault that better SPAs weren't around on the Internet - but it was also IE6's fault that so many companies had the 1990s near-equivalent of an SPA: ActiveX-heavy intranet sites that only worked in IE6. That point amuses me.

acemarke 5y ago
Hi, I'm a Redux maintainer. I'm always interested in hearing examples of Redux being used without React :) What are you using it for? Any particularly interesting problems you're solving with it, or pain points you've run into?
- DaiPlusPlus 5y ago
  In .NET at least, I find the Redux design works better when Action objects are allowed to contain Delegates/Funcs to perform their state-mutation (state-progression?) instead of forcing a separation of Actions and Reducers.
  - acemarke 5y ago
    Hmm. I realize that the .NET world is different than JS, but that _is_ an anti-pattern for Redux usage - separation of "what happened" from "how the state is updated" is absolutely intentional: - https://redux.js.org/style-guide/style-guide#model-actions-as-events-not-setters https://redux.js.org/style-guide/style-guide#model-actions-a... - https://redux.js.org/style-guide/style-guide#put-as-much-logic-as-possible-in-reducers https://redux.js.org/style-guide/style-guide#put-as-much-log... - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/#reducers-in-actions https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
    - DaiPlusPlus 5y ago
      > separation of "what happened" from "how the state is updated" is absolutely intentional In most projects I've worked on using Redux or Redux-style patterns (which, I'll admit is not a large number), keeping the separation didn't improve things, instead it added to more "fiddliness" and yo-yoing between files in the editor/IDE - this is especially the case when a project is iterating through changing project-requirements, especially for trivial actions/reducers. This only applies to cases where actions had a 1:1 mapping to reducers - and the bundled funcs were strictly pure-functions too, of course. But I stress that I'm not a Redux expert (blame my lack of experience) so I appreciate that I almost certainly have done something wrong, so I'd love to be able to have a Redux expert on-call who I could just ping on Slack and pose a very domain-specific question to and ask "what is the Redux-way(TM) of doing this?" instead of having to try to go through the very abstractly written (often past the point of comprehension) pages of official documentation, blog articles and the like and hope I'm doing things correctly (especially in non-JavaScript environments). ---- Obviously the biggest barrier to the adoption of the Redux-pattern in non-JS environments is other languages' syntactical hostility to immutable objects, especially immutable object construction. In OOP-family languages like C#, Java, etc it really is a significant burden to have to both define primary constructors and the logic for reconstituting an entirely new state-graph for actions that only make 1 small, tiny deeply-nested change.... across multiple deeply-nested objects. The next major burden is the extra workload involved to change all of the above when project-requirements change regularly. There are also associated problems with having to normalize the state-graph and how to handle back-references (as true immutable objects cannot have back-references to parent objects unless you add another layer of wrappers over the state graph, and now you see the problem...!). Also, remember that statically-typed languages are not going to get anything like JavaScript's spread-operator for a long, long time. It sounds horrible (if not being complete heresy), but having state exposed as read-only to components/consumers, while allowing state mutation in-place by actions, does result in a drastic simplification of logic (I can't really call them "reducers" at this point), while you do lose the "free" Undo/Redo bonus you gain much faster performance. The important thing is the strictly one-way flow of data within the application, which is preserved, as is determinism: replaying the same actions from the same initial state will still result in the same end result state. (I'm not strongly advocating for the above, I'm just saying that to non-Redux-experts like myself, compromises can and do have perceivable value; after-all, we aren't all working on the official Facebook mobile app).