[kerkeslager]

This is a product short tenures: software developers switch jobs every 18 months on average, so they don't get to see the long-term effects of their decisions. This leads to decisions with big payoffs in the short term that come back to bite you in the long term. Some examples:

1. Pervasive, maximal frameworks that favor terse magic over clear explicitness. At first this allows you to spin up a website in a few lines of code, but years down the line you're spending all your time reverse-engineering a workaround for a bug in Ember 0.2 so you can implement the same functionality in Ember 17.3 when the controller that it referred to is no longer in the codebase and the naming convention for tying together models and views has changed twice.

2. 0.x versioned libraries which solve the problem you have today, but cause 100 problems tomorrow when the maintainer deletes the repo.

3. Global state, which lets you bypass having to pass data through to components until later when you want to have more than one component per page.

[Mathnerd314]

Global state is actually a good model, see https://awelonblue.wordpress.com/2012/10/21/local-state-is-p....

The issue is more one of fragmentation; figuring out which file(s) / method(s) are responsible for some item of state can get to be impossible without a powerful debugger, and constantly changing frameworks / libraries don't help.

[marcosdumay]

Whatever this article is talking about, it is not what most developers mean when they say "local state".

For a start, one does not persist "local state", and this is a clear give-away:

> state cannot be cheaply recomputed or regenerated like other live values

The author seems to be arguing against a global state encapsulated into a tree of disjoint accessors. And his solution:

> our programs become stateless logics manipulating a stateful substrate

Is verbatim the FP-way of avoiding working on global state.