Brian2Wasm: How Spiking Neural Network Simulations Run in the Browser via WebAssembly
Sharing a neuroscience simulation has always been painful
You run a spiking neural network model in Brian2, get a nice result, and want to show it to a collaborator. They need Python. They need conda. They need Brian2 installed, probably a specific version. By the time the environment is working, the moment has passed. Brian2Wasm is an attempt to reduce that to a link.
What Brian2 actually is
Brian2 is an open source Python simulator for spiking neural networks. It lets researchers write neuron dynamics as differential equations in standard mathematical notation, rather than learning a simulator-specific language. You describe your model, specify a network, and Brian2 handles the rest. Under the hood it generates C++ or Cython from your model description, compiles it, and runs it—so the readable syntax doesn’t cost you performance.
It handles everything from simple leaky integrate-and-fire neurons to full Hodgkin-Huxley biophysics to custom synapse plasticity rules. The community is primarily computational neuroscientists, and the main distribution channel is conda-forge.
How Brian2Wasm works
Brian2Wasm is a Brian2 device—an alternative compilation target that plugs into Brian2’s existing code generation pipeline. Instead of producing native C++ and compiling it for your machine, it feeds that same generated C++ through Emscripten: the LLVM-based toolchain that compiles C and C++ to WebAssembly.
The output is a self-contained web folder. A Wasm binary, a JavaScript glue file, and an HTML page. You can host that on GitHub Pages, Netlify, or any static file host. Someone opens the URL in a modern browser and the simulation runs client-side, with no server involved and nothing to install.
Why Emscripten instead of Pyodide?
Pyodide is the other well-known path to Python in the browser. It ports the CPython interpreter itself to WebAssembly, which lets you run Python packages without modification. Powerful, but it means shipping a substantial runtime—and you’re still executing Python, which has its own overhead.
Brian2Wasm goes lower. It skips Python entirely at runtime. The Wasm binary contains only the compiled simulation logic. Smaller payload, simpler execution model. The tradeoff is that you can’t call back into Python mid-simulation or use arbitrary Python libraries. The simulation is frozen at compile time. That’s a fine tradeoff for reproducible, shareable demos and teaching materials—less fine if you need runtime parameterization.
One current dependency worth knowing: interactive plots rely on CDN-hosted Plotly assets. If you’re targeting offline environments or need tight dependency control, that’s a constraint to plan around.
The GSoC 2025 work
The existing Brian2Wasm repo is functional but rough. You can run Brian2 models in a browser today. What you can’t easily do is install it in one command, trust that it works across platforms, or contribute to it without a painful local setup. That’s what Palash Chitnavis is working on this summer, mentored by Marcel Stimberg, Dan Goodman, and Benjamin Evans.
Conda packaging
The Brian community lives in conda environments. Brian2 itself installs from conda-forge, and users expect the same from ecosystem tools. The packaging challenge for Brian2Wasm is that it needs the Emscripten toolchain available at model-compile time—managing that as a build-time dependency in a conda recipe takes care with platform detection and compiler path configuration. Getting it right means users can do conda install brian2wasm and not think about it again.
Testing a Wasm build in CI
This is the part that determines whether the project stays healthy after GSoC ends. Testing native Python is easy: pytest runs locally and in CI without ceremony. Testing a Wasm build is not. Your options are a headless browser via Playwright or Selenium, a Node.js environment loading the Wasm module directly, or a WASI-compatible runtime like Wasmtime. None of these are zero-setup, and each adds CI complexity.
A practical two-tier approach: test the Python-side code generation logic natively—fast, no browser required—and run a smaller set of integration tests that compile a minimal simulation and verify its numeric output in a headless Chromium instance. The integration tier will be slow, so keeping the test fixtures minimal from the start saves pain later. The goal isn’t full parity with native coverage immediately; it’s catching regressions in the compilation and output correctness paths.
Build pipeline
Right now getting Brian2Wasm running locally requires manual steps and familiarity with the Emscripten toolchain. Reproducible one-command setup is table stakes for attracting contributors. Without it, anyone who wants to submit a fix has to reverse-engineer the environment first.
What it unlocks
Once this infrastructure lands, the workflow is: write a model in Brian2, run one command to compile it to Wasm, push the output folder to a static host, share a URL. No dependencies on the recipient’s end. For teaching, that’s meaningful—students interact with a simulation before they’ve installed anything. For reproducibility, it’s useful too: the simulation output is baked into the Wasm binary, so results don’t drift as library versions change across machines.
Emscripten-compiled scientific code is already a proven pattern. SQLite, OpenCV, and various physics engines have shipped production Wasm builds this way. The architecture Brian2Wasm chose is sound. The current GSoC work is about closing the gap between a clever proof of concept and a tool people outside the core team can actually use.