An article revealing the evolution, practice and implementation of Ele.me's cross-end technology

This article will first lead everyone to briefly review the background and evolution of cross-end technology and the status quo of Ele.me cross-end in this wave after wave of cross-end waves, and in this context, compared with the industry-based React/Vue R&D habits start with various cross-end solutions. Why did Ele.me choose to go the other way? During this process, some of our thoughts, problems encountered and solved, and some achievements achieved, I hope to bring you Some new ideas on cross-terminal aspects.

Cross-terminal technology background and evolution process

Cross-terminal, which terminals are crossed?

Since the emergence of the World Wide Web in 1990, we have successively experienced the PC era, the mobile era, and the current Internet of Everything (IoT) era in the following 30 years. Behind the prosperity are more and more devices, more and more Many systems and various solutions.

In general, according to the cross-terminal scenarios, it mainly includes the following four categories:

Cross-device platforms, such as PC (computer) / Mobile (mobile phone) / OTT (set-top box) / IoT (Internet of Things devices). Different device platforms often mean different hardware capabilities, sensors, screen sizes and interaction methods
Cross operating systems, such as Android/iOS/HarmonyOS. Different operating systems usually provide different programming languages, application frameworks and APIs for application development
Cross-mobile applications, such as WeChat/Alipay/Shoutao/Douyin/Kuaishou, etc. Due to the CS architecture of the mobile platform and the natural barriers between Apps, different Apps are isolated from each other, and each follows a set of own standards in its closed system to index, locate and render various resources. When the same business is deployed to different App terminals, these different rules need to be adapted separately.
Cross-rendering containers, such as Webview/React Native/Flutter. The first three types of scenarios gave birth to solutions for different device platforms, different operating systems, and different apps. Therefore, various native rendering, self-drawing rendering, and magic Webview solutions in the mobile field were also designed. At the same time as the cross-terminal problem, it also increases the cross-terminal migration threshold and the difficulty of solution selection to a certain extent.

At the moment, the mobile field is still the absolute protagonist. Let's take a look at what stages the cross-terminal technology of the mobile terminal has gone through.

Evolution of mobile cross-terminal technology

With the vigorous development of the mobile Internet, the terminal forms have become diverse. In addition to the traditional Native and H5, emerging models represented by dynamics and small programs are flourishing. Frameworks/containers/tools in the world are also emerging in endlessly. towards fragmentation.

For developers, the direct impact of fragmentation is to bring various uncertainties including, but not limited to, the device platform, operating system, rendering container, syntax standard, etc. mentioned earlier, and increase a lot of learning. , Development and maintenance costs.

Therefore, the core of various cross-terminal technologies that emerged as the times require is to find certainty from uncertainty, to ensure the consistency of R&D experience and products, to adapt to the optimal solution for each terminal, and to achieve the best with the least cost. The effect is truly "write once, run anywhere".

Mobile cross-terminal has roughly gone through the following stages:

H5 Wap stage: Web is naturally cross-platform, and responsive layout was a major means at that time. However, due to the early network environment, the page loading speed could not meet business expectations, coupled with the lack of device sensor standards, large memory usage, and low GPU utilization. , at the beginning of the outbreak of mobile devices, the embarrassing argument was suddenly pushed to the forefront, and reached its peak in 2012.
Hybrid stage: The typical representative is Cordova/ionic. Functionally, Hybrid solves two historical pain points:
- 1) Performance, relying on container capabilities, various offline, pre-installed packages, and Prefetch solutions greatly reduce the time-consuming loading, and with coding optimization, the H5 experience has been raised to a higher level in the 3/4G era;
- 2) Function, through the JSBridge method, it avoids the lack of underlying capabilities caused by the original separation from Native.
Framework + native stage: the typical representative is ReactNative/Weex. Based on JSC or similar engines, combined with React/Vue at the syntax layer, using native components for rendering at the rendering layer, trying to find a better balance between R&D efficiency and performance experience, solutions in various fields (restricted DSL + magic modification Web standards + Native rendering capabilities) began to emerge, which opened the prelude to the big front-end fusion rendering solution.
Self-drawing rendering stage: the typical representative is Flutter/Qt. The "self-drawing" here emphasizes not using the system's native controls or Webview's rendering pipeline, but relying on cross-platform graphics libraries such as Skia and Cairo, and self-built rendering engines, research and development frameworks, and basic supporting methods from the bottom up. The characteristics of /iOS quickly ignited the field of client research and development.
Small program stage: Typical representatives are WeChat/Alipay small programs. Small programs are created. The essence is that each APP manufacturer constructs a relatively closed ecosystem for commercial considerations. There are differences in standards and capabilities between the Web and manufacturers. In terms of capabilities, it is custom DSL & API + A combination of Hybrid + same-layer rendering + commercial control. The strategy of cross-terminal solutions in the market is to anchor a research and development protocol to smooth out and adapt the differences between compilation and runtime of various forms.

