DEV Community: Anton

I Gave a Fruit Fly Connectome a Body—and Let It Learn in the Browser

Anton — Wed, 07 Oct 2026 18:57:25 +0000

A fly wakes up on a kitchen floor.

It is hungry, slightly cold, and surrounded by furniture. Its compound eyes receive the scene. Competing neural populations choose between food, warmth, light, rest, and exploration. Leg activity starts a gait. If the flight pathway wins, the wings accelerate until the body actually leaves the floor.

This is FlyLab, an interactive browser experiment built around fruit fly connectome data.

Open FlyLab: flylab.ankhit.com

FlyLab running in the browser: the shared kitchen, neural activity, compound-eye view, needs, and movement are visible at the same time.

Why build this?

A connectome is a map of connections. By itself, it cannot show whether a visual signal can guide a body around a table, whether a fly can switch from walking to flight, or what happens when one neural pathway is removed.

FlyLab turns that static map into a testable loop:

brain → body → environment → sensors → brain

You can observe the loop, intervene in it, and measure what changes. That makes the project useful for experimentation, education, debugging, neuro-inspired control, and visualization.

Here are three examples of what that means in practice.

Story 1: A developer asks, “Does the brain really control the wings?”

Imagine you are building a neural simulation. The fly moves, but you do not know whether the movement comes from its neural state or from a hidden steering rule.

In FlyLab, you can inspect the chain directly. Activity from descending neurons contributes to walking, steering, and flight permission. Wing power produces modeled forces. The body takes off only after those forces overcome support and gravity.

Now silence the relevant motor output. If the wings stop producing thrust, you have a causal test—not just a moving 3D model.

The same approach works for other questions:

Does removing vision change the route?
Does body feedback help the fly escape an obstacle?
Can it walk with silent wings?
Can it land when the neural goal changes to rest?

Every intervention connects a visible behavior to a measurable part of the model.

Story 2: A student asks, “How does a wiring diagram become behavior?”

FlyLab starts with the FlyWire FAFB v783 dataset. The source connectome contains 139,255 reconstructed neurons. After model-specific nodes are added, the runtime graph contains 144,794 cells and 3,346,722 directed edges.

Those numbers are difficult to reason about as a table. FlyLab makes them observable.

One screen shows the fly’s compound-eye panorama, active neural populations, internal needs, wing output, leg contact, current goal, physical movement, and trail through the kitchen. A student can watch a stimulus change photoreceptor activity, see a goal population win, and then watch the body respond.

The interface also exposes the difference between intention and action. A fly may choose food while physically blocked by the kitchen island. The brain goal remains visible while contact feedback triggers a turn or climb response.

That distinction is one of the most useful lessons in the project: deciding what to do and successfully doing it are separate problems.

Story 3: An experimenter asks, “Which model works across repeated trials?”

The Train button creates a second experimental fly with its own full neural graph. The main fly remains in the shared kitchen while the experimental fly enters a controlled training environment.

The user can train or test:

food seeking;
warmth and light seeking;
obstacle escape;
need-based choice;
spectral cue discrimination;
hypotheses about uncertain neurotransmitters.

Each browser receives a reproducible random seed. Different browsers can test different candidates and contribute results to a shared archive.

The current live-lab-v4 protocol does more than compare reward scores. A candidate must complete the task on two held-out seeds before FlyLab can accept it.

In the spectral task, the fly must reach reinforced food without touching an equal-brightness decoy. The current model completed a five-seed probe with five correct food contacts and zero decoy contacts.

FlyLab then tested a new candidate. Both models completed the held-out task, but the current model kept the higher mean score: 3.020 versus 2.690. The system preserved the stronger model and archived the rejected candidate, its parameters, and its trajectory.

That is useful because optimization systems often celebrate a better-looking number even when the agent never completes the task. FlyLab requires an observable outcome.

One browser, one fly

Every open browser computes its own neural model locally in a dedicated Web Worker. WebGL renders the kitchen and brain activity. A small Python aiohttp server connects participants through WebSocket.

When two people enter the same room, their flies share the kitchen. They receive one another’s position, posture, leg pose, and wingbeat state. More importantly, they can see one another through the compound-eye model. Furniture and nearer flies can occlude those behind them.

This creates a simple path from individual experiments to multi-agent ones. A future task might test following, avoidance, competition for limited food, or communication through modeled signals.

The brain runs locally in the browser. Once the data is prepared, neural computation does not depend on an external AI service or paid API.

What FlyLab can be used for today

Causal testing: disable a pathway and measure which behavior disappears.
Model comparison: evaluate candidates with fixed seeds, controls, and held-out trials.
Distributed experiments: let multiple browsers explore different parameter hypotheses.
Teaching: demonstrate the path from sensory input to neural activity and movement.
Simulation debugging: separate goal selection, motor output, physics, and feedback.
Neuro-inspired robotics: study competition between needs and switching between locomotion modes.

The model layers remain explicit: neural dynamics, sensory conversion, motor readouts, body physics, and added decision circuits can each be inspected or replaced. This traceability is what turns a visually interesting fly into an experimental tool.

What comes next

The next steps are to benchmark one neural graph against two, run more independent trials, improve receptor and neuromodulator models, add richer leg and joint mechanics, and design social tasks for multiple flies.

