Changes and invariance in the wave of cross-end development

Since the beginning of the PC era in the early 1990s, with the rapid popularization of mobile networks, various mobile Internet devices have been emerging in the mobile era and IOT era around 2010. In addition to the most common PCs, Pads and smartphones, it may also be a small smart watch or a large screen terminal. Intelligent devices emerge in endlessly, filling all corners of people's lives, and the system type and screen size of devices are becoming increasingly fragmented.

The data shows that the current user has an average of 5 intelligent devices; It is estimated that by the end of 2022, China's Internet of Things connectivity will exceed 10 billion devices. With the rapid growth of intelligent devices, users have increasingly strong demand for cross device connectivity such as smart home and smart office, which means that the demand for cross end development will also surge.

In the past, different types of hardware development were independent of each other. Mobile phones belonged to mobile phones, and computers belonged to computers. If the systems of the same type of hardware are different, the development is also independent of each other. iOS belongs to iOS, and Android belongs to Android. There is a lot of repetitive work behind this, and it is an inevitable trend that one-time development can meet the needs of the whole scenario. Because of this, there are endless cross end solution exploration.

Change and unchanging of cross end technology

Throughout the evolution of cross end technologies, from Web containers to pan Web containers to self rendering, technical solutions have been changing rapidly. The cost of moving from one solution to another is equivalent to that of secondary development. How can we keep the business code unchanged no matter how the cross end technical solutions change? To solve this problem, we need to review the cross end technology evolution again.

Cross end technology evolution

1. Web container scheme:

Browsers and WebViews are standardized Web containers under the W3C specification, so Web pages can be easily put into any browser or WebView. In terms of development cost, unified standards and ecological prosperity, Web solutions are basically the best choice; However, the Web itself has some problems, such as slow page loading, large memory consumption, and poor interaction experience. Although a series of Web capability enhancement schemes, such as Hybrid, PWA and PHA, have been derived on the basis of the Web, which have greatly improved the performance and experience, the disadvantages of native performance and experience still exist.

The efficiency and dynamics of the Web are hard to achieve by Native development. The performance and experience of Native are also what the Web has always been pursuing. Is there a way to find a balance between them? The appearance of React Native has brought new ideas to developers.

2. Containerized Native Scheme: RN/Weex

In order to make up for the deficiencies in the performance and experience of the Web container solution, we can also have the efficiency of Web R&D; RN like containers learn from each other as much as possible and retain the JS engine, so as to maximize the connection with the front-end ecology and improve the development efficiency; For the sake of performance and experience, Native's rendering pipeline is reused in rendering, and native rendering is used to ensure performance and experience; Cross end can be achieved through similar container solutions, which are adopted by mainstream RN and Weex.

It seems that the containerized Native solution can not only have the native experience but also embrace the prosperous ecology of the Web. However, it still has problems: such as the consistency that is difficult to smooth, the lack of W3C standard support, the R&D experience, and the lack of surrounding ecology. However, the containerized Native solution is still successful, and it rapidly expands the frontend boundaries.

3. Self rendering scheme: Flutter

The Web container has performance problems, and the Native container has consistency problems; So can we bypass the native rendering pipeline and build our own rendering engine to solve the cross end consistency problem? The answer is inevitable. Flutter has implemented a self painting engine based on Skia; Therefore, Flutter is characterized by high consistency and good performance; But it also has its own shortcomings.

As a result of adopting a new idea in the design, we abandoned JS and used Dart as the development language, so there is a certain learning cost for both native and front-end research and development. However, from the perspective of developers, the learning cost is not particularly high. The bigger problem is that the front-end ecology needs to be rebuilt. CI, CD related to projects, and ecological related investment and intelligence need to be rebuilt, with huge costs.

It is for this reason that many front-end developers are deterred; Then naturally there are all kinds of explorations; The upper layer allows Flutter to better interface with the front-end ecosystem. The lower layer uses Flutter self painting rendering to ensure the consistency of multi terminal rendering. We will not start here.

4. One code multi throw cross app scheme for applets:

Applets help the head App establish a closed traffic system and container management and control. At the same time, the introduction of its dual thread model and self built DSL also brings new cross end problems. As major manufacturers have implemented their own small program containers and fast applications, the fragmentation of cross end containers has intensified.

Implementation schemes can be roughly divided into two categories: compile time and runtime.

• Compilation time idea: convert the business code of the framework to the native DSL of the applet during compilation;

• Runtime idea: cross end is realized by docking applet setData with runtime framework.

There are many such frameworks. In fact, one code and multiple inputs of applets is a kind of helplessness and technical compromise under the business model.

Change and Invariance in Evolution

Based on the introduction of the above cross end technology evolution, it will be found that no matter how the cross end technology solution changes, the cross end goal remains unchanged, and the pursuit of performance experience, delivery efficiency and multi end consistency is always maintained. The essence of the solution is nothing more than how to balance and choose.

