(This post is essentially an expanded transcript of a short talk given at Sydjs.)
Why are you making a static site?! That's a bit old school isn't it?
In every web job I've had, at some point deploying a static site was the right option... but people react as though it's crazy to be considering it. That it's somehow too old a technique to be used now.
Everything old is new again
There are reasons for old patterns to come around again. It has become so easy to build a client side application, it's easy to build something needlessly complex.
But if something can be deployed static, why not? "Generate dynamic, deploy static" has been a strategy for a very long time, and with good reason. If you look around, you'll find plenty of people deploying static sites, because it still makes sense.
Good use cases
- Small/medium sites
- Version-specific or bundled documentation
Good use cases for static deployments tend to be either about the content, or the deployment environment (and the reliability and long-term maintenance of content in that environment).
If the content doesn't update much or at all, if the deployed artefact is about content rather than actions and manipulation, then it's probably going to be a good static site. That's why it's great for blogs: once published, they usually don't change. Each time you view a blog post, it will still be the same content.
The documentation for a specific version of a code base is much the same. It needs to be generated along with other compile-time resources for future reference. Once released, you should never need to change it - you would release a new set of docs with the next release.
This is when you can really see the benefit of producing a set of flat, static files: you don't want to be running a server for every frickin patch release you've ever done. You really want to fire and forget, not add to a large pile of future maintenance.
Bad use cases
- Anything else :-P
- Things that actually should be an app.
Upsides of static sites
- Fast / performant
- The download is it. Done.
- No runtime dependencies:
- you don't have to worry about services coming back up after downtime
- you don't need to mirror your dev environment on the server
- Static files should have less vulnerabilities than a full stack+application
- Deploy anywhere
- zip files with your library
- deploy to cheap hosting options
- Some options even deploy via FTP so you dont have to futz about with SSH keys
Static sites are quite pure, they stick the native trinity - HTML, CSS, JS. Things the browser can consume directly now and likely long into the future.
Downsides of static sites
- Static sites do require oldschool scripting approaches for any content that is not static.
- "It just seems too simple."
People often feel static sites are somehow too easy, or they're getting away with something.
It's like building a browser extension and feeling bad for not having to suffer at the hands of IE8 – understandable, but time to break free.
Fundamentally we need to be comfortable with simple. We should strip things back if we can, remove risks if we can.
We can keep complexity in the dev's realm. All those little tweaks you can do at compile time have to be totally automated on the server, lest you want to attract the rage fo devops - they're on call.
Users don't care regardless.
...and anyway, "simple"?
We seem to need quite a lot of dependencies to do simple things these days.
We should be meditating on the concept of simplicity.
A few nodejs options for generating static sites
- Blacksmith, CabinJS, DocPad, Wintersmith...
- See modernstatic.com for a list
* As seen in JS Weekly ;)
All languages seem to have a few static site generators - even Nodejs, the relatively new kid on the block, has lots of options. This means we can use the same dev tools, languages etc that we use in app projects to produce a static site.
Having a common stack across projects has a lot of benefits:
- Faster onboarding
- Less siloing
- Good for maintenance
- Match to your own team's skills - if that leads away from node, that's cool
Choosing an option
Rather than demonstrating a specific option, I'll run through some key things to look for while evaluating the options.
- Clear setup, dev, test and deploy phases
- Your preference for:
- Deployment options
- Proof of life (beware abandonware)
When you are working with preprocessors, minification, concatenation and deployment, you will want a tool that easily supports multiple steps and transforms. Some awareness of development vs. deployement is good.
Also you want to check the package can run up a server for you locally, particularly if you want to use full relative paths and so on. Remember - it's ok to have some extra parts in your dev stack, so long as you're still deploying static assets.
Basically, every templating and preprocessor/transpiler option is available. You can pick the exact way you like to write scripts, style and content. Don't like LESS? Use SCSS. Don't like Markdown? Use Textile. There are options out there that will support it - the range was actually surprising when I was researching the options.
Checking for documentation and proof of life is just a sanity check - your own sanity.
Taking the pulse of an open source project is a bit of an art; but you should at least check there are issues being raised, see if pull requests are being submitted, etc. You want to see some evidence the project is still being maintained and has some level of uptake.
Static sites have their place
My message is: don't feel like static deployments are too simple, or they don't make good use of the modern toolset. You can use a great dev stack and still deploy static files as the deliverable asset.