Static file serving lets you map a URL prefix to a directory on disk so the server handles serving files (HTML, CSS, JS, images, etc.) automatically without writing route handlers for each one.
How it would work:
- app.static("/assets", "./dist") serves every file inside ./dist when the URL starts with /assets
- Requests to /assets/style.css would read and return ./dist/style.css
- MIME types detected from file extensions (.js → application/javascript, .png → image/png)
- Proper caching headers (ETag, Last-Modified, Cache-Control) so browsers don't re-download unchanged files
- Returns 304 Not Modified when the browser already has the current version
- If the file doesn't exist, falls through to other routes instead of returning 404
How it would NOT work:
- Does not execute or process files — no server-side rendering, no template engines, just raw file bytes
- Does not allow directory traversal — requests with ../ are blocked so users can't escape the served directory
- Does not serve dotfiles (.env, .git, etc.) by default — these are denied unless explicitly allowed
- Does not compress on the fly — but can serve pre-compressed .gz/.br files if they exist next to the original
- Does not replace a CDN — it's for development and small deployments, not high-traffic production static hosting
The initial implementation would work through the existing JS bridge (Rust → JS → fs.readFile → response). A future optimization could move file reading into the Rust layer entirely, bypassing JS for static files.
Static file serving lets you map a URL prefix to a directory on disk so the server handles serving files (HTML, CSS, JS, images, etc.) automatically without writing route handlers for each one.
How it would work:
How it would NOT work:
The initial implementation would work through the existing JS bridge (Rust → JS → fs.readFile → response). A future optimization could move file reading into the Rust layer entirely, bypassing JS for static files.