Since the birth of wechat small program, after more than 2 years of iterative upgrading, there have been millions of small programs online, after Web, iOS, Android, the fourth major development technology.

Along with it, the development ecology of small programs is also booming, from the original wechat native development, to the emergence of wepy, MPvue, Taro, uni-app and other frameworks, from slash-and-burn development to modern development, the ecology is getting richer and richer.

The choice is much, the question also comes, develop small program, should use native or choose tripartite framework?

First of all, most of the slots of wechat’s native development are as follows:

  1. Native development has poor support for Node, precompiler, and Webpack, affecting development efficiency and engineering build process
  2. Wechat defines a nonessential syntax, as is learning vue, React, learn the whole end of the general, rather than just wechat small program
  3. The React/Vue ecosystem is full of tools to improve development efficiency, such as ides, validators, tripartite libraries…
  4. The wechat IDE is really hard to use compared to a professional editor

At the same time, developers have various concerns about tripartite frameworks:

  1. Afraid of performance as original
  2. Afraid of some functional framework can not be implemented, can only use native
  3. Jump into the pit lest the frame be unstable
  4. And the various tripartite frameworks, which one to use

Faced with such a tangled scenario, many enthusiastic developers have published reviews to share their experiences, but there is a sense of confusion and too much overdue information. The lack of a very professional, in-depth, or, as it’s now called, “hardcore” review report.

Doing a review report, unlike general experience sharing, can be very time consuming. It needs to:

  • You have to become a professional user of each framework, rather than a superficial acquaintance with them
  • Write real hands-on test cases of multiple platforms, compare the functions and performance of each platform, understand their community conditions, technical services
  • You need to be able to track and update your report over the long term to avoid it becoming outdated six months later

In other words: To be honest, you have to go deep!

The UNI-App team took two weeks to complete the report and insisted on updating it quarterly. The current update is May 2019.

This paper makes a horizontal comparison between wechat’s native and mainstream development frameworks such as WEPY, MPvue, Taro and Uni-APP from two dimensions of user and developer, hoping to provide a reference for developers in the selection of small program framework. Based on the available public data and real test data collected from the official website of each framework, this paper aims to objectively and fairly evaluate the status quo and advantages and disadvantages of each framework. But for the sake of interest, the view of this paper is likely to be biased, you can take a critical view, if you find any evaluation distortion in this paper, welcome to issuse here.

User-oriented and developer-oriented dimensions, including:

  1. Users: Provide complete service implementation and guarantee high performance experience
  2. Developers: Smooth learning curve, modern development experience (engineering), efficient community support, active development iterations, multi-reuse

1. The user

1.1 Function Implementation

The primary goal of software development is to provide complete, closed-loop business functionality to the user.

In Web development, if the use of vue, React and other frameworks makes it impossible for developers to manipulate all the apis provided by the browser, such frameworks are definitely immature. The same goes for applets. No development framework can limit the underlying API calls.

The bottom layer of various business functions relies on the components and interfaces exposed by wechat (components and API specifications introduced on wechat official website, namely wechat native API), and the three-party framework is a secondary encapsulation based on wechat native. Developers often have a question at this time: Applets are constantly being upgraded. What if a business relies on the latest applets API, but the tripartite framework has not been encapsulated?

In fact, just like vUE and React for Web development, the browser releases a new API and does not involve vUE and React upgrades. None of the frameworks in this review limit developers’ ability to invoke the underlying capabilities. Here’s why:

  • Wepy: there is no secondary encapsulation of the API for small programs. The API is still wechat native, and the framework has nothing to do with whether the API is added to wechat small programs
  • Mpvue: supports all native components and apis of wechat without limitation. The framework also encapsulates its own cross-end API, which is used in a similar waympvue.request()
  • Taro: Support all native wechat components and apis, unlimited. The framework also encapsulates its own cross-end API, which is used in a similar wayTaro.request()To supportTaro code mixed with small program code, can be mixed by the way to call the framework has not encapsulated the applets added API
  • Uni-app: Supports all native components and apis of wechat, without limitation. In terms of cross-terminal, even if we still use wechat’s native components and APIS, we can directly cross-terminal compile to App, H5, Alipay, Baidu Toutiao and other small programs. However, for management clarity, it is recommended to use the API wrapped in UNI, similaruni.request(). At the same time supportConditional compilationIn conditionally compiled code blocks, you can freely call new apis and components of each platform

