5 posts tagged with "Web IDE"

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?

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.

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?

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.