Multi-Platform Front-End Development with Taro: Technical Selection, Integration, and Performance Evaluation

Author Frank, a former Ctrip front‑end engineer, focuses on performance optimization, multi‑platform development, and engineering construction.

With the proliferation of mobile internet and smart devices, front‑end developers must adopt multi‑platform (mini‑program, App, Web) solutions, facing differences in browser engines, operating systems, interaction models, and programming languages, which increase development effort and maintenance complexity.

Multi‑platform (同构) technology aims to reduce cost and difficulty by providing a unified code base that can be adapted to various terminals, improving development efficiency and user experience consistency.

The article evaluates five mainstream cross‑platform frameworks—Hybrid, React Native, Flutter, Weex, and Taro—across cross‑platform capability, cost, performance, code‑language universality, and Ctrip internal support, using a star‑rating matrix.

Hybrid uses JavaScript and WebView, offering low cost but limited performance; React Native provides near‑native performance for Apps but lacks mini‑program support; Flutter, based on Dart, delivers superior performance on Apps but has limited hot‑update support on iOS; Weex, a Vue‑based solution, offers similar capability to React Native with a smaller community; Taro offers an open‑ended, cross‑framework solution with high cross‑platform capability, good code‑language universality, and strong internal support, making it the chosen technology.

Integrating Taro with existing Ctrip technologies involves:

For App (React Native): injecting custom plugins in Taro’s config, alias replacement in Metro bundler, and adapting Taro components/APIs (e.g., Text, navigation) to RN equivalents.

For Web (NFES): using Taro’s static compilation with Next.js‑based SSR support, injecting H5 plugins, alias replacement via Webpack, and adapting components/APIs similarly.

Technical practice covers component and API richness (over 60 built‑in components, with additional business‑specific extensions), handling platform‑specific differences (e.g., animation implementation across RN, mini‑programs, and Web), and CSS adaptation challenges such as lack of nested styles, pseudo‑elements, and platform‑specific property support.

Performance tests show that Taro’s static‑compiled View component is slower than native divs on Web (≈123 ms vs. 17 ms for 2000 renders), suggesting a wrapper approach that combines Taro functionality with native Web components.

Applicable scenarios: when >70% UI similarity across App, H5, and mini‑programs, a single View layer can be shared; PC often requires separate Views due to distinct interaction patterns. Multi‑platform development is suitable for applications needing consistent functionality across terminals, but not for performance‑critical or platform‑specific features (e.g., canvas games).

Cost analysis indicates that after adopting Taro, development effort drops from a total of 4 person‑months to 2.2 person‑months across App, H5, mini‑program, and PC, with additional learning and testing overhead that can be mitigated through unit and automated testing.

In conclusion, Taro enables code reuse across multiple platforms, reduces development and maintenance costs, and improves user experience, positioning it as Ctrip’s primary multi‑platform front‑end framework for future projects.