Chameleon Cross-end Framework – The open source work of an idealistic team

• background
• The solution
• The principle of
• proven
• Production application Examples
• Ease of use is good
• Polymorphic agreement
• Low learning cost
• Progressive access
• The contrast
• In the late planning
• Idealism,

After nearly 20 months of work, Didi’s cross-platform solution Chameleon is finally open source github.com/didi/chamel… , really focus on one set of code to run multiple.

background

Wechat live 1 billion monthly (more than the number of Internet users, multiple accounts?) , Alipay 400 million, Baidu 330 million; In Q3 2018, Android phones accounted for more than 80% of the smartphone market in China; Both BAT and Android apps are the real user entrance for Chinese Internet users. As small Internet companies, they hope to take advantage of small programs to ride a wave of traffic.

The historical development of computer technology tells us that every new technology will experience the stage of “independent”, and small program technology is no exception. Wechat small program as the founder, although other small programs are deliberately imitate in the implementation principle of technology, interface design, but as a front-line developer in the face of the same application often need to repeat development, testing, formerly 1 unit of work into N units of work.

Didi chuxing’s r&d engineers are among the most prominent victims. The company has access to wechat Wallet, Alipay and Android Apps, and accounts for a large share of user traffic.

A variety of mini-programs have reached all Chinese Internet users, and the project itself has grown since Facebook opened react in 2013. ReactNative, a spin-off of the original WebUI engine, has even more ambitious goals.

Vue. Js was released in 2014 and occupied a large number of user groups against the current. In 2016, Alibaba also released weex project based on Vue, and NativeAPP can be written with Vue.

At the end of 2018, Google officially released future-oriented cross-andoID and IOS Flutter1.0.0, which has a bright future as a future-oriented cross-end framework.

The solution

Although the environment of different end frameworks is constantly changing, no matter all kinds of applets, Weex, React-Native, Flutter and fast applications, they are always the same is the DESIGN idea of MVVM architecture. Chameleon wanted to use one set of code to fulfill all side requirements and converge the same business logic to the same layer of system without making the project less maintainable due to the same abstraction.

Make MVVM cross-end environment unified: Based on the common technical characteristics of various cross-end technologies (Weex, React-Native, WebView browser, Flutter) and product businesses (wechat applets, Kuaiapps, Alipay applets, Baidu Intelligent applets, Toutiao applets, and other applets) — MVVM architecture design, Chameleon, a programming language framework aimed at unifying the MVVM cross-end architecture platform (any terminal designed using the MVVM architecture can be developed and run in Chameleon).

View:

ChameleonSDK includes various applets, Web, and clients (React-Native, Weex, and Flutter). Currently, it supports wechat applets, Web, and Weex, and will support more MVVM as standard applications in the future.

View Model:

CML(Chameleon MarkupLanguage) is a set of label language designed by the framework. It combines basic components, event system, and data binding to build the structure of a page. In order to reduce the learning cost, VueTemplate class is supported.

The principle of

proven

When wechat mini program was released in 2017, Didi, as a whitelist user, first tried to access it. At this time, we specially set up a small project team of 1 or 2 people to complete a project named MPV. The goal of the first phase was to “achieve a set of code to run web and wechat applets without affecting users’ performance and relying on the principles of the framers”. After the development of MPV, more than 90% code reuse has been achieved in several project practices. Overall, the development efficiency and testing efficiency have been significantly improved, while exposing more problems:

• Maintainability issues, no separation of common code and end difference code.
• The direction of MPV is wrong. MPV uses the syntax standard of small program (life cycle of small program, API interface, etc.), which makes it difficult for users to clearly understand the usage specification.
• There are too many small differences around each end.
• The template DSL syntax is not canonical.
• The interface effects at both ends are inconsistent.
• Multi-terminal debugging costs are high.
• Engineering construction is backward.
• There is no direct use of existing ecological components on each side, i.e. there is no standard specification to access existing open source components on one side.

In April 2018, we further expanded the scale of the cross-terminal project and named the cross-n-terminal solution Chameleon/ KMILn /, short for CML. The Chinese word for chameleon means a cross-end holistic solution that can adapt to different environments just like a chameleon.