Note: The above order, according to the birth order of each framework, the same as below.

Therefore, all the three frameworks can call all apPLETS API to fulfill the user’s business requirements. There is no difference between the frameworks in this dimension.

The difference, however, is the performance experience.

1.2 Performance Experience

Tripartite framework, most of the internal do layers of encapsulation, these encapsulation will increase the operating load, resulting in performance degradation? Especially compared with the native micro channel small program development performance, this is a common concern.

For objective comparison, we have specially built a test model as follows:

  • Development content: develop a complex long list of the front page of micro blog mini program, supporting pull down to refresh, pull up to turn the page, like.

  • The interface is as follows:

  • Development version: A total of 5 versions have been developed, including wechat native version, WEPY version, MPvue version, taro version and UNI-app version, which are installed by default through cli according to the official website guidelines.

  • Test code open source (making warehouse address: https://github.com/dcloudio/test-framework), Tips: if you have any classmates think test code written inappropriate and welcome to submit PR or Issus

  • Test models: Redmi 6 Pro, MIUI 10.2.2.0 Stable version (latest version), wechat 7.0.3 (latest version)

  • Test environment: Before each framework starts the test, kill each App process and empty the memory to ensure that the test machine environment is basically the same; Each time static data is read locally, network differences are shielded.

Using the above micro-blogging applets as an example, we tested two performance problems: long list loading and the response of a large number of likes.

1.2.1 Loading a long list

A list that mimics twitter is a list that contains many components. This complex list puts more pressure on performance and is good for performance testing.

Accurate timing is required from trigger pull-up loading to data update and page rendering completion. Human visual timing is definitely not good, so we adopt the method of burying the program and develop the following timing:

  • Timing start time: before an interactive event is triggered and a frame is assigned, such as the start of an onReachBottom function
  • Timing end: page rendering complete (wechat setData callback function start)

The beginning of the setData callback function can be considered as the page rendering completion time, because wechat setData is defined as follows (wechat specification) :

Test method: Starting from the empty list of the page, the program automatically triggers the pull-up loading, and 20 lists are added each time to record the single time consumption. When N pull-up loads are triggered continuously at a fixed interval, so that the page reaches 20*N lists, calculate the average time between these N pull-up loads and the completion of rendering.

The test results are as follows:

Description: Article 400 weibo list, for example, starting from an empty list page, every 1 seconds to trigger a tensile load on the new article 20 (weibo), recording a single time consuming, trigger 20 times after stop (article 400 weibo page), calculate the 20 times the average time consuming, results WeChat native on this 20 times trigger pull – > render to complete an average time of 876 milliseconds, The fastest uni-app is 741 ms and the slowest MPvue is 4493 ms

If you look at this data at first, you may be confused. Don’t worry, there are more details below

Note 1: Why is mpvue/ WEPY test data incomplete?

When MPVue and WEpy were born, wechat small programs did not support custom components and could not be developed componentarily. In order to solve this problem, MPVUE and WEPY compiled Vue components written by users into templates in WXML, realizing component-based development ability in a disguised way and improving code reuse, which was a great technical solution under the technical conditions at that time.

However, when the page is complex and has many components, the number of DOM nodes on the page will be greatly increased, even exceeding the dom node limit of wechat. According to our test on Redmi 6 Pro, when the number of page components exceeds 500, the micro-blog imitation App implemented by MPvue and WEpy will report the following abnormality and stop rendering. Therefore, the test data of these two test frameworks are incomplete when there are too many components. This means that when there are too many page components, these two frameworks cannot be used.

dom limit exceeded please check if there’s any mistake you’ve made

Tips1:wepyOfficial website of theCHANGELOG, mentioned that v1.7.2 test version added support for native components of small programs, the test pit is a lot, because it is a beta version, the official issue also said that it is not recommended to use; According to the official documentation, the default v1.7.3 version does not support native components

Tips2:wepyWhy the performance is better than wechat’s native framework within 400 lists depends on the management overhead of custom components and business scenarios (wepyCompiled as a template, which does not involve component creation and management overhead), the performance advantages of the wechat native framework are demonstrated when the component data is transferred. See the test data below.

Explanation 2: Why does the test data show uni-App performing slightly better than the wechat native framework?

In fact, with 200 records (200 components) on the page, taro’s performance data is also better than wechat’s native framework.

The time consuming of the wechat native framework is mainly in the call of setData. If the developer does not optimize it individually, a large amount of data will be passed each time. Uni-app and Taro do diff calculation automatically before calling setData, and only transfer changing data each time.

For example, the current page has 20 pieces of data, and when pull-up loading is triggered, 20 pieces of data will be loaded. At this time, when the native framework passes the following code test, setData will transmit 40 pieces of data

data: {
    listData: []
},
onReachBottom() {// pull up loadletlistData = this.data.listData; listData.push(... Api.getNews()); // This. SetData ({listData}) // Full data, send data to view layer}Copy the code

Developers using the wechat native framework can completely optimize and simplify the transmission of data by themselves, such as modifying the following:

data: {
    listData: []
},
onReachBottom() { // Pull up load
    // Get the index of the next render by length
    let index = this.data.listData.length;
    let newData = {}; // New change data
    Api.getNews().forEach((item) = > {
        newData['listData[' + (index++) + '] '] = item // assign value, index increment
    }) 
    this.setData(newData) // Delta data, send data to the view layer
}
Copy the code

After the above optimization and modification, the performance data of the wechat native framework is tested again as follows:

As can be seen from the test results, after manual optimization by developers, the wechat native framework can achieve better performance, but the performance gap between Uni-App and Taro is not big compared with the wechat native framework.

The result is similar to Web development, which also has native JS development, vUE, react frameworks, and so on. Without special optimization, web pages written with native JS often perform worse than the Vue and React frameworks.

It is precisely because of the excellent performance and development experience of Vue and React frameworks that the use of native JS development has been gradually reduced.

Evaluation conclusions: wechat native development manual optimization, Uni-app > wechat native development manual optimization,taro > WEpy > MPvue

Some people think uni-App is the same as MPvue. Uni-app did use MPVue in the early days, but it has since been redeveloped due to performance and vUE syntax support issues.

1.2.2 Response speed of liking components

Can a component in a long list, such as a “like” component, be clicked to change its “like” or “like” status in time? This is the test point.

Test method:

  • Select a microblog and click the “Like” button to switch the “like” status (highlighted “like”, gray “unliked”).
  • Thumb up buttononclickThe function starts the timer,setDataThe callback starts and ends the timer;

Multiple tests were conducted on Redmi 6 Pro, and the average results were as follows:

Note: When the number of lists is 400, it takes 111 milliseconds for the “like” button to change from the click to the status of the app developed by wechat native.

Test result data description:

  • The reason for the incomplete wepy/ MPvue test data is the same as above, the page is no longer rendered when there are too many components
  • The framework for component development based on wechat custom components (UNI-APP/Taro), the data communication performance of component is close to that of wechat native framework, and much higher than that based ontemplateFramework (WEPY/MPVUE) performance for component development

Component data update performance evaluation: wechat native development, Uni-app,taro > WEpy > MPvue

To sum up, this performance test carried out two tests, long list loading and component status update, and the conclusion is as follows:

Wechat native development manual optimization, Uni-app > wechat native development manual optimization,taro > WEpy > MPvue

2. The developers

On the premise of satisfying users’ business needs, let’s talk about developers’ needs and compare them from the following dimensions:

  • Smooth learning curve: easy to learn, preferably reuse existing technology stack, rich learning materials
  • Efficient development experience: modern front-end development process, engineering support
  • Efficient community support: Get help quickly when you encounter problems
  • Active development iterations: The framework is in a state of active updating without fear of downtime

2.1 A gentle learning curve

2.1.1 DSL syntax support

Choosing a DSL that the development team is familiar with and can pick up quickly is a fundamental point in the selection of the team framework.

First of all, wechat’s native development syntax, like React and Vue, is a bit nonsensically different. For developers, it is like learning a new syntax, which greatly increases the learning cost, which has been criticized by everyone.

Other development frameworks basically follow React and Vue (vUe-like) syntax. Their main purpose is to reuse engineers’ existing technology stacks and reduce learning costs. The React/Vue syntax is an important measure of how well the framework supports the React/Vue syntax. If the support is low and the syntax is different from that of the original framework, developers will have to learn a new framework, which will cost too much.

In actual development, we found that all the syntax of Vue and React on the Web was not fully implemented by each development framework:

The development style of Wepy is close to Vue. Js, which is a vUe-like implementation. It is a big step forward compared to wechat native development, but there is still a big gap compared to the complete Vue syntax.

The mpvue and Uni-APP frameworks are based on the vue. js core, and can run in the small program by modifying the runtime and compiler of vue. js. Mpvue supports slightly less Vue syntax, while UNI-App basically supports most Vue syntax, such as filter, complex JavaScript expressions, etc.

Taro’s support for JSX syntax is as complete as most support.

DSL syntax support reviews: Taro, UNI-app > MPvue > Wepy > wechat native

2.1.2 Degree of perfection of learning materials

Official documentation, problem search, sample demo completeness:

  • Wechat native: rich documentation, accurate API search, official sample demo, support to upgrade wechat developer tools on the official website, see the preview effect
  • Wepy: The document is only 2 pages, no search, component API and other documents are directly read wechat documents. No example demo is provided, and much of the configuration is guesswork. As shown in the
  • Mpvue: There are few documents, but its concept is not complicated. Documents such as component API can be read directly from wechat, which is easy to learn. Question search results are average. No sample demo is provided. As shown in the
  • Taro: Complete basic documentation, few resources for specific use of questions, and general query search effect. The demo only contains basic functions, and only one end of wechat is released. As shown in the
  • Uni-app: Rich content of basic documents and various usage topics, good problem search effect, complete demo function, and released as 7-terminal online. As shown in the

Teaching courses:

Evaluation of learning materials: wechat native > UNI-app > MPvue, taro > Wepy

2.2 Modern front-end development experience

At the level of development experience, the obvious disadvantage is wechat’s native development. The main gap lies in:

  • Framework development provides streamlined code organization (wechat native development, a Page consists of 4 files, write a code to open too many tag cards)
  • Framework development provides greater componentization capabilities
  • Framework development provides application state management (Vuex/Redux/Mobx, etc.)
  • Framework development can flexibly support various Sass and other preprocessors
  • Framework development provides full ES Next syntax support
  • Framework development facilitates custom build strategies

Other small program development frameworks all support CLI mode, can be developed in the mainstream front-end tools, and basically with d.ts syntax hint library.

Mpvue, Uni-app, taro directly support Vue and React syntax, supporting ide tool chain is rich, complete coloring, verification, formatting; Wepy is weaker, with some three-party maintenance of vscode plug-ins.

A good development tool can definitely improve the development experience. Uni-app, which is also the manufacturer of HBuilder, dcloud.io, is a framework that is significantly superior in this dimension. HBuilder is one of the four mainstream front-end development tools (compare with Baidu Index). It has made many optimizations for UNI-App, so the development efficiency and ease of use of UNI-App are not as good as other frameworks.

Develop experience dimensions and compare results: UNI-app > Taro, MPVue > Wepy > wechat native

Here’s the takeaway: If you need engineering capabilities, forget about wechat native development.

2.3 Efficient community support

Learning and development inevitably encounter problems, and official technical support and community engagement are important.

During the development of this evaluation demo, our students (mastering VUE and React at the same time) really felt the learning threshold caused by the differences in grammar, learning materials and community when learning and studying various multi-terminal frameworks, and spit out a lot of mistakes.

Comprehensive evaluation: wechat native, UNI-app > taro > MPvue > Wepy

2.4 Active development iterations

The developer must be concerned with the question: is the project being maintained over the long term?

Github commits, Changelog, baidu search indexes, and other indicators can be compared.

Making commits frequency

We collected the days of commit for each project on github master branch in April 2019 (from 4.1 to 4.30), and the results are as follows:

Tips:

  • Micro blog posts are closed source, and there are no commits, but they maintain a regular pace of updates at least once a month
  • wepyThe most recent 2.0.x branch had only 1 commit day in April

According to the commit records, taro and Uni-app are in a relatively active update state, while WEpy and MPvue are relatively weak, showing a state of no maintenance.

Product update log

Browse the product update log to see if the product is actively iterating, adding new features, and fixing user bugs.

We check the CHANGELOG of the official link of each framework respectively. Below is the link address:

  • Wechat basic library update log
  • Wepy website CHAGELOG
  • Mpvue official website Chang Log
  • Taro Github Update log
  • Uni-app official website update log

According to the comparison of product update logs, wechat native, Taro and UNI-app are updated frequently, bug fixes and new function supplements are all in a relatively compact state. However, mpvue and Wepy have not been released for a long time, and WEpy has not released an official version for nearly a year, so developers need to be careful in selection.

2.5 Multiterminal multiplexing

With the popularity of small programs in wechat, companies such as Alipay, Baidu and Bytedance have also entered the field of small programs. Each of these companies lives over 100 million days and has a large number of users. Business owners hope to reach every user with their business, no matter which small program the user is in.

What happens when the requirements go to the programmer? Is it true that bricks are moved everywhere on every platform? At this point, a set of code, multi-terminal release has become the dream of many programmers, small program cross-terminal framework came into being.

Can reality really be so ideal? Can each cross-end framework really be developed once and released to all applets as advertised on the official website? Even reuse code with the H5 platform?

Speaking by facts, we still used the above fake Microblog App and released it to each platform in turn to verify the compatibility of each framework at each end. The results are as follows:

Test results:

  • ⭕ indicates that it is supported and works properly, ❌ indicates that it is not supported, and other indicates that it is supported but has some bugs or compatibility problems

As can be seen from the simple examples: Uni-app,taro > MPvue > native wechat applet, wepy

But the above tests alone are not complete, and the actual business is much more complex than this test example. But we can’t develop a lot of complex businesses to measure, so we need to add some information from different documents. The cross-side support for various components and apis is described in the documentation for each framework. After reviewing the documents of several companies, we found that each company basically took wechat applets as the baseline, and then implemented various components and APIS on other ends:

  • taro: H5 end implements most oF wechat API
  • uni-app: Components, apis, and configurations. Most of them are implemented on each end. Some apis are not supported on some end. It can be seen that UNI-App completely implements a set of wechat simulator in H5 terminal

Cross-end framework, on the one hand, we should consider the universal CROSS-end API support provided by the framework, and at the same time, we should also consider how different features of different end are compatible. After all, each end will have its own characteristics, can not be completely consistent.

  • taro: provides the JS environment variable judgment and unified interface multi-terminal file, can be in the component, JS, file extension multi-terminal, does not support the sub-platform processing of other links.
  • uni-app: provides conditional compilation model, all code including components, JS, CSS, configuration JSON, files, directories, all support conditional compilation, can not be limited to write different codes.

Cross-end framework, also involving a CROSS-end problem of a UI framework, the evaluation results are as follows:

  • taro: Officialtaro ui, only support wechat small program and H5 ends, App is not supported.As shown in the
  • uni-app: Officialuni ui, can run at all ends; Uni-app also has a plug-in market that has a lot of tripartite UI components,As shown in the

Finally, add the cross-end case:

  • Mpvue: There are plenty of cases in wechat terminal, but no other terminal cases
  • Taro: There are plenty of cases on wechat. There are also a few cases on Baidu, Alipay and H5
  • Uni-app: Rich multi-terminal cases, official examples have been released to 7 terminals (including app terminal)

Based on the above information, the final evaluation conclusions of this project are as follows: UNI-app > taro > MPvue > native wechat applets and WEpy

Here can output a conclusion, if there are multiple publishing requirements, wechat native development, wepy these two ways can be directly excluded.

conclusion

Real and objective is always experiments and data, not conclusions. Developers with different needs can draw their own conclusions on selection according to the above experimental data.

But to be a complete review, we must also provide a summary, although it may add our subjective feelings:

Uni-app and Taro are better choices if you only develop wechat mini programs. They are the equivalent of Vue and React in the Web world. With these tools, you don’t need to use native WXML development.

  • If you insist on wechat native development, you need to pay attention to manually write optimization code to controlsetdataAnd note that its engineering capability is very weak
  • If you arereactFasten, then usetaro
  • If it isvueFasten, then useuni-app.uni-appIt has more advantages in performance, surrounding ecology and development efficiency

If you are developing multi-terminal, uni-App and Taro can be selected according to the technology stack you are familiar with. Uni-app is relatively more mature in multi-terminal.

Readers who find any of the reviews in this article distorted are welcome to post them hereissuse.