After reviewing the background and evolution of the above-mentioned cross-terminal technologies, what is Ele.me’s cross-terminal launch situation like in this wave? Which end did you vote for? What problems did you encounter? How to solve it?

As we all know, Ele.me is a company that provides users with online-to-offline services around O2O. Through the organic combination of time, space, people and goods, it links merchants and consumers. Compared with traditional e-commerce, space-time people and goods It has regional attributes, which means that what we are doing is not a hypermarket business, but more about providing refined services around regional characteristics. There are a series of space-time, experience, scale, and cost constraints that need to be considered and dealt with.

Behind this series of constraints, there is actually a common business appeal for all parties:

For merchants: in order to have better business operations, they need more exposure and more contacts with customers in order to bring in deals.
For the platform: In order to allow more consumers to enjoy our services, in addition to cultivating our own super APP (Ele.me APP), we also need to increase our exposure, voice volume and service capabilities in places with high traffic to expand our scale.

This all leads to one purpose: where there is a lot of traffic, we need to provide the ability to connect with consumers.

So the question is, where is the flow? Today's Internet is more about the business of users' time and energy. After dismantling it, there are actually several key factors that can be measured: user density, user activity, market share, and user time allocation. Looking at it in detail , if any of the conditions are met, it can be used as a candidate set for our traffic position.

After years of hard work, Ele.me has made a large number of external key channels and has many business positions. From the effect point of view, the channel business has a high contribution to the overall market in terms of user traffic scale and order scale. With the continuous improvement of business With the continuous improvement of the external cooperation environment, incremental channels are also constantly emerging.

In so many business positions, the form of applications deployed on each end is based on:

The operating environment of the channel
channel traffic characteristics
Channel business positioning
Channel control rules

At present, a small program-based, H5-assisted undertaking method has been formed, and these differences have brought a lot of uncertainty, mainly reflected in:

High uncertainty of the channel environment: With so many channels connected, there are huge differences in the operating environment of each terminal. Take the mini-program capability as an example. Inconsistencies in design ideas, capability maturity and completeness, and R&D support (grammar, framework, tools, etc.) will also make the R&D experience significantly different. For technical students, this brings a high degree of uncertainty in the channel environment ;
High uncertainty of business demands: At the same time, the APPs we launch can be divided into certain subdivided fields, user characteristics and user demands on the platform are different, and channel positioning is also inconsistent. With the development of each business domain With more and more functional evolutions, whether multiple channel functions are aligned, should they be aligned, whether there is alignment, and when alignment has become a very realistic and troublesome matter. At the same time, there may be functional correlations between business domains, which further It increases its complexity. Without a good mechanism and capability guarantee, business, product, and research and development will have a large deviation in the perception of the synchronization strategy and capability range of each channel, and even an iteration of requirements, each end When it can be synchronized has become an unpredictable thing, which brings a high degree of uncertainty in business demands for industry, production, and research.

And what we have to do is to find the certainty that technology can bring in these two kinds of uncertainties. How to systematically solve these problems has become the key for us to continuously improve R&D efficiency and experience on the basis of ensuring the flexibility of channel business.

In terms of response to differences, the ideal way for business R&D is to be insensitive to underlying changes and inconsistencies, and to respond to business demands with peace of mind. Based on this point, our main strategy is: Focus on "improving the consistency of R&D experience and improving the coordination mechanism of complex applications" "To ensure efficient iteration of business. This requires a strong set of infrastructure that fits the business characteristics to support it. The first thing that comes to mind is how to reduce costs and increase efficiency for business research and development by "promoting framework unification" and "realizing one code and multiple terminals". However, the ideal is very full, and the reality is very skinny:

Under normal circumstances, the upgrade of the framework has a high probability of bringing about business restructuring. After comprehensive evaluation, the small program business, which has the largest traffic in external channels, has become our priority business. Based on this, in order to minimize the impact on the business The impact and access cost, we have made it clear that the mini program is the first perspective to achieve multi-terminal.

The current situation and thinking of the industry based on the cross-terminal of small programs

After clarifying the direction, the question arises: is there any open source framework or solution suitable for us in the industry?

On the market, from the perspective of small programs, there are many excellent multi-terminal frameworks with similar capabilities, such as Taro, uni-app, Rax, etc., most of which use React or Vue as the DSL

So can these frameworks solve the problems we face? The answer is: not really.

Why did Ele.me choose to implement cross-terminal based on the applet DSL?

The following points need to be considered when considering Ele.me’s channel business background:

Transformation costs: Ele.me mini-programs represented by Alipay, WeChat, and Taobao have been in operation for many years, and most of the stock business is written in Alipay or WeChat mini-program DSL. Attention should be paid to the transformation cost of existing business logic (or component library), However, adopting the industry framework will basically directly lead to a large number of business restructuring, and the cost of this transformation is unacceptable.
Performance experience: Channel business is a very important traffic position for Ele.me. The emphasis is no different from that of APP, and there are extreme requirements for experience and performance. Therefore, we hope to reduce the introduction of runtime as much as possible while promoting cross-end performance loss.
Business collaboration: Since each channel is basically equivalent to a small Ele.me APP, the complexity is high, and it involves the collaboration of multiple business domains, including the consideration of the consistency of the main line, the integration of multiple business lines/application types, and the full link function Seamless connection, etc. In addition to this, it is necessary to give each business line the maximum self-control and closed-loop capabilities, behind which is the integrated research and development support of large-scale small program business.

After doing more horizontal comparisons and trade-offs, the adoption of the above frameworks was too costly for us, so we chose another path that is relatively difficult but more in line with the evolution direction of Ele. DSL is used as the foundation to build a cross-terminal solution to ensure that the product code of each terminal conforms to the native syntax of the applet to the greatest extent, so as to reduce the experience loss and multi-terminal access cost of services caused by isomorphism as much as possible.

Cross-terminal solution based on small program DSL

After deciding to use the small program DSL as the direction to build a cross-terminal solution, the first thing to solve is how to quickly adapt the existing small program to the multi-terminal. This requires a careful analysis of the differences at each end and a solution.

How to solve multi-terminal compilation of small programs?

In order to be able to balance performance and R&D experience, we chose a compile-time (heavy) + runtime (light) solution.

What problems does static compilation solve?

Static compilation conversion is mainly used to process parts of JS, WXS/SJS, WXML/AXML, WXSS/ACSS, JSON and other source codes that have strong constraints and cannot be dynamically modified, such as:

