[JOSS] Comparison of web app and CLI from user perspective

[yongrenjie]

(This issue is opened as part of @yongrenjie and @llewelld's review of the Journal of Open Source Software submission, 'Powering single-cell analyses in the browser with WebAssembly'.)

---

The paper provides a cogent description of the benefits of running single-cell analyses in the browser from a developer perspective: for example, not having to provision a backend server. However, given that the main contribution of the tool is client-side visualisation and execution, it would be useful to have an idea about the benefits and drawbacks of this approach for the user. In particular:

[LTLA]

I think your text got cut off.

Anyway, the "Further comments" sections has some comments about the consequences of client-side compute for the user. I've fleshed them out a little in kanaverse/kana-paper#8.

[llewelld]

Apologies for the lost text; the full wording should have been as follows:

The paper provides a cogent description of the benefits of running single-cell analyses in the browser from a developer perspective: for example, not having to provision a backend server. However, given that the main contribution of the tool is client-side visualisation and execution, it would be useful to have an idea about the benefits and drawbacks of this approach for the user. In particular:

1. What is the overhead of running it via WASM rather than natively or as an R package?
2. What order-of-magnitude size of data generally needed for single cell analysis, that would otherwise have to be transferred to the server?

Biology is not our specific area of expertise, but we wonder whether, for a biologist working in bioinformatics, an R-based solution wouldn't nevertheless work well for them (we expect R to be a tool many biologists would be familiar with). Given this, would it be possible to more fully justify the use of the browser and the impacts of doing so in the text?

The changes you've already made in https://github.com/kanaverse/kana-paper/pull/8 and https://github.com/kanaverse/kana-paper/pull/9 already go a long way to addressing these comments in my view. Could you suggest representative dataset sizes in your "No latency from transfer of data" bullet point? If your benchmarking files are representative then I guess we're typically talking tens or hundreds of MB?

[LTLA]

That's correct. For the public test datasets, we're talking about 10 - 500 MB. (If interested, you can inspect the sizes at https://github.com/kanaverse/random-test-files/releases.) Internally, we have see kana used with files up to 1 GB in size. The results themselves are usually several MB, probably not more than 10 MB in total but split over multiple requests while the user interacts with the application. This is a less obvious source of sluggishness, e.g., when the app has to constantly query the backend for expression values when the user picks a different gene for coloring the t-SNE/UMAP.

I added some ballpark figures to the manuscript, fleshed out in kanaverse/kana-paper#10.

Biology is not our specific area of expertise, but we wonder whether, for a biologist working in bioinformatics, an R-based solution wouldn't nevertheless work well for them (we expect R to be a tool many biologists would be familiar with). Given this, would it be possible to more fully justify the use of the browser and the impacts of doing so in the text?

FWIW I think that expectation is... optimistic, at least in my personal experience with collaborating with bench scientists.

[llewelld]

Thanks for making these changes; these look good to me, and I think make a much clearer and stronger case for the use of client-side compute. @yongrenjie, what do you think?

[yongrenjie]

Looks great!