Learning path · Level 6 · Tutorial 3

Run a Local Development Server with Vite

Serve a locally authored HTML, CSS, and JavaScript page with Vite and use a reliable edit-save-check workflow on your own computer.

Level: Beginner
Duration: 15 min
8 steps

Start tutorial Back to the path

What you will go through

Understand Vite's Role Identify how the Editor, Vite process, and Browser work together in a local development workflow. 1 min
Install Vite and Define the dev Script Install Vite as a local development dependency and add the npm script that will start it later. 2 min
Create the HTML, CSS, and JavaScript Entry Files Create a complete three-file page whose HTML correctly loads its stylesheet and deferred JavaScript module entry. 3 min
Start the Server and Open the Reported URL Start the Vite development server, use the Local URL it reports, and deliberately manage its running process. 2 min
Practice the Edit-Save-Check Loop Use a running local Vite development server to make, save, and verify visible CSS and JavaScript changes without unnecessary restarts. 2 min
Diagnose the Right Layer Use Terminal, Network, and Console evidence to distinguish local Vite startup, resource-path, and JavaScript execution failures. 3 min
Recognize What the Server Does Not Provide Separate Vite file serving, browser DOM updates, Editor saves, and writable application behavior. 1 min
Complete a Local Development Session Complete an independent local Vite session and consolidate the workflow, diagnostic choices, and server boundary. 2 min

What you will learn

Add Vite to a local project and define an npm script that starts its development server.
Connect an HTML entry document to CSS and a JavaScript module entry file.
Open the URL reported by Vite, observe a saved source change, and stop the server deliberately.
Use terminal output and browser diagnostics to distinguish startup, resource-path, and JavaScript execution failures.
Explain why serving local project files does not create a writable application API.

Before you start

Manage npm Dependencies and Lockfiles
Link Local Pages with Relative Paths
Apply CSS with Stylesheets and Selectors
Read and Update the DOM Safely

Step 1 of 8

Understand Vite's Role

Identify how the Editor, Vite process, and Browser work together in a local development workflow.

See the local workflow

Three jobs, one workflow

A local development workflow has three separate jobs:

Editor: where you write and save project files.
Vite process: a development tool running on your computer that serves those resources.
Browser: opens the local HTTP address, loads the page, runs its interface JavaScript, and displays DOM updates.

Vite helps the browser obtain your authored files. It does not take over the browser’s job of executing page code.

Diagram of authored files flowing from an editor through a local Vite development server process to a browser, where JavaScript updates a page element. — The Editor authors files; the Vite process serves them locally; the Browser loads and executes them.

What local hosting means

Local serving is not publishing

A development server uses a local HTTP address so the browser requests the project resources through a running process on your own computer.

This differs from opening an HTML file directly with a file:// address. A local server supports a development workflow between your saved source files and the browser.

“Localhost” means the address points back to your own computer. Serving a project this way does not publish it as a public website. Other people cannot visit it simply because it is running locally.

Tip

Follow the responsibility

Keep the roles separate when you investigate a page:

A saved source change starts in the Editor.
The running Vite process makes project resources available at a local HTTP address.
The Browser requests those resources and executes the page’s JavaScript to update the DOM.

Later, you will install and start Vite. For now, use this model to identify which part is responsible for each job.

Check your model

Match the responsibility

Match each part of the workflow to its primary responsibility.

Tap an item and then its matching pair.

Step 2 of 8

Install Vite and Define the dev Script

Install Vite as a local development dependency and add the npm script that will start it later.

Add Vite to the intended project

Install a project-local tool

Install Vite inside the intended npm project folder—shown here as vite-practice/. With an internet connection, npm adds Vite as a project-local development dependency.

Use a supported Node.js LTS release that is compatible with the Vite release npm installs. If npm reports an engine or Node.js version error, stop and address that compatibility issue rather than forcing the installation.

How the local command is connected

Diagram showing an editor project folder, npm installing Vite locally, and an npm script invoking the local Vite command. — The package installation and the `dev` script belong to the same local project.

