Understanding the Big Front‑End: Definition, Benefits, and Implementation Strategies

Author: Wang Xin‑Jia, Ctrip IBU hotel technology leader with ten years of front‑end experience.

In the era of rapid Internet+ growth, the term “big front‑end” has become a hot topic, yet achieving it is challenging.

1. What is the big front‑end? Academically it can be split into two dimensions: horizontal (cross‑platform UI such as PC, H5, React Native, Weex, hybrid apps, mini‑programs, and even iOS/Android) and vertical (browser side versus Node.js server side). The rise of Node.js expands front‑end work beyond the browser, enabling a “full‑stack” approach.

2. Why pursue a big front‑end? The primary goal is cost reduction: lowering communication overhead (one requirement no longer needs to be explained for each platform) and decreasing development effort by adopting a “write once, run anywhere” strategy. This improves efficiency, resolves product and testing pain points, and ultimately enhances user experience.

3. How to implement a big front‑end

3.1 Technology selection – Numerous front‑end frameworks exist; the mainstream MVVM options are Vue, React, and Angular, with jQuery still in use. Rather than following popularity alone, the choice should be driven by current production pain points and requirements. The author’s team settled on React (React IE for PC, Preact for H5, React Native for iOS/Android) combined with Node + Koa2 for server‑side rendering (SSR).

3.2 Architecture design – Front‑end responsibilities include user interaction, browser compatibility, and code extensibility, while heavy data processing stays on the back‑end. The architecture separates business logic from framework code, introduces monitoring (e.g., window.onerror ), and records user traces for analysis. Node services handle crawler requests and SSR, but avoid business computation.

Key architectural diagrams (code repository split, Node architecture, front‑end component layout) illustrate the separation of Online, H5‑specific code, shared Ares DB components, and the Node + Koa shared framework, all distributed via npm packages.

3.3 Benefits and effects – Sharing components between Online and H5 reduces development cost; a single logic change propagates to both platforms. Real‑world data shows a ~50% reduction in bundle size and request count for an order‑completion page, with domready speed more than doubled and white‑screen time cut by SSR.

4. Summary – While the big front‑end concept is gaining traction, many challenges remain. Teams should start from concrete pain points, choose appropriate technologies, and design clear architectures rather than following trends blindly.

Recommended Reading:

How Ctrip Hotel’s intelligent monitoring platform handles ten‑million‑level data within 20 seconds

How Ctrip Flight predicts future call‑volume accurately

Step‑by‑step guide to custom video compression on iOS

A brief discussion on testing under Ctrip’s micro‑service architecture

Evolution of Ctrip’s holiday pricing engine architecture