A colleague of mine reached out to me and asked if I could spend a little bit of time blogging about how I created this blog. I told that colleague I would soon, so hopefully they’ll enjoy this.
Aside from being asked by a colleague: I want to talk about what my needs currently are for the blog, the technologies I’m using to create the blog, and why I chose those technologies over competitors.
First things first: this is a blog. It’s a website, not an app, and I knew I didn’t need or want to maintain any kind of app. That helped narrow down my tech search. I wanted this to just be a website that I could post my thoughts and ideas and projects to.
There were things I could have done that would have made the site much more complicated to setup initially, but I could have added more features over time: I could have created some kind of Ruby on Rails application and served my content via a CMS such as Strapi, but there were two major concerns that I had about that:
First thing is that I would have needed to setup and deploy both the website in Rails, as well as a Strapi instance somewhere like Digital Ocean or on Heroku, but for something like a blog there are cheaper options.
The second concern I would have had about that is performance: Rails screams, but only if you have the hardware an infrastructure to help it scale. I didn’t want to worry too much about performance with this, because in the end it’s just a blog, and you could end up paying big with that kind of server side rendering architecture… Or really any kind of rendering for that matter.
I knew that I could achieve better performance through static rendering and generation than I could if I hosted my content on a CMS and loaded that content in for each page hit, and because I know how to write JavaScript (and I like to write JavaScript code), it became pretty clear what I wanted to do: JAMStack it!
In the world of JAMStack, there are many technologies and companies that make it extremely simple to make a website. In fact, on the JAMStack site, there are a ton of options listed here that can help you achieve what you’re wanting to do. I’m not going to talk about all of the options that you have, but I will talk about a few that I did consider:
Next.js is a React framework for building websites, created by Vercel (formerly Zeit), with the aim of being extremely flexible: site pages can be generated statically, they can render dynamically using microservice APIs, it’s easy to add your own microservices into the same code base, and code-splitting is built-in, meaning that your JavaScript isn’t bundled into one big blob, but rather just the JavaScript that each individual page needs.
For pages that are dynamically rendered, Next.js creates a lambda function, which is a huge plus for anyone who wants to create dynamically rendered pages: lambda functions are a great way to keep the costs of deploying a website down, and it doesn’t require a server to be constantly running.
I’m a huge fan of using Next.js to build applications and websites. I would recommend it to a lot of people. However, I didn’t really feel as if I needed all of the power that Next.js had to offer: I don’t have a need to create any microservices, and if I did I can always create and deploy those very easily. If I did feel as if I needed them though, Next.js would be what I would reach for.
One other thing I don’t find particularly convenient about Next.js is the ability to create posts using Markdown: Kendall Strautman made a blog that you can find here on how to setup a Markdown blog using Next.js. I spent a good long while trying to get this to work with NetlifyCMS, but Next.js just isn’t elegant for this because I believe at it’s core it’s trying to solve a completely different use-case: quickly rendering pages through the use of microservice architectures. But like I said, I don’t really need those, I just want to write Markdown and get a site working.
Nuxt is another JavaScript framework that looks to solve many of the same use-cases as Next, but instead of using React it uses Vue.
I don’t really have more experience with Nuxt than I do with Next, but of the experience that I do have, I can tell you that Nuxt’s plugin system is pretty elegant. With Next, there tends to be a lot of webpack configuration you have to go through in order to get things exactly how you want them if you’re deviating from use-cases that Next tries to solve. In my opinion, Nuxt has a lot more intuitive configuration and plugin setup, and there are so many nice conventions in Nuxt that make organizing the source code very easy.
For more complex websites, Nuxt is a great option for those who want more configurability in their site, or for those who just love Vue more than they love React. Nuxt really was a close second for this site.
Gatsby is considered to be the defacto static site generator for React developers by many in the React/JAMStack community. It’s primary goal is to utilize APIs to create static pages. It heavily utilizes GraphQL and plugins curated by the Gatsby community to query data sources and build a site. It’s also very easy to learn if you have a good understanding of React. In fact, much of the groundwork for this website was laid using the tutorial on Gatsby’s website, found here.
The main difference between Nuxt/Next and Gatsby to me is that Gatsby makes it extremely easy to source information from files within a repository in order to build the content, whereas Nuxt/Next make it easy to create small services that can be used to dynamically render pages. To me, this was the simplest and easiest way to create a blog: I wrote posts in Markdown, and Gatsby turns it into a website!
The one caveat about Gatsby, that I think I’m willing to compromise on at the moment, has to deal with build times. Next and Nuxt are both best tailored to load content from REST APIs, which means that your build times are only as long as it takes to build each lambda or static page that your site requires. You sacrifice a small portion of load times to have extremely fast builds.
As of the publishing of this post, there are only a total of 4 blog posts, and as such, Gatsby’s build times are extremely quick. However, with my current implementation, Gatsby won’t be able to scale as I continue to add more and more posts. My builds will start to take longer because Gatsby will have to build every single post as a new page.
However, loading times for statically rendered sites are significantly faster than those backed by services. In this case, I’m willing to sacrifice slower builds to be able to host the same content and have that content be really fast to load.
There are about as many options for hosting as there are for actually generating your site. I already mentioned Digital Ocean and Heroku, but those fit different use-cases than what I was really needing. I didn’t want to have to manage an OS, or hardware resources, or whether or not I wanted my site to be scalable… I just wanted to deploy a website.
There are a few platforms I’m aware of that make this extremely easy to do. I’ll discuss two of them that I didn’t use, and what I ultimately decided to utilize.
Surge is a platform you can use to deploy static sites quickly and easily. It offers a CLI that can be easily installed via NPM, and the free tier is extremely generous in terms of being able build as many projects into Surge as you want. It’s really easy to use.
However, Surge is almost too simple: your website has to be built first in order to deploy it. The project has to be in a pre-built state before being published to the Surge network. This means that if you want to automate deployments when you push to a repo, you’ll need to setup some kind of continuous integration service to take care of getting the CLI and publishing for you. If you’re interested in Surge but you want automated deployments, there should be a guide in the docs on how to set it up with an old favorite of mine, Travis.
Sadly, I did not choose Surge for my deployments and hosting.
Oh boy… I’m sure I’m going to get some flak for this… I’ll admit it: I’ve actually never tried using Netlify. For those of you reading this who love Gatsby, you must think I’m crazy. You might be right.
Netlify is a big favorite amongst many in the JAMStack community, and it’s not hard to understand why: Netlify deploys sites to a super fast CDN, and is capable of deploying static pages, as well as lambdas. It’s a really great choice for anyone who is creating a website with Nuxt, Next, Gatsby… Really, any static site generator.
Netlify also has an easy-to-integrate CMS aptly named Netlify CMS. The way that Netlify CMS works is that the data is actually all hosted in GitLab or GitHub, and Netlify CMS will load posts from those sources. Then, when a post is edited or added, those updates will be pushed to the repository from Netlify CMS on your behalf, and can be stored as JSON, Markdown, whatever is supported.
This is Gatsby’s strong suit: since the data that Gatsby uses to generate all of the pages is held within the repo itself, it’s possible to easily add Netlify CMS to any Gatsby site.
Netlify, Netlify CMS, and Gatsby, would all be extremely attractive options if you wanted to create a website for practically no money down, and you wanted multiple people to be able to contribute to it, or if you wanted people who were not engineers to be able to contribute without having to understand Markdown or code. Couple that with things that developers care about, like Git integration and built-in site generation and deployments, and you have a match made in heaven.
… Or at least for other people. Not necessarily for me. There’s another platform I’ve been using for quite some time now that I just can’t stop using.
Vercel (Zeit) is a company that you may or may not have heard about: I don’t think they get nearly the amount of praise that Netlify does or the kind of attention that Netlify typically does, but they are just as good as Netlify for building and deploying sites. The company itself owns a lot of really neat open-source software that you may already be using, such as the Hyper terminal emulator, and they’re also the minds behind Next.js, Mongoose… My main point is that they do a lot of really neat stuff.
There are so many great things about Vercel that make it an excellent platform for developers: a free pricing tier that allows you to deploy all kinds of projects is just the start. Actually, fun fact about Vercel: as of the writing of this article, ALL personal accounts are FREE, meaning you don’t have to pay anything to deploy your personal projects. Accounts only become paid if they are team accounts, where you want multiple contributors to join your project.
Next are the different features: full integration with GitLab, GitHub, and Bitbucket, easy to use integrations to other sites through their integrations marketplace, but probably my favorite feature of all is the CLI.
With the Vercel CLI, it’s possible to take advantage of all the power Vercel has to offer right at your fingertips. You can buy a domain name, manage DNS records for your domains, deploy a node project straight to the Vercel platform (regardless of whether or not it’s stored in a Git repository), manage deployments… Literally anything you would normally want to manage through a web client, you can do on the command line. You never have to leave your development environment to manage your projects in production. Like Surge and Netlify, Vercel will also deploy your site with every push, can can create vanity URLs on it’s platform for every Git branch you create.
For me, having used Vercel for many years, this wasn’t a difficult decision to make.
And that’s all she wrote! These are the decisions that lead me to develop my website the way you’re currently experiencing it. Hopefully these insights and thoughts that I’ve expressed have perhaps inspired you to consider creating your own blog, or experimenting with creating any kind of static website. Like I said before: there’s not much risk involved with using these platforms. It’s very easy, and almost always free, to create and experiment with different technologies and ways of creating websites. If you have any questions, please reach out to me on social media! You can find links below. I’d be happy to answer your questions or hear your feedback. Thanks for reading!