The author | ZhuoLing new retail product | alibaba tao technology

The front end of this technology, from the birth and development of only a few more than ten years. If the first decade was the era of the PC front end, the second decade must be the era of the mobile front end. In particular, with the development of network system, mobile devices have gained unprecedented popularity worldwide. In the front-end field, a series of new mobile front-end technologies like Hybird Web, React Native, Weex and Flutter have sprung up like spring rain. Today I would like to share with you my understanding of “mobile front-end development versus Web front-end development”.

Review: Front-end development history

Stage one: Slash-and-burn

More than a decade ago, developers were struggling with compatibility with IE6, jQuery was the top framework, and ambitious front-end developers would probably use Zepto.js to reduce the size of web pages. At this time, the front-end page is mainly PC, this time there is no concept of mobile front-end, in the small mobile phone screen traffic page is mainly plain text.

Stage 2: Engineering

In the historical period between 2011 and 2014, modular thinking was dominant. At that time, modular protocol specifications were developed for the design of Assets loader. The popular modular protocols at that time were AMD (RequireJS), CMD (Seajs) and KMD (Kissy). Kissy apps are popular on Taobao and Tmall, so KMD dominates the market. In Alipay and the external community, Seajs application is very popular, so CMD dominates the world, and Yubo’s great fame and prestige are particularly high in the front circle. AMD is more popular in foreign countries, but it was gradually weakened by the later CommonJS specification.

Stage 3: Mobile

With the development of 3G and 4G and the increasing popularity of iOS and Android phones in the market, the main battlefield of PC business has gradually shifted to the mobile end. The front-end thinking mode has shifted from PC to mobile, and the user experience is similar to that of App. Mobile HTML5 protocol support is not perfect, front-end production supporting is not complete, Android screen fragmentation, so the front-end development at that time mobile end page adaptation pain is far more than the PC era.

Stage 4: Framing

In the front-end community, MV* frameworks like Angular, React, Vue, and RN (React Native) emerged one after another, allowing the front-end to embrace data-driven thinking and RN to upgrade the mobile experience, including Weex and Flutter.

At this stage, the front-end starts to have the terminal’s underlying architecture group, and begins to conceive the loading performance and user experience performance of the front-end page on the mobile terminal. Inside Alibaba, in order to solve the problem of multiplex, Rax uses VDOM to get through both ends of WebView and Weex, and a set of code runs all over the world.

Stage 5: Vertical

With the release of the original iPhone, large-screen phones gradually became mainstream, and mobile demand exploded. On Taobao tmall, the mobile transaction volume of Singles’ Day is increasing year by year, and gradually occupies an absolute leading position. The field of the front end is gradually subdivided along with this trend. According to the scene, it can be simply divided into mobile (wireless) front end development and middle and back end development.

Mobile front-end development is oriented to the consumer side of the Web and light App business scenarios, in this scenario, Tao department after years of marketing activities precipitation, gradually formed a mobile terminal unique, lightweight solutions, as well as module dimension, oriented to the operation of the page building system.

The mid-background front-end is for enterprise ERP, CRM, OA and other back-end business scenarios, such as business background systems. In this scenario, with the help of mid-background materials such as flying ice and Fusion Design, a visual mid-background construction solution is formed to provide one-stop mid-background production solution for the front end of business, development or product role.

The Mobile front End: The past and present of hybrid technology

There was a time when mobile client development and front end development were two parallel lines with no intersection, but now we are increasingly embracing the product of their collaboration: Hybird application development, or the concept of big front end technology, which is hot these days.

From the expression of technology thinking, in essence, client development and front-end development are terminal technology, its characteristics is directly oriented to user UI programming.

What are the pain points we face in UI programming?

Technical limitations of traditional Web front-end technology

1. Resource loading: static resources such as HTML, JS, CSS and images are stored in the remote server, which requires dynamic asynchronous pulling and then data pulling for display. The initialization efficiency is much slower than that of Native. In browser design, JS execution is on the same main thread as page layout and Paint, which cannot be parallelized. Moreover, JS performance is not as good as AOT, which usually blocks UI due to lag when executing complex logic. As a result, the browser’s rendering experience is not superior when comparing Native equally. 3. Page switching: there is no concept of routing in the browser, so the switching experience between pages completely depends on the capabilities provided by the browser Shell, which will be loaded repeatedly during page switching. Of course, the concept of single-page applications is emerging in the front-end community, but multiple page resources significantly increase the size of jsbundles and complicate page development. 4. API capabilities: Browser security is a same-origin policy-based sandbox that prevents front-end developers from using native system capabilities. You can only use functionality defined by W3C standards, and these interfaces are often not directly available due to fragmentation. This is fine in PC scenarios, but not on mobile, where developers want the ability to call the system interface for more interactive scenarios. 5. Interactive performance: The real-time interactive performance experience of browsers is poor, and the large-scale rearrangement in complex interactive scenes limits the UI frame rate, which is particularly serious in middle and low-end mobile devices. JS is a JIT language, that is, dynamic parsing is required to execute, compared to the pre-compiled machine code AOT language performance is much worse.