Tip

Keep the setup local

You do not need a global Vite installation or a scaffolding command. The project’s npm script will locate its installed Vite command.

Install and configure the script

Install Vite with npm

From the project root, run this installation command. Its exact package count, timing, audit notices, and installed version can vary. What matters is that it completes without a compatibility error and records Vite in package.json as a development dependency.

Terminal command

Run this from the project root.

shell

npm install --save-dev vite

Expected output

added 11 packages, and audited 12 packages in 2s

3 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Your package count, timing, audit notices, and installed Vite version may differ. Check that the command completes without an engine error and that package.json records Vite as a development dependency.

Define the repeatable command

Next, edit the existing scripts object in package.json. Add the dev entry while preserving every unrelated script and package field already present. JSON uses double quotes and no trailing comma after the final entry.

Example

Existing scripts are preserved

For example, if the project already has a check script, keep it and add dev beside it. Your project may contain different existing fields or scripts; retain them.

Add the dev script

This is the scripts object only, not a replacement for the whole package.json file.

json

{
  "scripts": {
    "check": "node check.js",
    "dev": "vite"
  }
}

Practice the two required edits

Configure your local project

Complete the missing package name in the terminal command and the missing value in the package.json script entry. Then apply those same two changes in your local npm project.

shell

npm install --save-dev 

"dev": ""

Step 3 of 8

Create the HTML, CSS, and JavaScript Entry Files

Create a complete three-file page whose HTML correctly loads its stylesheet and deferred JavaScript module entry.

Keep the three files together

Set up the project root

Your existing npm-initialized practice folder is the project root when you later run Vite from that folder. In this example, the root is vite-practice/.

Place these three authored files directly beside package.json:

index.html — the page entry document
style.css — the stylesheet
main.js — the browser JavaScript entry file

Do not put these files inside another folder. This small page uses no external assets.

How the entry files connect

Diagram showing index.html, style.css, and main.js beside package.json in the vite-practice project root, with the HTML document linking to the stylesheet and JavaScript entry file. — `index.html` is the page entry document. It points the browser to the other two files.

Link both entry files from HTML

Create the HTML entry document

Create index.html directly in the project root. Its head links the stylesheet and loads main.js as a module entry file.

The module script is in the head, but it has no async or defer attribute. A module script without async runs after the HTML has been parsed, so the status paragraph exists when main.js selects it.

index.html

Save as index.html in the project root.

html

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Local Dev Lab</title>
  <link rel="stylesheet" href="./style.css">
  <script type="module" src="./main.js"></script>
</head>
<body>
  <main>
    <h1>Local Dev Lab</h1>
    <p id="status">Waiting for JavaScript.</p>
  </main>
</body>
</html>

Expected output

Browser page after Vite is started in the next step:
Local Dev Lab
JavaScript is running.

The HTML initially contains “Waiting for JavaScript.” The module entry file replaces it when it runs.

This is the expected Browser result after Vite is started in the next step and you open its reported Local URL.

Add the CSS and JavaScript

style.css

Save as style.css in the project root.

css

body {
  background: #eef2ff;
  color: #172033;
  font-family: system-ui, sans-serif;
}

main {
  max-width: 42rem;
  margin: 4rem auto;
  padding: 2rem;
}

Expected output

Browser result after Vite is started in the next step:
The Local Dev Lab page has a body background of #eef2ff and page text colored #172033.

This is the expected Browser styling after Vite is started in the next step and the page is opened through its reported Local URL.

main.js

Save as main.js in the project root. This browser entry file has no imports or exports. The null guard means the assignment happens only when the selected paragraph exists.

javascript

const statusMessage = document.querySelector('#status');

if (statusMessage) {
  statusMessage.textContent = 'JavaScript is running.';
}

Expected output

Browser result after Vite is started in the next step:
The Local Dev Lab page displays the status text:
JavaScript is running.

This is the expected Browser result after Vite is started in the next step and the page is opened through its reported Local URL.

