Static sites are BACK!

Way back in the day, web pages were just static sites, with only HTML and CSS (and later some JavaScript maybe). Just try to remember what that actually means. There were no server code or database, there was only an .html file hosted somewhere that your browser downloaded and displayed to you. Their development was done in the text files directly or, oh god, through programs like the notorious Dreamweaver.

At some time finally, the web development took up its pace and, up to now, it has not stop speeding up. At some point, the notion of the CMS came to be and then a whole new way of developing (among other types of pages) portals, blogs, and marketing sites grew and prosper, and still does, with WordPress being the leading CMS choice right now.

Although a CMS can solve many problems, either from the point of the developer or from the point of the administrator, there are some reasons to NOT use one of them and maybe, revert to an old, very old friend.

Selecting a CMS for a specific project will instantly require some tight specifications and dependencies. For example, a typical WordPress installation will require at least, a web server like Apache, PHP installed with various extensions and of course, MySQL database. All these must be updated and maintained and, at some times, these procedures can actually cause even more problems.

One of the most important factors of today’s web development is security and that, unfortunately, is one of the most important downsides of CMS’s. Using a CMS you are making yourself vulnerable to many attacks. The number of vulnerabilities you open yourself to increases by a lot the more plugins you install and use ( which is the real reason to use a CMS in the first place ).

Apart from security, one other very important thing of a modern project is performance. A CMS either generates the page the user requested from scratch or uses a, either built-in or through an installable plugin, cache system that ensures to reuse a pre-generated page whenever possible. Using some type of cache system can help a lot, but even so, it adds quite some overhead.

By creating a static site on the other hand, these problems become obsolete. A static site consists only of, as the name suggests, static files, like some .html files, some .css, and a few .js. There is no specific requirement for the type of the machine that will host the page, no backend language restriction and no need for a database. Being just static files served to the browser, there are next to none actual vulnerabilities. The actual pages are already generated and maybe minified, which from the performance point of view, will be always a lot better than any CMS-cached solution.

Even more, modern static site generators typically read content from flat type files, mostly Markdown. The post’s content resides in files, instead of a database, so you can/should put them under your git (or other version control system) workflow.

On the other hand, static sites have some disadvantages too. You are basically ditching out on the backend world of the web. Most importantly, you lose every interactivity with the user ( things like user login/profile, favorites, suggested read etc.). There are some ways to add a couple of features, like commenting system through the Disqus platform, but these are not optimal for sure. The biggest feature missing from these generators ( although it is a fair guess that there will be a solution for that at some point ) is the lack of an administrative UI. Maybe the more tech-savvy people will not find it difficult to create new files in proper folders and link accordingly assets like images but, for the most content writers that will be a living hell.

Up to that, it is primarily a project planning decision based on its requirements. For a very big portion of the Web, a CMS is definitely an overkill. Considering the above points one should be able to answer if a static site is enough for a specific project. But, there is one more problem for the static site generators and that is the extremely large amount of choices and the accompanying initial setup time which will be required.

On the CMS world, there are countless options but there is also a prominent winner, WordPress, which as a choice will do the job for any project. On the Static Site Generators world, there are too many options (459 to be precise) without a clear winner or even some way to differentiate them easily so that a choice between them could be done easier. That seems like its going to change from now on, but it remains to be seen. Some of them, have gained extensive popularity and they are worth noting.

Jekyll is by far the most popular one of those generators. It is built with Ruby and is integrated into GitHub Pages, so it is quite popular for personal projects and/or documentations. It has a huge user base and a big directory of plugins.

Hugo is quite similar to Jekyll. It is built on Go and its main point against Jekyll is its blazing fast speed. Jekyll, especially when the number of posts/pages goes up, can be quite slow when the actual site is being generated. Hugo on the other hand is generating the site in a matter of seconds. There are also some other abstractions that make Hugo more user-friendly and easier to start with, as it does not need that much configuration to create something from scratch.

Hexo is a newer addition and is created with NodeJS. It is advertised, and mostly used, as a blog platform and combines the extensibility of Jekyll with the speed of Hugo (actually faster than Hugo).

Wintersmith is another one built on top of NodeJS. This one is different as it is quite minimalistic and it basically is a platform that you can customize through some plugins to your needs. It definitely requires some more tweaking to make it work but leaves more space for customizations.

The last option is the newest and maybe the most interesting one. Gatsby is the one framework that brings the static pages to nowadays stacks. It uses React.js and Webpack to create a SPA ( Single Page Application ) with your content. It promises to remove much of the configuration needed for such an application and provide the developer with an easy to use solution that will, in the end, produce a modern and high-end level application. The truth is that Gatsby can be used for many other things than just a blog and its true limit is nowhere to be found yet( as it only reached its first stable release earlier this month ). The fact that it uses React helps a lot as more and more developers nowadays are using React right now or plan to in the near future.

Summary

Looking at the downloads from the last six months, we can see that Gatsby might be a winner in the making. Those numbers might not be 100% true, as Gatsby can also be used for more complex things than a markdown-to-html conversion but, as its user base expands fast, we might have found the WordPress for static site generators.