Can Browsers Power Real‑Time Frontend Builds? A Deep Dive into Bundless Architecture

Self‑Introduction

I am a member of the Ant Financial front‑end team, known as "玄寂" at work and "pigcan" or "猪罐头" elsewhere, also sharing my life on a WeChat public account.

Demo

A GIF demonstrates a real‑time preview built with CodeMirror, Ant Design tabs, and Gravity, where changes to JavaScript or CSS files instantly update the preview without any server.

Outline

The discussion is divided into five parts:

Background: how historical shifts in build tools relate to front‑end trends, especially the 2019 changes that motivated this exploration.

Opportunities and challenges introduced by these shifts.

Technical choices and overall architecture.

Key technical difficulties and proposed solutions.

Future expectations for the approach.

Background

From 2011’s “particle‑based” file fragmentation (handled by Grunt/Gulp) to the module‑loader era (Webpack, NPM), the front‑end build landscape has repeatedly adapted to new standards and steep learning curves.

In 2019, voices such as Luke Jackson’s “Don’t Build That App!” and Fred K. Schott’s “A Future Without Webpack” questioned the bundler paradigm.

Key questions arise: how to load and distribute front‑end resources more efficiently?

Opportunities and Challenges

Three platform attitudes are identified: editor‑only, editor + restricted environment, and editor + fully open environment, which map to two technical solutions—container technology and browser‑based loading strategies.

Two fundamental approaches emerge:

Export server capabilities (high cost, low immediacy).

Release client capabilities (no server dependency, high immediacy, offline support).

The cloud era pushes us to reconsider heavy bundlers in favor of lighter, browser‑centric solutions.

Bundless Concept

Bundless relies on runtime module analysis (e.g., SystemJS, JSPM, StackBlitz, CodeSandbox) and native ES‑Module loading in the browser.

The proposed stack is: cloud + browser‑based bundless + web NPM, which forms the basis of the Gravity solution.

Gravity Architecture Overview

Gravity consists of a Core layer handling event registration, dispatch, and execution, while Presets encapsulate vertical business logic (React, Vue, mini‑programs, etc.). Plugins declare events; custom plugins subscribe to them.

The event flow mirrors Webpack’s plugin system, built on the Tapable library, which provides ordered, asynchronous hooks such as AsyncSeriesWaterfallHook.

Plugin Mechanism

Plugins define events (e.g., Code for fetching source), the Core binds and dispatches these events, and users implement custom plugins to respond.

Compilation Chain

Rulesets describe how a file should be transformed by specific transpilers. For example, an index.axml file is first processed by an app‑specific compiler, then by Babel, and finally passed down the consumption chain.

File System and Package Management

BrowserFS provides a Node‑like file system in the browser, enabling resolve algorithms without a native server.

Two package‑management strategies are discussed:

Full NPM implementation in the browser (slow, large storage, limited script support).

Service‑oriented NPM using CDN backends (e.g., unpkg, jsDelivr) to fetch metadata and files on demand, with custom caching and dependency resolution.

Future Directions

Gravity aims for pipelined workflows, visual configuration of Presets, and cloud‑native service deployment.

All of the above constitutes the speaker’s presentation on “Exploring Real‑Time, Browser‑Based Build Systems”.