From Frameworks to Smart Resource Management: Evolving Frontend Engineering

Preface

Many teams still treat frontend as a product or design role rather than a software engineering discipline. The author, a former R&D leader at Alibaba and Baidu, writes a series to systematically present his engineering view of web frontend.

Hey, the designer, just hand over the page to the engineer and let them wrap it in a template.

Hello, slicer.

1. Frontend Is a GUI Software

Modern frontend powers a wide variety of web applications—news aggregators, e‑commerce platforms, social networks, fintech, music communities, video sharing, etc. All these are essentially software running in a browser, with the graphical user interface (GUI) being the frontend.

From a fundamental perspective, every web application is software that runs in a browser, and its GUI is the frontend.

Complex web apps involve dozens or hundreds of developers, and their frontend codebases are as large as traditional GUI applications.

Despite growing complexity, few frontend engineers consider software‑engineering principles when building these interfaces.

2. Three Stages of Frontend Engineering

Stage 1 – Library/Framework Selection

Choosing the right framework (React, Angular, etc.) based on project characteristics saves considerable engineering effort.

Stage 2 – Simple Build Optimization

After selection, developers focus on build tools for compression, linting, and basic resource merging to improve both development speed and runtime performance.

Stage 3 – JS/CSS Modular Development

Modularization (AMD, CommonJS, UMD, ES6 modules) and CSS preprocessors (Less, Sass, Stylus) enable better code reuse and, more importantly, a divide‑and‑conquer strategy for maintenance.

Modular development’s greatest value is not reuse but division—divide, conquer, repeat!

3. Fourth Stage – Componentization & Resource Management

Component‑based development treats each independent visual/interactive area as a component with its own directory, keeping all related assets nearby. Components can be freely combined, replaced, or removed.

Resource management follows the “incremental download” principle: only load assets required for the current page, cache previously visited resources, and avoid forcing users to download the entire site upfront.

Techniques such as on‑demand loading, preloading, request merging, CDN deployment, file fingerprinting, HTTP/2 server push, and advanced systems like BigPipe or Quickling all stem from this principle.

The most urgent task in the fourth stage is to embed the incremental principle into the core architecture.

4. No Silver Bullet

Like the classic “no silver bullet” insight from software engineering, frontend lacks a single magical solution. Instead, small, well‑defined rules—component boundaries, near‑by asset maintenance, and a generic resource table plus loading framework—provide a practical path forward.

5. Summary

Recap of the four stages:

Stage 1 – Library/Framework selection

Stage 2 – Simple build optimization

Stage 3 – JS/CSS modular development

Stage 4 – Componentization and intelligent resource management

The fourth stage solves the inherent engineering gaps of frontend by adopting a universal resource‑table generator and a table‑driven loading framework, enabling scalable, high‑performance web applications.

Hello, engineer!

{
  "a.js": {
    "url": "/static/js/a.5f100fa.js",
    "dep": [ "b.js", "a.css" ]
  },
  "a.css": {
    "url": "/static/css/a.63cf374.css",
    "dep": [ "button.css" ]
  },
  "b.js": {
    "url": "/static/js/b.97193bf.js"
  },
  "button.css": {
    "url": "/static/css/button.de33108.css"
  }
}