If you are a web developer and haven't used the Live Server extension in VSCode, are you even a developer? Just kidding. But have you thought about how that works under the hood? In today’s blog, let’s try to understand how that works with a hands-on implementation using Golang. Why Golang? Well, I am exploring Golang these days, and what’s better to learn than building a project? So enough context (not the one in golang ) let’s get started.
How live server works ?
So the live server automatically reloads the browser whenever it detects any modification in html,css or js files. It began by serving these static files through a HTTP server. Under the hood it employs a file watcher like fsnotify( we are going to use this for our project) , fswatch (in UNIX-based file system) or Chokidar(for Nodejs) to continuously monitor the project’s directory for file changes (basically when you save any file with extensions .html,.css,.js ) .
At the core it Uses a WebSocket connection between the your (node js) server and the browser. When the server detects a file changes it sends a reload notification through WebSocket to the browser. The browser , in turn, reloads the page to reflect the new changes being made. Additionally it uses CSS injection(updating only styles without a full reload) ,HMR(hot module replacement) for javascript module. This ensures the developer get’s a real time feedback without the need of manually reloading the browser after each change in code .
Project overview
So with this project, my idea was the same. My goal was to watch for file changes (like HTML, CSS, and JavaScript) and trigger a browser reload whenever any modifications were detected. For this, I used Go's built-in HTTP server and the fsnotify
package, which efficiently monitors file system events.
1. Serving Static Files
The first step was to set up a simple HTTP server in Go that serves static files from a directory. The static files, such as HTML, CSS, and JavaScript, would be loaded from the ./static
folder. This is handled using the http.FileServer
:
http.Handle("/", http.FileServer(http.Dir("./static")))
2. Reload Endpoint
Next, I needed an endpoint that would notify the client to reload when a file change was detected. The /reload
route acts as a trigger, sending a "reload" message to the browser when the server detects a modification:
http.HandleFunc("/reload", func(w http.ResponseWriter, r *http.Request) {
<-reloadChan
w.Write([]byte("reload"))
})
This route listens for events on a channel, which will later be populated by file change notifications.
3. Watching File Changes
I leveraged the fsnotify
package to track changes in specific file types (HTML, CSS, and JS). The watcher listens for any modifications and pushes a notification to the reload channel when it detects changes:
func scanFileChanges() {
watcher, err := fsnotify.NewWatcher()
if err != nil {
log.Fatal(err)
}
defer watcher.Close()
for {
select {
case event := <-watcher.Events:
if event.Op&fsnotify.Write == fsnotify.Write && isTrackedFile(event.Name) {
log.Println("Modified File:", event.Name)
reloadChan <- true
}
case err := <-watcher.Errors:
log.Println("Error:", err)
}
}
}
4. Filtering Tracked Files
Not every file change should trigger a reload, so I added a filter that only tracks specific file extensions: .html
, .css
, and .js
. This was done using the filepath.Ext
function to check file types:
func isTrackedFile(fileName string) bool {
ext := strings.ToLower(filepath.Ext(fileName))
return ext == ".html" || ext == ".css" || ext == ".js"
}
5. Running the Server
Finally, I launched the HTTP server to listen on port 8000 and started the file watching process concurrently:
log.Println("Starting the server at: 8000")
log.Fatal(http.ListenAndServe(":8000", nil))
Final Thoughts
While this example focuses on reloading static files, there's plenty of room for improvement—like adding WebSocket support for smoother communication, better file handling, and expanding the list of tracked files.
With just a few lines of Go code, I was able to improve the workflow for static web development, and I look forward to refining this tool even further.
Check out the code: serve-it GitHub
Top comments (0)