How We Built Orphos: Private Gene Prediction in the Browser

Scientific software earns trust differently from ordinary software. A polished interface helps, but it is not evidence that an analysis is correct. The more useful signals are whether the method is described honestly, whether its implementation can be inspected, whether results can be reproduced, and whether limitations are made visible.

That is why we built Orphos in the open. Orphos is a free, open-source implementation of Prodigal-style prokaryotic gene prediction written in Rust. It is available as a command-line program, a Python package, a reusable Rust library, and a browser application powered by WebAssembly.

This article expands on my earlier essay, “Writing Bioinformatics for the Future: Why Rust Is a Perfect Fit”. Rather than making the general case for Rust again, I want to show what those ideas look like in a real project—and where the boundaries of the project are.

What Orphos does#

Gene prediction is one of the first computational steps in analysing a newly sequenced prokaryotic genome. The task is to identify regions that are likely to encode proteins and to report their coordinates, orientation, and translated amino-acid sequences.

Orphos follows the approach established by Prodigal, the widely used prokaryotic gene-recognition program created by Doug Hyatt and collaborators. It supports both single-genome and metagenomic workflows and can produce common downstream formats including GenBank, GFF3, BED6, SCO, and amino-acid or nucleotide FASTA.

Orphos is not a new biological discovery, and it is not a clinical diagnostic system. It is an engineering implementation of an established gene-prediction approach. That distinction matters: software quality can make a scientific method easier to run, inspect, and maintain, but it does not replace biological validation.

Why build another implementation?#

The original question was practical: could a modern systems language preserve the performance expected from bioinformatics software while making the codebase easier to reuse across environments?

Rust was a compelling fit for four reasons:

1. Predictable performance. Rust compiles to native code and provides control over memory layout without requiring a garbage collector.
2. Safety at the language level. Its ownership and type systems prevent broad classes of memory and concurrency errors before code is run.
3. One core, several interfaces. The same implementation can support a CLI, Python bindings, and WebAssembly instead of maintaining separate analytical engines.
4. Long-term maintainability. Explicit types, package tooling, generated documentation, and compiler checks make assumptions easier to find and refactors safer to perform.

None of this means that Rust is automatically faster than C, or that a rewrite is automatically better than mature scientific software. Performance depends on the algorithm, data structures, compiler, workload, and measurement method. The more defensible reason to use Rust is the combination of speed, portability, and safety it makes possible.

One analytical core, four ways to use it#

The Orphos repository is organised around a shared core rather than several independent implementations:

• orphos-core contains the gene-prediction logic and can be embedded in Rust applications.
• orphos-cli exposes the workflow as a command-line tool for local analysis and pipelines.
• orphos-python uses PyO3 to make the same core available to Python users and is distributed through PyPI.
• orphos-wasm compiles the core to WebAssembly for use in a web browser.

This structure has an important scientific benefit: an interface does not need to reimplement the underlying algorithm. A Python notebook, shell pipeline, and browser session can all use the same analytical core. That reduces the number of places where behaviour can drift.

The crate-level API and implementation documentation are also published on docs.rs, while the source, issue history, tests, and licence remain visible on GitHub.

Performance, reported with context#

In the development benchmark described in the original Medium article, the measured running times were approximately:

These numbers show that Orphos was competitive on that test and that parallel work improved its running time. They should not be treated as a universal ranking. Results vary with the input sequence, hardware, operating system, software version, warm-up, and benchmark design. The small change from four to eight threads also illustrates a common limit: adding workers does not make every part of an algorithm parallel.

For scientific software, the benchmark setup is as important as the headline number. Anyone evaluating Orphos for a workflow should measure the current versions on representative data and compare outputs—not only speed—with the requirements of that workflow.

Bringing gene prediction into the browser#

The most visible result of the architecture is orphos.full-human.com. It runs Orphos locally in a compatible browser using WebAssembly. A user can select sequence data, configure options, run prediction, and download outputs without installing a compiler, Python environment, container, or command-line package.

This is useful for education, exploratory work, and cases where installing specialist software creates unnecessary friction. It also changes the privacy model: the browser app performs the analysis on the user's device, so selected sequence data does not need to be uploaded to an Orphos analysis server.

Browser execution still has constraints. Available memory, sustained performance, and browser behaviour differ from a native environment. Large or automated workloads will usually be better suited to the CLI, Python package, or core library. The browser app is another interface to the project, not a claim that every bioinformatics pipeline belongs in a browser.

What open source contributes to scientific trust#

Publishing source code does not prove that software is correct. It does make stronger forms of scrutiny possible.

With Orphos, researchers and developers can:

• inspect how inputs, parameters, and output formats are handled;
• run tests and benchmarks in their own environment;
• compare predictions with established tools and known datasets;
• identify assumptions or edge cases in the implementation;
• report issues with a reproducible example; and
• propose changes through a public review process.

The project is released under the GPL-3.0 licence and credits the original Prodigal work on which the implementation is based. That provenance is not a footnote. Scientific software is cumulative, and being explicit about what is original, what is reimplemented, and what remains to be validated is part of responsible engineering.

How Orphos relates to Full Human Health#

Orphos and Full Human Health address different biological problems. Orphos predicts protein-coding genes in prokaryotic sequence data; Full Human Health helps people explore findings associated with variants in compatible consumer DNA files. Building one is not scientific validation of the other.

The connection is in the engineering principles: local processing where practical, clear data boundaries, traceable sources, reusable components, and candid communication about limitations. Orphos provides a public example of how we approach privacy-sensitive scientific software—and gives others a concrete project they can inspect rather than a trust claim they simply have to accept.

Try it, inspect it, or reproduce it#

You can explore Orphos at the level that suits your work:

• Run gene prediction in your browser with no installation.
• Inspect the source and installation options on GitHub.
• Install the Python package for scripts and notebooks.
• Read the Rust API documentation.
• Review the original motivation and benchmark context.

We welcome technically specific feedback: unexpected predictions, format compatibility issues, reproducible performance results, documentation gaps, and use cases the current interfaces do not serve well. Scientific trust is not a badge a project awards itself. It is built through evidence, transparency, and the willingness to make the work testable.