Carry the main battlefield of the Web shift

On January 9, 2017, in the morning WeChat launched a small program, for the mobile end family adds new business form and style, when everybody was on this new platform can do, jingdong first launched “jingdong shopping” small programs, then more electricity industry giants are in small programs, from now on, The main battlefield of e-commerce has gradually shifted from mobile apps that need self-built traffic to small programs.

The emergence of small programs has brought great challenges to the research and development of e-commerce industry. More and more traffic head after WeChat Internet companies have targeted small program this cake, have launched their own small application platform, such as jingdong, ali, baidu beat, bytes, 360, etc., in order to make our electricity business can quickly ported to these small application platform, help our rapidly expanding business channels, we started a new attempt.

We started to experiment with technology, to explore a new technology that would unify all platforms.

Break through the thorns — the birth of the first-generation architecture

React applet?

As mentioned earlier, WePy and MPvue emerged as a solution to the pain points of multistage development of various application platforms, so why don’t we just adopt them instead of “building the wheel”?

At that time, React and Vue, both of which remained the dominant front-end UI frameworks, were indispensable when it came to front-end frameworks. In addition, it was common to see enthusiastic communication between fans of the two frameworks on the Internet, which generated some sparks of ideas and made the community extremely active.

In 2017, our team bravely abandoned the historical baggage and was honored to introduce the React technology stack. This led our team to get rid of kerosene lamps and start getting electricity, away from slash-and-burn front-end development. In order to meet the business environment’s requirements for extreme performance and compatibility with lower versions of Internet Explorer, we also developed an excellent React framework, Nerv, which deepened our understanding of React development philosophy and technology stack.

Unfortunately, the community didn’t have a framework for developing applets using React.

React is obviously more modern and standardized than the applets development approach, and React is inherently componentalized for our business development, and JSX is much more expressive than string templates. That’s when we started thinking, can we write applets with React?

Explore rationally

By comparing React applet and React applet, we can still find that there are many similarities between them, such as life cycle, data update method and event binding. This provides a good foundation for using React applet.

However, we should also see one big difference between applets and React: templates. React uses JSX as a template for components, while applets use string templates like Vue. These are two completely different things, and it’s a huge obstacle for us to explore solutions. So, in order to achieve the goal of writing applets using React, we had to address the huge difference between the two.

Resolve differences

Since wechat does not support JSX, we just need to compile JSX into a small program template to run on wechat soon, this step can be achieved through Babel.

As a code compiler, Babel can compile ES6/7/8 code into ES5 code in three stages:

  • Parsing process, in the process of lexical, syntax analysis, and semantic analysis, generate ESTree standard virtual syntax tree (AST)
  • The transformation process, which makes defined actions against the AST,babelConfiguration file of.babelrcDefined in thepreset 、 pluginIt is in this step that the AST is executed and changed
  • The build process generates a string of object code from the AST transformed in the previous step

Coming back to our need to compile JSX into a small program template, it is fortunate that Babel’s core compiler, Babylon, supports parsing of JSX syntax and can be used directly to help us build AST. The core of our focus is on transforming AST. Get the new AST we need, and then recursively traverse the new AST to generate the template of the small program.

This is just the tip of the iceberg for our conversion rules. JSX is extremely flexible, so we can only support the common and React recommended conversion rules by using an all-inclusive approach.

The first-generation architecture was born

After time and again, we’ve been able to convert the React class code into code that can run in an applet environment. But when we get excited, we calm down and think about what else we can do for fun.

We find that in our normal work, our business often has some “multifaceted” requirements. The same service or page needs to adapt applets, H5, and even React Native. At this point, you will find that you may need to write the same interface and logic several times.

Therefore, we hope that React applet can be adapted to H5 terminal, mobile terminal, and various platforms while developing wechat applet. Write once, run anywhere is the dream of all engineers.

However, after careful consideration, we will find that it is far from enough to simply convert the code in accordance with the corresponding syntax rules, because different ends will have their own native components, API and so on. After the code is directly converted, it cannot be executed directly, but also needs to be adapted at runtime. Therefore, we implement component library and API library in other end (H5 and RN) according to the standard of component library and API of wechat small program.

