Three and a half years ago, the Next.js maintainers were not very friendly and helpful to community. Documentation was not extensive too. If you had a problem, you had to find out the answer from the source code. On top of that, Next.js does SSR (server-side rendering) by default, but many libraries did not support that which caused serious FOUC (Flash of unstyled content) problems. The famous material-ui didn’t work well with Next.js in those days. So I created a library to solve this problem. https://github.com/thundermiracle/next-mui-helper
That’s when I met GatsbyJS with Jamstack, GraphQL, a nicely documentation site, tons of starter projects, a plugin eco system that is very easy to implement, Gatsby image even handling responsive images automatically. It was very attractive. By the way, React.js Documentation and creator of Redux Dan’s blog are also made with GatsbyJS.
However, time has changed. While it is said that Next.js is often ‘stealing’ excellent ideas, but yes, it is much more popular and easier to use nowadays. Unfortunately, I can’t really recommend studying GatsbyJS to those who want to enter the React eco system now.
I’ve migrated my homepage from GatsbyJS to Next.js. GatsbyJS was the top of the SSG frameworks in my opinion, even with Next.js, but time flies, everything changed a lot. I’d like to share my thoughts about GatsbyJS and Next.js in past and now.
Comparison three and a half years ago
|ease of creating blogs and documentation websites||◎||×||Framework created for Static sites in the first place.||by
|i18n(multilingual support)||○||×||Community plugins make it easy||No support for path-based multilingualism, and can be created in a nutshell using
|Automatic image processing||◎||×||Supported by gatsby-image||no way|
|Speed of site||◎||△||Fast because of static html||Has
|Ease of deployment||◎||△||Easy to deploy||Because of SSR, now(became to Vercel) is required|
|Difficulty of learning||△||△||difficult for those not familiar with GraphQL||Easy to learn first but hell to deal with SSRs|
|Kindness to the community||◎||×||Friendly, answers questions well||Issues that are unanswered and just CLOSED are noticeable|
|Documentation||◎||×||Clean and tidy||Only README.md with a
|ease of creating blogs and documentation websites||○||◎||The STATIC part remains the same as before, but the more pages you have, the longer the build time||new IF
|i18n(multilingual support)||○||◎||Community plugins make it easy||Official support|
|Automatic image processing||○||◎||the same as before, but the more images you have, the longer the build time||next/image is excellent|
|Speed of site||◎||◎||Fast because of static html||SSR, but it has improved a lot|
|Ease of deployment||◎||○||Easy to deploy||Edge Function and Serverless Function are becoming more popular make Next.js easier to deploy|
|Difficulty of learning||△||○||difficult for those not familiar with GraphQL||A lot of sample of SSRs, not difficult anymore|
|Kindness to the community||○||○||The decision to exclude Community Starter from the documentation site was a real bad decision||It changed to be so kind because it became a Vercel project|
|Documentation||◎||◎||Clean and tidy||Clean and tidy with large numbers of examples, really easy to catch-up|
|Support of pnpm||△||◎||Community-based plugin that doesn’t work well||Official support|
Apart from that, Next.js has ‘pirated’ Layouts RFC from Remix, added Turborepo for monorepo, and announced the amazing bundling tool Turbopack, which is a competitor to Webpack. Three years ago, Next.js, GatsbyJS and create-react-app against each other, but in future, it may be inevitable that Next.js will be the dominant player.
Thanks, GatsbyJS. ByeBye!