Small program open source framework selection and principle introduction

At present, the popular open source frameworks for small programs include JD.com’s Taro, dclound’s uni-app (integrated with mpvue), Meituan’s mpvue and Tencent’s wepy. Below we compare these 4 frameworks from various aspects.

selection

Community ecology

The following data is obtained through Github Statistics

maintenance status

It can be seen that uni-app and taro have been updated recently, and the latest submissions of wepy and mpvue have been several months ago.
insert image description here
2. Star

As of October 27, 2021, the overall situation is as shown in the figure below. As can be seen from the figure, the rising stars uni-app and taro are in the leading position.
insert image description here

frame	Number of Stars	Star average growth
weps	21566	11.93
uni-app	34051	28.32
mpue	20372	15.32
taro	29854	23.01

Issues

Issues can reflect the activity level of the community. It can be seen that the taro issue is far ahead, indicating that the taro community is very active. Since the bug label is marked by the user himself, it is relatively inaccurate, but it can also be seen that uni-app feedbacks more bugs.
insert image description here

frame	IssuesOpen/Close	bug tab on/off
weps	344 / 1781	9 / 51
uni-app	827 / 1855	24 / 147
mpue	422 / 1264	3 / 22
taro	850 / 7063	7 / 76

Framework capability

	taro	uni-app	mpue	weps
grammar specification	nerv, react, vue specification	vue-spec	vue-spec	class vue specification
template system	JSX	string template	string template	string template
type system	Business code + jsx template	Business code	Business code	Business code
Component specification	applet component	applet component	html tags + applet components	applet component
style specification	postcss、sass、less、stylus	postcss、sass、less、stylus	postcss、sass、less	sass、less、stylus
Componentization	react, vue componentization	Vue componentization	Vue componentization	Custom componentization
Multiplexing	Reuse as H5	Reuse as H5	Reuse as H5	Reuse as H5
automatic build	Built-in build system + webpack	Built-in build system + webpack	webpack	built-in build system
Startup cost	Familiar with react\vue	familiar with vue	familiar with vue	Familiar with vue+wepy
data flow management	redux	vuex	vuex	redux

For each scenario, the best-performing code can be written natively, but the ROI is too low. The advantage of the framework lies in: writing more efficient code, having a richer ecology, and having good performance.

From the perspective of community ecology and framework capabilities, Taro is the best.

Realization principle

Taro 1/2 (heavy compile time, light runtime)

In order to achieve compatibility with multiple applets, it is divided into two stages:

Compilation stage: convert it into a template of the specified applet through babel;
Operation phase: through the runtime framework, it is responsible for adapting the underlying capabilities of each end.

This approach has several disadvantages:

JSX is too flexible and expensive to adapt. (Although the analysis of react can be introduced, how can Taro use the "dog head" of React).
source-map is not supported. Because Taro will transform the source code, source-map will not work. (could be handled during conversion, but too costly and low ROI)
Strong binding to React DSL, once React has new features, it also needs to be adapted. As a developer, you can only upgrade to use new features.
Because the AST needs to be manipulated frequently, the compilation speed will be slower.

Taro 3.x (light compile time, heavy runtime)

Use framework designs such as React and Vue to implement the relevant APIs required by render on different platforms. Simulate and implement DOM and BOM related APIs on the applet side, let the front-end framework run directly in the applet environment, so as to achieve the purpose of unifying applets and H5. As for the differences in life cycle, component library, API, routing, etc., by defining a unified standard, each end is responsible for its own implementation to smooth it out.
insert image description here

Due to the structural adjustment, Taro 3 is no longer strongly bound to a certain DSL, the development is more flexible, and the compilation speed is faster.

version difference

	Taro 1/2	Taro 3.x
Development experience	Strong binding to React DSL, and some JSX syntax is not supported (requires hack)	No DSL restrictions
performance	It is better in scenarios where the application is complex, there are many page nodes, and large-scale data updates are frequent	The above scene will be a little weaker, but the official said that the performance difference is not obvious. It also provides solutions such as pre-rendering and virtual list components
community support	Taro 1/2 will continue to be maintained, but with relatively less manpower	The focus of research and development is on Taro 3, giving priority to implementing new features