You can't get away from mutable state. Redux, for example, just hides the big `state = newState` mutation but it's still very much there. When a library/framework uses mutable state, it's not that they're saying immutability is an anti-feature. They're just being pragmatic in the sense that mutation has to happen anyways and they consider explicit to be better than implicit. (With that said, some people do argue that immutable JS is in fact an anti-pattern because JS doesn't really lend itself to idiomatic performant immutability in the first place and emulating it as an abstraction adds a lot of unwanted complexity)
IMHO, it's a disservice to yourself to just blindly drink the immutable koolaid without understanding the very real drawbacks it comes with in JS-land. There's a great deal of gray area where explicit mutation is perfectly adequate in ways that overzealous immutability might be counterproductive.
you're arguing based on a very mechanical understanding of why immutable state is important. Immutability is just a solution to the actual goal which is controlled side effect as someone put in the other comment.
Given a side effect (a piece of data is mutated), I need to know what code caused it and when. When you casually throw assign statements everywhere that question becomes really hard to answer.
Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tree nodes because Context or whatever). Svelte reactivity generally only staying within a single file (with some exceptions) is one approach to align system limitations with "pit of success" in a way that happens to use explicit mutation idioms.
> Discoverability is a function of colocation, not of immutability
That's one way to do it, tying discoverability to coding convention (which is usually how collocation is enforced), as opposed to being an inherent property of the code.
could you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation.
The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.
> it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature"
Mutating state is actually the de-facto standard across most of the industry. Look at Vue or iOS or Android or Unity or Rails or J2EE... People literally use ORMs to make things more mutable than SQL.
Yes, you can use React setState, but surely it's not lost on you that this is wrapping over a lot of mutable operations too? Worth mentioning as well that setState semantics have some amount of complexity that is attributable to mutability leaking out of the immutability abstraction (e.g. the callback argument, what happens when things like multiple calls to setState occur synchronously, etc). This is the "curse of abstraction" that comes when you are trying to implement semantics that don't exist natively and the abstraction themselves have semantic weaknesses due to the chicken-and-egg problem of the required semantics not existing natively.
again with the mechanical definition of mutability. Ok "controlled" is the word, as I mentioned in other comment state encapsulation (which ORM is) is another solution for this.
These giant monstrosities are really easy to avoid. Redux Actions make locating a state change a breeze. I have worked on giant applications that did not use a redux-like approach to state and it was a horrendous mess.
FWIW, I see a lot of codebases at work (I maintain a large org-wide monorepo), and you'd be surprised at how daunting real world codebases can get. I agree that it's relatively easier to keep a codebase clean when the number of owners is small, but conversely, from my experience, when a codebase has multiple owners, keeping things organized can definitely be a challenge (in some cases I've seen, multiple teams owning overlapping sets of the codebase...)
I've seen codebases with messy redux and codebases with messy non-redux architectures, and conversely also clean codebases with both types of architecture. There really is no silver bullet technology. The "you can write cobol in any language" thing is always going to be a looming plague.
I think it's easy to get into a mess as an applications complexity increases regardless of which state management approach one chooses. Every paradigm has a trade off.
IMHO, it's a disservice to yourself to just blindly drink the immutable koolaid without understanding the very real drawbacks it comes with in JS-land. There's a great deal of gray area where explicit mutation is perfectly adequate in ways that overzealous immutability might be counterproductive.