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

My first web development experience started with PHP and MySQL and transformed into .NET during university studies. I really liked the type safety, MVC model, and debugging possibilities. Thatʼs right, no more echos, “Iʼm here.” I kept working with .NET during my development and consulting jobs but slowly transferred into JavaScript with early versions of Angular.

About two years ago, I almost fully converted to Jamstack. I chose to get familiar with Vue.js as it felt like the most friendly among JavaScript frameworks. I built my personal site using Nuxt.js, a static site generator that is now called the intuitive Vue.js framework. When I finished it, my colleagues at DevRel were just releasing the first version of a source plugin for Gatsby, an SSG or web framework for React. So I used it for the next project, which was Kentico Advantage, a simple site supporting web agencies. That was my first experience with React, and I hated it. It was so complicated to do just tiny bits of functionality.

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.

Then Sourcebit came. Itʼs a plugin between a headless CMS and an SSG that normalizes data so that switching between CMSs and SSGs is easier. The only JavaScript related supported SSG was Next.js, so I learned the basics and used it also for one other project.

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 mentioned three JavaScript frameworks, but Jamstack is not always Javascript. You might feel closer to PHP or Ruby. Check out the list below to find the right SSG for you.

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

Vue.js is known and famous for its stellar documentation. Gridsome follows the same path. The documentation is very clean and contains exactly what you are looking for as a beginner. Really. It felt like it was reading my mind. It uses GraphQL, so your data source needs to be connected via a special plugin. Gridsome automatically connects your data models with templates of the same name and also handles routing, which is handy for beginners. Apart from Nuxt.js, it allows you to use your own external JavaScripts. I know itʼs not the best practice, but if you download a template from a site like HTML5UP.net, it comes with some JS functionality. Nuxt.js was giving me a hard time with this, and I ended up rewriting the functionality in Vue.

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.

Gridsome	Nuxt.js
+ 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.

Gatsby	Next.js
+ 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

My choice

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 :-)