Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the difference between mobile front-end development and Web front-end development". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Review: the history of front-end development

▐ stage 1: slash-and-burn cultivation

More than a decade ago, developers were still struggling with IE6 compatibility. JQuery was the leader in the framework, and aspiring front-end developers might use Zepto.js to reduce the size of web pages. At this time, the front-end page is mainly PC-based, at 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 from 2011 to 2014, modular thinking dominated. At that time, in order to design the Assets resource loader, a modular protocol specification was developed. The popular modular protocols at that time were AMD (RequireJS), CMD (represented by Seajs) and KMD (represented by Kissy). In Taobao and Tmall, Kissy applications are very popular, so KMD dominates the world; in Alipay and external communities, Seajs applications are very popular, so CMD dominates the world, and Yubo's fame and prestige are also particularly high in the front-end circle; while AMD is more popular abroad, but it is also gradually weakened by the later CommonJS specifications.

Stage 3 of ▐: mobility

With the development of 3G and 4G and the increasing popularity of iOS and Android mobile phones in the market, the main battlefield of PC service is gradually transferred to the mobile end. The front-end mindset has shifted from PC to mobile, and is in line with the user experience of App. The support of mobile HTML5 protocol is not perfect, the production of front-end is not complete, and the screen of Android is fragmented, so the pain of mobile page adaptation in front-end development at that time is far more painful than in PC era.

▐ stage 4: framing

In the front-end community, MV* frameworks such as Angular, React, Vue, RN (React Native) appear one after another, making the front-end accept the baptism of data-driven ideas, but also complete the mobile experience upgrade with the help of RN, including later Weex and Flutter.

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

▐ stage 5: verticalization

With the release of the original iPhone, large-screen mobile phones have gradually become the mainstream, and the demand for mobile devices has begun to break out. In Taobao Tmall, the annual mobile turnover of Singles Day is rising year by year, and gradually occupies an absolute leading position. The front-end field is also gradually subdivided with this trend, according to the scene can be simply divided into mobile (wireless) front-end development and mid-background front-end development.

Mobile front-end development is oriented to consumer-side Web and light App business scenarios. In this scenario, after years of marketing activities, Taosi has gradually formed a unique and lightweight solution on the mobile end, as well as a module-dimensional, operation-oriented page building system.

The middle and backend front end is for enterprise ERP, CRM, OA and other later business scenarios, such as merchant backend systems. In this scenario, with the help of Feibing, Fusion Design and other middle and background materials, a visual middle and background construction solution is formed to provide an one-stop middle and background production solution for business front-end, development or product roles.

Mobile Front end: the past Life and present Life of Hybrid Technology

Once upon a time, mobile client development and front-end development were two parallel lines that did not intersect, but now we are increasingly embracing the cooperative product of the two: Hybird application development, or using a recently popular concept-big front-end technology.

Considering from the expression form of technology, in essence, both client development and front-end development are terminal technology, which is characterized by direct user-oriented UI programming.

▐ is both UI programming, what is the pain point we face?

Technical limitations of traditional Web front-end technology

1. Resource loading: HTML, JS, CSS, pictures and other static resources are stored on remote servers, which need to be dynamically pulled asynchronously, and then pulled data for display. Initialization efficiency is much slower than Native.

2. Rendering mechanism: in the design of the browser, the execution of JS, the layout of the page and the Paint are all in the same main thread and cannot be parallelized. In addition, the performance of JS is not as good as that of AOT. Stutters caused by complex logic usually block UI, coupled with lengthy rendering pipelines, which makes the browser's rendering experience not dominant when comparing Native with the same amount.

3. Page switching: there is no concept of routing in the browser, which causes the switching experience between pages to rely entirely on the capabilities provided by the browser Shell, which will be loaded repeatedly when the page is switched. Of course, the concept of single-page application also appears in the front-end community, but the resources of multiple pages also significantly increase the size of JSBundle and make the development of pages more complicated.

4. API capability: the security mechanism of the browser is a sandbox mechanism based on the same origin policy. This sandbox mechanism prevents front-end developers from using native system capabilities. You can only use the functions defined by the W3C standard. Considering the fragmentation of terminals, these APIs often cannot be used directly. This is not a problem on the PC side, but on the mobile side, on the contrary, developers want to be able to call the system interface to achieve some more interactive scenarios.

5. Interactive performance: the real-time interactive performance experience of browsers is poor, and large-scale rearrangements in complex interactive scenes limit the UI frame rate, especially in low-and middle-end mobile devices.

6. Scripting language, dynamic parsing and execution

JS is a JIT language, that is, it requires dynamic parsing and execution, which is much worse than the AOT language that precompiles machine code.

What are the limitations of traditional client technology?

1. Dynamic: client development usually has a fixed version release plan, and is subject to Apple's App Store audit rules, and the uncertainty of version release will also be affected by policies. Android has many channels in China, and each release has to be checked repeatedly. Once online problems are found, you need to rely on re-release, and the fault tolerance cost is very high, which greatly increases the limitations to the business.

2. Development cost: the development cost of the client is high, but the ecology is not as rich as Web. Tens of thousands of open source packages in the npm community, coupled with a more active developer community, cause the client development cost for enterprises to be higher than that of Web development.

3. Cross-end consistency: when a traditional client develops a set of business, it needs to implement two sets of Android + iOS codes, and due to the differences in operating system capabilities of Android and iOS, the same requirements are often realized with different vision and interaction, which also leads to high business costs.

▐ hybrid front-end development

Why is there hybrid front-end development?

As iOS + Android has established the dominance of the mobile operating system, front-end developers are also looking for models for business development using the capabilities provided by the operating system. The development method of Web is far more convenient and efficient than iOS and Android, and the endless variety of libraries and frameworks on Web are much more convenient than those of Android and iOS. We can easily use a variety of front-end frameworks on Web to preview the results in time (think about the compile time of large Android/iOS projects).

From Alibaba's point of view, as the concept of Zhongtai has been gradually accepted: the business needs to pursue rapid development, the UI and requirements of the foreground will iterate rapidly with business decisions, and different positions in the front end and client have also formed a decentralized R & D model.

The front end is up, and the front end, as the only interface of the business side, gradually evolves into the business layer of the large front end. At this level, it is responsible for defining specifications, standardizing the business development process through the framework, encapsulating unified solutions and engineering capabilities, and removing repetitive work.

The client goes down to decouple the business requirements and turns into a large front-end architecture layer to provide capability support to the upper-level business developers. By exposing the system-level API of the client and the ability of the host application to the upper front-end, the carrying capacity of the front-end page to more rich interaction scenarios is improved.

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

▐ stage 1: JSBridge

At this stage, it is mainly WebView, and the communication link between Naive and JS is provided with JSBridge. Based on this communication basis, Native can expose some standard services API to JS calls, and the same JS can also encapsulate some basic API to Native calls. Front-end developers use the traditional JS + HTML + CSS for page development, and call JSBridge API driver client capabilities. At this stage, Apache Cordova is a leader in the industry, and most Internet companies also have their own JSBridge framework implementation. It can be said that JSBridge gives front-end developers the ability to call Native for the first time.

However, the main disadvantage of the JSBridge scheme is the lack of performance and scalability of advanced components, and the fluency is always not comparable to that of Native.

▐ stage II: native UI

Although the dynamic and efficient development efficiency of Web is unmatched by 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 burden, which significantly slows down the performance of browsers.

2. Due to the defect in the design of WebView rendering engine, the rendering pipeline is very long, which causes the browser to treat compositor animation differently from non-compositor animation, and the performance of non-compositing animation is poor.

3. Single-threaded model can not give full play to the multi-core performance of modern hardware architecture, especially ARM architecture.

4. In the design of asynchronous rasterization, the phenomenon of white screen is inevitable when scrolling the long list.

* * is there a way to have the best of both worlds?

The emergence of React Native/Weex brings a dawn to front-end developers. **

React Native/Weex uses the JS engine to call the components on the Native side to achieve the corresponding functions. Both React Native and Weex allow front-end developers to use JS for business logic development, use VDOM to describe document structure, and work with a subset of CSS to customize the separation of styles, styles, and templates.

In the Weex system, the JS execution is executed in the JS Thread,Layout in the independent Layout Thread, and the rendering execution in the system's MainThread. The three threads are independent of each other and execute in parallel.

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

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

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

▐ stage 3: self-drawing engine

What is a self-painting engine?

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

In the last stage, front-end developers can already use the JS engine to drive native UI, so why do they need a self-drawn engine?

React Native/Weex fully exports the View system of Native to the front-end system, and there are many insurmountable obstacles in the process of packaging Android/iOS Native View. For example, it is difficult to smooth out the problem of double-end consistency, the ability of complex styles is difficult to achieve, and Layout animation needs to be performed twice (WeexCore Layout and Layout of Android Native itself). The encapsulation cost of components becomes higher and higher with the increase of complexity, so it is difficult to provide more detailed W3C standard capabilities beyond the limitations of Native View.

Flutter was born in 2018 to build a set of cross-platform development components through the Dart language. All components are self-drawn based on the Skia engine, which is comparable to the View of the Native platform in performance. At the same time, it solves the problem of double-end consistency that the previous generation architecture is difficult to solve. It has attracted wide attention and fully verified the feasibility of UI rendering engine which is comparable to Native View by drawing building components.

But Flutter itself is lack of dynamic update features, there are also some projects in the community to explore the dynamic characteristics of Flutter, our team is also implementing a front-end-oriented dynamic Flutter engine: Kraken, unlike other schemes, Kraken does not extend based on Flutter's own Widgets framework, but extends the W3C standard API from the bottom, which makes it more like a browser and greatly reduces the barrier for Flutter to use for Web developers.

Future: return to Origin

The general trend of the world, long-term division must be United, long-term cooperation must be divided. Mobile front-end development is essentially a form of terminal development. No matter how the container, framework and language change, only W3C standards remain the same among front-end developers. The author believes that with the development of Web, browser technology will become a more general UI programming standard after solving a series of performance and experience problems.

▐ PWA

In the early years, Google has worked hard in this field, introducing the concept of PWA (Progress Web Application).

PWA implements a user experience similar to that of Native App in Web App by providing a standardized framework in mobile browsers. Its feature is actually a series of W3C standards and private standard collections, which are simply supported by PWA:

Offline loading: through the cache mechanism provided by Service Worker, users are allowed to read offline resources directly when the network is off or weak.

Background resident process: normally, when the browser's page is closed, its entire life cycle ends and memory is freed. Service Worker allows the page to continue to run when closed, which ensures things like offline caching, active push, and so on.

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

Other features of mobile App, such as saving icons directly to the desktop, allowing users to open PWA applications like normal App; hiding the default browser elements in UI, allowing Web content to be displayed full screen, visually making Web applications more like a native application, sometimes you can't tell whether it is a Web application or a native application at all.

▐ PHA

Of course, at a time when standard capabilities are not perfect and business needs customization capabilities, hybrid applications will continue to develop.

The concept of PHA (Progress Hybird Application) comes into being. PHA is a progressive hybrid application enhancement strategy that provides end-testing assistance and improves the rendering performance and experience of WebView. In a broad sense, Mini Program and Kuaidi applications, which are popular nowadays, are all an implementation of PHA.

Within the Taos system, we are also implementing a lightweight PHA scheme, and we have achieved good results in promoting it. I would like to write a separate article on PHA later.

As for the future, with the diversification of technical solutions and the expansion of end boundaries, we believe that the most important thing is the issue of efficiency and performance.

Based on big data's machine learning ability, there will be more efficient UI choreography on the mobile, which will eventually enable real-time personalization of UI rendering.

Based on the recent hot WebAssembly capabilities, browsers can break through the limitations of JavaScript and have more room for imagination.

This is the end of the content of "what is the difference between mobile front-end development and Web front-end development". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.