In July 2026, we performed a systematic performance pass on Dora Web IDE. The trigger was not one dramatic freeze. The workbench had gradually accumulated an editor, resource tools, Git, logs, visual editors, and a Coding Agent. Each feature worked in isolation, while hidden costs began to overlap.

This article is a technical record rather than a dramatic story.

A hidden panel might still listen for data. Every few Agent characters might rerender the entire history. Search might display a few dozen matches only after scanning forty thousand files, while a Git title list might calculate every changed file in advance.

I have worked on embedded systems and Android applications. Both taught me a familiar ritual: before testing a small idea, spend a long time arranging SDKs, dependencies, drivers, cables, and device connections.

Years later, I picked up a small open-source Android retro handheld and wanted a simpler answer: could the device run Dora and also host the tools needed to change the game?

One day I inspected Dora's application data and found an Agent database of roughly 255 MiB.

That is not enormous by modern storage standards, but it was still growing. The diligent colleague had kept before-and-after file bodies for checkpoints, tool steps, parameters, results, and session data. Some orphaned tasks and checkpoints could also survive after their original session disappeared.

The discovery changed the question from “How much can an Agent remember?” to “Which memory deserves which lifetime?”

Models writing wrong code is not unusual. The frustrating part is simpler: when a model does not know something, it can only guess through hallucination.

When I asked Agents to make Dora games, they often invented APIs that looked perfectly plausible. Dora is a small, comparatively young engine; public examples and discussions are scarce beside older ecosystems.

I had been considering a reverse question before the community discussion began: instead of teaching every model all of Dora from scratch, could Dora learn a game language models already knew?

Before Dora SSR, I built a game engine project called Dorothy. It was Dora's predecessor, and many resource formats and creation ideas can be traced back to it.

Dorothy included editors for character hierarchy and animation, physics shapes and joints, and particle parameters. The original tools were themselves written with the engine's own interfaces. That gave them immediate runtime feedback—but also tied their data, UI, and execution environment closely to an old engine structure.

In July 2026, we reorganized parts of Dora Web IDE's interface: first-project guidance, visual-editor styling, file navigation, and document reading.

The goal was not a new coat of paint. We wanted to answer three practical questions: where a first-time user should begin, how an active state should look, and what deserves attention when the screen becomes crowded.

Dora Web IDE now has a Git panel, and its scope is intentionally modest.

It is not a complete Git reimplementation in the browser, nor an attempt to pull experienced users away from their terminals. It answers a narrower question: while a project is already open, can the common loop of reviewing changes, selecting a commit, writing it, and synchronizing with a remote stay inside the same workspace?

Self-update sounds like three operations: compare versions, download an archive, and replace the old files.

In practice, a version number says only what release we intend to install. It does not prove who published the download, whether its bytes are correct, or whether the previous application will survive an interrupted update. Dora SSR separates those questions into explicit verification gates.

I have long wanted open-source games to work like a relay.

Not merely as source archives that people can inspect, but as living projects another creator can download, run, change, commit, and carry forward. In Game Jams, I often see people rebuild the same input, scene, character-state, menu, and genre foundations. Rebuilding can be good practice, but it also makes me wonder: could yesterday's finished game become today's starting point?

Dora therefore had an early, deceptively simple goal: obtain an open-source game through git clone.

How a community author's networking library entered Dora SSR

One day in May 2026, our community chat turned to AI Coding.

People were no longer asking models to complete a few lines. They were supervising hours-long Agent tasks, handing over refactors, watching mistakes appear, correcting them, and running another round. Tokens went in like fuel; code grew at the other end.

Yezi—Elbold Dadunur—described the emerging collaboration in one sentence:

Everyone burns tokens to make something, then shares the result.

I found the phrase playful and precise.