In my yearn for simplicity as a developer, I’m always looking for ways to reduce code. I found a personally fascinating tiny purpose use for esbuild via Jake Lazaroff.

At the time, I was reviewing the upcoming contrast-color() function that Webkit added, which is pretty compelling. One of the blogs I read mentioned that Jake had another solution that he came up with for color selection based on contrast. Very cool! So I perused around this neat subdomain called TIL and found another entry that immediately had my brain on alert.

Run a development server with live reload

After reading that it was possible to use esbuild for building, bundling, and live reload with no extra dependencies, I opened up VSCodium. I used a blank folder to initialize NPM and install esbuild for one reason.

How many folders and subfolders show up in the /node_modules/ folder?

screenshot of node_modules for esbuild showing minimal folders and files

I was once again shocked. Somehow, this is all that’s installed from running npm install esbuild and somehow this is all it takes to have build, bundle, and live reload capabilities!

I then set up the suggest project structure to test it out:

src/
|-- index.html
|-- index.ts
|-- style.css
|-- livereload.js

I kept the code in each file minimal, almost identical to what Jake suggested, but I was running into one problem. While the localhost page was showing what was contained in index.html, it wasn’t actually performing any live reloading. I couldn’t understand what I did wrong.

Additionally, I assumed that running the webuild command that Jake suggested would literally generate a new /build/ folder in the root folder of the project I created. Nope, nothing. Somehow something was working, but not live reload.

Frustrated, and without answers, I let it sit for a few days.

This evening, Jake followed up from a social media inquiry asking if I had luck.

@asuh did you end up getting this working? i just set up a new repo and i had no issues with it.

i don’t see the build folder actually being created on the filesystem, i think in serve mode it just keeps everything in memory.

Hmm… hold on, it keeps everything in memory. This means… maybe I won’t see a literal build folder generate into the project? Maybe?

Okay, so I reviewed my code to see what I had, fired up the server again using npm run dev, still the same issue. Why? Then I saw the script source attribute, which contained the build folder its path. I removed it.

That did it!

I had a working live reload, a bundler that transpiled typescript to javascript, and it builds all the files on demand. What a miracle!

This might not be useful in large projects where everyone’s using countless NPM packages. I’ll have to think more about this with anything I’m using because I’ve also actively started using Vite as my go-to build system for new projects. But, maybe, just maybe, this esbuild idea could turn into something even simpler!

I mean, I know we’re quickly approaching a reality where I can actually use HTML, CSS, and JS for the majority of what I need without too many abstractions. I’d need templating, so either server side JS or PHP, which I’ve used for decades, would give me the rest. It’s a fascinating time for the web.

I created a Github repository for this bundler so that I have reference in the future and as a proof of concept.

https://github.com/asuh/bundler