Why I Abandoned Vercel's 'serve' for 'http-server'

In my previous posts, I talked about adopting modern tools like npx and serve. But today, I want to share a real-world lesson on Tool Selection.

While building this portfolio, I initially chose Vercel's serve package to run my static site locally. It's the industry standard for React/Vue apps. But for a simple HTML/JS site, it turned out to be "too smart" for its own good.

The "Clean URL" Trap

The serve package has a feature called "Clean URLs". If you navigate to /blog, it automatically looks for blog.html and hides the extension. This sounds great, but it caused a conflict with my production environment (Nginx) and my dynamic routing logic (?id=...).

1. Local: The server would strip .html and issue a 301 Redirect.
2. Production: Nginx expected .html to be present.
3. The Loop: Trying to fix one broke the other. I ended up writing complex serve.json configurations just to tell the tool to stop helping me.

The Simplest Tool for the Job

I realized I was fighting the tool instead of building my product. So, I switched to http-server.

npx http-server . -p 8080 -c-1

• -c-1: Disables caching (No more 304 errors during dev).
• Dumb by Design: It doesn't try to be clever. If I ask for /blog.html, it gives me /blog.html.

Leveling Up as a Developer

Coming from the .NET world, we often rely on heavy frameworks that do magic for us. In the Node.js ecosystem, the philosophy is different: "Small tools for specific jobs."

Sometimes, the "Modern Standard" (serve) is overkill. Recognizing when to downgrade to a simpler tool (http-server) is a sign of maturity in software engineering.

Lesson Learned: Don't use a Ferrari to go to the grocery store. A bicycle might actually be faster.