Cross‑Platform Native Fusion: Expert Insights from IMWeb Conf 2018

Background

Write once, Run anywhere.

This famous programmer slogan, originally Java’s slogan from 1991, reflects the long‑standing desire to bridge language and platform gaps. Despite many efforts, a perfect solution still does not exist, and the reality often becomes “Write Once, Debug Everywhere.”

In recent years, numerous cross‑platform mobile solutions have emerged as mobile internet matures and traditional PC technologies migrate to mobile. The rise of WeChat Mini‑Programs adds another player to the Web, iOS, and Android landscape, making cross‑platform integration essential for reducing development costs.

The term cross‑platform fusion captures both the aspiration of innovative developers and the concern of traditionalists.

Event Overview

On October 14, 2018, in Shenzhen, the IMWeb Conf 2018 hosted a “Native Cross‑Platform Fusion” track featuring leading front‑end evangelists from major companies. Attendees could learn the history and latest trends of cross‑platform technologies, dive into underlying principles, compare solutions, and discover which approach best fits their business.

Session Topics

Deep dive into the multi‑platform development framework Taro – Li Weitao (JD)

Hippy – Billion‑scale dynamic operation solution – Zhao Honggang (Tencent)

Hippy – Terminal architecture design and core optimization – Sheng Bo (Tencent)

Weex core principles and evolution direction – Zhang Han, Shen Yuan (Alibaba)

Expert Q&A

Question 1: Some foreign companies are abandoning React Native (RN) for native development. Should new projects still invest in RN?

Zhao Honggang: No technology is a silver bullet. For well‑resourced projects like Airbnb with modest dynamic needs, RN’s advantages are limited, so abandoning it is understandable. However, for scenarios demanding high development efficiency and heavy dynamic operations, RN remains a solid choice because it bridges native and H5 pain points. Existing issues are being addressed by frameworks such as Tencent’s Hippy, which aims to become a “non‑pain” solution and represents the future of mobile development.

Question 2: Facebook is rewriting RN, indicating performance concerns. If a new RN version outperforms alternatives, how can teams switch back quickly?

Zhao Honggang: RN’s origins were fragmented across Android and iOS, leading to architectural shortcomings and performance bottlenecks. Facebook’s rewrite focuses on low‑level communication while keeping the upper‑level API compatible. Since Hippy already maintains RN‑compatible APIs, migrating from Hippy back to RN would require minimal effort, essentially zero cost at the business layer.

Question 3: JSBridge communication can be a performance bottleneck. Beyond reducing payload size and call frequency, what deeper optimizations exist?

Zhao Honggang: Two practical tips:

Most JSBridge implementations use JSON. Design protocols with flat structures to avoid deep nesting, which slows serialization and deserialization.

Consider lighter custom protocols instead of JSON. For example, Weex uses WSON and Hippy uses Hippy Buffer, enabling smaller and faster encoding/decoding.

Future‑oriented approaches involve offloading more work to the JS engine itself—such as VDOM diffing, layout, and rendering calculations—so that the native bridge handles less, a direction currently being researched by the Hippy team.

Question 4: Many large companies have their own solutions (Weex, Taro, Hippy, Plato, custom RN). How should developers overcome choice paralysis, and what if a framework is no longer actively maintained?

Zhang Han: Choice paralysis stems from unclear technical requirements and misunderstanding of a framework’s capabilities. Clarify both to make an informed decision. Regarding maintenance, open‑source projects thrive on community and enterprise collaboration; labeling a project as “unmaintained” is often a misconception. Developers should contribute to the ecosystem or, if contribution isn’t feasible, consider commercial services from the originating company.

Question 5: In the era of “big front‑end,” native and front‑end are converging. Beyond build tools, DOM‑diff, and VDOM, where else can front‑end value be extracted?

Zhang Han: Pursuing native‑level performance is key: using binding instead of bridge, leveraging TypeScript for strong typing, moving VDOM, DOM‑diff, and layout to native layers, and employing direct drawing techniques to replace system UI components for specific scenarios.

Conclusion

The session provided deep technical insights into cross‑platform native integration, practical optimization strategies, and guidance for selecting sustainable mobile frameworks.