Preface: The following article was published in April 2019, and the review version for 2020 has also been released. The latest review click: In-depth review of cross-end Development Frameworks 2020 edition

Last week, Taro’s team released a comprehensive Review of Small Application Multi-endpoint Frameworks to give developers a taste of the industry’s leading cross-endpoint frameworks. Thanks to the Taro team for their efforts.

But it takes a lot of time to perfect it. Instead of just looking at the document, it needs to:

  • Write a real test demo of multiple platforms, compare the functions and performance of each platform, is their actual situation as advertised in the document?
  • What about actually learning each framework, understanding their learning curve, and getting a feel for their documentation, tutorials, community ecology, and tech capabilities when you run into problems in actual development?

Our Uni-App team took a week to complete this in-depth review, and below we share some of the problems encountered in the actual development of test cases for different frameworks, as well as the final test results.

Introduction to evaluation Experiment

  • 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 6 versions have been developed, including wechat native version, WEpy version, MPvue version, Taro version, UNI-app version, chameleon version (sorted by the release time of these products, the same below). They are installed by default through CLI according to the official website guidance (it should be the latest stable version).

  • 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.

  • Test dimensions:

    1. What is the cross-end support?
    2. How about performance?
    3. To study the threshold
    4. Tools and surrounding ecology

1. How is cross-end support

Developing once, running everywhere, is every programmer’s dream. But the reality is often to develop once, tuning errors everywhere.

Are the various frameworks to be evaluated really as one-development, multi-release as advertised?

We released the above micro-blog imitation App to each platform in turn to verify the compatibility of each framework at each end. The results are as follows (the table is long, so it needs to scroll left and right to view) :

platform WeChat native wepy mpvue taro uni-app chameleon
Wechat applets ⭕ ️ ⭕ ️ ⭕ ️ ⭕ ️ ⭕ ️ ⭕ ️
Alipay small program ❌ ❌ ⭕ ️ ⭕ ️ ⭕ ️ The pull-down refresh cannot be stopped
Baidu applet ❌ ❌ ⭕ ️ ⭕ ️ ⭕ ️ The pull-down refresh cannot be stopped
Headline applet ❌ ❌ ⭕ ️ ⭕ ️ ⭕ ️ ❌
The H5 end ❌ ❌ ❌ Pull-up load/pull-down refresh invalid ⭕ ️ Pull-up load/pull-down refresh invalid
The App end ❌ ❌ ❌ Pull-up loading failed ⭕ ️ Lists cannot scroll and cannot test pull-up load/pull-down refresh

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
  • wepyThe 2.0 claimed version already supports other applets on which this test is basedwepyOfficial website guide installationwepy-cliThe default version is 1.7.3, which does not yet support multi-terminal
  • chameleonOfficial website not foundstopPullDownRefreshDefinition (lookup date 2019.04.01), stop page pull-down refresh to be written platform by platform

As can be seen from this simple example, the evaluation results of cross-app support: Uni-app > taro > Chameleon > MPvue > Wepy, native wechat applets

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 terminal realizes most oF wechat API, App terminal and wechat are quite different.
  • 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 on the H5 end and a set of wechat applets engine on the APP end to achieve relatively perfect platform compatibility.
  • chameleon: Some of the most commonly used components and apis are already implemented on each side, with less platform variation. However, a large number of components and apis require developers to write their own code for each platform.

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.
  • chameleon: provides a polymorphic scheme, can be in the component, JS, file extension multi-terminal, do not support other ways of sub-platform processing.

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

  • taro: Officialtaro ui, support small programs (wechat/Alipay/Baidu), H5 platform, 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
  • chameleon: Officialcml-uiExtended component library, which can run fully, but with slightly fewer 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: There are rich cases of wechat, APP and H5, and official examples have been published to the 6 terminal
  • Chameleon: No end cases seen

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

There has been a friend business before a real cross end and pseudo cross end of the dispute, through the Demo measured, this debate can cover the coffin.

2. What is the performance of cross-end frame

Cross-end frameworks are generally implemented in Compiler + Runtime mode. Will runtime be degraded?

Especially compared with the native micro channel small program development performance, this is a common concern.

Again, using the example above, we tested two performance issues: long list loading and the response of a heavily liked component.

2.1 Long list loading

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) :

field type mandatory describe
data Object is The data to change this time
callback Function no Interface update caused by setDataRender to completeAfter the callback function

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. Calculate the average time it takes to complete the rendering for N pull-up loading triggers at a fixed interval so that the page reaches 20*N lists.

The test results are as follows (the table is long, so scroll left and right to view) :

List a number of WeChat native wepy mpvue taro uni-app chameleon
200 770 625 969 752 641 1261
400 876 781 4493 974 741 1970
600 1111 – – 1250 910 2917
800 1406 – – 1547 1113 4040
1000 1690 – – 1878 1321 5196

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, in this scheme, dom nodes will be greatly increased in pages with many complex components, even exceeding the dom node number 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

