Hot Reload: Hot Module Replacement and How It Accelerates Development

What Is Hot Reload?

Hot Reload is a development mechanism where changes to source files are immediately reflected in a running application without restarting it. The developer edits code in the editor, saves the file, and the result is instantly visible in the browser or emulator.

The key feature of this technology is preserving application state. Variables in memory, form data, current navigation — everything stays in place. The developer does not need to repeat a sequence of actions to return to the required screen.

In web development, Hot Reload is implemented through the Hot Module Replacement (HMR) mechanism. The bundler monitors file changes, determines which modules are affected, and sends the updated code to the browser via WebSocket. The browser replaces only those modules without reloading the page.

The popularity of Hot Reload skyrocketed with the rise of single-page applications (SPAs), where a full page reload destroys all client application state. React, Vue, Angular, and other frameworks recommend HMR as the primary development mode.

How HMR Works Inside the Bundler

The HMR mechanism consists of four stages. The bundler on the server side compiles the changed module, generates a JSON patch with the new code version, and sends it to the browser over a WebSocket connection. The browser-side HMR runtime receives the patch, replaces the old module with the new one, and notifies the module's subscribers.

Compilation and Sending Stage

Webpack Dev Server uses WebSocket to communicate with the client. When a file changes, the bundler generates hot-update.js and hot-update.json with a manifest of changes. The client automatically loads these files via JSONP.

// webpack.config.js - HMR setup
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'development',
  devServer: {
    hot: true,
    liveReload: false
  },
  plugins: [new HtmlWebpackPlugin()]
};

Module Application on the Client

The HMR runtime in the browser checks whether the module being replaced supports accept. If the module has declared module.hot.accept(), the runtime replaces it in-place and triggers the update callback. If accept is not declared, HMR falls back to the parent module level.

In React Fast Refresh, this logic is built into the framework level — there is no need to manually write module.hot.accept in every file. The Babel plugin react-refresh/babel adds code that safely replaces components without losing state.

Difference Between Hot Reload, Live Reload, and Full Reload

These three terms are often confused, but they differ radically in behavior. Live Reload reloads the entire page on any change — all state is lost. Full Reload happens when the development server is fully restarted, losing not only client but also server state.

The choice between Hot and Live directly affects development speed. With HMR, the “edit code → see result” cycle takes 50-200 ms. With Live Reload — 1-3 seconds plus context restoration time. Over a workday, the difference amounts to tens of minutes of saved time.

React Fast Refresh: Features for React

React Fast Refresh is the official Hot Reload implementation optimized for React components. It replaced the old React Hot Loader mechanism, which was unstable and required manual configuration. Fast Refresh is built into Create React App, Next.js, Vite, and Webpack via react-refresh/babel.

Functional Component Support

Fast Refresh correctly preserves the state of functional components when their code changes. If you only change JSX markup, useState and other hooks retain their values. If the hook logic changes, the component is remounted.

// Example - state preserved when JSX changes
import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </div>
  );
}

Safe Replacement Rules

Fast Refresh does not preserve state if the new code contains a compilation error. If the component is not exported by default (named export), state may also not be preserved. It is recommended to use default export for components and wrap exports in memo if state preservation needs to be guaranteed.

Build Tools with HMR Support

Modern bundlers provide HMR. Webpack is the HMR pioneer with flexible configuration via devServer.hot. Vite uses native ESM and esbuild for instant HMR without bundling. Parcel offers zero-config HMR. Turbopack is a new bundler from Vercel with Rust-based HMR.

Vite stands out in speed — HMR in Vite works through native ES modules in the browser. When a file changes, Vite sends only that module via import(), without recompiling the entire project. Webpack compiles each module entirely, which slows down HMR in large projects.

HMR Configuration Examples in Projects

Let's look at HMR setup for different bundlers. In Webpack, you need to set hot: true in devServer and add react-refresh/babel. In Vite, HMR works out of the box with any preset. In Next.js, Fast Refresh is enabled by default through the turbocompiler.

Vite with React

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  server: {
    hmr: {
      port: 3001
    }
  }
});

Webpack 5 with Fast Refresh

// webpack.config.js
const ReactRefreshWebpackPlugin =
  require('@pmmmwh/react-refresh-webpack-plugin');

module.exports = {
  mode: 'development',
  devServer: { hot: true },
  plugins: [new ReactRefreshWebpackPlugin()],
  module: {
    rules: [
      {
        test: /\.jsx?$/u,
        use: 'babel-loader'
      }
    ]
  }
};

Limitations and Issues of Hot Reload

HMR does not work correctly in all scenarios. CSS modules with dynamic classes may not apply. Global variables and singletons (Redux store, router) may reset on reload. Heavy libraries under HMR can sometimes generate memory leaks due to module replacement without GC.

The solution to HMR problems is to isolate hot code into pure components without side effects. Side effects (WebSocket subscriptions, timers) should be cleaned up in useEffect. For Redux, a persister that saves state in sessionStorage is recommended. CSS solutions like CSS Modules or styled-components work correctly with HMR without additional configuration.

Another limitation is debugging in production: HMR is intentionally disabled in production builds. The source code is minified, and hot replacement in production is impossible. To debug errors in production, use source maps and logging, but not HMR.