When we are considering which framework to use for new web projects, we tend to prefer the tools we know regardless of how suitable they are. So I tried the opposite. With every new opportunity, I tried a new technology. What did I learn throughout this experiment, and why is Next.js my default choice of SSG now?
Ondrej PolesnyUpdated on Mar 27, 2023Published on Sep 8, 2020
In this article, Iʼll show you my journey over the various web technologies and my experience with them. Iʼll share my way into Jamstack, explain how to choose the right tool suitable for you and your project, and why it is Next.js for me.
Where I am coming from
The next project was my own wedding site. I gave Gatsby and React another chance only to end up with Gridsome two days later. At that time, Gridsome was just gaining popularity and I was stumbling upon it everywhere. I was able to get the base site up and running in three hours. I was amazed. More points for Vue.js.
How do you choose the right Jamstack tool?
The mentioned tools are the ones I used the most during my last two years. As always, there is no clear winner among them.
Letʼs say youʼre a developer, and youʼre responsible for selecting the right tool for your next project. Maybe your team depends on your choice, so itʼs not like you can afford to play around with many of them.
Choose based on experience
Choose based on experience, but not only your experience. If you worked with Angular in the past, you probably want to start looking at tools for Angular first. If that was too long ago, ask your colleagues what theyʼre working with. I didnʼt do that and chose Vue.js right away. The problem was that all of my colleagues were working with React, so I ended up googling every issue on my own.
The other aspect is the size of your project. If youʼre building a personal site as a proof of concept, your Google queries will be simple and mostly lead to the respective platformʼs docs. On the other side, building a corporate site with incremental builds, partly server-side rendered, and using multiple data sources—you will need help from your colleagues or the community.
I canʼt speak for the platforms I havenʼt tried yet, but I can share my views on Vue.js and React and their respective static site generators.
Vue.js—Gridsome vs. Nuxt.js
Overall, with Gridsome, I had a feeling that I could breathe, that the framework was helping me achieve the functionality, not that I needed to deal with any obstacles of the platform. You can get a simple website up and running in hours.
My biggest struggle with Nuxt was to understand and implement a Vuex.store. Itʼs used as data storage. If components need to get or manipulate data, they use this single place. You can, of course, handle data operations at the component level, but components often share data sets, so you want to avoid code duplication. To implement the data store, you donʼt need any special plugins gathering data from your content repository. I used one for Kontent.ai, which definitely made things easier, but I could have just as easily used simple Fetch API with Delivery SDK. As soon as I got it working, I actually enjoyed this pattern. Itʼs robust and flexible, and Iʼd prefer it for larger projects. It just requires time investment at the start.
Nuxt also supports server-side rendering, preview mode, and has a larger community, all of which makes it more mature than Gridsome and, overall, a better choice for serious projects.
|+ great documentation||+ flexible|
|+ easy to use||+ mature and more robust|
|+ uses GraphQL||+ larger community|
|+ allows easy integration of external JS code||+ server-side rendering possibility|
|- needs data source plugin||+ preview mode|
|- sometimes “smarter” than youʼd expect||- steep learning curve compared to Gridsome|
React—Gatsby vs. Next.js
Letʼs start with Gatsby and, in my opinion, the best feature of all, GraphiQL explorer. Gatsby uses GraphQL, and the explorer allows you to browse through the data that is made available to your website. I canʼt emphasize enough how much this helps. It saves you from reading any documentation of your data source. Just click through the data, select what you need, and copy-paste the generated GraphQL query into your components.
GraphQL also means that your data source needs to have a source-plugin integration with Gatsby. All major headless CMSs feature this integration, though. Another great benefit is the plugin ecosystem. Anything you may need, there is a plugin for it—from SEO through progressive image loading to exporting GraphQL schema.
Next.js, on the other hand, lacks a standardized way of getting data. You need to invest some time into figuring out which way works the best for you. I took inspiration from this repository and used the repository pattern. If you can live without GraphQL, Next.js will do everything Gatsby does and more.
It has a routing model based on filenames, which makes it super easy to find pages and templates even if youʼre not familiar with the project. It allows you to combine static and dynamically generated pages and even use both methods on a single page. That helps a lot with preview functionality. Both Gatsby and Next.js feature incremental builds, but with Gatsby, you have to host the site on Gatsby Cloud that is available only to first-class plugins. They now have a free tier too, but youʼre still locked in with a single provider. Next.js supports any Node hosting and turning on incremental builds in a one-liner.
Next.js also produces a smaller release bundle than Gatsby. In my experience, solving issues and getting help from the communities is comparable.
|+ uses GraphQL||+ straightforward routing model based on filenames|
|+ GraphiQL explorer||+ universal preview mode|
|+ lots of plugins||+ possibility to combine static and dynamic pages|
|- lacks true server-side rendering||+ produces smaller output|
|- incremental builds and previews tied to Gatsby Cloud||- no standardized way of getting data - need to figure out a way to get data the right way|
|- Gatsby schema and build caching often cause cache issues|
Other aspects of your chosen platform
When considering which tool to use for web projects, we often say, “Docs are good,” “lots of people talk about it on Twitter,” “it gets frequent releases,” “it has lots of plugins,” and it ends there. If youʼre locking yourself with a platform for a longer time, and you think it will be used for more than one project and might even become one of your company-wide recommended tools, try to also check:
- How long the toolʼs around and what is its history
- If people have issues with scaling large sites
- Which integrations to other services are available
- Whether itʼs possible to migrate your implementation to another tool if necessary
- Who is the owner and how they decide on future plans
- Which features require paid services
When we talk about platforms, I prefer to use Vue.js whenever I can. I find it easy and quick-to-use without any configuration. The typical use cases are custom elements, traditional website components that need dynamic front-end functionalities, and small sites. And because I donʼt use Vue.js for larger projects, I tend to use Gridsome.
For larger and serious projects, I choose React. Kentico is doing almost all front-end development in React, and it will continue with that trend in the future, so it only seemed logical to do the same myself. Regarding the static site generator choice, I am currently using both but slightly inclined to Next.js over Gatsby. The top feature for me is the file-based routing that also supports dynamic routes and compatibility with Sourcebit, which allows me to switch the data source or SSG any way I want in the future without reimplementing everything from scratch.
If you are reading this, let me know what your Jamstack choice is. On Twitter. Thanks :-)