Regarding the no-spinners: I think it is the wrong approach to argue that just because you have data locally, you don't need any spinners.
Whether you need a spinner or not should be decided by the User Experience (e.g., when the user has to wait for more than 100ms, show a spinner), and not by the location of the data. I am a big fan of local-first apps and enjoy building them myself. However, sometimes your app takes a moment to load. With local-first, you eliminate the network as a source of delays, but there are other factors as well, such as large data sets or complex algorithms.
For example, when you have a project planning software and want to plan 100 work packages with multiple resource combinations in an optimal way, depending on the algorithm, this can take some time. In that case, a spinner or a progress bar is a good thing.
I didn’t get the impression that the author is advocating for removing spinners as a UI concept, rather it’s just being used a shorthand for, “you should not need to send and load the data to and from elsewhere while you are working.”
A properly designed app would leverage multi threading to place any long running jobs in the background, allowing the user to carry on with other tasks.
Spinners should not exist in a local first app.
Agreed. No loading spinners is a good goal, but processing spinners might be unavoidable.