What Is HMR?
HMR stands for Hot Module Replacement. It is a development technique that replaces, adds, or removes modules in a running application without requiring a full page reload. Instead of losing application state each time code changes, HMR swaps individual modules while the app stays up and running.
More from this site
Keep reading the latest coverage
HMR originated in the webpack ecosystem, where it became a cornerstone of fast frontend development. The core idea is simple: when a file changes, the build server sends the updated module to the browser, and the runtime integrates it on the fly. This creates a tight feedback loop that preserves state and keeps developers in flow.
How HMR Works
Under the hood, HMR relies on a client-server architecture. The development server watches files for changes and compiles updated modules. A WebSocket connection pushes the update to the browser. The HMR runtime then determines whether the changed module can be hot-replaced or whether a full reload is necessary.
The Module Update Flow
- The file watcher detects a change and triggers a recompile.
- The server sends the updated module hash to the HMR client.
- The client requests the new module code over the WebSocket.
- The runtime attempts to apply the update to the running module.
- If the module accepts the update, state is preserved. If not, a full reload occurs.
Benefits of Using HMR
The primary benefit is speed. A full page reload can take seconds, especially in large applications with complex state. HMR reduces that to milliseconds. More importantly, it preserves component state, form inputs, and scroll position, so developers do not lose context with every edit.
HMR also improves iteration velocity. When changing styles, logic, or configuration, the update appears instantly. This encourages experimentation and reduces the cognitive cost of switching between writing code and verifying results.
Common Benefits at a Glance
| Benefit | Impact |
|---|---|
| Faster feedback loop | Changes appear in under a second |
| State preservation | No lost form data or navigation state |
| Reduced context switching | Developers stay focused on the problem |
| Better error recovery | Errors are displayed inline without killing the page |
HMR in Practice
Most modern frameworks provide built-in HMR support. React applications use react-refresh to update components without losing local state. Vue.js includes HMR out of the box through its dev server. Svelte, Angular, and webpack itself all offer first-class HMR tooling.
Setting up HMR typically involves enabling a flag in the build configuration and adding a client entry point. For webpack, this means setting the devServer.hot option to true and including the webpack-hot-middleware or webpack-dev-server client. For Vite, HMR is enabled by default and requires no extra configuration.
Limitations and Common Pitfalls
HMR is not a silver bullet. Some changes, such as modifications to entry points or configuration files, still require a full reload. CSS HMR works well in most cases, but complex global style changes can occasionally cause flicker or require a refresh.
Another common pitfall is poorly written module boundaries. If modules do not declare an HMR acceptance boundary, the runtime cannot hot-swap them and will fall back to a full reload. Structuring code with explicit accept handlers ensures that HMR works predictably across the application.
HMR Beyond the Frontend
While HMR is most commonly associated with frontend development, the concept extends to other environments. Server-side HMR can update route handlers or business logic without restarting the entire process. This is especially useful in long-running applications where cold starts are expensive.
The principles of HMR also apply to any system that benefits from live reloading of individual components. Plugin systems, dynamic feature flags, and modular backends can all adopt similar patterns to improve developer experience and reduce downtime during iteration.