Designing a Mini‑Program Engine: From Single‑Thread to Dual‑Thread Architecture and Vue Modifications

1. Single Thread

The author initially treated the mini‑program as a single‑page application (SPA) because its host environment is a browser, aiming to let developers write mini‑programs using Vue syntax just like on the web.

However, mini‑programs forbid certain HTML elements and APIs such as <iframe>, <a>, direct DOM manipulation, and dangerous APIs, which required restricting Vue’s rendering layer.

1.1 Modifying Vue

Two common approaches exist: using polyfills to override Vue APIs or forking Vue. Both have limitations, so the author chose a third method:

Install Vue.js into node_modules.

Configure a webpack alias.

Copy the part of Vue to be modified into the project and edit it.

To redirect imports, the web alias is re‑defined as follows:

const path = require('path');
module.exports = {
  'vue$': path.resolve(__dirname, '../src/web/entry-runtime-with-compiler'),
  compiler: 'vue/src/compiler',
  core: 'vue/src/core',
  shared: 'vue/src/shared',
  web: path.resolve(__dirname, '../src/web'),
  weex: 'vue/src/platforms/weex',
  server: 'vue/src/server',
  sfc: 'vue/src/sfc'
};

The principle is that imports of unmodified parts resolve to the original Vue files in node_modules, while imports of modified parts resolve to the author’s edited files.

1.2 Tag Blacklist

During DOM creation, the author checks the tag name against a blacklist (e.g., iframe, a) and issues warnings if prohibited tags are used, though this only deters well‑behaved developers.

1.3 Problems

Because the environment is a web page, developers can still execute arbitrary JavaScript, manipulate the DOM, and use the BOM, making it impossible to fully prevent prohibited actions.

2. Dual Thread

To improve safety, the author moved user code into a Web Worker (or hidden iframe) creating a master‑slave model: the master (sandbox) runs Vue and emits instructions, while the slave (UI thread) listens and applies them.

This introduces challenges such as translating DOM operations into messages, handling event binding, event objects, modifiers, routing, two‑way binding, and ref handling, all of which increase message traffic and affect performance.

2.1 Performance

Large UI updates generate many cross‑thread messages, causing noticeable slowdown despite the UI thread being idle.

2.2 Limited Native Capabilities

Because Vue runs inside the sandbox, even official native components must be registered there, restricting their ability to interact with the DOM or BOM, making features like video or audio components difficult to implement.

A workaround is to register a placeholder component in the sandbox that forwards data to a real component on the UI thread.

3. Returning to Single Thread

Due to time pressure and risk, the author reverted to a single‑thread approach, using a closed Shadow DOM to lock the body, preventing direct DOM manipulation while still allowing free JavaScript execution.

4. Returning to Dual Thread

The final decision is to adopt a dual‑thread model again, but this time with a lighter logic thread and a heavier UI thread, moving most native component work to the UI side to solve both performance and native capability limitations.

5. Some Reflections

Most mini‑programs are built on web technologies; the main difference is that some use multiple webviews while the author uses a single page with a worker.

5.1 Cross‑Platform Mini‑Program Thoughts

Two ultimate solutions are suggested: (1) a unified rendering engine (e.g., Flutter) that abstracts platform differences, and (2) industry‑wide standards for mini‑program packages, URI schemes, and widgets, as being drafted by W3C.

6. Summary

The author’s experience shows that while many claim dual‑thread models are for performance or developer convenience, the real motivations are security and control; the chosen architecture must balance these concerns with practical constraints.

Disclaimer: This article is for learning purposes only; the final solution is still undecided and may be influenced by technical and non‑technical factors.