Recently I was considering revamping www.rhythmandbinary.com, and potentially branching out to a different platform. There are a lot of options available, and I wanted to pick the right one for what I was doing. In the process of my research, I also was able to develop my professional site andrewevans.dev (more on that later). This all turned out to be a great learning experience, and I wanted to write about it. In this post I’m going to talk about my experience with the latest CMS technologies, and the reasons I chose to use what I have today.
As a side note, in this post I’m only focusing on a small subset of the CMS options available. There is a wide variety available, and I encourage you to look beyond this post before making a selection.
If you google “CMS tools,” you’ll get a flurry of different sites and platforms. To begin, the term “CMS” stands for “Content Management System.” CMSs are typically used to manage content for Enterprise Customers as well as websites like blogs. I included CMS in the title of this post because I’m specifically reviewing CMS platforms that service blog sites. Common examples of CMSs include WordPress.com, Drupal, and Joomla.
The bigger CMS platforms offer things like analytics, RSS feeds, and other ways to maintain and interact with your data. CMS systems are really powerful because they provide easy to use tools that work for both technical and non-technical people. With a CMS platform, you can get up and running very quickly. CMS platforms typically provide:
- Publishing Capability
- Indexing of content
- Mailing Lists (followers)
- RSS Feeds
- and more
The challenge, however, is that there are a large amount of different options. They all offer similar services, but it depends on what you’re comfortable with and the experience you want.
In my search (and for this post), I’m focusing on the following:
I also want to mention that there are many innovative solutions developed by individual engineers. My friend Tim Deschryver has a fantastic site at https://timdeschryver.dev/ that provides a great example of this. I was looking at the larger platforms because I already had a well established site with WordPress.com. I liked the ease of use with a platform system, and wanted to look at all my options to see what was available. I was also super interested in a custom option for just the sheer ability to have complete control over my content. In the following sections I’m going to cover the pros and cons of several platforms, and end with a summary of why I chose what I did in lieu of the competition.
GatsbyJS with Netlify CMS
GatsbyJS with Netlify CMS is a really cool option if you want to generate and manage your own content.
Netlify CMS is an open source utility that (when combined with Netlify’s Identity service) does a lot of the legwork for bloggers in terms of generating and retrieving content. When you use Netlify CMS, you can use a provided widget within your site that provides a GUI and editor for posting.
When you create a site with GatsbyJS and Netlify CMS all of your content is stored in your GitHub repo. Netlify uses the OAuth keys in your repo to coordinate security and to push content to the repo. You use the Netlify CMS widget to generate the content, and when you save it is pushed directly to the repo. If you host it with Netlify, this results in a new build of your site. In addition to all of this, Netlify has free accounts for developers! This all makes for a really nice combination of technology and services, if you’re wanting to have a blog where you control all the moving pieces of the system.
For a good walkthrough of setting this up for yourself, please check out the tutorial here.
As I’ve said, the coolest part about this solution is that it is all code that you control. The Netlify CMS utility is an open source project, and actually supports multiple providers (other than just Netlify). Plus, I didn’t mention that GatsbyJS also uses GraphQL to parse over your repo’s content. If you want to use these two technologies, its an excellent learning opportunity for both GraphQL and ReactJS development.
Despite all the cool features, however, I didn’t choose this option for several reasons. First I went through and setup a few different sites, but felt that my WordPress site’s look and feel was still superior. Second, it turned out to be a lot of work! I had not worked with GraphQL before, and was not really that familiar with ReactJS either. Learning JSX Syntax and the ins and outs of styling components in ReactJS definitley had a learning curve. I do have to say though that after being sufficiently beat up by ReactJS, the learning experience was very solid. The experience gave me a good intro into the power of GraphQL and ReactJS together.
Additionally, I also realized that I really liked the ease of use with the WordPress site I have. I’m going to cover more about WordPress later, but reviewing GatsbyJS with Netlify CMS showed me how much CMS tools actually do for you. However, I’d still recommend checking out both of these technologies if you’re starting out or want to learn how they work.
So I’m actually already a frequent Medium contributor. If you checkout my profile page you will see my contributions to both Angular-In-Depth and ITNext. These are also in addition to my personal posts.
I don’t mind Medium, and actually really like the interface. The content is easy to create, and the “social media” tools make it easy to share content.
So I have to give kudos to my friend Tim Deschryver for getting me interested in Sapper. As I mentioned in the first section, Tim actually maintains a personal blog site with Sapper at https://timdeschryver.dev/ which is really cool! He’s done a great job of building out custom content generation, and even created his own RSS feed. Tim mentioned Sapper to me when I asked him about different platforms, and after writing a few sample apps I was pretty impressed.
A little history about Sapper …..It’s basically a framework that utilize Server Side Rendering wherever possible. The goal is to make performant applications that use limited resources on the machines that they run on. This is particularly beneficial to mobile devices that don’t have the processing power that traditional computers do. This is particularly useful as more and more things are moving into cloud applications. The size of the downloaded bundle and processing requirements of the browser becomes crucial.
Sapper is also actually a framework powered by SvelteJS. Both frameworks came from Rich Harris from the New York Times. SvelteJS was an effort to utilize server side rendering to boost performance on the browser. Sapper was built on top of SvelteJS as a way to more easily scaffold applications, and utilize the serger side rendering power provided by SvelteJS. Both the main Sapper and SvelteJS documentation sites are pretty solid. SvelteJS even has a basic tutorial that shows you some solid code examples to work from.
Rich Harris also has some YouTube videos and this introductory blog post that cover the technology in greater detail.
The things I liked about Sapper is that it greatly simplified the development experience. You build “svelte” files which are like old school html. You have
<style> and a
<script> built into the file to write any scripts or styling necessary. You also can make use of other libraries by just importing them directly. When you build an application with SvelteJS, you also have a "static" folder where you store images and other files that you want to display. This is all incredibly straightforward, and makes for both an easy and fun development experience.
Sapper and SvelteJS are both topics that you could write entire posts on by themselves. Stay tuned for a future post that goes into both more in depth.
Despite the use of Server Side Rendering, SvelteJS also still supports making rest calls with fetch. There are also multiple lifecycle hooks that you can make use of for events like “onload” etc.
I liked Sapper so much that I built out my professional site andrewevans.dev with it. I also even created an Open Source Post Aggregator function that I use to collect blog posts from the various places I contribute. To checkout my Post Aggregator go to the GitHub repo here.
After building out andrewevans.dev, I then turned my attention to WordPress and the potential of moving my content. I ended up deciding to stay with WordPress and the next section will explain why.
WordPress (the solution)
A lot of times people are faced with choices about going with something new and exciting or just staying with what they have. I’m a big proponent of taking risks for a brighter future, but in this case what I decided to stay where I am.
I’ve been using WordPress for this blog site for a year now. The process of switching would have required me to move content over to a new provider, updating any linked posts and a lot more. Moreover, after considering other platforms I realized I was fairly happy with WordPress. WordPress provides all of what I need, and the process of my search made me appreciate features that I was taking for granted. A subscription with WordPress.com (not .org) provides me with the following:
- Site Backups
- Site Resiliency
- All the basic CMS needs of a blog site
- RSS Feeds
- and a whole lot more!
If I had moved over to one of the other solutions, I would have to built out infrastructure that provides all of these items I just listed. It would’ve turned to be a huge headache.
However, I must say that the other technologies I’ve mentioned are still worthy routes. I just have to say that WordPress worked for me, and the cost of switching was too much for my primary site.
I also want to note that I think WordPress has gotten a bad wrap for being the “non-technical” solution. However, I have to say as a very technical person, WordPress makes my life easy. I know it’d be cool to be able to say that I built my own site completely, but I realized I was happy with what I had. Any of the technologies I’ve listed are worthy options. As I said in the introduction, it all depends on what you want to do.
My search of CMS solutions took me down many avenues. I learned a lot in the process. The search was fairly exhausting, but it provided me with a solid understanding of the technologies that are out there. Moreover, I gained respect for technologies that I hadn’t really been able to get into until now.
“Everything should be made as simple as possible, but not simpler.” -Einstein
This search also made me appreciate the value of keeping things simple. Often times as technical people, we all attempt to find the best solution. This potentially leads us into rabbit holes and deep dives that could’ve been avoided. One of the biggest takeaways I had from this experience was that simple is ok. It is all up to what you want and what you’re comfortable with. We all have a lot of things on our plates, and sometimes it’s really good just to appreciate simple things. The CMS solutions I’ve chosen were not necessarily the fanciest, but I’m content with my choice.
Hope you enjoyed this post. Feel free to leave comments, and please check out some of the links above. Thanks for reading!
Originally published at https://rhythmandbinary.com on June 9, 2019.