jane*
Scientific computing for the life sciences: plasmid and sequence editing, cloning simulation, primer and qPCR design, gels, Sanger traces, CRISPR guide design, alignment and phylogenetics, proteomics, structures and chemistry, and the file formats around all of it. Each engine is checked against the reference software of its field.
Everything runs in your browser. No install, no upload, no account, no subscription. Your sequences never leave your machine — not as a policy, but because there is no server to send them to.
What these docs are
One page for every tool, every panel and every canvas the editor ships — not a feature list, a teaching manual. Each page covers what the operation actually is, when you would reach for it, every control and what changing it does to your result, a worked example you can reproduce on a real file, the science with its citation, and — the part most tools skip — what it cannot do.
New here? The four guides make a complete path, in order: Install and open → Your first project → The workbench tour → Files and formats.
Start here
| Guides | Install and open, your first project, the workbench tour, files and formats |
| Workflows | "I want to do X" — the route through the tools, end to end |
| All capabilities | Every tool and panel, the engine that runs it, and how it is reached |
| Canvases | The viewers: what each draws, what opens in it, and how to read it correctly |
| Science | The algorithms, written once where several tools share one |
| Compare | How this compares with the tools you already use |
| API | The headless engines, callable with no editor involved |
Why you can check what these pages say
The scientific engine reimplements fourteen published libraries faithfully — pydna, DnaCauldron, QUEEN, DnaChisel, SeqTrace, cfutils, sangerseqR, poapy, pyMSA, crisprScore, cas-offinder and others — and every capability is checked against the published library it comes from: its output is captured by running the real upstream library and asserted byte for byte.
That standard extends to these pages. A number in a worked example is a number the app produced on a
named file. A citation is a paper that was opened. A screenshot is the real app on real data. Where
something is approximate, unbuilt, or standing on a gap we have not closed, the page says so in the
Limitations section rather than leaving you to find out.
How the page list stays honest
It is not maintained by hand. The tool pages are generated from the editor's own command catalog and rail registry, and the canvas pages from the renderer registry, so a tool added to the workbench gets a page here with nothing to keep in step — and a tool removed from it is reported as an orphan rather than lingering in the nav.
How to cite
The software. Cite it as its citation file states: Court Naieem Fathy, jane*, the version you used, https://janeslabs.vercel.app. The same record is in the machine-readable form reference managers and archives read (Citation File Format), so a manager can import it instead of you typing it.
The methods a construction used. Open the construct in History & Provenance and export Methods (Markdown). It ends with References: the published method behind each step (Gibson assembly, Golden Gate, PCR) by DOI, and for a step made in this workbench the published software its simulation reproduces, each with the step numbers it supports. Cite those, not only the software: the method is what a reader needs to repeat the work.