It took about three months from the inception of Taro’s project to the stabilization of the architecture. From the initial heated discussion and collision of various ideas, to the gradual formation of the project, the hot development iterations, and now the smooth support of the apu, H5 and RN platforms, Taro’s future has come.

New GitHub open source

Taro, the multi-endpoint unified development framework, is officially open source on 7 June 2018.

Taro is the first development framework that supports writing small wechat programs using React syntax and ADAPTS them to multiple applications. Less than two months after open source, there are more than 6,600 stars on GitHub, topping GitHub Trending for weeks; Meanwhile, nearly 300 issues have been processed, and more than 100 are waiting for feedback and optimization. There have been more than ten Taro projects that have received feedback from both inside and outside the company.

As of December 18, 2019, Taro has 22,254 Stars and 250 ficolin-3 players with 150+ community-initiated development cases: taro-user-cases, some of which are multi-ended.

As of January 11, 2021, Taro has 27914 Star, ranking among the top applets development frameworks.

The Taro team continues to iterate on the community’s questions and feedback, and continues to refine the Taro framework around multi-application, development experience, and community building.

In order to facilitate developers to develop projects quickly, we launched Taro UI, the industry’s first small program multi-component library based on Taro.

In terms of multi-end adaptation, we continue to follow up and become the most adaptable applets development framework in the community.

For a better development experience, we support React Hooks, CSS Modules, Mobx, etc.

In terms of community building, we have launched platforms such as the Taro Forum and the Taro Material Market, followed by the community building plan.

In follow up the business at the same time, we also need to constantly follow up questions and feedback in this community, and thus must constantly work overtime to complete, although sometimes feel very tired, but the technical achievement, and can help developers to more satisfaction or constantly inspire us to go forward, let Taro project is getting better and better.

Hard work — a painful climb to the next level

Taro has received a lot of praise since its launch on GitHub as an open source, and it has exceeded 10,000 Stars in a short period of time. However, due to the complex design of Taro’s initial custom component architecture, there will always be a lot of problems when using components for development, which has been criticized by many users.

In the early stage of Taro’s design, the template tag is used to implement the componentization architecture due to the imperfect functions of the customized components just launched by the wechat mini program, which cannot meet the requirements of flexible use of componentization.

Componentalized architectures implemented using the Template scheme work well in general, but problems occur when complex loops are nested with output components, mainly because:

  • The JS logic is isolated from the template and needs to be handled separately, resulting in cumbersome component parameter passing and difficult alignment
  • A custom component implemented by template cannot nest child components

Therefore, in the early days of Taro, the problem of custom components was always a pain for us. As an official team, we had to face the constant feedback and doubts from the community while thinking about solutions, which made us feel gloomy about our future.

However, previous experience tells us that we should not give up. Lu Xun once said, “If there is no fire afterwards, I am the only light.” After struggling with the Template solution for so long, we finally turned to custom components that come with applets.

Is the so-called mountain and water doubt no way, another village, small program custom components just have a wave of updates, after a few days of overtime exploration, the problems that plagued us before have been solved one by one, the perfect implementation of the new custom component architecture, bringing a more stable version.

In the new architecture, we will compile Taro’s components directly into Component method calls of the native components of the applet. Taro’s Component processing will be implemented by using the componentization capability of the applet through runtime adaptation to handle Component parameters, lifecycle adaptation, and event incoming.

After the reconstruction of this version, the stability and reliability of Taro has achieved a qualitative leap, and the community continues to praise it, while the number of Taro’s attention has also increased sharply. This version of the architecture has also become the longest-running program ever implemented by Taro, laying a solid foundation for the future development of Taro as a multi-faceted program that can be trusted.

It was an experience of pioneering hardships and valuable experience for the Taro team. There is no smooth journey all the time. Only by not giving up and being brave in pioneering can we see the future and go further.

To push ahead — to constantly push yourself

After completing the transformation of the custom component architecture, Taro has gone into full swing.

In November 2018, Taro launched version 1.1, which completes the application support for Baidu and Alipay, becoming the industry’s first multi-end development framework for multiple application platforms at the same time. During the application, the Taro team established contact with the official teams of Baidu and Alipay Apps. For the development of the other small program put forward a lot of constructive suggestions. At the same time, Taro has become one of baidu’s official recommended frameworks for small programs.

