Based on React and Vue, how does the mobile open source project Weex define the future?

[51CTO.com original article] This year, many people have said this on different occasions: the development of the Internet has entered a turning point, and mobile Internet has entered the second half. Today, the Internet has reached a turning point in new forms of interaction and new computing methods, and is constantly facing the challenge of how to produce better content and interaction methods.

Every progress and development of the Internet represents the possibility of connecting future changes through a more open, unified and standard architecture. If the emergence of React is to establish a new order of parallel research and development in the entire mobile client field, then I think Weex may be able to establish a new component ecosystem technology in 2017 and the future.

For all the application scopes of HTML5 front-end, in the past Web era, the capabilities we faced were mostly provided by browsers. As a container for program operation, different browsers provided APIs as tags to call. In today's intelligent era, hardware is constantly upgraded. Browsers as the main API provider can no longer meet the needs of application scenarios. Hardware capabilities have far exceeded the scope of browsers. Therefore, in the future mobile field, as hardware capabilities improve, it means professional and common components.

On December 15, 2016, the Alibaba Weex team shared with me the news that Apache accepted the donation of Alibaba's open source product Weex, which is expected to become the first Apache project in the Chinese mobile field. I believe that Apache's rigorous and open technical atmosphere will give the Weex project more research and development ideas, and of course it also represents Weex's determination to open source, community and internationalize.

So, what kind of mobile front-end cross-platform project is the open source Weex? With the recent public beta of Weex v0.9.5, let’s talk about the core innovative capabilities that Weex has for mobile developers.

Weex connects Web->Native

It can be said that the development trend of mobile terminals in recent years is to lean towards the Web terminal. JS-Native represented by React Native has largely blurred the boundaries between Web and Native applications. The emergence of Weex truly connects the Web engineering system with the internal Native, provides more capability expansion, and advances the process by a large step.

In order to be able to call upper-level businesses in a more standardized and transparent manner, Weex continues to use HTML5, JS, and CSS to achieve mobile cross-platform solutions that developers should pay attention to in the future.

The simple Weex page above contains a description of Weex and two texts on a picture. In fact, the entire page is divided into several layers, ***: The top layer is DSL, which includes JS, CSS, and JS, which makes the picture more interactive. The second layer is Virtual DOM, which can keep the three ends of IOS, Android, and H5 consistent, so it must be guaranteed at the architectural level, and at the same time, H5 is regarded as an independent rendering end at the special architectural level.

This is also a framework for Weex to build UI across platforms, which needs to have four features:

1) Lightweight: The learning cost is low, and the entire SDK is relatively lightweight.

2) Extensibility: Supports connecting Native components to Weex. At the same time, there is a URL interception work, registering module extensions to the system, fully customizing module extensions, and providing some modules, as well as support for ***'s dom and Steam, a JS Service, and a dependency management mechanism similar to JS Service***. Business parties can decentralize and horizontally customize components and functional modules.

3) Performance: Rendering is the most intuitive aspect on mobile devices, so we need to achieve high-speed loading, high-speed rendering, and experience flow in terms of frame rate and memory.

4) CPU: It is directly related to power consumption and operating efficiency, ensuring that content consumption is reduced without reducing the frame rate.

Therefore, the rendering speed of the first screen must determine the quality of the user experience. The author remembers that in the main venue page of Double 11, the entire page was divided into two parts. The first sub-venue framework was completely written in Weex JS. During the loading process, the naked eye could not distinguish it. According to the author's statistics, the local performance was about within 100 milliseconds. The naked eye could not distinguish whether it was Weex, H5 or Native.

Weex custom components

The entire Weex project is divided into 5 layers: the first layer is the business layer, which is mainly used to access the business and is carried in the form of a client. The second layer is the middleware layer, where the entire publishing platform, preloading, components, and some APIs are placed. The latter is the tool group layer, DSL, and Engine.

Next, let's take a look at the changes in the overall architecture:

Weex has added a Market layer, which includes a component library, namely DysAPI, and also covers some business-related APIs and Cookie mechanisms, Shema interception mechanisms, front-end stores, API support, tool support, and other support for the entire site.

The R&D support layer provides packaging for release, phased release, and online monitoring in the context of rapid business expansion. Below, the author focuses on analyzing the core issues that the Market layer can solve.

Market has the ability to quickly release, update and maintain components. It can be simply understood that developers can make components themselves, and then add, delete and check components in seconds through Market, which is more in line with everyone's technical thinking.

