Dash Bio packages interactive bioinformatics viewers as Dash components

What the suite actually contains

Dash Bio is a suite of bioinformatics components built to work with Dash, and the components fall into three categories.

The custom chart types are Dash Circos, Dash Clustergram, Dash Manhattan Plot, Dash Needle Plot and Dash Volcano Plot. The sequence analysis tools are Dash Alignment Chart, Dash Onco Print, Dash Forna Container and Dash Sequence Viewer. The visualization tools are Dash Mol2D, Dash Mol3D, Dash Speck, Dash Ngl.

Each of those names maps to a real piece of scientific visualisation that would otherwise be a large piece of work to build. A Manhattan plot is the standard genome-wide view of association signal against genomic position. A Volcano plot shows differential expression between two conditions. A Clustergram is a heatmap with hierarchical clustering. The alignment viewer renders sequence alignments with their annotations, and the sequence viewer handles a reference sequence with track data.

The molecule components are the heavier ones. Dash Mol2D and Dash Mol3D are 2D and 3D structure renderers, Dash Ngl uses the NGL viewer for interactive molecular visualisation, and Dash Speck handles speck plots. Behind them sit real dependencies: the package.json lists the circos JavaScript library, ideogram for the chromosome diagrams, igv for the genome browser, jsme-react for the Forna container, and the molecule renderers, several of them pinned to specific Git commits rather than published versions.

That pinning is worth noticing. The npm dependencies include git URLs with commit hashes, so the JavaScript layer is pinned to exact upstream states of circosJS, fornac, jsme-react, molecule-2d-for-react and molecule-3d-for-react. That is how the maintainers keep a fork's behaviour fixed, and it also means a component's behaviour is tied to a fork rather than to a stable upstream release.

The components are Dash components first

The integration is the point of the project, and the README's usage example shows exactly how little glue is needed.

import urllib.request as urlreq
from dash import Dash, html
import dash_bio as dashbio

app = Dash(__name__)

data = urlreq.urlopen(
    'https://raw.githubusercontent.com/plotly/dash-bio-docs-files/master/alignment_viewer_p53.fasta'
).read().decode('utf-8')

app.layout = html.Div([
    dashbio.AlignmentChart(
        id='my-default-alignment-viewer',
        data=data
    )
])

if __name__ == '__main__':
    app.run(debug=True)

There is no JavaScript build step in your project and no asset directory to manage. The component is imported from the Python package, placed in the app layout, given an id and a data payload, and Dash handles the rest.

That id matters more than it looks. Because these are Dash components, the data does not have to be loaded in Python at all. A callback can fetch a file, filter it, or respond to a dropdown selection and push a new dataset into the component, and the viewer updates. The example above loads the FASTA file at startup, which is the simplest possible case, not the intended one.

The repository layout shows how the two languages are joined. The src/ directory holds the React source, the dash_bio/ directory holds the generated Python package, and there is a webpack.config.js for the JavaScript bundle plus a babel.config.js. The build:backends script runs dash-generate-components to generate the Python wrappers, and the postbuild script runs es-check es2015 to verify the emitted JavaScript meets that syntax level. The src/lib/components directory is the source of truth for the component set.

There is also an R/ directory and a man/ directory, plus a NAMESPACE and a DESCRIPTION file, and the build:backends script passes --r-prefix and --r-imports options. Dash Bio therefore ships R bindings alongside the Python ones, which matters if your lab writes its analysis in R.

The Python side brings a bioinformatics stack with it

The install requirements in setup.py are where the real dependency weight shows, and they are worth reading before you install anything.

    install_requires=[
        'dash>=1.6.1',
        'pandas',
        'scipy',
        'scikit-learn>=0.20.1',
        'biopython>=1.77;python_version>="3.0"',
        'biopython==1.76;python_version=="2.7"',
        'colour',
        'GEOparse>=1.1.0',
        'jsonschema',
        'parmed<=3.4.3',
        'periodictable',
        'requests'
    ],

Biopython is the centre of that list, and it is what does the sequence parsing behind the alignment chart and the sequence viewer. GEOparse is there for Gene Expression Omnibus data, parmed for molecular parameter files with an upper bound of 3.4.3, periodictable for element data in the molecular viewers, and scikit-learn for the clustering in the clustergram and the statistical parts of the other tools.

Two details in that list are easy to miss. The biopython requirement is split by Python version, with 1.77 or later on Python 3 and a pinned 1.76 on Python 2.7, which tells you the package still carries a Python 2 branch even though the classifiers list only Python 3. And parmed is capped with parmed<=3.4.3, an upper bound that means a newer parmed will not be picked up automatically.

The Python package name is derived at build time rather than hardcoded: setup.py reads dash_bio/package-info.json and replaces spaces and hyphens with underscore characters. The version comes from the same file, and the long description is read straight from README.md. So the package metadata is generated from the JavaScript side, which is the usual Dash convention and the reason the version in package.json and the version on PyPI match.

Running it inside JupyterLab takes extra steps

Running a Dash app in a notebook environment is a different path from running it as a server, and the README walks through it in numbered steps because there are three separate tools to install.

