Evaluation and Evolution of Mini‑Program Development Frameworks for Frontend Teams

This article reviews the background, key considerations, architectural principles, evolution, performance comparison, and a customized solution for building mini‑programs using frameworks such as WePY, Taro, and UniApp, highlighting cross‑platform support, TypeScript integration, and development experience improvements.

Liulishuo Tech Team
Liulishuo Tech Team
Liulishuo Tech Team
Evaluation and Evolution of Mini‑Program Development Frameworks for Frontend Teams

Background Introduction

Since the launch of WeChat Mini‑Programs in 2017, they quickly became a new internet phenomenon, allowing users to access functionality without downloading heavy apps, offering an "instant, use‑and‑go" experience that greatly improves user satisfaction.

Various industries—e‑commerce, social, platforms, tools—have leveraged mini‑programs to discover new business models and boost acquisition and traffic.

On the technical side, the ecosystem has flourished: after WeChat, Alipay, Toutiao, Baidu, and others released their own mini‑program platforms, prompting a wave of development frameworks aimed at higher efficiency and better developer experience.

Considerations

Given the rise of mini‑programs, the Liulishuo children’s business has many scenarios (activities, acquisition, tools). The frontend team must support rapid business growth without compromising developer experience, considering:

Mini‑program performance and quality – poor performance or many bugs lead to user loss.

Developer experience – IDE hints, build speed, API documentation completeness, etc.

Multi‑platform support – as needs expand beyond WeChat, the ability to "Learn once, Write anywhere" or even "Write once, Run anywhere" can save considerable development cost.

Framework Principles

Using WeChat Mini‑Programs as an example, the underlying framework consists of two layers: the Logic Layer (App Service) and the View Layer (View). The Logic Layer runs JavaScript, while the View Layer renders pages; they communicate via Events and Data and invoke native APIs through JSBridge.

Regardless of framework design, the core operation is calling setData to notify view changes. Frameworks fall into two architectures:

Static compilation + runtime

Heavy runtime

1. Static Compilation + Runtime

Code is compiled based on AST technology into directly runnable mini‑program code, enabling cross‑platform development.

Because the mini‑program DSL resembles Vue syntax, many Vue‑like frameworks (e.g., MpVue, Wepy, UniApp) use AST analysis to transform code, mainly by adjusting the Vue runtime.

React’s JSX syntax is more complex; after AST compilation to the DSL, the difficulty is higher, which is why most mini‑program frameworks adopt Vue‑like syntax (e.g., Taro 2).

2. Heavy Runtime

The entire lifecycle runs within the original React or Vue framework, bypassing DSL limits and allowing full use of framework APIs (e.g., Taro 3, Remax).

The key is rendering the view dynamically on the mini‑program page. For React, the react-reconciler library maintains virtual‑DOM operations; developers need to implement a custom hostConfig and invoke the runtime’s render function to interact with the mini‑program.

Evolution Timeline

The children’s frontend team experienced the following stages in mini‑program development:

Native

Initially, simple mini‑program requirements led the team to develop directly with the official WeChat documentation using native APIs.

Wepy

As complexity grew, native development faced limitations with npm packages, webpack, and third‑party libraries, hurting efficiency. The team adopted Tencent’s Vue‑like framework Wepy to address these pain points.

Taro

Seeking better developer experience, the team moved to TypeScript across all projects. Wepy’s poor TypeScript support prompted a switch to Taro 3.0, which promotes a "Write once, Run anywhere" philosophy, breaking DSL constraints and offering near‑full runtime capabilities with dynamic template building, making development feel like a regular React project.

UniApp

Due to performance issues of Taro 3’s heavy runtime on low‑end devices, the team evaluated alternatives and settled on UniApp, which also follows the "Write once, Run anywhere" principle, offers a complete Vue ecosystem, and provides strong IDE support, fitting the team’s needs.

Framework Deep‑Dive Comparison

Performance and feature comparison on a Redmi 6 Pro device.

Cross‑Platform Support

Ecosystem Support

Long‑list Like‑Speed Test

PS. Taro 3.0, WePy, and MpVue data are incomplete because the list is too long for the page to render, and both WePy and MpVue have stopped maintenance .

Taro 3.0’s higher like‑response speed stems from its near‑full runtime implementation, which uses template rendering; complex pages can cause deep hierarchy and performance degradation.

page.setData({
  "root.cn.[0].cn.[0].cn.[0].cn.[0].markers": []
})

More detailed analysis can be found in the appendix.

Solution

After extensive use of UniApp and aligning with business needs, the team built a standardized mini‑program solution with the following directory structure:

├── README.md
├── babel.config.js
├── build // build config
├── dist // output directory
├── package.json
├── postcss.config.js // postcss
├── public // H5 template
│   └── index.html
├── resource // static assets
├── src
│   ├── App.vue
│   ├── common 
│   ├── components
│   ├── config
│   │   ├── dev.ts
│   │   ├── index.ts
│   │   └── prod.ts
│   ├── custom-tab-bar // custom tab bar
│   ├── main.ts // entry file
│   ├── manifest.json // uniapp config
│   ├── mixins // shared modules
│   ├── pages // pages
│   ├── pages.json // global page config
│   ├── services // APIs
│   ├── sfc.d.ts // missing lib definitions
│   ├── static // static images
│   ├── store // vuex store
│   │   ├── index.ts
│   │   └── modules
│   └── utils // utilities
├── tsconfig.json // TypeScript config
├── vue.config.js // webpack config
└── yarn.lock

Because UniApp’s CLI project is too generic and its TypeScript setup is not optimal, the team extended it with a complete TypeScript configuration, IDE settings, basic components, and utility packages, further improving developer experience.

VSCode integration requires plugins ESLint, Vetur, uniapp‑snippet and enabling the vetur.experimental.templateInterpolationService setting.

Conclusion

As the saying goes, "A single thread does not make a rope, a single tree does not make a forest" – the mini‑program technology stack is the result of collective effort and summarization. The current solution can quickly respond to various mini‑program and cross‑platform needs, is developer‑friendly, boosts R&D efficiency, and reduces costs.

The team will continue to monitor mini‑program evolution and refine the solution to adapt to rapid framework changes.

References

WeChat Mini‑Program Official Documentation: https://developers.weixin.qq.com/miniprogram/dev/framework/

2019 Framework Deep‑Dive Evaluation: https://ask.dcloud.net.cn/article/35867

2020 Framework Deep‑Dive Evaluation: https://ask.dcloud.net.cn/article/37155

UniApp Official Documentation: https://uniapp.dcloud.io/

Taro Official Documentation: http://taro-docs.jd.com/taro/docs/README

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Performanceframeworkevaluation
Liulishuo Tech Team
Written by

Liulishuo Tech Team

Help everyone become a global citizen!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.