What are the difference between full page reload and HMR update?
A full page reload completely resets the application state by re-requesting all resources, while an HMR update replaces only the changed modules in memory, preserving application state and runtime context
The fundamental difference between a full page reload and an HMR update lies in what gets preserved and what's re-executed. A full page reload is like restarting your entire application—the browser navigates away from the current page, clears all JavaScript state, and re-requests every resource from the server. An HMR update, by contrast, surgically replaces specific modules in the running application's memory, allowing the rest of the application to continue executing uninterrupted. This preserves application state, form inputs, scroll positions, and ongoing animations, making the development feedback loop significantly faster and more pleasant.
- 1
Destroys all JavaScript state: Every variable, component state, and module export is lost .
- 2
Resets the DOM: The browser constructs an entirely new DOM tree from scratch .
- 3
Clears runtime context: Event listeners, intervals, and WebSocket connections are terminated .
- 4
Re-requests all resources: The browser fetches HTML, JavaScript, CSS, and assets anew .
- 5
Time cost: Typically 800ms-3s depending on network and application size .
- 1
Preserves JavaScript state: Unchanged modules continue running with their existing state .
- 2
Surgically updates the DOM: Only elements affected by changed modules are updated .
- 3
Maintains runtime context: Event listeners not attached to changed modules remain active .
- 4
Fetches only changed modules: The browser requests only the files that were modified .
- 5
Time cost: Typically 50-200ms regardless of application size .
The difference becomes dramatically apparent in real-world workflows. Consider editing a component's styling while testing a multi-step form. With a full page reload, you'd lose all form inputs and have to re-navigate through the steps. With HMR, the styling updates instantly while the form data and navigation state remain intact. This preservation of context is what makes modern frontend development feel fluid and productive .
Even with HMR, full page reloads occur in specific scenarios: when you edit a file that doesn't have an HMR handler, when you change a module that no accepting parent can handle, when you modify the HTML entry point, or when the HMR boundary can't propagate the update due to circular dependencies . Vite attempts to recover but will trigger a full reload when necessary .
Some older tools use live reload, which automatically refreshes the page when files change but provides no state preservation. HMR is a significant evolution beyond live reload because it maintains the application's runtime state. The difference is analogous to hot-swapping a hard drive in a running server versus shutting down and restarting the entire machine .
Scenario Questions
- 1
You're adding a new CSS file to a Vite project. After saving, the browser updates styles instantly without a full page refresh. Explain what Vite is doing under the hood and why the page didn't reload.
- 2
If you modify a React component's render logic and see the whole app flicker and lose its state, what likely went wrong with the HMR setup, and how would you fix it?
- 3
During local development you notice that changing a .env variable requires you to manually refresh the page. Why does Vite fall back to a full reload for this change?
- 1
You introduced a new third‑party library that mutates global prototypes. After a code change, Vite's HMR seems to reload the entire page unexpectedly. Walk me through how you'd debug why HMR fell back to a full reload.
- 2
While working on a feature, updating a Vue component's template triggers a full page reload instead of hot swapping. What are the possible reasons, and what trade‑offs would you consider when deciding to keep HMR or accept the reload?
- 3
Explain how you would configure Vite so that CSS module changes use HMR while changes to the Vite config file trigger a full reload, and why this distinction matters for developer productivity.
- 1
Design a strategy for a large monorepo using Vite where some packages need HMR and others must trigger full reloads due to side‑effects. How would you orchestrate this at the build and dev server level, and what performance implications would you monitor?
- 2
Your team reports intermittent state loss after HMR updates in a complex React app. Propose a systematic approach to identify the root cause, mitigate it, and ensure reliable hot updates across the codebase.
- 3
Discuss the impact of relying heavily on HMR in production‑like preview builds and how you would safeguard against accidental full reloads affecting end users.
- 1
The company plans to migrate a legacy Webpack project to Vite across multiple teams. How would you evaluate the trade‑offs of HMR vs full reload behavior during the migration, and what guidelines would you set to maintain consistency and avoid regressions?
- 2
At scale, you need to support fast HMR for UI developers but enforce full reloads for security‑sensitive modules (e.g., auth). How would you architect the dev environment and CI pipelines to enforce these policies without hindering developer velocity?
- 3
Consider a scenario where a new browser feature disables WebSocket connections, breaking Vite's HMR. How would you design a fallback mechanism that gracefully degrades to full reloads while preserving as much state as possible?
Follow-up Questions
- ❓What are the main limitations of Vite's HMR mechanism?
- ❓How can you verify that a component's state survived an HMR update?
- ❓When might you deliberately choose a full reload during development?