Why I built my site with a static site generator and why I design client sites for WordPress Part 2
In the previous article, I discussed the three options I considered when redesigning my website and explained why I chose a static site generator. Although a static site generator made sense for me, I don’t think it’s a good option for many of my clients. Let me explain why.
Static site generators are intended for developers
If Jekyll, the static site generator that I use, is any indication, then static site generators are tools designed for web developers.
As a web designer, I don’t consider myself a developer. With the help of a tutorial and the Internet, I build and manage my site. But I don’t believe that my skillset is representative of the majority of my clients.
Jekyll uses a command-line interface. My experience with the command line is limited at best. Most of my clients, however, probably have had less experience with the command line than me.
I knew when I chose Jekyll that I would be challenging myself. For many of my clients who are small business owners, they may not look forward to the same challenge.
My goal as a designer is to provide a solution that my clients can maintain themselves without ongoing support from me or anyone. With that in mind, a static site generator isn’t the best option.
The website workflow is multi-step
To give you an idea of what working with a static site generator is like, here are the steps that I take each week to publish a new blog post. I author all my blog posts in Google Docs.
- Because Jekyll works with Markdown, a file format that can be converted to HTML, I export my Google Doc to Markdown with the Convert to Markdown script.
- After the Markdown file is generated, I put it in the appropriate folder for Jekyll to find. Then I edit the blog post in Brackets, a free text editor from Adobe. In this step, I proofread my text for the last time, check the Markdown syntax, and generally clean up my file. I also add images to my post if I have any. I could skip step 1 and author my Markdown files in Bracket, but I prefer to use Google Docs, so I always have cloud-based backups of my posts.
- Also in Brackets, I make a small change to the configuration file that Jekyll uses to generate my website. If I don’t make this change, then I’m unable to view my site locally.
- Using Terminal on my MacBook, I start up the Jekyll server, which automatically builds my site. Once the site is built, which takes less than two seconds, I can view it in my browser.
- I check my home page, blog page, and blog archives to ensure that my new blog post appears on all three. I also take a look at my other pages to ensure they were built correctly. If all goes well, then there’s no need for me to edit anything further.
- I edit my configuration file in Brackets and build my website again via the command line.
- I upload my output files to my web host using Cyberduck. I’m not a GitHub user, and I don’t use GitHub Pages because I already have a web host. If I were a user of either or both, then my steps would be different.
- When the upload is complete, I go to my website at www.tarahall.me to make sure that all files were uploaded and updated.
- Finally, I use W3C Link Checker to check my website links.
In total, I use five tools—not including my web browser—each week to I update my website. But despite all the tools, in a typical week, I spend less than an hour updating my site, not including the time it takes to write my blog posts.
WordPress is server-based. You need only a web browser to access and update your website. You can make updates from any computer and on any device. This isn’t the case with Jekyll.
Because Jekyll is installed locally and because it requires a command-line, I’m unable to access it from another computer or from a mobile device. If ever I’m away from my laptop and need to update my site, the changes would have to wait until I’m on my laptop again.
In WordPress, you can author new blog posts or web pages and publish to your site immediately or schedule them to publish at a later date.
With Jekyll, because it requires me to generate the site and to upload the files to my host, I can’t schedule publishing for later.
Many static site generators have no CMS
Many, though not all, static site generators, including Jekyll, do not provide a content management system (CMS). Because you aren’t creating or editing content with the static site generator, there is no user interface (UI).
There is a solution to the lack of CMS: Cloud Cannon. It offers a CMS for Jekyll sites for a price. Cloud Cannon’s Basic plan is $25 per month per user, and the pricing goes as high as $125 per month per user according to their site. WordPress, on the other hand, is free.
I don’t find the WordPress UI to be the friendliest UI, but with WordPress, my clients don’t need to code their web pages. With training and a custom manual provided at the end of every project, I’m confident that my clients have all that they need to maintain their website.
WordPress has far more plug-ins
WordPress has been around for more than a decade, making it a mature platform with widespread adoption. It’s estimated that more than 20% of the world’s sites—or more than 74 million sites—are built with WordPress.
With so many sites and with its history, it’s no surprise that there are so many plug-ins to extend and enhance WordPress. According to WordPress.org, there are more than 43,000 plug-ins, some free and some paid for, available today.
With so many plug-ins, creating a robust, feature-rich WordPress site is relatively easy. Building a custom site for a client can mean choosing and configuring the right plug-ins to meet their needs without custom code.
By comparison, the Jekyll site lists about 160 plug-ins. Of course, Jekyll is a newer technology compared to WordPress and has far fewer installations. If its popularity increases, then the number of plug-ins may increase as well.
But to be fair, Jekyll describes itself as “a simple, blog-aware, static site generator.” Its aim may not be to provide robust website features and functions, such as ecommerce support. Jekyll may never rival WordPress in number of plug-ins.
Despite the advantages of WordPress, I still chose a static site generator, primarily for the reasons outlined in the previous article: speed, security, and simplicity. But those weren’t the only reasons.
I worked in software long enough to know that technology ages and gets replaced. WordPress has been around since 2003. Sooner or later, a new technology will take its place. Will it be static site generators, website builder platforms like Squarespace, or something that we haven’t seen yet?
Whatever it is, I hope the technology:
- Caters to more than one audience—developers, designers, content creators, and so on
- Provides a CMS and a user friendly UI whether local or cloud-based
- Offers both speed and security
Until then, I’ll continue to design WordPress themes for my clients, but I’ll be on the lookout for what’s next.