I migrated my homepage from GatsbyJS to Next.js

Thoughts

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

	GatsbyJS	Next.js	Description(GatsbyJS)	Description(Next.js)
ease of creating blogs and documentation websites	◎	×	Framework created for Static sites in the first place.	by getInitialProps only
i18n(multilingual support)	○	×	Community plugins make it easy	No support for path-based multilingualism, and can be created in a nutshell using react-intl
Automatic image processing	◎	×	Supported by gatsby-image	no way
Speed of site	◎	△	Fast because of static html	Has next export, but basically requires SSR
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 learn next website

Comparison now

	GatsbyJS	Next.js	Description(GatsbyJS)	Description(Next.js)
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 getStaticPaths, getStaticProps with wonderful on-demand ISR
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

Finally

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!