Taro architecture analysis (1): multi-terminal framework analysis, Taro WePY uni-app comparison

Multi-terminal framework classification

All inclusive

The biggest feature of this type of framework is that everything from the underlying rendering engine and layout engine to the middle-level DSL and the upper-level framework are developed by themselves . The representative frameworks are Qt and Flutter. The advantages of this type of framework are very obvious: high performance (upper limit); consistent rendering results across platforms. The shortcomings are also very obvious: it requires completely relearning DSL (QML/Dart), and it is difficult to adapt to the terminal with Chinese characteristics: small programs.

This type of framework is the most original and purest multi-terminal development framework. Since every link from the bottom to the upper layer is in your own hands, it can also ensure consistent development and cross-terminal experience to the greatest extent possible. However, their framework development costs are huge. Each part of the rendering engine, layout engine, DSL, and upper-layer framework requires a lot of manpower to develop and maintain.

Web technology

This type of framework brings web technologies (JavaScript, CSS) to mobile development. It uses a self-developed layout engine to process CSS, uses JavaScript to write business logic, uses popular front-end frameworks as DSL, and each end uses its own native component for rendering. Representative frameworks are React Native and Weex, do this

The advantages are:

Develop quickly
Reuse front-end ecology
Easy to learn and use, no matter the front-end or back-end mobile version, you can learn more or less JS and CSS

The disadvantages are:

It is difficult to write high-performance code when the interaction is complex. The design of this type of framework will inevitably lead to the need for communication between JS and Native. Frequent triggering of communication such as gesture operations is likely to prevent the UI from being drawn in time within 16ms . React Native has some declarative components that can avoid this problem, but the declarative writing method is difficult to meet the needs of complex interactions.

Since there is no rendering engine and the native components of each end are used for rendering, the rendering consistency of the same code is not as high as the first one .

JavaScript compiled

This type of framework is the protagonist of our article: Taro, WePY, uni-app, mpvue, chameleon. Their principles are also similar: first select a DSL framework based on JavaScript, and use this DSL framework as the standard to Each end is compiled into different codes respectively, and each end has a runtime framework or compatible component library to ensure that the code runs correctly.

The biggest advantage and the biggest reason for the creation of this type of framework is the small program, because in addition to being able to cross system platforms, 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, and Weex has native support)

Another advantage is that the mobile terminal is generally compiled into React Native/Weex, so they also have the advantages of web technology frameworks. This looks great, but in fact the shortcomings of React Native/Weex compiled frameworks cannot be avoided. In addition, the abstraction of compiled frameworks is not free: when bugs occur, the root of the problem may lie in runtime, compile time, component libraries, and libraries that the three depend on, etc.

In the process of Taro's open source development, we have encountered Babel bugs, React Native bugs, JavaScript engine bugs, and of course Taro's own bugs. I believe that other frameworks with the same principles cannot avoid this problem.

But this does not mean that this kind of multi-terminal framework designed for small programs is not useful. First of all, there are now a hundred flowers of mini programs from giant super apps. The framework will do a lot of work to smooth out the mini programs. In most cases, developers do not need to care about these tasks . Secondly, many business types do not require complex logic and interaction , and it is not so easy to trigger bugs in the underlying dependencies of the framework .

So when your business is suitable for choosing a compiled framework, in the author's opinion, the first thing to consider is the starting point of choosing a DSL. Because businesses with multi-terminal requirements usually hope to develop quickly, a DSL that can quickly adapt to the team's development rhythm is crucial. Both React and Vue (or Vue-like) have their advantages and disadvantages, and you can choose according to your team's technology stack and preferences.