This article comes from Shengsi, the user technology team of Feizhu, to talk with you about the origin and future of Alibaba’s cross-end technology.
With the diversification of Internet business forms, wireless traffic channel matrix gradually takes shape, more scenario-based traffic entrances bring natural segmentation of the crowd and contact points, and the gradual decline of traffic dividend makes more and more businesses begin to pay attention to user growth. In the application of small procedures, the light open platform, and tencent advertising information flow, weibo, huge amounts of engine, baidu, ali inovance commercial engine capacity under the blessing, the whole domain on the touch, global, global marketing ideas gradually become the standard of IoT, OTT, POS equipment needs also explosive growth, such as end side business needs in the right time, Through the right end/channel, appear in the hands of the right people to form the undertaking, simple business needs, but also for multi-scene business research and development put forward higher requirements and challenges.
When we talk about straddles, what are we talking about?
The seeds of front-end technology began to take root in 1990 when Tim Berners-Lee opened the door to Web technology with his NeXT computer, bringing HTML and HTTP. The next three decades have seen a surge of devices, systems and solutions, from the PC era, the mobile era to the Internet of Everything era.
As a branch of big front-end technology, cross-end focuses on providing efficient business scenario research and development solutions for different terminal devices and ensuring performance and experience. The cross-ends mentioned today generally include four types of scenarios:
-
Cross-device platforms, such as PC/Mobile/OTT/IoT. Different equipment platform often means different hardware capabilities, sensors, screen size and interactive way, especially in the early days of mobile Internet, because the main research and development is still in PC, and mobile devices as the next tuyere also need to layout, the birth of a large number of cross-platform solutions, Web technology under typical is responsive layout.
-
Across operating systems, such as Android/iOS/HarmonyOS. For traditional front-end development, the differences of mobile operating systems have been smoothed out by infrastructure such as graphics libraries and rendering engines, and the upper API is provided in a standardized form. However, in RN, Weex and other schemes that rely on native control rendering, cross-end differences can still be sensed obviously.
-
Cross-app, such as Taobao/wechat/Toutiao. Due to the natural barriers between MOBILE platform CS architecture apps, different apps can no longer index resources in the form of hyperlinks, but follow a set of own standards within the closed system of each App to index and locate resources. When the same service is deployed to different apps, different routing rules and native methods need to be adapted.
-
Cross render containers such as Webview/RN/Weex. The first three scenarios give rise to the differences in solutions between different platforms, operating systems and apps. Various native rendering, self-drawing rendering and magic Webview schemes in the wireless field have been designed, which greatly increase the cost of migration in cross-end scenarios.
Considering that mobile is still the absolute ruler of the Internet, let’s focus our discussion on mobile technology.
History of cross-end technology
In 2007, Apple released the first generation oF iPhone, which opened the prelude of Mobile Internet. From 2008 to 2014, the world witnessed a rapid growth of 35.1% compound annually. With the increasing diversification of terminal devices, a series of new devices such as Mobile, IoT and OTT began to appear on the historical stage after PC. In the process of adapting Web standards to mobile devices, a wide variety of cross-end solutions emerged, which can be broadly divided into several stages:
1. H5 WAP stage, jquery/KISSY → Zepto/ Kissy-mini Web is naturally cross-platform, but due to the early network environment, the page loading speed cannot meet business expectations, coupled with the lack of sensor standards, large memory occupancy and low GPU utilization, at the beginning of the explosion of mobile devices, the argument of embarrassing great responsibility was suddenly put into the forefront, and reached its peak in 2012:
“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native. It just wasn’t ready.” —— Mark Zuckerberg, 2012
Standards bodies and browser vendors were at war, the WHATWG was born in 2004, and the HTML5 standard was finally released a decade later; Compared with the later cross-end solutions, PWA is Web orthodoxy and fully standardized operation. However, due to the resistance from many sides, it has been pushed forward slowly, and there is relatively some noise at the international level. However, in China, it can only exist in the interview questions of major manufacturers.
2. Hybrid: Cordova/PhoneGap/ Ionic. From the perspective of core functions, Hybrid solves two major pain points in the web cross-terminal era. 1) Performance. Depending on container capacity, various offline, pre-loaded package and Prefetch schemes greatly reduce the amount of loading resources required for page rendering or advance loading time, and cooperate with some coding optimization. In the early 2/3G and 4G era, the second opening experience of Web has been pulled to an order of magnitude level with Native. 2) Functions. By means of JSBridge, it avoids the long process of Web standard formulation and the loss of underlying capabilities caused by the separation from Native.
In essence, Hybrid is a tradeoff and compromise of Web standard/implementation lagging behind the development speed of wireless business. With the support of Hybrid, Web technology has successfully opened a gap in the wireless era, allowing the front end to have a place, and laying a lot of exploration and foundation for the future evolution direction. However, the superset of Web standards brought by Hybrid and the differences in container capacity and supporting facilities between different apps also lead to the third fragmentation of front-end development after PC browser and mobile operating system.
3. In the containerization stage of Native, the typical representative is ReactNative/Weex. JSC (V8) links Web ecology and native controls, combines React/Vue and other frameworks, tries to find a better balance between r&d efficiency and performance experience, and opens up a new way for the collaborative mode between front-end and wireless. Domain solutions (limited DSL + modified Web standards + Native rendering capabilities) are emerging. Native containerization opens the prelude to large front-end fusion rendering schemes, and the functional boundary of traditional front-end/client begins to blur.
“It’s worth noting that we’re not chasing ‘write once, run anywhere.’ Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach ‘learn once, write anywhere.'” —— Tom Occhino, 2015
Compared with RN’s “Learn Once, Write Anywhere”, Weex’s “Write Once, Run Everywhere” is more idealized and closer to the front end. However, from the perspective of their development, two drawbacks cannot be avoided: 1) Native containerization does not eliminate the consistency problem in essence, but transfers the problem to the container layer to solve, and the bottleneck still exists; 2) With the complexity of business requirements, the support of each new feature brings an increase in container complexity, which affects performance/experience/stability, and more layers make troubleshooting more difficult; When these two problems reach a critical point, the performance of Native containerization solution will even be weaker than that of traditional Web, and “the dragon slayer eventually becomes the dragon”.
4. The same layer rendering stage, typically represented by WVC/BlendUI/CoverView. It is an intermediate state cross-end enhanced rendering scheme between Hybrid and Native containerization. In the early stage, Native components were drawn directly on Webview and followed by sliding to realize the protobiochemistry of rich interactive components such as videos in the client and enhance the experience. Later, with the help of the same-layer rendering technology provided by Android U4 and iOS WKWebView, Native components can be used like ordinary DOM elements, with sliding following, hierarchical control/covering, event transparent transmission and life cycle opening, so as to better fit the local rendering environment in cross-end scenarios. Progressive enhancement. Strictly speaking, the same layer rendering technique does not have the same mass impact as the other stages, but the ideas it represents are important for the integration of present and future directions, so a brief note is also made here.
5. Taro/ UNI-app/MPvue are typical examples of small programs/quick applications. The core of applets is the business model, not the technical implementation, and it is not designed to solve cross-end problems. It is listed here as a phase because of new cross-end problems introduced by the two-threaded model and the introduction of a custom DSL.
Technically speaking, small program cross-end schemes are generally divided into compilation and runtime. The former mainly converts business code based on React/Vue framework into native DSL of small programs through static compilation, such as Rax compilation and Taro 2.x, which has the advantage of relatively good performance. However, due to compiler limitations, it is necessary to use non-standard restricted syntax, which leads to poor R&D experience. The latter is realized by the way of the small program setData interfacing with the runtime framework, and the advantages and disadvantages are just the opposite with the compile time; According to the specific implementation of different runtime schemes, it can be further divided into two categories. 1) Using the features of the React framework, the React-Reconciler can be directly connected to the VDOM layer for small program rendering, such as Remix; 2) Maintain THE VDOM and render applets in the runtime framework layer by emulating the DOM/BOM API, such as KBone, Rax runtime, Taro 3.x. This solution can theoretically connect to react, Vue, Angular, and any other upper-layer framework.
The small program helps the head App to establish a closed flow system, and also enables Chinese people to “walk in the forefront of the world” in the field of cross-end technology for the first time (manual dog head to save life). Various development frameworks, supporting engineering systems, and magical DSLS have created a “mini-program universe” (Rax, Remix, Wepy, MPvue, Uni-App, Megalo, MPX, Chameleon, Taro, you name it) in the mysterious East, which is magical and realistic.
6. Self-paint rendering stages, such as Flutter/Qt. Self-draw itself is not a new word, and it is not strict to juxtapose self-draw with H5 and native rendering. The “self-draw” here emphasizes the bottom-up self-build rendering engine, development framework and basic supporting methods by relying on cross-platform graphics libraries such as Skia and Cairo rather than using native controls or Webview rendering pipelines. Resolve cross-end consistency issues. The ability to render as a standalone phase is largely due to the rise of Flutter, a cross-end upstart that has quickly ignited client development with features such as dual-end consistency, HMR, state-driven, and the asynchronous programming experience Dart offers.
However, self-drawing is not a panacea. It is separated from the native design language of iOS/Android, which is not friendly to the access of existing apps that use native controls and follow the platform interactive vision standards. In the future, the system level standard upgrade will also need to invest higher costs to adapt. The feedback data obtained from the research of 2020Q1 shows that THERE is no shortage of Flutter that RN/Weex has experienced, such as debugging, Debug, crash, and memory problems. At the community level, ecological construction is flourishing, but it will take time to reach maturity.
The Dart Framework itself is not expensive to get started with, and the front-end ADAPTS to its syntax and design patterns faster than the client. But JS is about standards and ecology. Switching to Dart is not just about learning a new language, it’s about rebuilding a complex ecosystem. According to the data, although Flutter is growing rapidly, there are a lot of discussions about solutions driven by RN and other partial front-end, but they do not cause much impact. Instead, they replace traditional solutions such as Cordova and Xamarin. In the future, its positioning in the big front-end field still needs to be explored. The relationship with the front end also needs us to explore more actively.
Other involved across the scheme still has a lot of, such as Xamarin/SwiftUI Kotlin/Qt/Unity, Electron, etc., considering the plan or not geared to the needs of the front field, or in lack of widespread domestic audience and discussion, or with an emphasis on wireless, or has already entered a recession, skip this table.
If you look at the history of cross-end technology, imagine a line segment, with H5 on the left, representing R&D efficiency and dynamics; Right is Native, on behalf of high performance and experience, the process of the evolution of technology in recent years is through constantly in the process of looking for a better balance between two endpoints, program there is no absolute good or bad, but more is to see the business scenario, there is no silver bullet, these solutions will also be in the future a long period of peace, jointly build the boundary of the front end and ecology.
The present situation and thinking of Ali cross – end direction
With the development of various cross-end solutions mentioned above, alternative solutions are emerging, but they also carry more and more historical baggage. With the formation of Alibaba App matrix and the emergence of more and more two-party linkage and three-party investment scenarios, problems caused by multiple RESEARCH and development frameworks and multiple rendering engines are becoming increasingly prominent, and business undertaking efficiency and cross-end performance experience are also facing unprecedented challenges.
At the beginning of this fiscal year, we conducted 1V1 communication on the technology status of more than 25 BU/ departments in the economy. According to the sampling results, 91.7% of the team’s business involves multiple App terminals (Hand-tao, Alipay, Feizu, Autolavi, Dingding…). Release scenario, which involves a lot of problems such as inconsistent engineering capability, inconsistent cross-end API, and inconsistent cross-end buried point/account; On this basis, more than 95.8% of the departments have multiple rendering container adaptation scenarios, which need to be compatible with Web, Hybrid, Weex, small program and other rendering schemes in the case of inconsistent container selection among one/two/three parties, which also expose the problems of repeated development cost of multiple SETS of DSL, inconsistent performance experience and lack of construction ability.
Traditionally, cross-end technology focuses on performance experience, consistency, and R&D efficiency. These problems existed in the past, exist now, and will continue to exist for a long time in the future. From the background of cross-end technology and the technology status quo of Alibaba economy, the essence behind these problems can be seen:
-
Hardware upgrade alone is difficult to solve the performance experience problem. The breakthrough of hardware technology under Moore’s Law does not bring the expected performance experience problem, which is solved by default. In business research and development, considerable efforts are still needed to carry out targeted optimization. In essence, the reason is that the improvement of end technology architecture and business function complexity has eliminated the performance bonus brought by hardware upgrade. And along with the mobile Internet traffic peaked, business has entered into the phase of memory game, will further improve the complexity, pure Web solutions ceiling will still exist for a long time, so the combination of PHA/SPA/SSR/Snapshot/Prerender direction, each independent business custom container side rendering still inevitable;
-
It is difficult to balance unlimited business scenarios with limited capability boundaries. On the basis of the above problems, self-built solutions for their own business scenarios are almost mandatory options, such as Weex, Alipay mini program, Autonavi AJX. Self-built solutions often have a beautiful start, light and efficient solution for a specific scene, then accompanied by the expansion of the business scope to support, on the one hand, due to the pressure of the construction period, part of the standard began to deformation, there are all kinds of castration and super set, two way through the cost of a steep rise; On the other hand, each new feature’s support increases cartesian complexity with older features, creating performance/stability issues that eventually erode the performance experience bonus once it passes a certain point. Airbnb’s RN and Weex have had similar experiences. Therefore, self-built solutions need to answer two questions: 1) Lack of standards, how to do a good job in stock business migration and multi-investment business support; 2) How to define limited technical boundaries and control complexity in the face of infinite business scenarios.
-
The technology evolution rhythm that front end and wireless do not match, reconfiguration becomes normal. From the perspective of H5 and Native technology evolution, front-end technology focuses more on breakthrough of programming thought (MVC/MVVM/ Reactive /one-way data flow), while container technology focuses more on performance and experience (Bridge/Native container/self-drawing rendering engine). New programming ideas and new rendering container technologies often bring new solutions and supporting research and development, directly leading to 1) business code needs to follow the two main lines of frequent reconstruction, “the world is suffering for a long time”, take Flying Pig as an example, 15 years to now, KISSY (PC), Kissy-Mini (wireless), React (framework upgrade), ReactNative (Native rendering), Weex (MVVM), Rax 0.6 (framework unification), and Rax 1.0 (Web) Render) → Rax 1.0 runtime (small program), refactoring less than once a year on average; 2) Further deepen the fragmentation of cross-end technical solutions in the process of evolution and iteration, including the fragmentation of intra-end framework/container (stability risk) and the fragmentation of heterogeneous solutions of different Apps delivered across the end (high compatibility cost).
-
Technical scheme supply and demand side is not unified, the position is extremely unequal. Across the side on the multi-channel distribution, a guest is essentially a business and service, have a strong appeal is often not flow entrance or small company has insufficient flow/business team, volume is small, it is very hard to channel App technology selection of voice (for example, can’t support WeChat applet required with Flutter Dart development), the solution except: 1) One end of the strategy, for example, Feizhu needs to be adapted to Mobile, Alipay, Dingding, Autoravi, UC, wechat and other apps plus iOS/Android/Web. The cost is very high, and limited research and development resources have the meaning of “why not eat minced meat”; 2) Build the upper framework for multi-terminal solutions, take the intersection of capabilities, and strike a balance between capabilities, efficiency and performance experience. In most cases, this is a better choice, but there is also a large cost of compatibility and adaptation.
The very essence of business demands, it is under a set of research and development process, a business code (even if the code there is a certain limit) adapter can span end, at the same time, in the new App or render container plan, can realize the business code of seamless PingQian, “I refactor because I really want to, not because the underlying rendering scheme to iterative update”. The non-convergence of cross-end technical solutions forms a complexity O(MxN) network between business RESEARCH and development and containers, and the communication and adaptation costs increase exponentially behind the connection. What is the optimal solution? Ideally, all available channels provide a unified rendering container solution (which smells like the Web) with complexity down to O(Mx1); However, the different business characteristics represented by different App channels are often difficult to be bribed through a set of solutions. Once each end starts to develop in different ways, the problem of high threshold of cross-end will come back.
Back to the question itself, since the front-end R&D framework, Native rendering container and r&d supporting facilities carry different missions and have different evolutionary rhythms, can a standard system be developed to achieve the decoupling among the three, “what is God belongs to God and what is Caesar belongs to Caesar”?
The origin of the front end is standards. Under the operation of standardization organizations such as W3C, WHATWG and TC39, browser fragmentation and system fragmentation gradually converge, bringing the prosperity of Web ecology. With the same idea, through the standardized operation mechanism, a set of research and development standard guidance is provided for the upper rendering container, and the compatible implementation of each rendering container scheme is promoted for the lower rendering container. By analogy with the browser, a business code can be seamlessly adapted and migrated between different rendering containers. The setting of subset standards should comply with Web standards as much as possible, which has many advantages:
- Reuse best practices (experience/ecology/talent) while controlling implementation costs;
- Lower complexity, high performance through streamlined layouts, etc.
- Compatibility with Web standards, the possibility of switching to Web rendering for underlaying or outcasting.
At the same time, several principles should be followed:
- Explicitly output in the form of a subset of Web standards to ensure that standards-compliant services can use the Web container as a backstop;
- From the two dimensions of R&D experience and performance cost, the classification specification is formed, and the corresponding feature classification and container support scope are explicitly marked by documents, CanIUse, IDE Plugin and other forms.
- Allows support for extended capabilities beyond the standard, similar to browser private properties.
By decoupling the three components through standards, we have the opportunity to unify the upper development framework at a low cost and seamlessly replace them to different containers in different environments. Supporting engineering, construction, Hybrid apis, performance optimization solutions and basic components can also be independently developed based on standards. And by each independent business to form their own solutions.
One step further, Flutter is undoubtedly the hottest big front-end technology at the moment. From the perspective of the front-end, how do we see it positioned in the future? I believe many students have similar questions. Essentially, Flutter shows the big front-end the possibility of unifying underlying rendering capabilities. Imagine if client development (Dart), Dynamic template development (DX), front-end development (Web), and interactive gameplay development (Canvas) could reuse a base similar to Flutter Engine. First, it can reuse underlying optimizations (such as for low-performance hardware), and second, it can reuse and unify solutions and ecosystems at lower cost for future IoT scenarios (such as FuchsiaOS).
Google’s own project HummingBird (later renamed Flutter for Web) was announced at I/O 2019 to enable Flutter to run on the Web. There are two main problems to solve. One is to run DART in a Web environment. Dart has been designed from the beginning and is easy to implement based on DART 2JS. The other is the alignment of the rendering capability of Flutter Engine on the Web side. Currently, there are two schemes:
- HTML Mode: firstly, ALIGN UI capabilities through HTML and CSS, realize standard tags, and then realize custom tags through Canvas and SVG, and finally complete the construction of DOM tree. This scheme is also the original SCHEME of FFW, which has two problems: 1) The DOM tree generated has a complex structure and deep hierarchy, and it is difficult to ensure cross-platform consistency; 2) Events and interaction capabilities of Canvas need to be supported by itself, and the pixelation performance is also problematic.
- WebGL Mode, compiles Skia to WebAssembly library CanvasKit, and completes page rendering through WebGL. This is also the solution Google is currently focusing on, which is larger than HTML Mode code, but can achieve better consistency and visual reduction.
FFW is a perspective from Flutter technology to Web. At present, it is still on the way from laboratory to engineering system, and there are still many problems in performance and consistency. For business development, in the short and medium term, Flutter is more of a backstop solution when rendering anomalies occur. Let’s look at Flutter from the Web perspective. The founding team of Flutter has a lot of background in Web kernel development, which ensures that the Engine layer has a more elegant rendering pipeline. Given the separation of front-end business code, development framework, and client rendering containers based on classification criteria above, wouldn’t it be great to be able to leverage underlying capabilities to improve performance when Flutter is already in place? We define this direction as Web on Flutter, a new render container construction direction.
There have been many attempts of WOF, from The external MXFlutter of Alibaba to the internal Unicorn, Kraken and WFlutter. At present, the best practices are still being explored. The technical solutions involved are not listed here, and interested students are welcome to discuss with us. It should be noted that Flutter itself is still undergoing rapid update and iteration at present. The implementation strategy of Flutter should consider the general direction of its future evolution, make use of the infrastructure, and avoid premature differentiation of the technical system.
Summary and Prospect
From IE6, to Chrome; From waP browsers that automatically block images to ready-to-use applets; From the application development /UED part-time page writing, to the front-end to become an independent position, the topic of cross-end almost runs through the whole process of front-end technology development. We are certainly lucky to have the opportunity to participate in the current and be part of the historical development of technology. As cross-end technology evolves and iterates, our role has shifted back and forth between “standards defender” and “standards destroyer.”
Serverless, AI, Visualization, IoT, AR/VR/MR, end intelligence, Micro front-end, D2C/P2C/S2C…… The picture of the future is magnificent, but also by a pair of men a line of code into reality. Dream valuable, born fearless, let us unite, Make Web Great Again!