Understanding Web Componentization: History, Principles, and Design Practices
This article explores the evolution of web componentization from the early template era to modern SPA frameworks, explains why component-based development is essential, and presents practical design ideas such as treating components as finite state machines with atomicization and event‑driven interactions.
Componentization is a long‑standing concept in front‑end development, originally emerging when developers stitched together PHP, JSP, and other template fragments. The author, a front‑end engineer at Qunar, explains that componentization is not about magical performance gains but about encapsulating reusable parts, facilitating collaborative development, and enabling localized bug fixes.
Historically, web componentization evolved through several stages:
Web 1.0: Pages were assembled from server‑side HTML fragments; every page refresh recomputed all components, leading to performance overhead.
Web 2.0: AJAX allowed partial updates, CSS preprocessors (LESS, SASS) introduced component‑like styles, and JavaScript began handling DOM composition.
SPA era: Frameworks such as Angular and React shifted component responsibilities to the client, using data models to render views, but introduced complexity in controller logic.
Web Components: Modern browsers provide native encapsulation (shadow DOM), yet the approach is still experimental and many frameworks emulate it.
Designing components requires a mindset: each component can be viewed as a finite state machine where state transitions are triggered by events. For example, an input box has states for cursor visibility and value content. The state can be expressed in code:
M.state = {
curser: false,
value: ""
}When the input gains focus, the state updates:
M.state = M.on('focus', () => ({
curser: true,
value: M.state.value
}));Each character input fires an input event, further updating the state:
M.state = M.on('input', (c) => ({
curser: true,
value: c
}));Thus, new component states derive from previous states and events, then render the view.
To manage complex UI, components should be atomic. Instead of a page with dozens of combined states, break it into small, reusable pieces that communicate via events. Interaction between components mirrors user‑event monitoring (e.g., click) and backend‑event monitoring (e.g., XMLHttpRequest), enabling clear, decoupled communication.
The article concludes that front‑end componentization is still evolving; the ideas presented aim to inspire developers, especially for mobile‑first pages, acknowledging that today’s best practices may change tomorrow.
Qunar Tech Salon
Qunar Tech Salon is a learning and exchange platform for Qunar engineers and industry peers. We share cutting-edge technology trends and topics, providing a free platform for mid-to-senior technical professionals to exchange and learn.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
