- "respects your computer's memory and battery"
- "uses open file formats"
- "is scriptable"
Feels like we should also think about these kinds of things when we think about "organic" software. Kudos to the developer for these.
In Bike it's fast enough that when you scroll it just updates what you can see on the screen. This means you only pay memory for visible text. For most macOS apps scrolling performance is achieved by pre-rendering before and after the visible scroll area. So you pay for that cache and you also pay for the background processing required by pre-rendering.
Also consider simple things like window resize. In Bike that only effects visible text. If you open a large document in TextEdit you will see that resize is quite slow and processor and memory intensive. (you can test with https://www.hogbaysoftware.com/posts/moby-dick-workout/). And then after that resize there's lots of background processing to refill a bunch of layout caches I guess. On the other hand resize is instant and only does work for visible text in Bike.
I don't think the animations are expensive, but it's hard to test because that work happens in Mac OS window server and I'm not an expert there. If they really are a problem and you are on battery then you can turn off animations in preferences.
https://arstechnica.com/gadgets/2007/10/mac-os-x-10-5/8/
Of note:
> [The] advent of Core Animation probably means that we'll have to endure some amount of gratuitously animated software created by "overly enthusiastic" developers. But the same was true during the introduction of styled text and color graphics. Mac developers learn quickly, and Mac users are good at rewarding restraint and punishing excess.
There’s a similar story around SwiftUI. It was initially created by the Apple Watch team at Apple, then extended to all the other OSes (all this was long before it was made public).