With the accumulation of MPV practice, Chameleon has not only solved various maintainability problems encountered, but also made the subsequent planning more clear. The goal is really focusing on making a set of code run multi-terminal and providing standard MVV M mode to unify various terminals.

After a year of practice in hundreds of pages by dozens of front-end developers, this week is officially open :github.com/didi/chamel… .

Production application Examples

Ease of use is good

One of the most challenging aspects of the concept of a set of code running multiple sides is how to ensure ease of use.

• Development fast, the overall development process to be efficient.
• Simplicity, large space for customization of each end development, and common code will not be mixed with a certain end of the code.
• Good performance, cannot increase the output file package size.
• Consistency, multi – end to achieve the same effect.

Polymorphic agreement

After multi-terminal merger, it is inevitable to realize the differentiation of each end. At the beginning, differentiated code and business logic are mixed together. This is awkward, if you don’t think this is complicated, suppose there are 4 or 5 ends, business logic mixed with cross-end logic, product logic not broken, poor readability, requirements change, pull the whole body, each end has to be tested, cross-end code efficiency becomes counterproductive.

The differentiation code at each end is also mixed with logic

The polymorphic protocol design is inspired by the Apache Thrift – scalable cross-language service development framework, which is also cross-language in nature. It allows Chameleon developers to quickly access the underlying functionality of each client or to differentiate business implementations, avoiding poor readability and maintainability.

The polymorphic protocol defines a standard interface, and each end module implements it independently. The input and output of the interface are checked at compile time and run time.

There are two main objectives:

• Ensure multiple maintainability
• Break up multi-terminal code at compile time

Polymorphic protocol can effectively isolate the common code from the differential code to ensure that “the river does not invade the well” when users extend the functions of individual products with inconsistent effects or specific underlying capabilities according to the standard specifications.

For example, you might use Echarts when you want to develop a charting feature:

1. Follow the Web version separately in the projectnpm install echartsAnd wechat version download relevant files
2. Then define a polymorphic component charts
3. Define the input and output of this component in charts/ charters. interface
4. Call wechat version (wechat applet component folder) and Web version (.vue suffix file) in charts/charts.wx. CML and charts/charts.web. CML respectively.
5. Finally, you can use this component in your project

The output package contains the code for only one side of the component; Because of the input and output constraints, the component calls exactly the same, no special logic processing according to the end. You can place the Echart polymorphic component in a separate warehouse for separate maintenance and distribution; Others can use NPM install Echart without having to deal with the internal details.

Low learning cost

The CML syntax of THE VM layer is an abstract DSL of the associated view layer and the logic layer. Its learning cost is the most suggested by many enthusiastic students who help us. Its learning cost is very low, including two-way data binding, event binding, component tree, conditional statement, loop traversal and so on. At first we rejected it, but after some consideration, we compromised to support a VUe-like syntax to make CML easier for developers.

Progressive access

Many people have already developed small programs, but do not want to reinvent most of them, and also want to use CML? Sure, there are two ways to use CML:

Description/Type	The entire project uses CML	Common components use CML
The diagram
instructions	Business layer requirements are highly similar across end environments, There was a need for repeated development and testing for different ends, Then use Chameleon to run the entire project “from top to bottom” in one set of code.	Common components need to be developed and tested repeatedly, Develop common components using a set of code, Common components can be used directly by each end
For example,	Home page, details page, orders	Share component, payment component, Map component, Picker component

The contrast

Other frameworks in the industry do not have the same goal as us, we want to truly a set of code to run multiple times, while other frameworks are nothing more than “a small program syntax enhancement” or “promote a framework to write small programs”, but there are some overlap, to list the functional comparison:

In the late planning

Idealism,

1. We can’t bear to waste our time on repetitive work.
2. Either do not do to do to the extreme, a set of code running multi terminal is idealism, this road is very difficult, but we are paranoid to believe that we must do our best to make it, as a not so confident person, not to do good is not dare to release.
3. Every detail of the CML framework had to be done to perfection, and we couldn’t tolerate design flaws, so CML weekly meetings would often last six hours into the night.

Quick start: cmljs.org/doc/quick_s…

Frequently asked Questions: cmljs.org/doc/framewo…

Welcome to contribute code: Didi/Chameleon