Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to cross the end correctly in the front-end development. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Cross-end

Write once, run everywhere .

We have all heard this classic slogan, and then we all know that nothing can really run everywhere, and at best it can only be debug everywhere.

And when we talk about writing multiple runs at once, it's obviously impossible to really mean across all sides, and in most cases you don't need to develop a function simultaneously on your computer and bracelet.

Across PC and wireless.

Across multiple Native platforms: for example, across Android and iOS, or even across Windows.

Cross-launch APP: with more and more super APP, many businesses need to put the same page in multiple APP.

Cross-Web and APP:Web are still inevitable in many cases, and our pages may need to be shared, SEO, put on M sites, and so on, so we need to be able to run in both Web and APP.

Cross-Web, multi-Mini Program, QuickApp, etc.: in fact, it used to be similar to cross-APP, but Mini Program itself is a closed ecology controlled by each family, so there is a demand for development to adapt to multiple closed ecosystems at once.

Cross-end demands of other ends: for example, cross-POS machines, watches, etc.

Corresponding to our various cross-end demands is a cross-end solution in which a hundred flowers blossom.

Cross-end scheme of letting a hundred flowers blossom H5 Hybrid scheme based on Web

This kind of solution is the most straightforward, simply using web pages to cross the end. Since most of our clients (even the closed Mini Program ecosystem) support Webview, we just need to develop web pages and put them into multiple ends. The corresponding solution on the desktop side is Electron.

Why not just use Web?

In terms of low development cost, unified standards and ecological prosperity, H5 Hybrid is basically the best choice. However, it is difficult to avoid gaps in performance and experience in this scheme. The ecological prosperity of Web comes from its good historical compatibility, which also means a heavy historical burden.

As an open technical standard, W3C standard has a lot of historical burden and complex logic.

The Web standard is not Design for Performance in design, which makes it difficult to further improve in many areas, such as JS execution cannot be paralleled with Layout and rendering mutexes, resulting in stutters due to long JS execution tasks that perform normal rendering.

The standardization of Web is also slow, and the new capabilities may take a long time to use.

React-Native/Weex class scheme

The performance experience on mobile platforms, especially in the early days of WebView, was very poor, and as we mentioned earlier, this gap is mainly due to the heavy historical burden of the Web ecology itself.

Schemes such as React-Native/Weex learn from each other as much as possible, by combining the ecology of Web and the components of Native, let JS execute the code and render with the components of Native. By abandoning the historical baggage of Web, this kind of scheme can make some drastic changes.

For example, RN, as shown in the following figure, puts JS execution, layout (Yoga) and rendering (Native components) into three processes separately to avoid interface stutters when JS executes complex tasks. By abandoning a large number of standards in CSS, only part of the flex layout capabilities are supported to reduce the complexity of layout and rendering.

This approach also has some drawbacks:

The inconsistent components and layout mechanism of both ends of iOS/Android make it difficult to guarantee the consistency of both ends.

Relying on the Native mechanism also makes it difficult to implement some CSS attributes, such as the long-standing z-index problem.

The most troublesome point is that this solution means very high maintenance and support costs.

Borrowed the ecology of Web but not entirely Web ecology, there are many inconsistencies, the most common complaint is that the usual CSS layout does not work.

