How Bundleless Development with ESModules Supercharges Frontend Speed

Introduction

Webpack bundles all resources into a single bundle, but as the number of assets grows, the bundling process becomes increasingly slow. By letting the browser load resources directly, we can achieve a qualitative performance boost. This article shares the idea of using native browser ESModule capabilities for Bundleless local development, core technical points, Vite implementation, and a practical case in Alibaba's supply‑chain POS scenario.

Why Bundleless?

Webpack was created to solve front‑end modularization and integrate with the Node.js ecosystem. Over eight years it has become powerful, yet the extra bundling layer slows down builds, especially for large projects where each start can take dozens of seconds. When a project reaches a certain scale, the benefits of bundle‑based optimization diminish.

Bundleless removes the bundling step entirely. The browser loads the required files directly, allowing instant local updates and keeping the development time complexity at O(1).

Extremely fast local startup – only a dev server is needed.

Very fast compilation – only the changed file is processed.

Consistent O(1) build time regardless of project size.

Simpler debugging without heavy reliance on source maps.

By combining Bundleless with Hot Module Replacement (HMR), developers can achieve a “save‑and‑see‑immediately” experience.

Core Capability: Dynamic Module Loading

Two main approaches enable dynamic loading:

Using an ES module loader such as System.js for high compatibility.

Directly leveraging native browser ESModule support for a simpler, future‑proof architecture.

Since ESModule is supported by over 90% of browsers, we can let the browser load modules on its own, reducing build cost.

Related Tools

Tools like Vite, Snowpack, and es‑dev‑server already exploit ESModule for Bundleless development. The article focuses on Vite’s implementation.

From Resource Loading Perspective

Using a create‑react‑app project as an example, the traditional bundle workflow creates a compiled bundle and chunks, requiring a full rebuild on each change. In contrast, the Bundleless workflow loads individual source files directly, resulting in near‑instant startup and updates.

Implementing Bundleless

Using ESModule Loading

<div id="root"></div></code><code><script type="module"></code><code>// Directly use ESModule in script tag</code><code>import React from 'https://cdn.pika.dev/react'</code><code>import ReactDOM from 'https://cdn.pika.dev/react-dom'</code><code>ReactDOM.render('Hello World', document.getElementById('root'))</code><code></script>

Supporting Bare Imports with import‑maps

<!-- Enable experimental features in Chrome --></code><code><script type="importmap"></code><code>{</code><code>  "imports": {</code><code>    "react": "https://cdn.pika.dev/react",</code><code>    "react-dom": "https://cdn.pika.dev/react-dom"</code><code>  }</code><code>}</code><code></script></code><code><script type="module"></code><code>// Bare import support</code><code>import React from 'react'</code><code>import ReactDOM from 'react-dom'</code><code>ReactDOM.render('Hello World!', document.getElementById('root'))</code><code></script>

For non‑JS assets (CSS, images, etc.), the dev server must serve them with a Content‑Type: application/javascript header and transform them into ESModules so the browser can import them.

Hot Module Replacement (HMR)

HMR allows code changes to take effect without a full page reload. In a Bundleless setup, each component is loaded independently, making it easier to inject react‑refresh scripts at the top and bottom of the returned module. A full HMR implementation also requires dependency analysis to determine which modules need replacement.

Optimizing Large Numbers of Requests

Bundleless can cause many network requests when many external dependencies are imported (e.g., lodash‑es). To mitigate this, Vite’s optimizeDeps step pre‑bundles dependencies into a single ESModule using Rollup, reducing request count.

POS Scenario Practice

The supply‑chain POS system consists of multiple domain bundles combined into a large SPA. Pain points included long startup time, slow incremental builds, unstable HMR, and unreliable source‑map debugging.

By adopting Bundleless with Vite, the team achieved:

Startup time reduced from ~10 seconds (Webpack) to ~1 second (Vite Bundleless).

HMR response in milliseconds, providing near‑zero‑perceived latency.

Overall page load time around 4 seconds, still faster than the previous build time.

Challenges and Solutions

Modules lacking ESModule output : Upgrade internal packages or submit PRs to external libraries; use @rollup/plugin-commonjs to convert CommonJS to ESModule.

Less imports using ~ syntax : Replace @import '~@ali/pos-style-mixin/style/lst.less' with standard import paths and configure lessOptions for Webpack compatibility.

Incorrect file extensions for JSX : Gradually rename files to .jsx or .tsx so Vite’s esbuild can process them.

Babel runtime helpers in CommonJS format : Use useModules flag for ES6 builds or alias @babel/runtime/helpers to the ESModule equivalents.

Feasibility of Direct Deployment

For large applications, bundles still provide loading benefits, but as browsers and networks improve, deploying native ESModules (possibly with Service Workers for caching) becomes viable for scenarios without strict compatibility requirements.

Conclusion

Bundleless shifts module resolution from the bundler to the browser, dramatically speeding up local development and improving HMR latency. With mature JavaScript/CSS/HTML standards and tools like Vite, the front‑end engineering focus is moving toward development efficiency, and Bundleless is a promising direction for the future.