Cross end technical solutions are changing all the time. The terminal capability requirements, containers, bridges, etc. based on the solutions are changing. The business development framework and infrastructure are also changing. How can we find the invariable existence in these changes, make chaos orderly by controlling variables, and make the evolution of cross end technology traceable? Can we take the "container" that will inevitably change in each solution iteration as the only variable, and keep the business code, infrastructure, R&D ecology, underlying capabilities, etc. unchanged?

• With a new container, the business code can still run stably on the new container without changing?

• With a new container, can the surrounding supporting facilities and R&D ecology be used continuously?

• If a new container is used, can the requirements for end capability remain unchanged?

Based on the above changes and invariants, "unifying cross end container specifications and realizing container standardization" is certainly a correct way. As long as the containers implemented according to this standard can be switched at will, without affecting the upper business, framework and infrastructure, so that cross ends can easily "write once, run anywhere".

How to standardize containers?

How to standardize

From the perspective of the Web, it is easy to find the answer. How do browsers standardize?

Let's take a look at the browser architecture first. The Web is rendered by the browser core, which executes HTML, CSS, JS and renders the UI expected by the developer. The kernel is mainly composed of browser engine and JS engine; The JS engine executes JS according to the TC39 (ECMAScript) standard. The browser engine is responsible for other work besides JS, such as DOM and CSS. It follows the W3C standard. The two engines are relatively independent and have strong cooperation. The implementation of these engines in different browsers is also different.

The core part of this architecture is WebCore, which is the basic capability of loading and rendering; All browsers in this part are shared; Other parts (the gray part in the figure) follow the same standard, but their implementations are different. Different browsers are allowed to design and implement in their own ways due to platform differences, different third-party dependencies, different needs, and other reasons.

Using the idea of browser for reference, we can also do this on cross end containers. Implementing cross end containers based on the same standards can greatly reduce our development work, while W3C standards can make it easier for us to connect to the front-end ecosystem. This is also true in Alibaba.

In terms of Alibaba's standardization practice, we have brought together several business units involved in cross end containers of the Group, and developed a subset of standards from four aspects: CSS/WebAPI/bridge channels, with reference to W3C/WHATWG standards and business needs.

Why do you choose to implement subset instead of full set? It is mainly considered after balancing performance and efficiency; It is undoubtedly the best to achieve standardized R&D efficiency and R&D experience; However, for cross end containers, various problems will be encountered, such as rounded corners, shadows, etc; There are many similar cases. Essentially, the design ideas of Web and Native are completely different. Forced adaptation will lead to serious performance degradation; In addition, browsers have been developed for many years. There are many related specifications and a lot of historical burdens. Performance on mobile and IoT is still a very challenging topic.

So whether a subset of HTML, CSS, and Web API standards has been developed to interface with the front-end ecosystem? I think it is not enough. From the current situation, different cross end containers have quite different standards, which will also lead to the inconsistency of cross end R&D ecology. In many cases, we need to make our own wheels; Many of the existing front-end and cross end ecosystems cannot be used directly; For example, our common debugging capabilities, because the containers implement different inspectors, it is difficult to use the existing Devtools directly, and most of them will develop their own Devtools; For example, WeexDevtools and AJXDevtools communicate based on remote debugging protocols, but their implementations are independent. Another example is the List component. Almost every cross end container needs the List component to solve the problem of list rendering, but they are all independently implemented custom List components. We have spent a lot of energy on these aspects. If we can share the capabilities of WebCore with WebCore in terms of core capabilities, then we can build a better cross end kernel, focus on optimizing the business field, and build a better and more suitable business container.

So whether a subset of HTML, CSS, and Web API standards has been developed to interface with the front-end ecosystem? I think it is not enough. From the current situation, different cross end containers have quite different standards, which will also lead to the inconsistency of cross end R&D ecology. In many cases, we need to make our own wheels; Many of the existing front-end and cross end ecosystems cannot be used directly; For example, our common debugging capabilities, because the containers implement different inspectors, it is difficult to use the existing Devtools directly, and most of them will develop their own Devtools; For example, WeexDevtools and AJXDevtools communicate based on remote debugging protocols, but their implementations are independent. Another example is the List component. Almost every cross end container needs the List component to solve the list rendering problem, but they are all independently implemented custom List components. We have spent a lot of energy on these aspects. If we can share the capabilities of WebCore with WebCore in terms of core capabilities, then we can build a better cross end kernel, focus on optimizing the business field, and build a better and more suitable business container.

In this year's D2 cross end technology special session, we also invited technical experts in this field to discuss with you the current situation and future of cross end technology, hoping to bring you some new inspiration, as well as some thinking and practical experience suitable for future development. In addition, the D2 Terminal Technology Conference in 2022 has also prepared Node.js, Swift, front-end engineering, Flutter, JS engine, network, AR/VR/3D, cloud rendering and other front-end&mobile topics. If you want to know more or have more exchanges, please click D2 to sign up. I hope to meet you in D2.