This is a very confused statement to be made, specially after the last decade where React established itself as the de facto way of writing any and every SPA.
Is it yet another example of "there are only two kinds of languages: the ones people complain about and the ones nobody uses."
I think the universe of SPAs that should exist is far smaller than the universe of SPAs that does exist, and the hype around react is largely to blame.
> I think the universe of SPAs that should exist is far smaller than the universe of SPAs that does exist (...)
That's a pointless thing to say. Your personal opinion on how people should not use a technology weights nothing on a discussion on how the whole industry actually use said technology. For that to hold any value, first you would need to argue that you know better than the entire industry put together, which would be quite the claim. Occam's razor doesn't favor your statement.
> the ones people complain about and the ones nobody uses
The funny thing is that prior to 2015 "the ones nobody uses" were the academically-designed ivory tower FP languages; perpetually relegated to being a minority curiosity because FP is immensely difficult to wrap one's head around at first, especially if all you've-ever-known was imperative C or VB and (compromised) OOP in Java and C#.
I remember when Google's overqualified design-team for Angular decided that Angular2+ is too good for Promise-based fetch() - instead everyone should be forced to learn RxJS's way-of-doing-things - cue the agony, wailing and the gnashing of teeth.
...I think being forced to live through that experience did 2 things:
1) It forced an entire generation of front-end web-devs (and VB6 refugees) to get familiar with FP-like concepts.
2) It also made those same front-end web-devs swear-off ever using a Google-maintained SPA framework in future.
...which set the stage for the mass-adoption of ReactJS:
1) It made effective use of FP concepts, which many devs were now accustomed-to after having survived Angular2.
React is more of a plague than a wonderful downstream effect or mixed bag. It’s essentially cemented Js as the way to build a website even if you don’t need the complexity. It is the leader in brain dead Js evangelism.
Credit where credit is due, though: ReactJS became #1 on its merits.
...yes, Redux (not React) deserves to be #1, but Redux isn't a complete, all-under-one-roof framework the way React is; but regardless of that: The Redux/React approach is just fundamentally a better design than what we had before: stateful-controls/widgets and two-way data-binding.
If you'd like to relive how UI devs suffered throughout the 1990s, 2000s, and most of the 2010s I invite you to try making a native Windows 11 desktop UI using WinUI3 using the MVVM (anti-) pattern: nothing but mutable objects of indeterminable state getting caught in infinite-loops or unbound recursion due to INotifyPropertyChanged - and Microsoft is still pretending that's the "right" way to build a UI.
Sorry am ranting on about something I have very little control over; it's just frustating.
> Redux only plays a role in adding syntactic sugar over React's support for reactive programming
Redux doesn't have anything to do with any kind of syntactic-sugar for Reac.
> the general guidelines are that you should only bother with Redux if your SPA is already considerably complex
If one already has an (non-React) SPA which is not already built following Redux then you're stuck with what you've got; it isn't really possible to take an existing SPA of any complexity and deciding to "make it use Redux" because it completely up-ends practically every aspect of SPA application-design, at least as far as how "traditional" (non-React) SPAs do things.
If you'll permit me to oversimplify: I tell people that React is a basically an opinionated Redux kernel wrapped around a JSX-based DOM+component/widget system (, which then means you now need a JS build system too); or conversely: Redux is like React, except without JSX components.
> If one already has an (non-React) SPA which is not already built following Redux then you're stuck with what you've got;
This is simply false and is outright wrong. This even goes against the most basic React+Redux guidelines. Dan Abramov, one of the creators of Redux, is quoted in Redux's FAQ:
> would like to amend this: don't use Redux until you have problems with vanilla React.
> it isn't really possible to take an existing SPA of any complexity and deciding to "make it use Redux"
Frankly, you sound as if you have absolutely zero experience with React. I know for a fact that a few flagship SPAs from a few companies, including some FANG webapps, do not use Redux.
I made several large Cocoa (macOS AppKit, Obj-C) apps in 2004-2018 using the classic Smalltalk-inspired MVC patterns and this was never a problem. Sometimes writing the controller boilerplate was boring, but at least there were no observer loops, it was simple to debug where things happened, and undo/redo were reliable to implement through the framework.
Maybe Microsoft just never was very good at these 1990s style GUIs?
This is a very confused statement to be made, specially after the last decade where React established itself as the de facto way of writing any and every SPA.
Is it yet another example of "there are only two kinds of languages: the ones people complain about and the ones nobody uses."