Comments (5)
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.
from kana.
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:
- What is the overhead of running it via WASM rather than natively or as an R package?
- 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 kanaverse/kana-paper#8 and kanaverse/kana-paper#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?
from kana.
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.
from kana.
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?
from kana.
Looks great!
from kana.
Related Issues (20)
- Some proposals from users HOT 11
- TypeError: e is not an Object. (evaluating '"_bioconductor_SLICE"in e') HOT 3
- [JOSS] Caption error HOT 2
- [JOSS] Expand on performance claims HOT 7
- [JOSS] Add description for non-specialist audience HOT 3
- [JOSS] Comparisons with other apps HOT 2
- [JOSS] Community guidelines HOT 2
- [JOSS] Instructions for deployment HOT 2
- [JOSS] Web app usage guidance HOT 4
- Subsetting by annotation is broken HOT 2
- move `summarizearray` from bakana to kana
- show # of cells in each group
- Fix issue with artifactdb zip file reader in explore mode
- Error that occurs when the number of cells is large HOT 7
- markers fails in explore mode if we don't have any row names HOT 1
- explore mode fails when switching between modalities
- Possible to visualize pre-done clustering? HOT 10
- missing annotations HOT 4
- Identifying expression of a gene across annotations
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kana.