In the world of complex frameworks and CMS platforms a new trend is gaining popularity. More and more people prefer a completely static site to a dynamic one, whether it’s a simple homepage, a blog or a portfolio. What is a static site? A static site brings us back to the good old times where…
In the world of complex frameworks and CMS platforms a new trend is gaining popularity. More and more people prefer a completely static site to a dynamic one, whether it’s a simple homepage, a blog or a portfolio.
A static site brings us back to the good old times where people used Frontpage and Dreamweaver to just put together their simple homepage. When you needed another news, you’d make a duplicate of an existing one and replace the contents with the new one, update the news list page and upload the new site to ftp. This was a plain and simple flow that was manageable to almost everyone and didn’t require any special programming skills. The site was fast and secure, didn’t rely on databases or PHP running on the server.
Same can be applied to a modern static site as well when describing its essence. The only difference is that the manual work needed for updating a modern static site has been significantly reduced by templating and data files
A static site is an option worth considering for those who want a relatively simple homepage or a blog that doesn’t require complex search, dynamic content and forms but requires to be fast and secure. While most static site frameworks have their simple online editing interfaces as well (similar to WordPress), the truth is that static sites need a bit more technical knowledge both configuring and setting the site up and updating the content as well. Depending on the generator the content manager may need to have basic knowledge of Ruby, Python, Node.js or some other and feel comfortable using command line interface to generate the site and manage its plugins.
The main reasons to go for the static site is speed and security, as mentioned before. Dynamic sites fetch their data from databases and generate pages to display to the visitor on the fly. All this takes time and can cause an overload in case of a sudden peak in traffic. If a site uses a mainstream CMS, you can be sure that it’s a target to malicious hackers trying to attack it through security holes.
Using a static site means the server only has to serve static html files and there is no database to drop or forms to use for submitting malicious code. A static site doesn’t depend on packages, libraries and plugins that require constant updating and may not be compatible with each other or the webserver. It’s much more complicated to exceed server limitations on a static side as it doesn’t connect to databases.
Another benefit for static sites is the ease of version control and collaboration. For most mainstream CMS platforms all site-specific configuration and content is stored in the database and versioning that is a difficult mission. Even though you have the capability of creating regular backups it isn’t comparable to having whole configuration and content in Git, including news, blog posts and whatsoever. There is no need for expensive and yet not bulletproof tools to merge databases from development environment to live environment.
The biggest argument against using a static site is that it’s static. This means it’s not capable of having any real time data. Meaning static sites won’t be the solution to booking systems, e-commerce, trending data based on visitors’ behaviour on sites, advanced recommendations system etc.
Visitors of static site won’t be able to give their input, whether it’s commenting but also logged in user areas or simple contact forms can turn out to be a challenge.
As described earlier, managing a static site requires somewhat more technical skills and knowledge. Many static site generators fetch their data from Markdown files (text content) or as JSON objects (configuration, structure, looping elements’ data). This may be scary in the beginning but not over complicated.
While setting up the static site development environment might not be the most user-friendly process, it’s a one-time job. The generation process is usually much easier.
There are 50+ tools to use for static site generation. Just as it was a trend to have your own CSS grid framework created at some point, it seems that nowadays it’s must-have to create a static site generator. When choosing a static site generator, it’s worth to consider some factors:
Most static site generators use Node.js, Ruby or Python for installation, running it locally and generating the site. A fewer rely on Google’s Go, Elixir, React, Erlang. While it’s possible to setup any of the generators to both Windows, Linux and Mac, some tools are optimized to a certain OS and it’s often Windows that isn’t officially supported
Some static website generators have a small niche to focus on. For example, DocPadand Slate are for generating documentation, Expose and Sigal are for photo galleries. Some generators introduce themselves as a tool for blogging but just as WordPress they can be „abused“ to create complex websites.
Making a static site generator fit to specific requirements can be a tricky task that requires some out-of-box thinking skills. In the search of technical solutions, it’s helpful to have a good detailed documentation with code examples at your hand. A not so thorough documentation can be compensated to some extent by strong community. If there’s a community support forum, Slack channel or users answering related questions at Stackoverflow, it’s a good chance you won’t be alone with your own questions.
If you plan to use a static site generator for something more complex, you might find yourself in a position where the tools provided won’t bring the results you need. For those cases it’s good to know if there are any third-party plugins available or how complicated it would be to create your own plugins. Some generators even support plugins originally meant for another generator with or without any modifications to the plugin itself.
Jekyll is one of the first and definitely most popular static site generator right now. It is built in Ruby by GitHub itself. Jekyll targets itself to bloggers and smaller companies. One of the biggest projects that use Jekyll is probably GitHub’s Official Teaching Materials. Its biggest bonus is wide selection of plugins and strong community. That makes it easy to fit it to any type of project.
Jekyll also has many spinoff tools like Jekyll Admin and Jekyll now to make setup and management easier for the beginner users. Just as many other generators Jekyll uses Markdown files for storing text content. Jekyll will be soon celebrating its 10th birthday. One of the biggest drawdowns for Jekyll is potential issues on Windows. It’s possible to set up Jekyll on Windows 10 but can be a challenge on older versions. Also, it’s worth noting that making Jekyll multilingual requires a bit more templating and configuration compared to other generators.
Hugo has been on the Static Site world half the time than Jekyll but it has taken a great leap in becoming the second most popular tool. It is built with Google Go programming language and just as Jekyll has tons of plugins, templates and snippets to use and a large library of premade themes to download and use as is or as a starting point to your own theme.
Hugo was chosen as the static site generator for Smashing Magazine after giving up WordPress. Just as Jekyll it uses Markdown for text content. In comparison to Jekyll, Hugo officially supports Windows as well.
Hexo is of same age as Hugo, being on the market since 2013. While Jekyll uses Ruby and Hugo uses Go, Hexo is a build tool created with Node.js. Its main focus is blogging but the flexible templating patterns and configuration options make it suitable to any kind of projects.
The biggest problem with Hexo is not the most detailed documentation and far less active community compared Hugo’s and Jekyll’s. It’s simplicity and reliability on all operation systems is what makes it a strong competitor and third most popular static site generator in this moment.