The virtual environment comes first, with the platform-specific commands given explicitly:

python3 -m venv env

on macOS and Linux, or `py -m venv env` on Windows, then activation with `source env/bin/activate` or `.\env\Scripts\activate` respectively.

Then the libraries, which the README gives as one line:

pip install dash dash-bio pandas numpy Jupyterlab

Then jupyter-dash, so that the Dash extension is available in the notebook:

pip install jupyter-dash

The build step that follows is the one that catches people out:

jupyter lab build

The README notes that this step requires Node.js and NPM installed, with the version check given as `node -v` and `npm -v`. Then Plotly figures inside JupyterLab need the JupyterLab extension, which the README installs as:

jupyter labextension install [email protected]

Note that the extension version is pinned exactly, which is the correct thing for a lab environment where everyone needs the same frontend bundle.

The last instruction is the one people forget: start JupyterLab with `jupyter lab`, and it must be run within the virtual environment that was activated earlier. The README marks this as important.

So the JupyterLab route costs a Node.js toolchain and a rebuilt JupyterLab frontend, where the plain Dash server route needs neither. That is the practical difference between the two ways of using the library, and it is the reason the server route is the one to choose unless you specifically need the notebook.

Maintenance: a community-maintained suite with an older release line

The README carries a banner stating that the project is maintained by the Plotly Community, and that badge is the most accurate summary of its status.

The release line tells the rest of the story. The three listed releases are v1.0.0 from 2022-01-17, v1.0.1 from 2022-01-20 and v1.0.2 from 2022-03-19, and the version in package.json matches at 1.0.2. So the published package has not been cut in roughly four years.

The source tree is different, though. The last push was on 2026-05-29 and the repository is not archived, so the code has been touched in the months since the last release. The gap between a moving source tree and a frozen release line is exactly what you would expect from a project whose upstream JavaScript dependencies are pinned to Git commits: those forks can move without the Python package needing a new release.

The repository also has the machinery of an actively worked project. There is a CircleCI configuration and a .github/ directory, a CHANGELOG.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, a .pylintrc for the Python side, an .eslintrc and a .prettierrc for the JavaScript side, a jest.config.js and a tests/ directory, plus a renovate.json for dependency updates and a dev-requirements.txt. The npm test script chains linting, formatting verification and the unit tests together, so a pull request is checked on several axes at once.

The licence is MIT in package.json and in setup.py, and the author is The Plotly Team with a maintainer listed as Hammad Khan. The CircleCI badge in the README points at the master branch, matching the default branch.

What none of this gives you is a compatibility promise. The Dash dependency is dash>=1.6.1 with no upper bound, so a newer Dash release can change behaviour underneath a component built against an older one, and there is no upper bound to catch that in a fresh install.

Where Dash Bio fits, and where it stops

The comparison worth making is with building the visualisation yourself in a notebook, and with the specialised single-purpose tools in the bioinformatics ecosystem.

Against a notebook analysis, the difference is that Dash Bio turns a static figure into an interface. The same data can be fed through a dropdown, and the viewer responds, which is the difference between a supplementary figure and an exploration tool. The cost is the dependency stack and the web framework, and the fact that the analysis now lives in an app rather than in a document someone can rerun.

Against the specialised tools, the difference is the opposite one. Jalview, IGV and the like are purpose-built for one task and go deep into it, with features Dash Bio does not attempt. What Dash Bio offers is the integration: the same callback-driven architecture, the same layout system, the same deployment story as the rest of a Dash application, so the alignment viewer and the volcano plot and the dashboard around them are one app rather than three tools with three deployment processes.

The limits are concrete. The Python 2.7 branch is still in the dependency list, which is a signal about the age of the code. The parmed upper bound and the git-pinned JavaScript forks mean a fresh install pulls specific old states of upstream libraries. The R bindings exist but the README documents only the Python path in any detail. And the suite has no component for reading raw sequencing data or running alignment itself, since it visualises results rather than producing them.

For a lab that has already committed to Dash for its dashboards and needs genomics or molecular views inside the same app, this is the obvious choice, and the fact that it is community-maintained rather than vendor-supported is a fair description of what you are adopting. For a team starting a new bioinformatics web app in 2026, the four-year-old release line is the thing to weigh first, since the JavaScript forks it depends on are exactly the kind of dependency that quietly stops working.

Editorial conclusion

Dash Bio suits a team that already has a Dash application and needs genomics or molecular visualisations as interactive React components, since each viewer takes data through a Dash callback like any other component and the suite covers the common plots. It is the wrong tool if you need a standalone script or a static figure, since every component arrives as a Dash dependency, and it is the wrong tool for a new project if the age of the release line matters, because the last PyPI release is 1.0.2 from March 2022 while the source has been touched more recently. Before starting, install with pip install dash dash-bio pandas numpy Jupyterlab, check the Dash Bio documentation for the component you need, and confirm your data parses with the biopython and pandas versions in setup.py before you build the layout around it.

Frequently asked questions

Official sources

1. License: MIT
2. plotly/dash-bio on GitHub
3. Project website
4. README
5. Releases