Tips: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 reflected when it comes to component data transmission. See the test data below.

Note 2: Uni-App performs better than wechat native framework? Playing god?

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 changed 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 lengthlet index = this.data.listData.length;
    letnewData = {}; GetNews ().foreach ((item) => {newData['listData[' + (index++) + '] '}) this.setData(newData) // Add data to view layer}Copy the code

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

Number of components Wechat native Framework (before optimization) Wechat native Framework (after optimization) uni-app taro
200 770 572 641 752
400 876 688 741 974
600 1111 855 910 1250
800 1406 1055 1113 1547
1000 1690 1260 1321 1878

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.

Review: wechat native development manual optimization, Uni-app > wechat native development manual optimization, Taro > Chameleon > Wepy > MPvue

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;

Run many tests on Redmi 6 Pro and average them. The results are as follows (the table is long and requires scrolling left and right) :

List the number of WeChat native wepy mpvue taro uni-app chameleon
200 91 279 666 92 93 101
400 111 501 1507 125 107 145
600 144 – – 152 148 178
800 176 – – 214 181 236
1000 220 – – 229 234 272

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 (UNI-app /taro/ Chameleon) that implements component development based on wechat custom components has data communication performance close to that of the wechat native framework, which is much higher than that based ontemplateFramework (WEPY/MPVUE) performance for component development

Component data update performance evaluation: wechat native development, Uni-app, Taro > Chameleon > 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 > Chameleon >> Wepy > MPvue

3. Learning thresholds

DSL syntax support

The mainstream cross-end frameworks basically follow React and Vue (vUe-like) syntax, whose main purpose is to reuse engineers’ existing technology stacks and reduce learning costs. In this case, cross-end frameworks’ support for the React/Vue syntax is an important measure. 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 the actual development, it was found that all the syntax of Vue and React on the Web were not fully implemented by various multi-terminal frameworks: Taro has relatively complete syntax support for JSX, and its documentation describes the future version plan.

More JSX syntax support, after 1.3 the only syntax that limits productivity is the creation of loop components using maps

The mpvue and Uni-APP frameworks are based on the vue. js core. By modifying the runtime and compiler of vue. js, they can run in the small program side and support most of Vue syntax. Uni-app was compiled to wechat using MPVue, but the framework was rewritten later to support more VUE syntax such as filter and complex JavaScript expressions.

Wepy and Chameleon are vUe-like implementations. They only support part of the syntax of Vue, and their rules need to be learned separately during development.

DSL syntax support reviews: Taro, UNI-app > mpvue > Wepy, Chameleon

Study material completeness

Official documentation, problem search, sample demo completeness:

  • Wepy: The document is only 2 pages long and no search is required. Only wechat is supported, so documents such as component API can be viewed directly from wechat. No sample demo is provided. As shown in the
  • Mpvue: There are few documents, but the concept is not complex, and there is no SUPPORT for H5 and App. Therefore, 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: The basic API documentation is complete, the specific use of the problem resources are few, the problem search effect is general, the demo only contains basic functions, only released one end of wechat. 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
  • Chameleon: The basic API documentation is complete, the specific use of the problem resources are few, the problem search effect is general, the sample demo only contains basic functions, only released one end of wechat. As shown in the

Teaching courses:

Learning materials: Uni-app > MPvue, taro > Chameleon > wepy

Technical support and community engagement

Development issues are inevitable, 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.

Uni-app > Taro > MPvue > Wepy > Chameleon

Tips: This evaluation ignores the learning thresholds of React and Vue frameworks themselves

4. Tools and surrounding ecology

tool

All multi-terminal frameworks support CLI mode and can be developed in mainstream front-end tools. Each framework basically comes with d.ts syntax hint library. Mpvue, Uni-app and Taro directly support vue and React syntax, and the supporting IDE tool chain is relatively rich, with perfect coloring, verification and formatting. Chameleon recommends plug-ins for some editors, and Wepy has some third-party maintenance plug-ins for VScode.

In the tool attribute dimension, the framework that is significantly superior is Uni-App, which is also the manufacturer of HBuilder, Dcloud.io. HBuilder/HBuilderX series is a domestic development tool with 3 million developer users. HBuilderX has done a lot of optimization for UNI-App, so uni-App is more efficient and easy to use than other frameworks. Of course, for developers who are not used to HBuilderX, uni-App does not have this advantage.

The surrounding ecological

A basic framework, its peripheral support is very important, such as UI library, JS library, project template.

  • Wepy: it has been around for a long time and has many open source projects.
  • Mpvue: It was released earlier and accumulated a lot of history.
  • Taro: The Taro UI is officially available, and there are several open source projects on Github.
  • Uni-app: Provides a plug-in market, RICH UI library and surrounding templates
  • Chameleon: The surrounding ecology has not been formed.

It is worth noting that uni-App and MPVue’s plug-in ecology are interlinked and both are VUE plug-ins. So the two sides also jointly held a plug-in competition. The peripheral richness of this united ecology is the richest among all frameworks.

By the way, I would like to advertise that the competent students are welcome to participate in uni-App/MPvue plug-in development competition to receive the iPhone Xs Max and other lucrative prizes.

Uni-app, MPvue > Wepy > Taro > Chameleon

Other common metrics

Making star:

wepy mpvue taro uni-app chameleon
18436 18085 20482 10035 5619

Github star count comparison: Taro > wepy > mpvue > uni-app > Chameleon

Tips:

  • Star number collection time: 2019.07.25 18:18
  • The number of STAR is related to product release time and user habits; In addition touni-appGithub issus is the main framework for communication and interaction.uni-appDevelopers are generally inuni-apptheQ&a communityGithub page view is low.

Baidu index

The Baidu index represents the number of searches by developers and the number of pages containing keywords. The baidu index of each cross-end frame in recent 7 days (2019-03-24 ~ 2019-03-30) is shown below:

Tips:

  • wepyIt is not included in the Baidu index, indicating that the number of searches and the number of pages containing the keyword are not large enough.
  • taroandchameleonThe name is taken from an existing name, and the index that actually refers to the development framework should be lower.

case

Just look at the cases posted to wechat, quantity and quality comprehensive comparison, wepy > MPvue > taro, uni-app > Chameleon

Uni-app > Taro > MPvue > Wepy > Chameleon

With the exception of UNI-App, other cross-end frameworks are produced by first-tier developers themselves, who use these frameworks for their internal projects and are battle-tested. At the same time, few other big developers use such frameworks.

There is a face-saving problem and a compatibility problem. Many developers build frameworks that can meet their own business needs, but after opening up to the outside world to satisfy all developers, they still need to put in a lot of work to improve the product, many developers are not in the main business, and do not do so.

This is why many open source projects are called KPI projects.

To be fair, the Uni-App team is also surprised and impressed that Bump Lab has put so much effort into polishing Taro. The Chameleon team also invested a lot in the early stage, but the release time is still short, so it is admirable if the team can continue to invest in the long term. The UNI-App team itself is a professional developer service. There are many cases, but most of them are entrepreneurs.

It can be said that the whole multi-terminal framework market is still in its infancy, and it needs the joint efforts of all framework authors before it can be accepted by more developers.

Other Supplementary notes

Supplementary notes on App side

Currently, taro, Uni-App and Chameleon support the APP side. Taro uses Expo (a React Native based package library) and Chameleon uses Weex.

React Native and WEEX have completely different architectures from small program architectures, including typography and API capabilities. As a result, these products are not compatible across apps.

Uni-app comes with a complete applet engine built into the app side, complemented by an optional WEEx engine for performance-demanding developers. This is why UNI-App can run wechat applet code normally on the app side.

The whole industry does not exist a fully open source small program engine (wechat, Baidu, Alipay, toutiao small program engine source code are not open source). Uni-app’s applets engine is not fully open source, but the capability layer is open source, and the central control is not open source.

Therefore, various multi-terminal frameworks may have imperfections in the App side, which requires developers to pay attention to when using them.

The App engine is not the front end, but another arena in the native realm. Uni-app will publish a review of Cordova, React Native, Weex and Flutter.

Conversion and mash-up

Taro provides a translator for converting native applets into Taro projects. It also supports the ability to embed some pages written by Taro in native applets, which is a feature of Taro that is not provided by other cross-end frameworks. That goes a long way toward lowering barriers to entry.

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 is a better solution if you want to develop more efficiently and without too many pitfalls.

If you only develop wechat mini programs and do not do many things, then use uni-App, wechat native development, taro are better choices.

  • If you use wechat native development, you need to pay attention to manually write optimization code to controlsetdata
  • 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 mainly for wechat and H5, then uni-App and Taro are ok. You can choose according to the technology stack you are familiar with.

Uni-app is more compatible if you mainly need to cross App side, other frameworks are too different on App side. If you only care about apps and don’t care about applets and H5, please check out our review of Uni-App in depth compared to Cordova, React Native and Flutter.

In addition to Uni-App and Taro, MPVue is also a good choice if you are mainly looking for small applications and don’t need complex components. Mpvue released version 2.0, the search index climbed significantly, hope to continue to update, usher in the second prosperity.

Chameleon is new and offers few components and apis, but its future plans are interesting to watch.

After writing this review, my editor was a little apprehensive.

On the one hand, this review is not very gentle and can offend people. However, we believe that such reviews will inspire all cross-end framework practitioners to invest more in improving their products, which is great for the industry and front-end developers.

On the other hand, readers may think uni-App is perfect at this stage, but we know uni-App has a lot of work to do. The UNI-App team will continue to work hard to benefit front-end developers in China!

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