What Your Tech Stack Should Look Like If You’re Building Static Sites
We’ve previously mentioned the many benefits of building static sites over using a traditional CMS like WordPress. But if you’re new to building static sites, it may feel intimidating to create something “from scratch” using a static site generator.
One of the biggest differences in building a static site is the technology involved, which scares many first-timers.
WordPress and other CMS’s may seem like a better choice because they claim to do much of the work for you, but many developers find the flexibility rather limited after a certain point.
And the good news is that building a static site doesn’t mean you’re left without help. In fact, there’s plenty of technology out there that can assist you in equal (or sometimes better) ways.
Here’s what you need to know about having a good tech stack when building static sites.
Languages
This is going back to the basics, but the first thing you need to consider before you determine your tech stack is what languages you will be using.
Preprocessor languages are programming languages compiled into three types: HTML, JavaScript, and CSS. Examples include CoffeeScript, LESS, HAML, and Dart.
Each offers different syntaxes, features, as well as other benefits, and each static site generator (SSG) will allow for different preprocessor languages. It’s important to determine what language you’re most familiar with before you decide on a SSG.
While you don’t necessarily need to know anything beyond HTML to build a static site, you may want to consider brushing up on a preprocessor language to gain some advantages. The team over at Raygun have a great blog article about 10 reasons for using CSS preprocessors.
Site Generators
Unlike CMS, building a static sites requires generating HTML files that are served “as is” with no other database involved. For many developers, that means using editors like Dreamweaver or Notepad to code everything and then hosting those files to create the finished project.
Thankfully, technology has evolved enough to give us SSGs, tools that allow the creation of static sites in any number of languages.
Some popular SSGs include Jekyll, MetalSmith, Grunt, and Pelican. These SSGs can be used either with markup files as a source or even using a hosted content API such as Contentful, or Medium
SSGs help developers perform important tasks such as combining multiple files into one, compiling preprocessor languages, or even packaging code into a mobile application without having to do everything “from scratch.”
So which do you choose?
Well, some SSGs are built for a specific purpose, while others can be used for almost any site. It’s essential to find something that fits your workflow, is actively maintained, and has an active user community for when you have questions. If you need help deciding, we’ve ranked a few of the top options here.
Templates
Of course, if you did want to take a more “from scratch” approach without needing to spend countless hours coding your site, you could always use a static HTML template.
HTML templates come with pre-made features that allow you to fill in the blanks, so if you’re used to plugging components into templates with a CMS but you still want the benefits of static sites, you can find a template to meet your needs.
You can find a variety of pre-made HTML templates on sites like Template.net, Template Monster, and ThemeForest.
Package Managers
Another important aspect of building a static site is packaging your files together. But keeping track of all those packages and making sure they stay updated can be difficult, which is why many developers choose CMS over SSG.
However, there are package managers designed to help you manage things like your libraries, languages, fonts, and even images. A couple of popular package managers include Bower, which allows you to install open source or shared library code, declare dependencies for your projects, and more.
APIs
One of the noted downsides to using static sites is the lack of APIs, meaning that there’s little interactivity, which, of course, is the point of doing something “static.” But if you still wanted the functionality of a dynamic site while building a static site, there are a few workarounds you could consider.
Raymond Camden has a tutorial for adding the “read” aspect of an API to your static site using any SSG.
Brandon Brown has another post on how to develop JSON APIs using Surge.
Static Web Hosts
Finally, and perhaps most importantly next to choosing a SSG, you will need a place to host your project once you're ready to launch.
There are many options for static web hosting including traditional shared hosts, online storage with hosting, and a few services even have dedicated static web hosting.
So how do you choose a good host? Here are a few things to look for:
- What is the cost you’re willing to pay for hosting?
- Does the host support HTTPs? Do you need HTTPs support?
- What is the upload method to host files? (GitHub, manual upload, etc.)
- Does the host offer a Content Delivery Network (CDN)?
- Do they support form handling?
- Do they support build automation?
- How easy is the deploy process?
- Are there other developer-friendly features like rollback?
A few of the top hosting services for static sites include GitHub Pages and Amazon S3. You want to find a service that will give you the flexibility and support you need for every project. And, while many hosting services are cheap or free, be careful that you’re not undercutting your value.
Final Thoughts
At the end of the day, choosing a tech stack comes down to finding technology that works well for you and your team and will help you stay productive.
If in doubt, you can always ask around (or check on the links we’ve offered). But, remember that what works well for one developer or site may not work well for yours, so it may require some testing to get things just right.
Remember, one of the benefits of building static is that you also have more flexibility to build your ideal stack, one that fits your needs and helps you do the work faster and keeps things maintained and updated with as little stress as possible.