Frontend Engineering Practices: Componentization, Modularization, and Build Optimization

The Douyin front‑end team shares years of practical experience and concepts in front‑end development, hoping the concise notes will help others and inviting feedback on any misunderstandings.

As a core part of front‑end architecture, engineering remains an evergreen topic because browsers originally lack native module support for HTML, CSS, and JavaScript, prompting the need for modular features to improve development.

Historically, HTML, CSS, and JS did not support module imports; developers had to stitch scripts together via HTML, while CSS already had some capability. The emergence of UI components—composed of HTML, CSS, and JS—led to engineering approaches that now benefit from Web Components supported by modern browsers.

To achieve divide‑and‑conquer, a component system is required that both constrains development and embodies the principle of modularity. This system solves reuse issues but also introduces runtime challenges, making packaging (the "package" concept) an indispensable topic for performance optimization.

In a componentized ecosystem, we encounter module characteristics similar to static languages—inheritance, extension, and dependencies. While static languages catch dependency errors at compile time, runtime dependency failures are harder to resolve, a problem that also appears in front‑end component systems.

Resolving dependencies is typically handled during the build phase by recognizing syntax such as require, define, or import. These belong to module specifications like CommonJS, AMD, CMD, UMD, and now native ES6 modules. Build tools analyze these statements to construct a dependency graph, which guides both bundling and pre‑loading in the browser.

Different build tools adopt various strategies for dependency resolution—some traverse a tree from the root, others first generate a dependency tree and then decide how to bundle, using techniques ranging from regular‑expression parsing to AST analysis; you can even devise a new method.

Loading components and their dependencies in the browser can be synchronous (using <script> tags) or asynchronous (dynamically creating script nodes, Ajax, or Fetch). A JavaScript loader—such as RequireJS or SeaJS—manages this process, handling loading, dependency processing, execution order, scope, and various loading modes.

The divide‑and‑conquer approach improves development, maintenance, and debugging, while packaging optimizes runtime performance; thus, the primary engineering goal is to optimize efficiency .

During development, the focus is on enhancing developer experience, which has spurred tools like scaffolding, mock services, LiveReload, and HMR.

Our aim is to cover the entire development workflow, which defines the mission of the tool direction.

From the browser’s perspective, fast and accurate execution is the ultimate goal. To achieve this, we must optimize the whole pipeline—resource loading, code execution, rendering, and data fetching—embedding accumulated experience into the engineering system so that optimizations become invisible to developers.

From a development standpoint, rapid coding, easy debugging, and quick releases are essential; coding standards help maintainability and enable faster syntax usage.

Both componentization, runtime efficiency, and development efficiency require a unified specification system, complemented by infrastructure such as better languages, higher‑level abstractions, and more efficient frameworks.

When CSS is hard to write, we use Sass; when JavaScript’s weak typing is a pain, we adopt TypeScript; and for higher productivity we rely on frameworks like React, Vue, and Angular.

We continuously build our engineering system from both development and browser viewpoints, aiming to simplify complexity and make performance optimizations transparent.

Overly rigid systems can stifle creativity, so a loosely coupled architecture—while allowing personalization—may reduce efficiency. Engineering is therefore an iterative trade‑off process, never a one‑time perfect solution.