> But I feel like I was substantially more productive after spending a (relatively) long time on the same stack.
That's obvious, although the "substantially" part is a bit vague. But it's still obviously true - you will be slower if you need to check the docs often, it's a given. But:
> I kind of want stick with one thing long enough to develop that again.
It should take just a few months at most. You'll get there much faster than you (I assume, sorry if I'm wrong) expect. :-)
Or is it that you're already many months after the switch, and you still feel that you're checking the docs very often and it slows you down? Maybe there's something wrong with the docs, then? Otherwise, you should probably try learning in a more structured manner, like reading a book or doing MOOC.
> But you could use the toolkit APIs blocking on a background thread, or integrated with the main event loop with a delegate object, or on the event loop with a callback block.
Exactly the same options are present in every general-purpose language. There are quirks, like Python and threading or JS and event-loop, but you get the choice of blocking/non-blocking, and later if the non-blocking is based on threads and synchronization or on an event loop (or coroutines, green threads, CSP, Actors, etc.) The only thing that changes is nomenclature, which for some reason language developers like to reinvent all the time.
> some ways are more verbose, some introduce more thread-safety risk, using blocks everywhere may increase the chance that someone generates a memory leak through cyclic references, processing large requests could be more performant on older phones on a background thread, some patterns make it easy to cancel the request, etc.
Ok, some of these are indeed specific to a given platform and have no direct equivalent in (as many) other languages and platforms.
Yes, you need to learn those - as there's no equivalent in other languages and stacks, you have no choice but to learn, no previous knowledge will help you with them.
However, these tend to be higher-level concerns, where understanding the concept is still more important than memorizing all the relevant details. You write: "some ways are more verbose", which is obviously true, but IMO it's more important here to understand what "verbosity" is, what trade-offs it presents, and what is the "correct" level of verbosity for the task. Knowing this, finding the solution with the right amount of verbosity is as simple as opening a bunch of libraries' GitHub pages and quickly glancing on the code examples there.
---
All in all, I'm not disagreeing with you at all. You're right that remembering a lot of details makes you faster. You're right that there are considerations unique to the stack of language.
What I'm saying is it's not hard to remember all the essential details: you only need spaced repetition, which happens naturally as you work. Further, while unique features for a lang or stack exist, they are very rare, and it's not hard to learn them (exactly because they're so different than the rest, which makes them stand out). All the other - non-unique - features and consideration form a large pool of concepts which are frequently reused across many (or most, depending on the feature) languages and stacks. Internalizing this pool of concepts lets you effortlessly switch stacks and languages; and while you're right that the productivity will drop after the switch, I assert that with a bit of effort it'll get back to normal levels after a short time - just a few months (for the real mastery it would take longer, of course, but that's true always and for every kind of work).
Anyway - thanks for the discussion, I enjoyed it very much, thank you. I hope it wasn't too boring on your side :-)