Module reference: module reference replacement and suffix name modification in source codes such as JS/WXS/SJS/WXML/AXML/WXSS/ACSS/JSON;
Template attribute mapping or syntax compatibility: in AXML/WXML, such as a:if → wx:if, onTap → bind:tap, { {`${name}Props`}} → { {name + 'Props'}}, etc.;
Configuration mapping: such as page { "titleBarColor": "#000000" } → { "navigationBarBackgroundColor: "#000000", "navigationBarTextStyle": "white" }

etc., the principle is to transform the source code into the code of the target platform by converting the source code file into AST (Abstract Syntax Tree) and manipulating the AST.

But static compilation can only resolve part of the differences, and some differences need to be smoothed out by runtime.

What problems does runtime compensation solve?

Runtime compensation is mainly used to deal with some runtime dynamic content that cannot be processed by static compilation or has high processing costs, such as:

JSAPI: In actual business use, whether it is the name of JSAPI or the input parameters of JSAPI, there will be dynamic assignment, which makes it difficult to parse the actual parameters through AST in the actual call of JSAPI;
Custom Components - Props Attributes: For example, Alipay attributes are declared using props, while WeChat attributes are declared using properties. The configuration methods are different and they are obtained using this.props.x and this.properties.x respectively. At the same time, there may be dynamic fetching value case;
Custom Components - Life Cycle: The didUpdate life cycle in the Alipay applet will enter the didUpdate life cycle after props and data updates are triggered, and prevProps / prevData can be accessed in didUpdate, while in the WeChat applet static transfer Defining this life cycle means that you need to dynamically analyze all the attributes to be used in didUpdate, and then dynamically generate listener functions for these attributes. This is obviously extremely low reliability;

Wait, there are many similar scenarios, so I won’t list them all here.

Through static compilation + runtime compensation, we can quickly migrate existing WeChat or Alipay applets to other applet platforms.

How to solve the problem of converting a small program to the Web?

With the launch of the takeaway mini-program for many years, various major channels (Alipay, Taobao, WeChat, etc.) have been switched to mini-programs, but there are still many sub-channels or non-mini-program environment channels, such as: various banking and financial channels, The extremely small package of the client, etc., still needs to rely on the form of H5 to quickly launch, but the current business of Ele.me is becoming more and more complicated, the investment resources of related channels are limited, the historical burden is heavy, the cost of iteration is high, and the product functions and service capabilities are far away. It is far behind Mini Programs and Ele.me App. The business urgently needs a technical solution that can quickly copy the functions of the applet to the h5 end, and meet the demands of the multi-channel capability alignment of the business with low R&D and maintenance costs.

Based on this background, we can naturally think that since applets can be transferred to other applets, whether it is also possible to directly convert applets to the Web, so as to maximize human efficiency and functional alignment efficiency.

How is it achieved? The main method is still through the organic combination of compile time + runtime:

Principles of Web Transition Compilation

The main difference and difficulty between the compilation part and the conversion of small programs to small programs is: it is necessary to uniformly convert and merge JS, WXS/SJS, WXML/AXML and other files into JS files and convert WXML/AXML files into JSX syntax, and unify style files Convert to a CSS file, and convert both the pages and components of the applet to React components.

runtime principle

The runtime of Web-to-Web is much heavier than that of other applets. In order to balance performance and experience, the core of runtime is to provide an efficient running environment equivalent to applets. It contains four main modules:

Framework: Provides the basic runtime functions of applets in the Web, such as: Page, Component, App and other global functions, and provides a complete life cycle implementation, event registration, distribution, etc.
Components: Provide support for common components of applets, such as view, button, scroll-view and other native components provided by applets
API: Provides a series of API implementations similar to wx or my in applets
Routing: Provides page routing support and method support such as getCurrentPages

Based on these four modules, combined with automatic injection and code conversion at compile time, and routing mapping, we can convert a small program into a Web SPA (single page) or MPA (multi-page) application, and successfully solve In order to solve the problem of business research and development efficiency, Ele.me's new M station is currently running based on this solution.

After solving the problem of compilation and conversion of each end, everything will be fine, and the next business only needs to realize one code and multiple terminals step by step based on this set of capabilities?

However, with the rapid expansion of Ele.me’s business scenarios and scope, some new demands have emerged, such as:

Alipay's independent mini-program is connected to WeChat mini-program as a subcontract
Taobao/Alipay's applet plug-in is connected to an existing WeChat applet as a subcontract
Alipay's independent applet is used as a plug-in to access the Taobao applet plug-in
The Alipay applet plug-in is connected to the WeChat or Douyin applet as a subcontract

Wait, if you observe these appeals carefully, you will find one thing in common: the form of the applet is different.

Although we already have multi-terminal capabilities, the difference in form has not been resolved. The previous practice of related businesses was to deposit general functions into the component library as much as possible, and output products in a multi-terminal manner. However, due to the same business in The problem of the difference in the form of different small program terminals is difficult to avoid in business, and the cost of reconstruction is relatively high, so some businesses choose to directly follow the different forms of different terminals (such as WeChat, Alipay, Taobao, Douyin) Each maintains a set of codes, but this not only prolongs the function synchronization iteration cycle, but also has many bugs, making maintenance difficult, and the development process is also extremely painful.

What are the differences in the form of applets?

Form differences refer to the differences in the operating modes of the three different forms of applets, applet subcontracts, and applet plug-ins, as well as the differences after conversion to other forms, as follows:

getApp diff
- Applet: You can get the global App instance and the attributes or methods mounted on the instance through getApp()
- Applet Plugin: Unable to call getApp()
- Small program subpackage: The global App instance and the properties or methods mounted on the instance can be obtained through getApp(); but when converted to a subpackage by the small program, the getApp originally called by the subpackage itself will be invalid and replaced by getApp of the host applet
App Application Lifecycle Differences
- Small program: The application will execute life cycles such as onLaunch, onShow, onHide, etc.
- Applet plugin: no application life cycle
- Small program subcontracting: no application life cycle
Global style (eg: app.wxss or app.acss) difference
- Applet: global styles can be declared through global styles
- Applet plugin: no global styles
- Small program subpackage: no global style
NPM usage restrictions
- Mini Programs: The support and limitations of each Mini Program platform vary
- Mini-program plug-ins: The support and restrictions of each mini-program platform vary
- Small program subcontracting: Each small program platform has different support and restrictions
Interface call limit
- Applets: unlimited
- Small program plug-ins: There are a large number of interface call restrictions, such as developing Alipay small program plug-ins or developing WeChat small program plug-ins
- Small program subcontracting: unlimited
routing difference
- Mini Program: After switching to other forms, its own routing will change
- Mini-program plug-in: After switching to other forms, its own routing will change. The jump plug-in page needs to include plugin:// or dynamic-plugin:// and other prefixes, and small programs or subpackages do not need to
- Mini-program subcontracting: the routing will change after switching to other forms
getCurrentPages difference
- Applets: unlimited
- Applet plug-in: the page stack of the applet cannot be obtained through getCurrentPages
- Small program subcontracting: unlimited
Page or component style differences
- Applets: unlimited
- Applet plug-in: Basic selectors only support ID and class selectors, not labels, attributes, and wildcard selectors
- Small program subcontracting: unlimited

And so on, the relevant morphological differences can be viewed in conjunction with each small program platform, and only the common parts are listed here.

How to resolve these differences?

Here are a few examples:

By automatically injecting the run-time simulation implementation of App and getApp into the product during the compilation process, it can solve the problem of error reporting caused by lack of subpackage and plug-in methods or conflicts.

The method is similar. It can detect whether the global style exists during the compilation process. If it exists, the corresponding global style reference will be automatically injected into each page and component to solve the problem of global style failure.

For the different NPM usage rules of each applet platform, NPM can be extracted to a specific place through dependency analysis, dynamic grouping, component extraction and packaging, reference replacement, etc., and the corresponding components and references in the page Replacement to solve the support problem of NPM, so that the business can basically use various NPMs without caring about platform differences.

By analogy, after the differences that are difficult to adapt to the business are resolved one by one, the remaining functional differences will be adapted by the business based on conditional compilation, which can greatly reduce the cost of business form conversion, and also form Our morphological conversion scheme for multi-terminal scenarios.

So here, the problem of multi-terminal conversion is basically solved.

How to manage "complex small programs"?

If the content mentioned above focuses on how to solve multi-terminal isomorphism and morphological problems through compilation, then the next thing to solve is the problem of application architecture and R&D collaboration for "complex small programs".

First of all, let us introduce the "complex applet" we defined, that is, the application with cross-business domain, long-term, multi-team collaboration, and presenting the main link + multi-branch business model. The reason why it is "complex" mainly reflects In terms of characteristics such as diverse application forms, diverse demands, and wide range of related businesses.

For Ele.me, each channel position is equivalent to a small Ele.me APP. In addition to providing convenience in research and development, a reliable application architecture is also needed to ensure its orderly evolution.

At the same time, due to the different positioning between channels, the business, product and R&D of each domain have different emphasis on each channel and the proportion of investment, which indirectly leads to the unevenness of the same business capabilities among channels, and the lack of functions of different channels continues to appear. .

Let’s take the Ele.me WeChat applet as an example:

What are the problems you are facing?

Complex engineering leads to low R&D efficiency: A large number of teams develop on a single small program application, which directly brings about poor R&D experience and low compilation efficiency caused by the huge size of the small program, and business interdependence, and single module construction fails It will cause the failure of the entire project. For example, the Ele.me WeChat applet takes more than half an hour to compile a single time, and the volume is close to the upper limit of 20m.
Irregular R&D process leads to poor stability: At the same time, due to inconsistent iteration cycles of different business teams, all business codes need to be released together for each release, even if a certain business subcontract or plug-in is not updated, but the corresponding underlying dependency library If there is a change, it is also very likely to introduce online bugs, resulting in high cost of testing and regression, and it is difficult to guarantee the quality of the release.

Solution: Integrated R&D model combining offline and online

Aiming at the core problems faced by the above two "complicated small programs", we have targeted to solve them through "offline integrated R&D" and "online R&D collaboration".

Offline integrated R&D

The key consideration is what kind of integrated research and development capability to provide, allowing multiple independent constructions (host, applet, plug-in, subpackage, etc.) to form a usable applet in the dimension of business units, eliminating strong dependencies between businesses, In order to achieve the purpose of independent development, debugging and deployment of the business, in terms of unifying the business collaboration process and reducing the cost of multi-terminal synergy, the key strategies are:

Provide a unified integrated R&D method and process
Provide standard, reusable integrated product specifications
Provide decoupling tools and integration methods for complex applets
Standardize the communication and capability injection methods between applet hosts, applet plug-ins, applet subcontracts, and applet modules

The small program host and each business module (subpackage, small program, plug-in) are merged into a complete small program after a series of processes such as form conversion, package pulling, compilation, construction, and merging, and can support according to different scenarios:

Main-sub-subcontract R&D mode: Split the subcontracts in the mini-program based on different businesses, so as to achieve the purpose of decoupling each business and independently iterating;
SDK R&D mode: Package general pages or components into an NPM package as an SDK providing specific functions for business use;
Small program plug-in development mode: integrated development can also be developed with small program plug-ins that support standards.

In this way, we can solve the problem of offline research and development.

Online R&D Collaboration

The "offline integrated R&D" described above provides business units with non-blocking development and debugging capabilities, but for the overall evolution of Ele.me's business, the emphasis is on the availability and controllability of the functions of each version. The scope of integration extends beyond all business domains and requires standardized process constraints:

Specifically, the ability to define business types is provided at the mechanism level, and developers can mark projects accordingly (main package, subpackage, plug-in, independent small program), and three stages of development, integration, and release are defined at the process level , which is somewhat similar to the APP development process:

Development: Each business application is developed by itself and combined with the platform deployment test. After the development test is passed, wait for the opening of the window period to enter the integration test;
Integration: The administrator sets the integration window period. During the window period, the business is allowed to integrate R&D multiple times to confirm the final integrated stable version. During this period, the main package administrator can deploy the trial version multiple times for integration testing. After the window period ends, random changes are not allowed;
Release: After the integration test is passed, each business performs code CR and enters the release stage, waiting for the main package review to pass the release and go online. Finally, the administrator completes this iterative release. After the release is completed, the main subcontract products that meet the standards will be saved. In subsequent iterations, if a subcontract has not changed, the product will be reused directly, which greatly reduces the risk of business release and improves the overall construction efficiency.

Going a step further, best practices for multi-terminal services

Through the dual capabilities of offline integration + online collaboration, combined with the existing multi-device compilation capabilities, while successfully supporting the stable and efficient R&D of Ele.me's multi-device channel business, we are also thinking about future-oriented multi-device R&D What should the schema look like?

The following figure is what we expect Ele.me to look like when its current multi-terminal application architecture is evolving:

As can be seen from the figure, we divide the application architecture into three layers (from bottom to top):

Basic service and R&D specification: The bottom part is the basic service and R&D specification. The multi-terminal R&D framework, multi-terminal R&D platform and multi-terminal R&D specification provide unified R&D support to ensure the basic capabilities, experience and efficiency of business R&D. Relevant businesses are packaged, encapsulated, integrated, and deployed and delivered to different channels;
Host application framework: The second layer is the host application framework (Framework), which can also be considered as a multi-terminal unified solution, which undertakes the basic API (such as login, location, request, routing, experiment , risk control, buried point, container, etc.), basic components and best practices, through channel-based configuration operation, standardized access methods and centralized capability management, to ensure the lightweight, standardization and continuous iteration of the overall framework and upgrades;
Channel application subject: the top layer is the application entity of each business, which consists of a shell project + N business projects. The shell project undertakes some capabilities customized by each channel, and exposes the capabilities of the lower-layer application framework to the upper-layer businesses. Each business only needs to care about two things:
- Multi-terminal form: In what form is it connected to the corresponding channel (that is, in the shell project)?
- Business functions: What functions do different channels need to demonstrate?

Based on this layered collaboration model, the business's perception of multi-device differences can be eliminated to the greatest extent, and the focus can be placed on how to better provide services to users.

The above content is Ele.me's cross-terminal practice and solutions based on the small program DSL. Let's take a look at the specific results achieved.

Cross-terminal results

Ele.me display of business effects of each channel

Business one-code multi-terminal R&D efficiency improvement data

R&D Efficiency Improvement: The average efficiency of business using the one-code multi-terminal and integrated R&D model is increased by 70%, and the more isomorphic terminals, the greater the efficiency improvement
Multi-terminal proportion: 85%+ of Ele.me’s internal multi-terminal business is based on this solution to realize multi-channel business development and launch
Business coverage: covering all business sectors of Ele.me

Ability Precipitation — Ele.me self-developed MorJS multi-terminal R&D framework

MorJS open source

We integrated Ele.me's multi-terminal multi-channel research and solutions into the MorJS multi-terminal R&D framework, and opened it to the community through Github open source.

GitHub warehouse address: https://github.com/eleme/morjs

The following figure shows the complete architecture diagram of MorJS:

The MorJS framework currently supports:

2 DSLs: WeChat Mini Program DSL or Alipay Mini Program DSL
4 compilation forms: applets, applet plug-ins, applet subpackages, and applet multi-terminal components
9 target platforms: WeChat, Alipay, Baidu, Byte, Kuaishou, DingTalk, Taobao, QQ, Web

It also supports the R&D and launch of most of Ele.me's C-end businesses on various channels.

For Ele.me, MorJS solves the problem of differences in multi-terminal R&D for a large number of businesses, allowing the focus of small program development to return to the product business itself, reducing users' investment in multi-terminal difference compatibility. Through the open source of MorJS, we hope to present the implementation details, architectural design and technical thinking to everyone, and serve more enterprises and developers with similar multi-terminal isomorphic needs. At the same time, we also hope to use this to attract more like-minded partners to participate in the joint construction, and together accelerate the development of the mini program's one-code multi-terminal capability. We welcome small program developers to communicate with us.

Introduction to MorJS Features

In order to help users in the community get started quickly, we have made a lot of preparations in terms of ease of use, standardization and flexibility:

Ease of use:

DSL support: You can use WeChat Mini Program DSL or Alipay Mini Program DSL to write mini programs without additional usage costs;
Multi-terminal support: support to convert a set of small programs into various small program platforms and web applications, saving double manpower;
Quick access: You only need to import two packages and add a configuration file to easily and quickly access existing applet projects;

standardization:

Out of the box: built-in scaffolding, construction, analysis, multi-terminal compilation and other complete research and development capabilities, only one dependency is needed to get started developing;
Consistent performance: Smooth out the differences between multiple terminals at compile time + runtime, so that small programs on different platforms can obtain a consistent user experience;
Form conversion: support different forms of the same project, allowing mutual conversion between different forms of small programs, subpackages, and plug-ins;

flexibility:

Easy to expand: MorJS plugs the complete life cycle and internal functions, and uses plug-ins (sets) to meet the hierarchical requirements of functions and vertical domains;
Type support: In addition to the standard file types of applets, it also supports multiple file types such as ts, less/scss, jsonc/json5;
On-demand adaptation: The adaptation capability can be selectively accessed according to the needs. Small projects only need the compilation function, medium projects can combine compilation and page injection capabilities, and large projects are recommended to use complex small program integration capabilities;

At the same time, it also provides a wealth of documents: https://mor.eleme.io/ for your reference.

user voice

In the past few months since MorJS was launched, we have received positive feedback from some community users, as well as some appeals and questions. Among them, the most worrying question for users is: Is MorJS a KPI project, and will it be maintained for a long time?

Here I borrow my reply from the discussion area (Discussions) of the Github project:

looking to the future

In the future, on the basis of the existing MorJS capabilities, we will further improve the existing multi-terminal capabilities, improve the availability of multi-terminal conversion, improve the compatibility with various community component libraries, and continue to expand the support for compiling target platforms (such as Hongmeng, Quick apps, etc.), while continuing to provide high-quality services for Ele.me’s own business and community users, it is hoped that one day MorJS can become one of the infrastructures for multi-terminal research and development of small programs in the industry.

Author｜Feather environment

Click to try cloud products for free now to start the practical journey on the cloud!

Original link

This article is the original content of Alibaba Cloud and may not be reproduced without permission.