Always use a Server for Local Development
You probably have a local development environment set up for your projects at work, complete with server and database. Maybe you manage a carefully designed custom environment with tools like Vagrant or Docker. Maybe you run a local instance of your CMS on an Server stack like MAMP or XAMPP. If your sites are small, you likely use whatever server comes bundled with your Rails, Express, or Jekyll app.
But local servers aren’t just for product development and client work. A lot of my side projects are Javascript libraries, and frontend demos, and while it’s possible for me to simply load these from my file system, I always use a server instead.
Here’s why:
It’s always best to develop and test in an environment similar to production, to prevent gotchas down the road. This is frequently employed for continuous deployment of large apps, but it applies to your small static projects too.
What does production look like for a small static front-end project? It’s a web server, responding to incoming requests by delivering static files that render and run in user’s browsers. This is always true, whether your webpages are served by Github pages, Amazon S3, or a CDN.
What gotchas can we prevent by using a server for static projects? Here’s a few that I’ve found:
- Assets referenced via protocol-relative won’t be successfully requested.
- Some browsers won’t automatically detect local favicons at /favicon.ico.
- Some third-party services won’t function properly if you cannot pass them an IP address or URL.
- Your browser’s security settings may prevent local assets from loading properly.
- Other inevitable edge-cases for your application (comment below if you have seen other issues).
And there are benefits too:
- Using a server allows for easy local device testing over your wifi network (especially if you use Alfred).
- You can configure .htaccess or other local server settings.
- You can set up a local SSL certificate to replicate serving files over https.
While you can live without these benefits and work around the issues, setting up a local server is so easy that there’s pretty much no excuse not to do it.
Here’s how:
Using the terminal, browse to the folder containing your static project. Then run this simple Python command:
python -m SimpleHTTPServer 1111
Note: You shouldn’t need to do any setup—all Macs and most Linux computers come with Python pre-installed.
Now you should see Serving HTTP on 0.0.0.0 port 1111
, and when you open a browser and browse to localhost:1111
, you will see the static webpages in your project served by the small python server. You can use any port by the way, but I use 1111
because it’s probably not being used by anything else and it’s easy to remember.
To make this even easier, I set up a Bash alias by adding this code to my .bashrc
file:
alias server="python -m SimpleHTTPServer 1111"
Now all I have to do is type server
in a terminal, and it will instantly start a small server for my static files.
If you prefer a different tech stack, there are also little servers out there for PHP, NodeJS, and any other major server-side language. You can use any of these… just use something. Use it with static sites, hackathon projects, HTML5 games, and more. Whatever you’re working on, no matter how small, can benefit from using a local server.