Just one month later, in December 2018, Taro quickly launched Version 1.2, an innovative version that enables Taro to reverse convert native code from small programs to Taro code. The original wechat small programs can be quickly transplanted to other platforms through Taro conversion, which provides a huge imagination for the rapid expansion of business and provides a great boost for the efficient delivery of business.

The “JINGdong Express” business is a good example of the successful application of reverse conversion features. Originally, “JINGdong Express” only had wechat mini program platform. Through Taro’s reverse conversion feature, it can be quickly transplanted to Baidu and Toutiao mini program platform at a very low cost. In addition, it can maintain only one code and maintain three applications at the same time, greatly reducing the maintenance cost.

Following the launch of Taro 1.2, Taro has received great praise and attention in the industry: The number of Stars on GitHub is more than 19,000, and THE number of NPM downloads remains the first among similar development frameworks. Meanwhile, the Taro team has also carried out in-depth and effective cooperation with the R&D teams of dozens of industry giants such as Tencent, Baidu and Huawei.

In June 2019, six months later, we finally launched Taro 1.3, our longest planned release: six months in development, nearly 2,000 code submissions, and nearly a hundred developers. Taro 1.3 not only brings support for QQ apps, but also for fast apps, making it the industry’s most supported multi-purpose development framework. More importantly, in this release we successfully put the industry’s hot React Hooks into Taro, It is an industry first that allows users to use React Hooks to develop small programs.

From the official launch of Taro to Taro 1.3, it can be seen that Taro has been constantly using the concept of innovation to polish itself, with innovation as its mission, to bring multi-terminal development solutions with excellent experience to the industry.

Embrace change — think for the future

Although Taro has always maintained a high rate of iteration, the overall architectural design of Taro has not changed much since the transformation of the custom component architecture, which makes Taro seem a bit buddhist at this moment in the changing era. Moreover, for a technical team that wants to make breakthroughs at all times, routine maintenance work, Obviously, it cannot appease our restless heart. After all, people’s dreams will never stop, so we decided to launch a series of subversive reconstruction designs.

We first start from CLI for transformation. As is known to all, originally Taro CLI compilation and construction system is self-developed. The whole construction system has complex logic and numerous marginal conditions to be considered, which leads to the following problems:

  • Maintenance is difficult. Every time a new function needs to be added, such as parsing Markdown files, the CLI needs to be changed directly, which is not flexible enough
  • Difficult to build. CLI code is very complex and has many logical branches, which makes it difficult for many people who want to build together to start
  • Low scalability. The self-developed construction system did not consider the subsequent expansibility at the beginning of design, leading to developers who want to add customized functions

Based on these issues, we decided to use Webpack for compiled builds, and 2.0 was born.

Taro 2.0’s CLI will be very lightweight and will only be able to differentiate between platforms, handle input parameters for different platforms, and then call the runner compiler of the corresponding platform to compile code. A large number of AST syntax operations will be transformed into Webpack Plugin and Loader to be handled by Webpack.

Compared to the old build system, the new applets compilation brings the following advantages:

  • It’s maintainable, a lot of the logic is left to Webpack, and we only need to maintain a few plug-ins
  • More stable, the new build will be more stable compared to the self-developed build system, reducing the probability of some strange errors
  • With strong expansibility, you can add Webpack Loader and Plugin to do the extension you want
  • Unified compilation of all ends. After access to Webpack, compilation and configuration of Taro ends can achieve a very large degree of unity

You can see a big improvement with the new build system. At the same time, more importantly, based on Webpack, we can try more features and technologies in small programs, such as optimizing the size of code packages through Tree Shaking, so that the development of small programs can be more in step with the development of the industry and Taro can embrace the community more.

Taro 2.0 is just the beginning.

At the last GMTC global Big Front-end Technology Conference of the decade, the Taro team showcased the arduous journey of exploring and implementing cross-framework development of small applications, and also provided an early glimpse of the ongoing development of Taro Next.

That is a completely different version of Taro’s past, a completely different path from the one he takes now, indicating that He is changing his life.

Festival scenery do not treat each other, sangtian Bihai a moment to change.