Tip

Expected baseline

After the server is started in the next step, the page will show the heading on a light background. The initial HTML status is replaced by the JavaScript result when the module entry file runs.

Build the three-file page

Connect the local files

In your own project root, create index.html, style.css, and main.js using the supplied source from the previous screens. Then complete this HTML head so it loads the stylesheet and the JavaScript module entry file.

html

<head>
  <title>Local Dev Lab</title>
  <link rel="stylesheet" href="">
  <script  src=""></script>
</head>

Step 4 of 8

Start the Server and Open the Reported URL

Start the Vite development server, use the Local URL it reports, and deliberately manage its running process.

Start and read the server output

Launch from the project root

Open a Terminal in your project root: the folder that contains package.json, index.html, style.css, and main.js. Start the development server with npm run dev.

Read the startup output before opening a browser. When Vite is ready, it prints a line beginning with Local:. That line supplies the address for this running server.

Leave this Terminal process running while you work. It is waiting for requests from the browser; it has not become stuck.

Start Vite

Run this command in the project root.

bash

npm run dev

Expected output

> vite-practice@1.0.0 dev
> vite

  VITE v6.0.0  ready in 142 ms

  ➜  Local:   http://localhost:5173/
  ➜  press h + enter to show help

This output is illustrative. Your project name, Vite version, startup time, and Local URL can differ. Use the Local URL printed by your own running process.

The local workflow

Diagram showing authored files in an Editor, a running Vite process in Terminal, and the served page in Browser. — Start the development server in Terminal, then use its printed Local address in Browser.

Open the Local URL; stop deliberately

Use the reported address and control the process

Open the exact address on your process's Local: line. It uses http://localhost, not a file:// address. The commonly used port is 5173, so http://localhost:5173/ is an illustrative address—not an address to assume.

If that port is already occupied, Vite can use another available port, such as the illustrative http://localhost:5174/. Keep the port that Vite actually reports.

To stop the server, focus its Terminal and press Ctrl+C. You can start it again later with npm run dev. A Browser tab may still display the last page after the server stops, so a visible page alone does not prove the process is still running.

Tip

Port rule

Treat the Terminal's Local: line as the source of truth every time you start the server. Do not replace a reported port with 5173 just because it is common.

Handle an alternate port

Choose the reported address

A running Vite process prints a Local address whose port is 5174. Which address should you open in Browser?

http://localhost:5173/http://localhost:5174/file:///vite-practice/index.html

Practice on your computer

Run, open, and verify

In your own project root, start the server. Open the exact Local URL that your running Vite process prints, then inspect the page.

Write both: (1) the full Local address you opened and (2) the status text currently rendered on the page. If your process reports a port other than 5173, keep that reported port in your answer.

Write at least 25 characters (0/25).

Step 5 of 8

Practice the Edit-Save-Check Loop

Use a running local Vite development server to make, save, and verify visible CSS and JavaScript changes without unnecessary restarts.

Use the running workflow

One loop for every change

With Vite still running, use one repeatable loop: edit a source file, save it, then check the Browser at the active Local URL. Keep the Terminal process running; a normal saved source edit does not require restarting Vite.

Vite may update the affected resource or reload the page after a save. Treat temporary page state as disposable, because an automatic update does not guarantee that temporary state remains.

From saved source to visible page

A diagram showing an Editor connected through a running Terminal process to a Browser, with a saved CSS and JavaScript change producing an updated page. — Edit and save in the Editor, leave the development server running in the Terminal, and verify the visible result in the Browser.

Check the sequence

Sequence the workflow

Put the edit-save-check workflow in its reliable order.

Edit the source file.
Save the file.
Check the Browser at Vite's running Local URL.

Make the two planned edits

1. Make a visible CSS edit

First, edit style.css. Preserve the existing text color and font family, and change only the body background declaration. Save the file, then look at the page in the Browser.

Updated stylesheet rule

In style.css, use this complete body rule after the edit.

css