The long-term goal is to make every behavior easier to explain, challenge, and reproduce.

What would you test first?

If you could intervene in the fly’s vision, needs, synaptic hypotheses, or motor output, what experiment would you run first?

What result would convince you that the behavior came from the connectome rather than from the surrounding model?

Share a test in the comments. The best suggestions have a clear control, a measurable outcome, and a result that could prove the hypothesis wrong.

Try the live project: flylab.ankhit.com

Statistical Tests in TypeScript Without a Separate Python Service

Anton — Sat, 03 Oct 2026 16:10:45 +0000

Imagine an internal tool that compares two variants of a workflow.
The application already has:

the measurements;
filters;
tables;
charts;
user interactions.

Now you want to add one more thing:
a proper statistical comparison between the two groups.

One common architecture is to send the data to a separate Python service.
Sometimes that is absolutely the right decision.
But sometimes it introduces a network boundary for a calculation that could have remained local to the application.
That made me wonder:
How much statistics can reasonably stay inside a TypeScript codebase?

The gap between mean() and an analytics platform
JavaScript already makes simple descriptive statistics easy.
Calculating an average is trivial.
The interesting part starts when you need things like:

confidence intervals;
hypothesis tests;
ANOVA;
regression diagnostics;
control charts;
power calculations;
time-series methods.

At that point, many teams immediately leave the JavaScript ecosystem.
Columna takes a different approach.
It has a separate columna/advanced entry point for statistical procedures.
For example, here is a small two-sample comparison.
The data below is synthetic and exists only to demonstrate the API.

import { DataFrame } from 'columna';
import { formatReport } from 'columna/advanced';

const measurements = DataFrame.fromRows([
  ...[42, 38, 45, 41, 39, 44].map((seconds) => ({
    variant: 'A',
    seconds,
  })),

  ...[40, 39, 42, 38, 41, 43].map((seconds) => ({
    variant: 'B',
    seconds,
  })),
]);

const result = measurements.ttest('seconds', {
  by: 'variant',
  equalVar: false,
});

console.log(formatReport(result, 'markdown'));

This uses Welch's two-sample t-test.
The API returns more than a p-value.
The result includes values such as:

test statistic;
degrees of freedom;
estimate;
confidence interval;
sample information.

And because the result is still a regular JavaScript object, the UI can decide how much of it to present.

Why this can simplify application architecture
Suppose a user changes a department filter.
The application could:

filter the observations;
run the statistical procedure;
update the result table.

No HTTP request is inherently required for that flow.
That does not mean every statistics workload belongs in the browser or Node.js.
It means the service boundary can be chosen for architectural reasons rather than because the calculation happens to require another language.
That distinction matters.
If the workload is already handled by a mature Python analytics service with established validation, there may be no reason to move it.
But if you only need a small, interactive statistical feature inside an existing TypeScript application, introducing a second runtime can feel disproportionately expensive.

Keeping data preparation and analysis together
There is another practical benefit.
The code that decides which observations enter the analysis can stay next to the code that performs the analysis.
For example:

const filtered = await measurements
  .filter((c) => c.seconds.gt(0))
  .collect();

const result = filtered.ttest('seconds', {
  by: 'variant',
  equalVar: false,
});

During review, the team can inspect the entire path:

which rows are included;
which rows are excluded;
how groups are defined;
which statistical method is used.

That is often easier than tracing the same calculation across frontend code, an HTTP contract, another service, and a separate statistics layer.

The short API call is not the difficult part
This is important:
A statistical function returning a number does not make the analysis correct.
The hard questions still exist.
Are observations independent?
Are the samples paired?
Is the chosen test appropriate?
How are missing values handled?
What effect size actually matters?
What should the UI show when the result is uncertain?
For example, if the same people were measured before and after a change, treating those values as two independent samples would be questionable.
You would want a paired analysis instead.
No library can infer the experimental design from a column name.

Please don't turn everything into "p < 0.05"
If statistics becomes easier to integrate into an application, there is also a risk that the UI reduces everything to:
significant / not significant
That is usually not a good interface.
At minimum, I would prefer to show:

sample sizes;
descriptive statistics;
estimated difference;
confidence interval;
the chosen method.

Users should be able to understand what was compared.
Developers should be able to reproduce the calculation.

What about correctness?
If I am going to use statistics inside an application, the first thing I care about is not the number of supported functions.
It is whether the implementation has been tested against established references.
Columna's advanced module is built around cross-checks against SciPy, NumPy, NIST references, property tests, and Monte Carlo tests.
That is a useful starting point.
But I would still validate any important production workflow against a known reference dataset before shipping it.
A statistical library should reduce implementation work.
It should not eliminate verification.

Where I think this approach makes sense
This is especially interesting for:

internal tools;
QA dashboards;
experiment explorers;
educational applications;
local analysis utilities;
interactive engineering reports.

For a large data platform, I would still expect heavy processing to live in something like DuckDB, Polars, a warehouse, or an existing analytics service.
But small statistical features do not always need to inherit that architecture.
Sometimes the most useful thing a library can do is not replace a platform.
It is to keep a small feature small.

The examples use columna/advanced:
https://github.com/ankhitlab/columna

I'm curious where people draw this boundary in real projects: which statistical operations would you keep inside a TypeScript application, and which would you always move to a dedicated analytics stack?