Picking Gatsby as a static site generator
Introduction
First things first, I'm not judging neither the Gatsby team nor the React team, this article is all about my opinions over the past year on whether you should use something like Gatsby or not, depending on different occasions and under contrasting circumstances. I am a huge fan of the React ecosystem and a React developer since 2016, however I often cheated on React when I developed apps in Angular, but this has nothing to do with this article, since this article is focused on static site generators (E.g Jekyll, Hugo, Gatsby). By the end of this article, I hope that you will be able to know how to build your personal website / blog using the right tools and methods that suit your needs.
Static site generators
In the end of the day, everything on the web is pure JavaScript, cascading style sheets and of course markup (HTML). In theory, if you write your entire application not using any framework at all, it is completely ok and pretty straightforward, so why people use static site generators? In order to see why people use it, we first have to understand what a static site generator does. In the 'modern' world of web development, the JAM stack (Javascript APIs Markup) is a huge buzzword with a tremendously large community across the world, however there is no 'best' tech to create a website or blog. So when people talk about JAM stack, they mean static site generation which usually (I could say always) comes with a prefered JavaScript framework, like React or Vue.
How static site generators work
What is the web? Back in the day when developers delivered applications with FTP, the networking model was fairly simple, the server shows whatever file you uploaded (usually prefers index.html) and the client asks for that specific file. My point here is that, files are static, it's not dynamic or something and they only change when you upload other files and overwrite them. Static site generators, are not here to change this hierarchy, they don't magically change files on the web, they generate them 'locally', and in order to generate, they use serverside logic (preferably Node.js). So the build pipeline is as follows
- Write source code (React, Vue, Vanilla JS)
- Add data (Markdown, XML, YAML, JSON, Third party APIs)
- Build (Generate HTML, CSS, JS)
- Deploy (Deploy static files to the web host)
Why not to use a static site generator
1. Requires by far more time than using a CMS
Using something like Wordpress or Drupal can really make the whole development phase faster, but the thing with SSG is that it can be seriously tweaked whereas CMS is partially standardized. If the budget does not allow to fine-tune stuff, go for a CMS.
2. Many options on the web can easily overwhelm you
Taking a quick look on the web about static site generators, you may see that they are endless. There is far more than one for every programming language, yet they all do the same thing. It is really easy to get overwhelmed by all modern tools, so pick what works for you or your team without worrying about if it's new or trendy or shiny. You must worry about documentation though, this is a vital step towards building something great, always go with the tools that have plenty of well written documentation.
3. No administration interface
There is no admin panel for such apps, and there is no point to be. People using SSGs also use a data-source where they manage their data (Headless CMS, Wordpress) but those data cannot be changed in real-time. When the data changes, a new build pipeline executes which rebuilds the whole project to static files.
4. You can't easily manage large sites
Imagine running the famous CNN news website with an SSG, where new articles come up every hour or more frequently. The data archive of their website contains thousands of posts and increases continuously. The JAM stack would be a terrible solution to this problem, since building all those posts to static sites can be highly time and resource consuming. Regardless of what I just said, there are plenty of large sites built on the JAM stack and seem to be working pretty well with lots of data, so it's not impossible.
5. No server-side logic (Can be solved with serverless architecture)
I'm not talking about SSR, im talking about serverside computation. For example, PHP is a serverside language which manages connections to databases and executes proper cloud computation tasks before delivering data to the end user. Static files cannot do that, they are.. static 😛, however you can use mircoservices with something like Amazon Lambda, Netlify's functions or Firebase functions to perform these kind of tasks. Most of the companies that sell "serverless" computing services are often free and easy to use.
Why should you use a static site generator
1. Security
There are only static files on our server, so there’s nothing dynamic to be exploited. It’s still possible to access the server if a hacker can find a vulnerability in the web server but the risk is greatly reduced.
2. Reliability
There is no chance that in the middle of the night, a slack message saying that the server is down will come up. You can't blame the back-end anymore since there is none.
3. Speed
SSR is a game changer when it comes to speed and SEO. There is no database involved and load speeds are faster.
4. Price (Cheap on shared web hosting services)
I literally pay nothing for this website, static file hosting is not just cheap.. its free! In some cases it's not free, but most of the times it is.
5. SEO
Search engines can crawl the whole site for better SEO.
Why did I pick Gatsby?
Gatsby is my preferred static site generator since it makes me productive, it uses React and has a huge community that creates awesome things like plugins and add-ons. The Gatsby people say this
Gatsby’s rich data plugin ecosystem lets you build sites with the data you want — from one or many sources: Pull data from headless CMSs, SaaS services, APIs, databases, your file system, and more directly into your pages using GraphQL.
So it basically follows the same strategy like every static site generator, with a difference that provides data with GraphQL directly to your components. There is a huge hype on GraphQL and everybody talks about it, however it doesn't make your website faster. I've seen people talk about using GraphQL and how cool it is, but in this case, it's not a performance game. Don't get me wrong, GraphQL on the server is insanely great, and has a big list of performance and flexibility boosts, but this is the client, not the server. Practically, you write GraphQL queries on every component you need to display data relying on the data sources I mentioned earlier. The data is pushed during the build time to the pages and not during runtime, so Gatsby does the heavy lifting for you by changing your GraphQL queries into actual data.
Should you pick Gatsby?
Considering they raised $3.8M seed for their newly established startup, yeah you should!
Now lets count lines of code for this website (jimfilippou.space) using Loc.
loc
Output
--------------------------------------------------------------------------------
Language Files Lines Blank Comment Code
--------------------------------------------------------------------------------
JavaScript 18 910 52 27 831
Markdown 6 526 136 0 390
JSON 5 218 0 0 218
Sass 7 212 22 0 190
YAML 1 3 0 0 3
--------------------------------------------------------------------------------
Total 37 1869 210 27 1632
--------------------------------------------------------------------------------
As seen, there are 910 lines of JavaScript for just a website which is really too much, and most of the times out of scope. I have spent a lot of hours on maintaining and keeping this codebase up to date with the latest and greatest libraries to run smoothly, and in some cases this is unacceptable. If your goal is to produce content fast without the front-end hustle, then don't use Gatsby, it will devour your time and you could use this time to produce actual content. Considering you are a front-end Developer, using Gatsby for your blog is a good idea for lots of reasons, like using latest tech with cool animations and tools that might impress possible future recruiters. Recruiters are more likely to pick a person who has built something good rather somebody who just sends a PDF CV document, so take a second and think what to build next!
Conclusion
Remember, in the end of the day, time is a valuable asset so spend it wisely.