Dimina: one mini program compiled into a bundle for four platforms

A mini program as a module, not a Web page in a frame

Dimina is the open source cross platform mini program framework released by DiDi, published under the Apache License 2.0. The problem it addresses is concrete: an existing mini program usually lives in one platform's runtime, and embedding it into a native app means reimplementing it. Dimina instead takes WXML, WXSS and JavaScript or TypeScript source and compiles it into a unified resource bundle, which is then loaded by containers on Android, iOS, Harmony and the Web. The intent is that a whole mini program can be embedded into a host app as an independent module, while new pages stay written in the familiar mini program syntax. The framework is not only a preview for the browser. It contains a mini program compiler, a logic and view runtime, standard components, a bridge to native capabilities, and the four platform containers.

DMCC turns source into a bundle of four resource kinds

The compiler is called DMCC, and it is the piece that decides what actually crosses the platform boundary. It converts mini program source into logic, view, style and configuration resources, and those resources end up inside the bundle. The architecture diagram in the repository describes it as compiling source through DMCC into a resource package that then runs on four platforms under a unified runtime contract. That is the key design decision. A host app does not receive a pile of platform-specific screens; it receives one package and a runtime contract, and the per-platform differences are absorbed inside the container. The documentation in docs/README.md covers the compilation flow, the dual thread model and the overall architecture, while fe/packages/compiler/README.md documents DMCC installation, its commands and its build output.

Logic and view never share a thread

The runtime keeps business logic separate from rendering. Business logic runs in a standalone JavaScript engine or a Worker, and the view layer is handed to a WebView or a browser to render. The runtime then takes over page semantics: page warm up, routing, lifecycles, components and cross thread messages. The platform table in the README is the clearest statement of how the model lands in practice. Android pairs QuickJS with an Android WebView, iOS pairs JavaScriptCore with a WKWebView, Harmony pairs QuickJS with a Harmony WebView, and the Web target runs its logic in a Web Worker with the browser as the view container. So the JavaScript engine is not the same on every platform, which is exactly why the semantic layer, rather than the engine, is what Dimina standardises.

Native capabilities arrive through one entry point

Another stated goal is keeping platform logic out of business pages. Standard APIs and an extension bridge are responsible for connecting to host capabilities, and the message channel inside the container links the logic layer, the view layer and those native abilities. The package can also be shipped offline: the mini program bundle is provided by the host and stored locally, which reduces runtime network dependencies. Update responsibilities are split out and described separately in docs/MiniProgram-Update.md, which covers mini program package updates and dynamic delivery. The repository also carries a shared/ directory with a README explaining how shared resources flow into the example projects on each side, plus integration guides for Android, iOS, Harmony and a Flutter host in docs/Flutter-Integration.md.

Running the bundled Web example on your own machine

If you want to see Dimina working before wiring it into a native app, the repository ships an example mini program and a Web container. The online demo at didi.github.io/dimina runs the same official component gallery in the browser. To run the bundled example locally, the project asks for Node.js 22.22.3+ and pnpm 12.2.0+. The steps are:

git clone https://github.com/didi/dimina.git
cd dimina/fe
pnpm install
pnpm compile
pnpm dev

The install step resolves the frontend workspace, pnpm compile builds the mini program under examples/miniprogram/, and pnpm dev starts the Web container together with a proxy service. The frontend workspace README covers the remaining build, packaging and debugging commands. The component gallery visible in the repository screenshots is the same one that runs on Android, iOS and Harmony, so the Web path is a reasonable first look at cross platform behaviour rather than a separate demo.

The capability boundary the project states out loud

Dimina says plainly that it is still aligning with the mini program standard and with the main capabilities of WeChat mini programs, and that it does not yet cover every API, component and feature. The project advises confirming the current capability range and platform differences before a formal integration. That is the most important limitation for anyone evaluating it, because a mini program codebase can depend on platform specific behaviour that a standards alignment will not reproduce exactly. The API reference guide in docs/API-Reference.md is the place where supported components, APIs and per platform differences are listed, and it is worth reading against your own source before committing. The architecture also references the mini program standardisation white paper, and the project describes filling in gaps gradually as real cross platform differences surface.

How the bundle approach differs from a plain WebView wrapper

The obvious alternative is to put a web view in the app and load a page, with your own JavaScript bridge for anything the host must provide. The difference is in what the runtime takes on. A wrapper gives the host a browser and leaves page semantics, routing, lifecycles and component behaviour to whoever wrote the page. Dimina moves those into the runtime and standardises them, and it also fixes the resource pipeline: source is compiled by DMCC into a bundle that the host stores locally, instead of shipping loose assets that the page fetches at runtime. The cost is the requirement to accept the compiler's model, its API surface and its incomplete coverage of the WeChat standard, plus the need to wire in the native bridge and the platform containers. If the content is a static web page, the framework adds machinery you do not need.

A release cadence you can watch, under Apache 2.0

Dimina is not a dormant repository. The last push was on 2026-10-20, and three tagged releases appear in recent history: v1.7.6 on 2026-09-24, v1.7.7 on 2026-10-08 and v1.8.0 on 2026-10-20. A CHANGELOG.md at the root records the changes, and the release notes are the place to look when you upgrade, because a runtime change can affect how a page behaves on a specific container. The project ships under the Apache License 2.0, which requires that the licence text and any notices travel with copies of the code and that modifications are marked. In practical terms, embedding Dimina in a commercial app means carrying the licence and notice obligations through your distribution, and the root LICENSE file is the authoritative text. No legal reading is offered here, only the practical packaging requirement.

Editorial conclusion

Dimina is worth adopting when you already have mini program style source and want the same pages to run on Android, iOS, Harmony and Web from one bundle, and when a separate logic thread and a native capability bridge fit your host application. It is the wrong tool if your code is a plain web page, if you need the full WeChat mini program API surface today, or if you want a runtime you can pin to a single tagged release. Check first what the API reference covers for the platform you ship, since the framework states that it is still aligning with the mini program standard and does not cover every API, component and feature yet. The last push was on 2026-10-20 and the most recent release is v1.8.0 on the same date.

Frequently asked questions

Official sources

1. didi/dimina on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases