What is the difference between mobile front-end development and web front-end development?
Posted Jun 5, 2020 • 13 min read
Introduction: This front-end technology has only developed for more than ten years since its birth. If the first ten years are the era of the PC front end, then the next ten years must belong to the era of the mobile front end. Especially with the development of network standards, mobile devices have gained unprecedented popularity worldwide. In the front-end field, a series of new mobile front-end technologies such as Hybird Web, React Native, Weex, Flutter, etc. have sprung up like mushrooms. Let me share with you today my understanding of "mobile front-end development and Web front-end development".
The front-end technology has only developed for more than ten years since its birth. If the first ten years are the era of the PC front end, then the next ten years must belong to the era of the mobile front end. Especially with the development of network standards, mobile devices have gained unprecedented popularity worldwide. In the front-end field, a series of new mobile front-end technologies such as Hybird Web, React Native, Weex, Flutter, etc. have sprung up like mushrooms. Let me share with you today my understanding of "mobile front-end development and Web front-end development".
Review:history of front-end development
▐ Phase one:slash and burn
More than ten years ago, developers were still having headaches for compatibility with IE6. jQuery is the leader in the framework, and the pursuit of front-end development may use Zepto.js to reduce the size of the web page. At this time, the front-end pages were mainly dominated by PCs. At this time, there was no concept of a mobile front-end. The pages on the small mobile phone screen were mainly plain text.
▐ Phase two:engineering
In the historical period between 2011 and 2014, the idea of modularity was dominant. 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(Seajs for representatives), and KMD(Kissy for representatives). In Taobao and Tmall, Kissy is very popular, so KMD dominates the world; in Alipay and external communities, Seajs is very popular, so CMD dominates the world, and Yu Bo’s great reputation and prestige are also particularly high in the front-end circle; and AMD is more popular abroad, but gradually weakened by the CommonJS specification that appeared later.
▐ Phase three:mobile
With the development of 3G and 4G and the increasing popularity of iOS and Android phones in the market, the main battlefield of the PC business has gradually transitioned to the mobile terminal. The front-end thinking mode has shifted from PC to mobile, and it is in line with the user experience of App. The HTML5 protocol support on the mobile terminal is not perfect, the front-end production support is incomplete, and the Android screen is fragmented, so the pain of front-end development at that time in developing mobile-end page adaptations far exceeded the PC era.
▐ Stage 4:Frame
In the front-end community, MV* frameworks such as Angular, React, Vue, and RN(React Native) appeared one after another, which allowed the front-end to accept the baptism of data-driven ideas, and also completed the mobile experience upgrade with RN, including later Weex, Flutter.
At this stage, the front end began to have the underlying architecture group of the terminal, and began 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-end multiplexing, Rax uses VDOM to connect WebView and Weex, and a set of code runs the world.
▐ Stage 5:Verticalization
With the release of the first-generation iPhone, large-screen phones have gradually become mainstream, and the demand for mobile devices has begun to explode. At Taobao Tmall, the turnover of the mobile terminal on Double Eleven each year is increasing year by year, and gradually occupying the absolute leading position. The field of front-end is also gradually subdivided with this trend, and can be simply divided into mobile(wireless) front-end development and mid- and back-end front-end development according to scenarios.
Mobile front-end development is oriented to the consumer-side Web and light-app business scenarios. In this scenario, after several years of marketing activities, Amoy has gradually formed a unique, lightweight solution on the mobile side, as well as a modular dimension, Operation-oriented page building system.
The front-end of the mid- and back-end is for business scenarios such as enterprise ERP, CRM, OA, etc., such as merchant back-end and other systems. In this scenario, with the help of Fei Bing, Fusion Design and other mid- and back-end materials, a visual mid- and back-end building solution is formed to provide a one-stop mid- and back-end production solution for the front-end, development, or product roles of the business.
Mobile front end:the past and present 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 collaboration product of the two:hybrid(Hybird) application development, or using a concept that has been more popular recently-Big Front-end technology.
Thinking from the technical manifestation, essentially client development and front-end development are both terminal technologies, which are characterized by direct user-oriented UI programming.
▐ The same is UI programming, what are the pain points we face?
Technical limitations of traditional web front-end technology
Resource loading:Static resources such as HTML, JS, CSS, and pictures are stored in a remote server, which requires dynamic asynchronous pull, and then pull the data for display, the initialization efficiency is much slower than Native
Rendering mechanism:In the design of the browser, the execution of JS, the layout of the page, and the Paint are all on the same main thread, and they cannot be parallelized. In addition, the performance of JS can not catch up with the AOT language, and the result of the implementation of complex logic. The UI is usually blocked, coupled with a lengthy rendering pipeline, resulting in the browser rendering experience is not dominant when comparing Native to the same amount.
Page switching:The concept of routing does not exist in the browser, which results in the switching experience between pages completely relying on the capabilities provided by the browser shell, which will be repeatedly loaded when the page is switched. Of course, the concept of single-page applications has also appeared in the front-end community, but the resources of multiple pages have also significantly increased the size of JSBundle, which has also made the development of pages more complicated.
API capability:The browser's security mechanism is based on the sandbox mechanism of the same-origin policy. This set of sandbox mechanisms prevents front-end developers from using native system capabilities. You can only use the functions defined by the W3C standard, and consider terminal fragmentation Problems, these interfaces often cannot be used directly. This is not a problem in the PC-side scenario, but on the contrary on the mobile side, developers hope to have the ability to call the system interface to achieve some more interactive scenarios.
Interactive performance:The browser's real-time interactive performance experience is poor, and large-scale rearrangement in complex interactive scenarios limits the UI frame rate, which is particularly serious in low-end and middle-end mobile devices.
Script language, dynamic analysis and execution
JS is a JIT language, that is, it needs to be dynamically parsed and executed. Compared with the pre-compiled machine code, the execution performance of AOT language is much worse.
What are the limitations of traditional client technology?
Dynamic: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 policy. Android has many channels in China, each release It is necessary to repeatedly check the channels. Once an online problem is found, it needs to be republished. The cost of fault tolerance is very high, which also greatly increases the limitations of the business.
Development cost:The development cost of the client is high, but the ecology is not as rich as the Web. The tens of thousands of open source packages in the npm community, plus a more active developer community, cause the development cost of the client to the enterprise is higher than that of Web development. .
Cross-end consistency:The traditional client develops a set of business that requires the implementation of two sets of code for Android + iOS, and due to the differences in the operating system capabilities of Android and iOS, the same needs are often realized with different visions and interactions. , Which also led to high business costs.
▐ Hybrid front-end development
Why is there a hybrid front-end development?
With iOS + Android establishing the dominant position of the mobile operating system, front-end developers are also looking for a mode of business development using the capabilities provided by the operating system. The development method of the Web is much more convenient and efficient than iOS and Android, and the various libraries and frameworks on the Web are much more convenient than the various libraries and frameworks of Android and iOS. On the web, we can easily use various front-end frameworks to preview the effect in time(think of the compilation time of large Android/iOS projects).
From the perspective of Alibaba, as the concept of centralization is gradually accepted:the business needs to pursue rapid development, the UI and needs of the front desk will rapidly iterate with business decisions, and the different positions of the front end and the client have also formed a division of labor Development model.
The front end is upward, and the front end as the only interface of the business party gradually evolves into the business layer of the large front end. At this level, its responsibility is to define the specifications, standardize the development process of the business through the framework, and at the same time encapsulate unified solutions and engineering capabilities to separate the repetitive work.
The client sticks down, decouples business requirements, and turns into a large front-end architecture layer to provide capability support to upper-layer business developers. By exposing the system-level API of the client and the capabilities of the host application to the upper-end front-end, the front-end page's carrying capacity for more rich interaction scenarios is improved.
Under such a big background, various hybrid development technologies are emerging one after another. Here we simply define the development of hybrid applications as three stages:
▐ Phase one:JSBridge
At this stage, it is still mainly WebView, and cooperates with JSBridge to provide a communication link between Naive and JS. Based on this communication foundation, Native can expose some standard service APIs to provide JS calls. The same JS can also be used This encapsulates some basic APIs for 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 a leader in the industry, and most Internet companies also have their own JSBridge framework implementation It can be said that JSBridge gave the front-end developer the ability to call Native for the first time.
However, the main disadvantage of the JSBridge solution is the lack of performance and advanced component expansion capabilities, and the fluency cannot always be comparable to Native.
▐ Phase 2:Native UI
Although the dynamic and efficient development efficiency of the Web is beyond the reach of native development, the bottleneck of browser technology is also very obvious:
As an open technical standard, W3C has a long history and many burdens, which significantly slows down the performance of the browser.
Defects in the design of the WebView rendering engine, the rendering pipeline is very long, which causes the browser to treat synthesizer animation and non-synthesizer animation differently, and the performance of non-synthetic animation is not good.
The single-threaded model cannot play the performance of modern hardware architecture, especially the multi-core of ARM architecture.
The asynchronous rasterization design inevitably causes a white screen when scrolling through a long list.
**Is there a way to achieve the best of both worlds?
The emergence of React Native/Weex has brought 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 the document structure, and cooperate with a subset of CSS to customize styles, style and template separation.
In the Weex system, JS is executed in JS Thread, Layout is executed in an independent Layout Thread, and rendering is executed in the system's MainThread. The three threads are independent and execute in parallel.
In the WebView system, the execution of JS, Layout, and Paint are all in MainThread, which affect each other, and will cause the interface to freeze when performing complex tasks.
The advantage of this solution is to maximize the reuse of the front-end ecology and Native ecosystem.
In Alibaba, Weex's large-scale application has even supported double 1.1 billion traffic.
▐ Phase 3:Self-painting engine
What is a self-drawing engine?
The so-called self-drawing engine is a rendering engine that directly calls the GPU or the underlying abstraction layer for drawing 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 the native UI. Why do we need a self-drawing engine?
React Native/Weex fully outputs the Native View system to the front-end system. There are many insurmountable obstacles in the process of packaging Android/iOS Native View. Such as:the dual-end consistency problem that is difficult to smooth, the ability to implement complex styles is difficult to implement, and the layout animation needs to be executed twice(WeexCore Layout and Android Native's own Layout). The packaging cost of components is getting higher and higher as the complexity increases, making it difficult to exceed the limitations of Native View and provide more detailed W3C standard capabilities.
In 2018, Flutter was born, and a set of cross-platform development components was built through the Dart language. All components are self-drawn based on the Skia engine, which is comparable in performance to the Native platform View. It also solves the dual-end consistency that was difficult to solve in the previous generation architecture. problem. It has aroused widespread concern and fully verified the feasibility of drawing rendering components to achieve a UI rendering engine comparable to Native View.
However, Flutter itself lacks dynamic update features. There are also some projects in the community that are exploring the dynamic features of Flutter. Our team is also implementing a front-end dynamic Flutter engine:Kraken. Unlike other solutions, Kraken is not based on Flutter. The built-in Widgets framework is extended, but the W3C standard API is extended from the bottom, which makes it more like a browser, and also makes Flutter's threshold for Web developers greatly reduced.
The future:back to the source
The general trend of the world is to divide the long time and to divide the long time. Mobile front-end development is essentially a form of terminal development. No matter how containers, frameworks, and languages change, among front-end developers, only the W3C standard will never change. The author believes that with the development of the Web, after solving a series of performance and experience problems, browser technology will become a more general UI programming standard.
In the early years, Google has worked hard in this field and launched the concept of PWA(Progress Web Application).
PWA provides a standardized framework in the mobile browser to achieve a user experience close to the Native App in the Web App. Its features are actually a collection of W3C standards and private standards. Simply put, PWA supports:
- Offline loading:Through the caching mechanism provided by Service Worker, etc., it allows users to directly read offline resources when the network is disconnected or weak.
- Background-resident process:Under normal circumstances, the entire life cycle of the browser is closed after the page is closed, and the memory is also released. Service Worker allows the page to continue running when it is closed, which guarantees similar to offline caching, active push, etc.
- Message notification:Allow web developers to implement an active push mechanism similar to App.
- Features of other mobile apps, such as saving icons directly to the desktop, allowing users to open PWA apps as normal apps; you can hide the default browser elements in the UI, let the web content be displayed in full screen, and make the web app more visually Like a native application, sometimes you simply cannot tell whether it is a web application or a native application.
Of course, when standard capabilities are not perfect and services require customized capabilities, hybrid applications will continue to develop.
The concept of PHA(Progress Hybird Application) was born. PHA is a progressive hybrid application enhancement strategy that provides end-testing assistance capabilities and improves WebView rendering performance and experience. Broadly speaking, the current popular small programs and fast applications are all an implementation of PHA.
Within the Tao department, we are also implementing a set of lightweight PHA solutions, and have achieved good results in the promotion. I want to publish a separate article on PHA to elaborate later.
Regarding the future, with the diversification of technical solutions and the expansion of end boundaries, we believe that the most important issue is efficiency and performance.
Based on the machine learning capabilities of big data, the mobile terminal will have more efficient UI layout capabilities, which will eventually enable real-time personalization of UI rendering.
Produce|Alibaba New Retail Amoy Technology Department
One More Thing
We are the founders of the hottest open source projects such as Rax, ICE, GCanvas, etc. It is the love and hate that you can't avoid when writing front-end in Ali. Do you want to lay a solid foundation for the group's front-end structure and make the 100-meter high building more rock-solid? Do you want your code to benefit the community? Do you want to spy on the beauty of the next-generation rendering engine(Kraken) and the next-generation hand-amended application container(PHA)? Well, what you see now is the only correct answer.
The boring code is the same, the interesting posts are chosen one by one, and the future of the terminal architecture is so broad. You need all your help. Welcome to join the Alitao front-end architecture team!
We are the big front-end technical architecture team of the Alibaba Amoy Department Technical Department. We sincerely invite all partners to join us and do great things together!
Resume can be mailed to firstname.lastname@example.org , looking forward to your contact.
- Big Competition | Next-generation high-performance cross-platform UI rendering engine
- Flutter Dynamic Solution Exploration
- The most popular mobile cross-platform solution inventory:React Native, weex, Flutter
- Talking about Hybrid App
- Other internal and external resources that cannot be cited