body {
  background: #ecfdf5;
  color: #172033;
  font-family: system-ui, sans-serif;
}

Expected output

The saved page background becomes #ecfdf5.

After you save, leave Vite running and check the Browser at its active Local URL. Vite may update the stylesheet or reload the page.

Updated JavaScript entry file

Next, in main.js, change the assigned status text and save. Keep the existing selector and null guard; browser code stays in this entry file.

javascript

const statusMessage = document.querySelector('#status');

if (statusMessage) {
  statusMessage.textContent = 'Saved changes are live.';
}

Expected output

Saved changes are live.

After you save, leave Vite running and check the Browser at its active Local URL. Vite may update the affected resource or reload the page.

Tip

Check the simple connection first

If a change seems absent, check these basics before restarting anything: confirm the file was saved, confirm you edited the file in the intended project root, and confirm the Browser is open at the active Local URL reported by Vite.

Apply the edit-save-check loop

Run and report the loop

On your own computer, keep Vite running and complete both planned edits. Then write a short report that:

gives the three workflow actions in order;
names the background color you observe after saving the CSS edit;
quotes the status text you observe after saving the JavaScript edit; and
states whether you restarted Vite.

Check the Browser at your running server's current Local URL before answering.

Write at least 100 characters (0/100).

Step 6 of 8

Diagnose the Right Layer

Use Terminal, Network, and Console evidence to distinguish local Vite startup, resource-path, and JavaScript execution failures.

Locate the failure layer

Start with the evidence

When something fails, start with the evidence closest to the failure—not with a package reinstall.

No usable Local URL in the Terminal means a startup problem.
A page that loads but has a missing stylesheet or script calls for the browser Network panel.
A running page whose JavaScript reports an error calls for the Console, especially its source location.

Make one correction at the indicated layer, save, then check the browser at the current Local URL reported by Vite.

Three diagnostic sources

Diagram connecting the Editor, Terminal, and Browser, with Network and Console shown as separate browser diagnostic panels. — Match the evidence to its source before choosing a fix.

Use the matching panel

Choose a targeted next action

A development server can be running while a resource path or browser script still fails. Use the panel that contains direct evidence, then make the smallest relevant correction.

Evidence-to-action guide

Use these signals to avoid treating unrelated problems as installation problems.

A reported Local URL is evidence that startup succeeded; it is not proof that every page resource or script works.
Evidence location	What it indicates	Targeted next action
Terminal, before a Local URL	Startup did not complete	Confirm the project root, the "dev": "vite" script, local Vite availability, and a Node.js version compatible with Vite.
Network, after loading the page	A requested resource may not match the authored file	Compare the request path with the filename in index.html; inspect whether the expected resource was delivered.
Console, with resources available	Browser JavaScript stopped or failed	Read the error and source location; correct the named identifier or line in main.js.
Any layer after a correction	The evidence may have changed	Save the file and recheck the running server URL before making another change.

Practice: classify first

Classify the evidence

Match each evidence sample to its failure category.

Tap an item and then its matching pair.

Practice: correct the resource path

Make one targeted correction

The Network evidence points to a stylesheet path mismatch. Complete the targeted correction in the index.html head.

HTML

<head>
  <link rel="stylesheet" href="">
  <script type="module" src="./main.js"></script>
</head>

Step 7 of 8

Recognize What the Server Does Not Provide

Separate Vite file serving, browser DOM updates, Editor saves, and writable application behavior.

What Vite serves

Serving files is not storing data

Vite serves the files in your project root to a browser at a local HTTP address. It can notice saved source changes and help the browser refresh or update affected resources.

That does not add application endpoints or data storage. Vite is a development tool; the browser runs the page’s JavaScript and holds the current DOM for the displayed page.

Project files and the current page are separate

A diagram shows files saved in an Editor being served through a Terminal to a Browser, while the Browser's current DOM remains separate from the files on disk. — The browser can change its current DOM without writing those changes back into the project files.

Compare the locations

Four different actions

These actions may look similar because each can change what you see, but they happen in different places.