In the next decade, many frameworks will be dead and many technologies will be reborn. Nothing is constant, only change is constant, and all we can do is embrace change and think about the future.

Ride the waves — the new architecture sets sail

As mentioned above, Taro welcomes a new structure.

Different from Taro 1 and 2, the new architecture is mainly based on runtime. We all know that React web development relies on the React-DOM to manipulate the DOM tree, while React Native relies on the Yoga layout engine. React, however, connects them together through abstract Virtual DOM technology, which enables cross-platform unification. Although there is no DOM and BOM API directly exposed in the applet, we can simulate the API to implement DOM and BOM in the applet by analogy with React and React Native, so as to directly run React into the applet environment. That’s where Taro’s new architecture comes in.

With the support of the new architecture, Taro is no longer limited to the React camp, and can no longer restrict the use of frame syntax. Officially, Taro has built-in support for four frameworks: React, Nerv, Vue2, and Vue3.

Taro2 to Taro3, is a technological leap, is also a victory of innovation, but also the embodiment of the Taro team’s continuous exploration, never stop spirit. The big ship Taro has set sail again with its original intention.

Riding the wind and waves will sometimes, straight sail to the sea.

Open architecture

Half a year has passed since the official launch of Taro 3 in early July 2020. In the meantime, we’ve been working on fixing the problem, and thinking about the next minor release.

Faced with an increasing number of small application platforms, Taro has decided whether to support only some of the mainstream small application platforms, or to become the infrastructure for all small application platform development and multi-terminal transformation. In V3.1, Taro gives the answer: open architecture.

Based on the Taro 3 architecture, single-platform compatibility code is distributed throughout the Taro core library, both compile and runtime. Supporting a new platform requires all of these changes, development complexity is high, and community participation is difficult.

So we came up with the idea of creating an open framework. The goal is to extend Taro’s terminal platform support through plug-ins:

  • Plug-in developers can write a terminal platform plug-in without modifying the Taro core library code.
  • Plug-in users simply install and configure the terminal platform plug-in to compile code to the specified platform.
  • Developers can inherit existing end-platform plug-ins and customize the platform adaptation logic.

We packaged the six platforms with built-in support as plug-ins, and the CLI loaded them all by default. In the process of encapsulation, we retrieved the latest components and apis of each small program, updated and supported all of them, and aligned the latest capabilities of each small program. With the open architecture, we have written several terminal platform plug-ins that developers can use after installing.

conclusion

Open source is not easy, you need to adhere to. Along the way, Taro has been accompanied by many developers who have entered the Top 5 most active open source projects in China. Just like the river flowing forward, Taro is always competing with each other. The Taro team would like to extend our heartfelt thanks to all the friends who have participated in the construction of the open source project, whether they have submitted code for Taro, built the surrounding ecology, provided feedback, or even just discussed and joked with us over dinner.

Concave-convex reveal series article address

1. Past and Future of Bump Laboratory

2. “Concave and convex Technology Revealed · Linglong Intelligent Design Platform · Dream Oriented Design”

3. “Concave and convex Technology Revealed · Deco Intelligent Code · Start the Revolution of Production and Research Efficiency”

4. “The Secrets of Concave-convex Technology · Visualization of Linglong Page · The Road to Growth and Transformation”

5. “Concave and convex Technology Revealed · Quark Design Assets · Creating high-quality Materials of the whole Matrix”

6. “Concave and convex Technology Revealed · Tide R&D Platform · Layout of NEW R&D infrastructure”

7. Revelation of Concave and Convex Technology · Taro · From Span end to Open Span Frame

8. Revelation of Concave-convex Technology · Basic Service System · Building Technology Center of service End

9. “The Secrets of Concave-convex Technology, Technical Improvement and Business Development”

10. “Concave and convex Technology Revealed, Number lazy, growth team good helper

other

Thank you for your attention to concave-convex laboratory readers. In order to provide better content, I hope you can spare a few minutes to complete a small survey. Next year, the content of concave-convex public account is up to you. Click on the direct

Join the concave-Convex Laboratory open, open source, professional, loving and dream family? Click on the direct

For those readers who haven’t followed bump Lab, please follow us. We only push 4 times a month. We cherish every push and won’t let you down. Wechat search “bump lab” can be followed.