Was leaving core.async.flow out of cljs an intentional design decision, or just a focus to get it working on JVM first?
I don't know about the actual reason, but there are definitely potential issues porting it as is to cljs. Specifically around most js apis you'll want to interact with already being async
as it's really about mapping process functions to threads (which don't exist in cljs), we were not planning to implement it there
Understood. Even being able to separate the flow steps from building the process has been quite helpful for me, separate from threads. I have a hunch that there might be ways to still include a subset of flow, and let users override things to use web workers etc to get parallelism and :workload :compute on their own without forcing a choice in the core implementation. If I do a little more thinking on it and can get a reasonable set of cases working, would you all be open to eventually taking a look at a JIRA issue?