A visible browser change is not automatically a saved project change.
Action	Where it happens	Effect on project files
Vite delivers index.html	Development server to Browser	No source file is rewritten
JavaScript changes #status	Browser DOM	No source file is rewritten
You edit and save main.js	Editor and disk	The authored file changes
An app saves submitted data	Separate implemented behavior	Not supplied automatically by Vite

Tip

Keep the boundaries clear

A page can display new text because JavaScript updated the current DOM. That visual result is separate from saving source in the Editor or persisting application data.

Test a common assumption

Check the boundary

True or false: When JavaScript changes the text of the status paragraph in the Browser, it also rewrites main.js on disk.

TrueFalse

Apply the distinction

Classify the workflow

Match each situation to what it actually represents.

Tap an item and then its matching pair.

Step 8 of 8

Complete a Local Development Session

Complete an independent local Vite session and consolidate the workflow, diagnostic choices, and server boundary.

Recall the complete local workflow

Summary

Review the workflow boundary

Use this final model to guide your session.

The Editor holds the authored files in the project root.
The Terminal keeps Vite’s development server running and reports its Local URL.
The Browser requests the page and executes its JavaScript; a DOM update does not rewrite files on disk.
Stopping Vite ends the running server process, not your source files or package configuration.

One local workflow, three roles

A diagram showing authored files in the Editor, Vite running in the Terminal, and the served page in the Browser. Browser changes do not flow back into source files. — The development server connects saved project resources to the browser, but it does not turn browser changes into saved source files.

Check the command and entry files

Check 1: Start command

Complete the command that starts the configured development server.

bash

npm run

Check 2: Entry-file connections

Complete the two local resource paths in this document head.

html

<head>
  <link rel="stylesheet" href="">
  <script type="module" src=""></script>
</head>

Apply the workflow and diagnostic choice

Run, verify, and stop

Now complete a short session on your own computer.

Work in your project root—the example root is vite-practice/.
Start Vite if it is not already running, or confirm that its terminal process is still running.
Open the exact Local URL currently printed by that process.
In style.css, set the body background declaration to #eef2ff, reversing the earlier green background edit. Save the file and verify the visible background change in the browser. If it was already that color, briefly save #ecfdf5 first, then save #eef2ff.
When verification is complete, stop the running server from its terminal with Ctrl+C.

Stopping the process leaves index.html, style.css, main.js, and the package configuration available for a later restart.

Choose the diagnostic source

Use evidence from the layer where the problem appears. Make one focused correction rather than reinstalling packages for every failure.

A quick diagnostic decision guide
Observed signal	First diagnostic source	Targeted next action
The start command reports a missing script	Terminal	Inspect the scripts object in package.json
A stylesheet or entry file is not delivered as expected	Network	Compare the requested path with the authored filename
A served page has a JavaScript error	Console	Read the error and its source location

Report and finish

Final session report

After you complete the local session, write a five-line report. Include: your actual Local URL; the background change you observed after saving; the action you used to stop Vite; the first diagnostic source you would use if npm run dev reported Missing script: dev; and why this setup does not provide a writable application API.

Write at least 120 characters (0/120).

Session complete

Congratulations! You completed: Run a Local Development Server with Vite

You completed a local Vite development session: start from the project root, verify a saved change at the current Local URL, use evidence to diagnose failures, and stop the server intentionally.

Next tutorial

Split Browser Code into JavaScript ModulesRefactor a small browser interface into connected JavaScript modules and explain how Vite makes local modules and installed packages usable by the browser.22 min

Continue Previous tutorial: Manage npm Dependencies and Lockfiles

Download the App now to have access to + 5000 free courses, exercises, certificates and lots of content without paying anything!

100% free online courses from start to finish

Thousands of online courses in video, ebooks and audiobooks.
More than 60 thousand free exercises

To test your knowledge during online courses
Valid free Digital Certificate with QR Code

Generated directly from your cell phone's photo gallery and sent to your email

Download our app via QR Code or the links below:.