Compared with the devtool that needs to be equipped with a new sensor API in the browser, the development experience guarantee of this kind of solution in most cases can be said to be slash-and-burn cultivation (the picture below is the devtool of Chrome's direction sensor API).

Today, when the performance gap of WebView is gradually narrowing, whether it is worthwhile to maintain the ROI of this complex solution needs to be considered according to the specific requirements of our scenario.

Flutter

The problem that Flutter wants to solve is different from the above solution, it does not intend to continue to borrow from the Web ecology, and the Web ecology is not taken into account from the beginning of the design. In contrast to RN, which relies on Native View rendering, Flutter is a self-drawn component that is drawn directly to the screen through Skia.

Because you can give full play to the ability of GPU, there is no need to go around Native. In theory, Flutter can achieve better performance and consistency between the two ends, which means that in the future, it is possible that Flutter-based JS dynamic solutions can support better styles than WEEX.

From the front-end perspective, it still looks more like a Native development solution than a cross-end solution (although it is actually cross-Android/iOS). The main problem at present is that the technical principle of Flutter for Web may be very far from being available in production. In addition, the ability to be dynamic does make some scenarios inapplicable.

Research and Development Framework for Mini Program

Mini Program is a created problem. Out of commercial considerations, Mini Program has actively constructed a relatively closed ecology on the basis of Web ecology. As a result, it is out of tune with the ecology of Web. However, it is difficult to accept the use of multiple Mini Program, or both Mini Program and Web.

Because the end of Mini Program is closed and uncontrolled, the cross-end problem of Mini Program can only be solved from the level of R & D framework.

Compile-time scheme

The more well-known compile-time scheme is Taro, the general principle can be explained as compiling JSX to Mini Program's WXML/WXSS/JS, but the implementation principle of this kind of framework is not really a React or React-like framework, but the template that looks like JSX is translated into Mini Program's own template by static compilation.

The limitation is very obvious, that is, JSX is the extension language of JavaScript (React Blog is written in is a syntax extension to JavaScript), while Mini Program's WXML is a template language with very limited expression, and it is impossible for us to compile from a general programming language to a template language.

In order to do this, the statically compiled class framework adopts a way to limit the way developers can write, which is why taro has made a lot of restrictions on how to write JSX. This directly led to endless maintenance costs and severely compromised development experience, and then taro/next turned to the combination of run-time solutions and static compilation optimization.

Runtime scenario

To put it immodestly, the runtime scheme for Mini Program should have been proposed at the earliest time when I wrote down the first issue of remax [1].

Through React Reconciler (similar to Rax Driver), we can make React running in the Mini Program container not directly manipulate DOM, but pass the operational data to Mini Program's View layer through setData to map to the final interface.

Although several schemes such as Remax, Rax runtime and Taro Next are different, the idea is more or less the same, that is, we use the dynamic ability of Mini Program template + VirtualDOM of React-like framework to render. Of course, this approach has a certain performance loss compared with the native rendering method of small programs.

Performance Test of Alipay side of remax

In some scenarios, the loss is worth it. These runtime frameworks are also improving performance by allowing you to turn off unused properties in compiled templates, partial static compilation, virtual lists, and so on.

Of course, in the end, embedded Webview is still a solution.

As a business technical team, what should we do?

The above are all solutions for specific scenarios, but for business technical teams, the essence of cross-end is efficiency. On the one hand, it is more important to put forward new plans for new changes, and more importantly, how to make this efficiency really long-term, so that our efficiency will not become a jump from one new plan to another.

Let's re-look at the above diagram and be sure that cross-end demands and corresponding solutions will still change frequently, and there will not be a solution to all cross-end problems. And the relatively constant part of it is worth investing in for the sake of long-term stability.

WebView & H5 Hybrid

WebView may be the most special of the many containers. Although it is difficult to meet the extreme requirements of performance and experience in some scenarios, it will be the most stable, long-standing and supported solution.

In terms of development efficiency and long-term maintenance evolution in the future, the Web solution is still the top priority on the premise that it can meet the requirements of performance experience.

At the same time, we can do more work on APP's WebView container, such as providing some in-side capabilities through the container, parallel data loading combined with Native capabilities, page preservation, and so on.

Infrastructure

No matter which cross-end scheme is adopted, the performance, stability and performance of the troika can not be bypassed in which container.

Performance

There are often different performance schemes for different solutions, and we also mentioned above that there are optimizations such as fields that reduce the output of compiled templates in Mini Program's run-time scheme. However, in fact, except for the optimization of this particular scheme, most of the optimization methods are more or less the same: offline caching, data prefetching, snapshots, SSR, NSR and so on.

For different ends and containers, the measurement and discovery of performance problems should also be consistent, and we need to have a clear perception and horizontal comparison of the performance of the page at different ends.

The end-to-side construction of performance (end-to-end capacity, performance measurement scheme specific to a certain end, performance management, etc.) may vary according to different end and different cross-end schemes. However, the performance infrastructure (first screen standards, data analysis, basic optimization capabilities) should be relatively stable across the end.

In terms of end-to-side capability, ICBU introduced the parallel loading ability in the early WEEX performance optimization, and used the parallel loading capability of the container through the wh_prefetch protocol. Then in the new container (WebView, browser), although the underlying capabilities are different, the same protocol is still identified.

In terms of data collection and analysis, we unify the cross-end basic database, so that different technical solutions at different ends can be analyzed, measured and compared under the same standard.

Stability construction

On the wireless side, we often refer to performance-stability as "high availability". The main scope of stability includes grayscale capability, business monitoring, alarm, error monitoring, white screen detection and so on.

These capabilities are less dependent on specific end-to-end and cross-end solutions, and other construction parts are relatively stable except for a slight difference in end-side data collection logic. The group also has some cross-end available solutions for these scenarios, such as iTrace.

Engineering infrastructure

For the cross-end of different scenarios, although there are some differences in the scheme, our engineering infrastructure can be unified.

The container layer provides unified API and documentation capabilities

Unified R & D process

R & D tools provide unified package grabbing, debug capabilities, etc.

Consistent tool library, etc.

In this way, when a new container or solution appears, we only need to align according to the appropriate capabilities to maintain a relatively stable state of our upper-level business code and development experience.

Business logic cross-end

Relatively speaking, we will find that in the evolution of a variety of cross-end solutions, the changes at the UI level such as how to render and how to layout are far greater than those at the business logic level. Even Mini Program and Flutter have not changed much in their general development paradigm. For example, the Flutter development paradigm is very similar to React, which is both declarative UI and VirtualDOM.

Considering SEO and performance issues and Flutter's own Skia-based rendering mode, Flutter for Web may not be available in a production environment for quite a long time.

After unifying the organization of business logic code, we can use the Hooks for ALL scheme to enable Flutter and Web to share a Hooks-based business logic code.

Sometimes you don't need a real run everywhere, and being able to improve performance and consistency has already achieved your goal.

View layer

At present, the cross-end of the view layer is still full of variables. After our business logic layer is sufficiently atomized, maybe some of our interactive logic layers that are not particularly heavy can cover more cross-end scenarios by means of DX + binding atomized logic + data parameters. So as to meet the requirements of performance and efficiency at the same time.

However, there is still no silver bullet for the cross-end of the view of the general scenario.

The above is how to cross the end correctly in the front-end development shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.