According to the tool map shown in the figure below, SDK, Devtools, and Playground can help developers quickly debug and error, create a complete Weex application through WeexPack, add components written by developers themselves, find more useful components from the Market, and finally complete all Weex-related operations through Weex CLi.

Integration with Vue

Speaking of Vue, the author has to introduce it in detail. It has developed rapidly since last year, and more and more key projects have been using it, including excellent projects such as Ele.me, Rare Earth Nuggets, Suning.com, Shenma Search, Changting Technology, Lizhi FM, Taobao Mobile, Fangduoduo, etc. In my personal opinion, there are desktop, mobile, user-oriented and background, etc. The whole vue development experience is very pleasant. Each page has a corresponding Vue file. In addition, it is more suitable for component development. When encountering more complex scenarios where frequent communication between parent and child components is required, vuex can be used. In general, it is a very excellent project.

Vuejs is a progressive framework. In the words of the author You Yuxi, "it makes high-end things approachable". It has simple syntax and solves complex problems, and solves them very well.

Let's talk about Weex. The choice of cooperating with such an excellent project as Vue.js has created a lot of sparks. The first is streaming rendering. Weex can control the granularity of the entire loading after the first rendering. This feature makes Weex reach the level of Vuejs; the second is that there is a very classic two-way data binding in Vuejs that developers like very much. It has been extended from Vuejs to Weex. The third is the management content of Weex to avoid memory leaks and ensure the long-term stability of the application. In the entire cooperation, Weex has basically integrated the advantages of Vuejs, and all the current development problems have been basically solved. Based on Vue2.0, a faster and better HTML5 rendering engine is established to support Transition transition animation writing. These are also the five features brought by the cooperation between Weex and Vue.

Below I will briefly summarize the feature enhancement list of Vue 2.0 in Weex:

• Streaming rendering logic control to optimize the first screen rendering time
• Two-way data binding, convenient for writing form space logic
• Securely manage multi-instance memory to avoid memory leaks and ensure long-term stability of applications
• Building a faster and better HTML5 rendering engine directly based on Vue 2.0
• Support <transitiion> transition animation writing

At the same time, Weex has also made comprehensive adaptations to Vue2.0 in peripheral tools, including the Loader, Cli, router, etc. that developers are familiar with. As for Hacker News, Weex cannot yet do server-side rendering, but other than that, all functions cover all versions of Hacker News. Below:

Weex Ecological Evolution

How do we understand an open source project like Weex, and the subsequent ecological evolution process? In a conversation with Yuan Xin, the head of Taobao FED, the author actually thought so.

Today's Weex can be understood as follows: it is roughly divided into two layers. One is the engine layer, and the other is the framework layer. In front-end terms, it is the browser's rendering engine, such as V8 or WebKit, and the other is the upper framework.

Weex is not only a framework, but a combination of the two. For an engine, it is constantly evolving and will not fade away with the passage of time. For a framework, it can be React or Vue, but it is still unknown what will be used in the future. Therefore, the development and update of the entire front-end framework layer is very fast, basically a cycle of two to three years. Yuanxin believes that Weex should be a solution that includes the engine layer and today's framework layer.

In fact, today's React is considered a standard, just like W3C, but the implementation of the API is determined by each browser manufacturer. If we regard React as a standard and then connect it with the Weex engine, the author believes that all APIs can be developed on the React language. Just like working with Vue, the advantages are integrated to fully meet the needs of developers.

So based on the React standard rendering engine, let's take a look at the entire implementation diagram:

In this implementation diagram, we can see that it is divided into three layers. The first layer is the original React component above, followed by the virtual DOM, and then the driver layer (which can be understood as an adaptation layer). Here, it can be adapted to different containers, including Natvie containers, HTML5 containers, and the entire PC Web container, so that everything can be produced in the entire backend engine. Let's take a look at the three major features of RAX after integration:

• The first is cross-container, which implements Native and Web through the intermediate driver layer;
• The second is lightweight. It is considered as a standard layer and can be self-implemented. In the process of implementation, it can make up for the time redundancy of itself, and the volume is only one-fourth of the original.
• The third is standards, based on W3C standards, maintaining the habits and development experience of all developers.

Therefore, the collision of cooperation can shape the Weex ecosystem and slowly give it vitality. In this process, the team can settle the DSL standards, and allow countless front-end frameworks and solutions to be connected, deeply integrated into the system, and open to more developers in the open source community.

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]