Abstract: WeChat small program development skills.
- Author: coldsnap
- Small program multi – terminal framework comprehensive evaluation
FundebugReprinted with authorization, all copyright belongs to the original author.
Recently, the front-end multi-terminal framework frequency, I believe that many developers who have the need to run multi-terminal code will have some doubts: what are the advantages and disadvantages of these frameworks? Which one should I use?
As a member of the TARO development team, I want to evaluate the selection and merits of each framework from an objective and fair perspective. But with respect to the interests, the point of view of this paper is likely to be biased, we can take a critical eye to look at, when the right to throw a brick to attract jade.
So, what are we talking about when we talk about multiterminal frameworks:
multiterminal
The author thinks that the current popular multi-terminal framework can be roughly divided into three categories:
1. The total package type
The biggest feature of this kind of framework is that the rendering engine and layout engine at the bottom level, the DSL at the middle level, and the framework at the top level are all developed by ourselves. The representative frameworks are Qt and Flutter. The advantages of this type of framework are obvious: high performance; All platforms render the same result. The downsides are also obvious: the need to completely relearn the DSL (QML/ DART), and the difficulty of adapting to the Chinese side: small programs.
This kind of framework is the most original and the most pure multi-terminal development framework, because every link from the bottom to the top is in your own hands, it can also ensure the development and cross-end experience is consistent as much as possible. But their framework development cost is huge, rendering engine, layout engine, DSL, upper framework each part needs a lot of manpower development and maintenance.
2. Web technology
These frameworks bring Web technologies (JavaScript, CSS) to mobile development, develop a self-developed layout engine to handle CSS, write business logic in JavaScript, use popular front-end frameworks as DSLs, and render each end with its own native components. The representative frameworks are React Native and Weex. The advantages of this approach include:
- To develop rapidly
- Reuse front-end ecology
- Easy to learn, no matter the front end and back end mobile end, more or less will be a little JS, CSS
Disadvantages are:
- The design of such frameworks inevitably results in the difficulty of writing high-performance code when the interaction is complex
JS和NativeCommunication is required between each other, and frequently triggering communication such as gesture manipulation is likely to cause the UI to fail to draw in time within 16ms. React Native has some declarative components to avoid this problem, but declarative writing is difficult for complex interactions. - Since there is no rendering engine, using native components at each end renders the same code with less consistency than the first one.
3. JavaScript compiled
These frameworks are the subjects of this article: Taro, Wepy, Uni-App, Mpvue, Chameleon, and they all work in much the same way: Firstly, a DSL framework is selected based on JavaScript, and the DSL framework is compiled into different codes on each side respectively. Each side has a runtime framework or compatible component library to ensure that the code runs correctly.
The biggest advantage and reason for the creation of these frameworks is small programs, because in addition to being cross-platform, the first and second frameworks can also be compiled and run in the browser. Qt has Qt for WebAssembly, Flutter has Hummingbird, React Native has React -Native-Web, Weex Native support.
Another advantage is that React Native/Weex is usually compiled on mobile, so they both have the advantages of Web technology based frameworks. This may seem nice, but the React Native/Weex drawback is that compiled frameworks are also unavoidable. In addition, the abstraction of compiled frameworks is not free: when bugs occur, the root cause of the problem can be runtime, compile-time, component libraries, and libraries that all three depend on. As Taro opened source, we encountered bugs with Babel, with React Native, with the JavaScript engine, and of course with Taro itself. It is believed that other frameworks with the same principles cannot avoid this problem.
But that doesn’t mean that such multiterminal frameworks designed for small programs aren’t all that useful. First of all, there are a lot of small programs in the super APP of the giants. The framework will do a lot of work to smooth out the small programs, which in most cases does not need the developers to care about. The second is that many business types do not require complex logic and interaction and are less likely to trigger bugs in the underlying dependencies of the framework.
When it comes to choosing a compiled framework for your business, it seems to me that the first thing to consider is the starting point for choosing a DSL. Because businesses with multiple requirements often want to develop quickly, a DSL that can quickly adapt to the pace of a team’s development is critical. Both React and Vue (or Vue like) have their strengths and weaknesses, which you can choose from based on your team’s technology stack and preferences.
If whatever DSL is acceptable, then we can move on to the next step:
ecological
The following is based on the fact that each framework is now in stable release (March 11, 2019).
1. Development tools
As far as development tools go, the Uni-app is a standout. It has the most extensive documentation and comes with an IDE graphical development tool that allows you to compile, test and publish with a click of a mouse.
Other frameworks use CLI command-line tools, but it’s worth noting that Chameleon has its own syntax checker, and Taro writes its own ESLint rules and rule sets.
TypeScript is supported by MPVue, Uni-App, Taro, and WEPY, and all of them can achieve editor auto-completion through typing. In addition to API completion, Taro also automates component completion thanks to TypeScript’s good support for JSX.
In terms of CSS, all frameworks support SASS, LESS and Stylus, while Taro supports one more CSS Modules.
So the result of this round of competition should be:
Uni – App > Taro > Chameleon > WEPY, MPVUE
2. Multi-terminal support
Just in terms of the number of supported apps, Taro and Uni-App are slightly ahead with six apps (Mobile, H5, WeChat applet, Baidu applet, Alipay applet, Toutiao applet), while Chameleon is close behind without Toutiao applet.
But it is worth mentioning that Chameleon has a set of self-developed polymorphic protocol, so the experience of writing multi-terminal code will be much better, which can be said to be a function that can poke the pain point of multi-terminal development. Uni-app has a separate conditional compilation syntax that works with JS, style, and template files. Taro can use conditional compilation in business logic based on environment variables, or can use conditional compilation of files directly (in a similar way to React Native).
In the aspect of mobile terminal, UNI-APP custom-made a set of NVUE scheme based on weex to make up for the deficiency of weex API; Taro does the same thing with Expo for a while; Chameleon has a set of SDK in mobile terminal to cooperate with multi-terminal protocol to communicate with native language.
In terms of H5, Chameleon is also supported by polymorphic protocol implementation, while Uni-App and Taro both implement a set of compatible component libraries and APIs in H5.
Both MPVue and Weby provide the ability to convert applets on each side, but neither has H5 or mobile support.
So the final round of comparisons:
Chameleon > Taro, Uni-App > MPVUE > WEPY
3. Component library/tool library /demo
As the framework with the longest open source history, WEPY has certain advantages in terms of Demo, number of component libraries and tool libraries.
Uni-app has its own plugin market and UI library, and if you count the paid frameworks and plugins, it’s nothing compared to Weby.
Taro also has an officially maintained cross-end UI library, Taro-UI, and a very rich selection of state management tools (Redux, Mobx, DVA), but the number of demos is not as great as the first two. But Taro has a tool for converting WeChat applet code to Taro code, which can remedy this problem.
While MPVue has no officially maintained UI library, Chameleon third-party demos and tool libraries are also basically missing.
So the order of this round is:
WePY > uni-app 、taro > mpvue > chameleon
4. Access costs
There are two aspects to access costs:
The first is that the framework plugs into the existing WeChat applet ecosystem. As the WeChat applet has become the dominant one, the open source components and libraries (such as WXParse, Echart, Zan-UI, etc.) are mostly written based on the native WeChat applet framework syntax. At present, it seems that there are documents or demos that directly use native applet components/libraries in the framework of UNI-APP, TARO and MPVUE. WEPY needs to change the source code of the target library in many cases due to the problems of the operation mechanism, while Chameleon provides a migration way to change the source code of the target library step by step.
Second, the original WeChat small program project part access framework reconstruction. In this regard, TARO has carried out a bold practice on Jingdong Shopping Mini Program. For details, please see the article “TARO’s Practice on Jingdong Shopping Mini Program”. Other frameworks don’t mention it.
For both access methods, TARO provides the TARO Convert function, which allows you to convert existing WeChat applet projects into TARO multi-terminal code, and to convert components of the WeChat applet ecosystem into TARO components.
So the order of this round is:
Taro > MPVue, Uni-App > WEPY > Chameleon
popularity
According to the GitHub Star, the difference between MPVue, Taro, and WEPy is very small. Taro (3K/Week) > MPVUE (2K/W) > WEPY (1K/W). But the timing was reversed. The author estimates the popularity of 3 and cases are not too much.
Uni-App claims tens of thousands of applications, but unlike other frameworks, it doesn’t have the same number of major applications. Uni-App also leads in terms of the number of developers, with more than 20 QQ communication groups (with a maximum of 2,000).
So in terms of popularity, it should be:
Uni-App > Taro, WEPY, MPVUE > Chameleon
5. Open source construction
How far an open source product can go is determined by the framework maintenance team and third-party developers. While open source construction cannot be specifically quantified, it is still a very important measure of the viability of a framework/library.
Taro leads the way in terms of the number of third party contributors, and some of Taro’s core packages/features (Mobx, CSS Modules, Alias) are also contributed by third party developers. In addition, Tencent’s open source Omi framework applet part is also based on Taro.
Wepy also has a good performance in this respect with the support of Tencent’s open source plan; MPVue has been stagnant for a long time and is lagging behind; Perhaps due to the product strategy, Uni-App is not enthusiastic about open source construction, and even some of the code is not open source. Chameleon is new to open source, but its code and test cases are very formal, and it may do well in the future.
So the comparison for this round:
Taro > WePY > mpvue > chameleon > uni-app
Finally, add a total ecological comparison chart:
In the future
From the plans that have been published by the frameworks:
Weby has released v2.0. Alpha, and while there is no public documentation available to see what new features are in the 2.0 release, according to its authors, Weby 2.0 will be a “developer friendly” release that is scaled up. I’m also looking forward to the performance of Weby after the 2.0 release.
MPVue has released version 2.0, which is mainly updated with support for other applets. But from the point of view of the reply/resolution rate of the code submission and issue, MPVUE wants to make a difference in the future, first of all, we need to dispel the community’s doubts about MPVUE regardless of whether it is updated.
Uni-App is already ecologically well built and should continue to grow steadily from there. If Uni-App can strengthen open source and cooperation with Dachang, I believe it will be able to reach a higher level in the future.
Chameleon’s plan is quite ambitious. Although it is the last framework, the following features are already planned or being implemented:
- Fast application and side extension protocols
- Generic component libraries and vertical class component libraries
- Graphical development tool for R&D
- Graphical page building tool for non – research and development
If Chameleon can make these features work, and then continue to improve the ecosystem and win over more third-party developers, then Chameleon will have a great future.
Taro’s future is just as promising. The upcoming 1.3 release of Taro will support the following features:
- Quick application support
- Taro Doctor, which automatically checks project configuration and code legitimacy
- More JSX syntax support, after 1.3 limited productivity syntax only
You can only create loop components with a Mapa - H5 package size is greatly reduced
Taro is also in the midst of a major refactoring of the mobile end; Develop graphical development tools; Develop component/material platform and graphical page builder.
conclusion
So with all that said, which one do we use?
If you don’t mind trying something new and learning DSL, you can try Weby 2.0 and Chameleon. One is a new 2.0 update that has been in the works for a long time, and the other has a polymorphic protocol for multi-terminal development.
Compared to Taro, the Uni-App is more of a “bucket” framework, with no obvious shortfalls in terms of tools, UI library, development experience, multi-terminal support, etc. MPVue has been stalled in development and now seems to be in every way inferior to the uni-app based on it on the small program side.
M: Yes, Talk is cheap. If you are more interested in this topic, you can go to GitHub for further research. If you have time to look at the code, you can not look at the submission:
- chameleon: https://github.com/didi/chameleon
- mpvue: https://github.com/Meituan-Dianping/mpvue
- Taro: https://github.com/NervJS/taro
- uni-app: https://github.com/dcloudio/uni-app
- WePY: https://github.com/Tencent/wepy
(Sort alphabetically)
About Fundebug
FunDebug focuses on real-time BUG monitoring for online applications such as JavaScript, WeChat applets, WeChat games, Alipay applets, React Native, Node.js and Java. Since its official launch on November 11, 2016, FunDebug has handled more than 1 billion error events in total. Its paying customers include many brand enterprises such as Google, 360, Kingsoft, and Peopling.com. Welcome to try it for free!
