I understand the allure of using something like Wordpress for some sites. It’s fast and easy to get started and everything is right there.
The problems with a CMS in my opinion are:
-
Security.
The attack vector for a CMS like Wordpress is relatively huge:
a. PHP vulnerabilities on the webserver require maintenance and updates to stay safe (assuming there’s not another layer of framework or something that might require even more).
b. SQL vulnerabilities have to be watched as well.
These two services (SQL and PHP) probably make up the vast majority of security issues on the internet right now.
Don’t forget that you’ll need to keep the entire CMS system updated on the server to make sure you’re safe.
-
Flexibility.
Sure, things seem fine as long as you’re willing to delve into the particular of building out templates and custom code for sites using whatever arcane method of use the system requires. It’s certainly not impossible, just unwieldy and very specific to the CMS.
-
Speed.
Even with some caching there is a requirement to hit the server-side script and possibly the database before serving up data. Might seem trivial until you get an occasional spike in traffic and realize you can’t really serve more than a few dozen simultaneous requests.
-
Use case.
If the content is truly static content, then a CMS with database and scripting language to parse on the server is just overkill. And honestly, most of the internet can be served as simple static pages without requiring server-side scripting.
What is nice about CMS is the WYSIWYG interface for most people and the ability to fiddle with shit endlessly (similar problem I have with MS Word or a WYSIWYG “document” editor).
Using a static site generator…
-
Security.
It’s just serving static content from the filesystem from nginx/apache. The only service you need to make sure is secure is the webserver. If you don’t update your build system in a few months it doesn’t matter because the content is still unchanged and only providing static files from the webserver to serve.
-
Flexibility.
This is a little more complex to setup initially, but if done correctly allows users to focus on content later on and not worry about fiddling with how something might look (WP does this too to some extent, but with a prettier interface).
-
Speed.
Just like security, I’m just serving static content from the web path. This will always be faster than any CMS by order of magnitude in some cases. We can handle hundreds (thousands?) of simultaneous requests without even breaking a sweat on the webserver.
That being said, I can completely understand why some folks would rather use a simple exporter directly to something like WP, but I do believe in the end the same or better can be accomplished with an SSG.
Some of them are quite nice these days (Hugo has done a great job of data types and management, including all of the essential “social” stuff that people like to add - check the opengraph/schema stuff that’s baked right in by default).
In fact, you could theoretically just dump photos into a directory structure and drop a .json or text file next to them that has metadata tied to them and let the SSG handle rendering the page pretty quickly.