Limitations of traditional client technology?

Dynamic: The client development usually has a fixed version release plan, and is subject to Apple’s App Store review rules. The uncertainty of version release will also be affected by policies. Android has many channels in China, and the channels need to be checked repeatedly every time it is released. Fault tolerance costs are very high, which greatly increases the limitations to the business.

Development costs: Client development costs are high, but the ecosystem is not as rich as Web development. The tens of thousands of open source packages in the NPM community, coupled with a more active developer community, result in client development costs higher than Web development for enterprises.

Cross-terminal consistency: Traditional client development of a set of business requires the implementation of Android + iOS two sets of code, and due to the differences in the capabilities of Android and iOS operating systems, the same requirements are often realized by different vision and interaction, which also leads to high business costs.

Hybrid front-end development

Why hybrid front-end development?

As iOS + Android establishes the dominance of mobile operating systems, front-end developers are also looking for models for business development using the capabilities provided by operating systems. Web development is far more convenient and efficient than iOS and Android, and the endless variety of libraries and frameworks on the top of the Web are far more convenient than Android and iOS libraries and frameworks. The Web makes it easy to use a variety of front-end frameworks and preview the effects in real time (think build times for large Android/iOS projects).

From the perspective of Alibaba, the concept of Centralization has been gradually accepted: business needs to pursue rapid development, UI and requirements at the front desk will be rapidly iterated with business decisions, and different positions at the front end and client end have formed a research and development mode of division of labor.

Front-end upward, front-end as the only interface of the business side, gradually evolved into a large front-end business layer. At this level, it is responsible for defining the specifications that define the business development process through the framework, while encapsulating unified solutions and engineering capabilities that separate repetitive work.

The client is connected down to decouple service requirements and become a large front-end architecture layer to provide capability support for upper-layer business developers. By exposing the system-level API of the client and the capabilities of the host application to the upper front-end, the front-end page can carry more rich interaction scenarios.

In this context, a variety of hybrid development technologies emerge endlessly. Here, we simply define the development of hybrid applications as three stages:

Phase 1: JSBridge

At this stage, WebView is mainly used, and JSBridge provides a communication link between Naive and JS. Based on this communication foundation, Native can expose some standard service apis to provide JS calls. In the same way, JS can encapsulate some basic API to Native calls. Front-end developers use traditional JS + HTML + CSS for page development, and call JSBridge API to drive client capabilities. At this stage, Apache Cordova is the best in the industry, and most Internet companies have their own implementation of JSBridge framework. It can be said that JSBridge gives front-end developers the ability to call Native for the first time.

However, the main disadvantage of JSBridge solution lies in the lack of performance and advanced component expansion ability, and the fluency is not as good as Native.

Stage 2: Native UI

Although the Web is more dynamic and efficient than native development, the bottleneck of browser technology is also very obvious:

1. As an open technical standard, W3C has a long history and a lot of baggage, which significantly slows down browser performance. 2, WebView rendering engine design defects, rendering line is very long, resulting in browser on synthesizer animation and non-synthesizer animation treatment, non-synthesizer animation performance is not good. 3. The single-thread model cannot give full play to the multi-core performance of modern hardware architecture, especially ARM architecture. 4, asynchronous raster design, in the long list scrolling, it is inevitable to appear the phenomenon of white screen.

Is there a way to have it both ways? React Native/Weex is a silver lining for front-end developers.

React Native/Weex uses the JS engine to invoke Native components to implement corresponding functions. React Native and Weex both allow front-end developers to use JS for business logic development, use VDOM to describe document structure, and customize styles with a subset of CSS, separating styles from templates.

In Weex, JS threads are executed in JS threads, Layout threads are executed in independent Layout threads, and rendering threads are executed in parallel.

In the system of WebView, JS execution, Layout and Paint are all MainThread, which affect each other and lead to interface lag when carrying out complex tasks.

The advantage of this scheme is to maximize the reuse of front-end ecology and Native ecosystem.

In Alibaba, Weex large-scale application, even supported the double 11 billion level of traffic.

J. Bradley Bradley. Stage three: Paint your own engine

What is a paint engine?

The so-called self-drawing engine is a rendering engine that directly calls GPU or the underlying abstraction layer to draw without relying on the layout and native component capabilities provided by the operating system.

In the previous phase, front-end developers could already use a JS engine to drive native UI, so why do they need a self-drawing engine?

React Native/Weex fully outputs the Native View system into the front-end system. There are many insurmountable obstacles in the encapsulation process of Android/iOS Native View. For example, it is difficult to erase the two-end consistency problem, difficult to implement the complex style ability, and Layout animation needs to be executed twice (Weex Core Layout and Android Native Layout). The cost of packaging components increases with complexity, making it difficult to overcome Native View limitations to provide more detailed W3C standard capabilities.

In 2018, Flutter was born to build a set of cross-platform development components based on the Dart language. All components are self-drawn based on the Skia engine, providing performance comparable to Native platform View, while addressing issues such as two-end consistency that were difficult to solve in previous generation architectures. It has attracted widespread attention and fully verified the feasibility of achieving UI rendering engine comparable to Native View by drawing construction components.

However, Flutter itself lacks the dynamic updating feature. There are also some projects exploring the dynamic feature of Flutter in the community, and our team is also implementing a front-end dynamic Flutter engine: Kraken, unlike other alternatives, does not extend Flutter’s built-in Widgets framework. Instead, Kraken extends the W3C standard API from the bottom up, making Flutter more like a browser. It also makes Flutter much easier for Web developers to use.

Future: Back to basics

The general trend of the world, long separated, will be divided. Mobile front-end development is essentially a form of terminal development. No matter how containers, frameworks, and languages change, only the W3C standards remain constant among front-end developers. I believe that with the development of the Web, browser technology will become a more common UI programming standard after a series of performance and experience problems are solved.

PWA

Earlier in the year, Google had already made efforts in this field, introducing the concept of Progress Web Application (PWA).

PWA provides a standardized framework in mobile browsers to achieve user experience close to Native apps in Web Apps. Its features are a set of W3C standards and proprietary standards that PWA supports in a nutshell:

1. Offline loading: Cache mechanism provided by Service Worker allows users to read offline resources directly in case of network disconnection or weak network.

2, the vxconfigd process: normally, after the browser page is closed, its entire life cycle ends and memory is freed. The Service Worker allows pages to continue running even when closed, which ensures things like offline caching, active push, and so on

3. Message notification: Allow Web developers to implement an active push mechanism similar to App

4. Functions and features of other mobile apps, such as saving ICONS directly to the desktop, allowing users to open PWA apps like normal use of apps; You can hide the default browser elements in the UI and make Web content display in full screen, visually making your Web app look more like a native app, and sometimes you can’t tell whether it’s a Web app or a native app.

PHA

Of course, hybrid applications will continue to grow in a world where standard capabilities are imperfect and businesses need customization capabilities.

The concept of Progress Hybird Application (PHA) was born. PHA is a progressive hybrid Application enhancement strategy that provides the auxiliary capability of end testing and improves the rendering performance and experience of WebView. Broadly speaking, the current hot small programs, fast applications are a PHA implementation.

In tao Department, we are also implementing a set of lightweight PHA solutions, and have achieved good results in the promotion process. I would like to write a separate article about PHA later to elaborate.

For the future, with the diversification of technology solutions and the expansion of end boundaries, we believe that efficiency and performance are the most important issues.

Based on machine learning capabilities of big data, mobile terminals will have more efficient UI choreography capabilities, and ultimately make UI rendering real-time personalized.

Building on the recent popularity of WebAssembly capabilities, let the browser go beyond the limitations of JavaScript and have more room to imagine.

Recruitment recruitment!

We are the originators of Rax, ICE, GCanvas and other hot open source projects. We are the entanglement-love and hate that you cannot get rid of when you write the front end of Ali. Do you want to lay a solid foundation for the group’s front-end architecture to make the 100-meter tall building more solid? Do you want your code to benefit the community and be worshipped? Want a peek into the next generation of rendering engines (Kraken) and the next generation of mobile application containers (PHA)? So, what you see here is the only correct answer.

Boring code is the same, interesting posts are one in ten thousand, the future of terminal architecture is so broad, we need your help, welcome to join alitao front-end architecture team!

We are alibaba Tao Department technology department – big front-end technology architecture team, we sincerely invite you to join us and do great things together!

Resume can be sent to [email protected], looking forward to your contact.