I strongly disagree that Gatsby is right for even most react projects.
Gatsby is fantastic if your sites main focus is content. Blogs, shops, forums, etc.
But any app that wants to provide a service, or some kind of complicated functionality will require either a lot of hacks on the developer end or poor UX.
Let’s say you were making a todo list with Gatsby where you save TODOs between sessions on a server somewhere. With Gatsby you’d have ur todo page template slug then during every page load you’d need to make a 2nd request (after the initial GET request) to a server to load up that user’s TODOs.
This mean the site would either load initially with no content THEN have the content flash in OR the page renders a spinner initially which is bad UX.
That’s the advantage you get with per request SSR. You can read a cookie at request time then render the whole page, TODOs included.
Honestly since Nextjs added smart static rendering at build time, I don’t really see a great story for using Gatsby unless you’re hooking into another CMS.
I agree with you that Gatsby is good for content-heavy websites. I mentioned in another comment that if your site has primarily private routes (which is what your TODO example would have since it would be user-based) then Gatsby wouldn't be a good choice and an SSR solution would work better.
However, if you have a content-heavy site with some private route functionality needed, then this approach would definitely work. I threw the PAAS idea into my article as a possibility but you'd probably be trying to do too much.
As for the bad UX around the spinner. I'd argue that if you have a Nextjs app, you'll either have a longer load time (initial load) or use something like nprogress (on page change) while the site finishes loading its data, which could also result in a bad UX experience. With Gatsby, you'll be able to, on-page change, also use nprogress or skeleton content loaders. You'd be able to give the same "loading" experience on both Gatsby and Next (without that much hacking, if any).
With both Gatsby and Next, your page change experience will depend on your API performance, network speed, and the effort you put in to indicate something is processing. As with any app/website, the effort you put into your UX will determine the quality, not the framework you use.
I love both Gatsby and Next, and I definitely agree with you that there are a time and place with both. Definitely depends on the type of website you are trying to build.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I strongly disagree that Gatsby is right for even most react projects.
Gatsby is fantastic if your sites main focus is content. Blogs, shops, forums, etc.
But any app that wants to provide a service, or some kind of complicated functionality will require either a lot of hacks on the developer end or poor UX.
Let’s say you were making a todo list with Gatsby where you save TODOs between sessions on a server somewhere. With Gatsby you’d have ur todo page template slug then during every page load you’d need to make a 2nd request (after the initial GET request) to a server to load up that user’s TODOs.
This mean the site would either load initially with no content THEN have the content flash in OR the page renders a spinner initially which is bad UX.
That’s the advantage you get with per request SSR. You can read a cookie at request time then render the whole page, TODOs included.
Honestly since Nextjs added smart static rendering at build time, I don’t really see a great story for using Gatsby unless you’re hooking into another CMS.
I agree with you that Gatsby is good for content-heavy websites. I mentioned in another comment that if your site has primarily private routes (which is what your TODO example would have since it would be user-based) then Gatsby wouldn't be a good choice and an SSR solution would work better.
However, if you have a content-heavy site with some private route functionality needed, then this approach would definitely work. I threw the PAAS idea into my article as a possibility but you'd probably be trying to do too much.
As for the bad UX around the spinner. I'd argue that if you have a Nextjs app, you'll either have a longer load time (initial load) or use something like nprogress (on page change) while the site finishes loading its data, which could also result in a bad UX experience. With Gatsby, you'll be able to, on-page change, also use nprogress or skeleton content loaders. You'd be able to give the same "loading" experience on both Gatsby and Next (without that much hacking, if any).
With both Gatsby and Next, your page change experience will depend on your API performance, network speed, and the effort you put in to indicate something is processing. As with any app/website, the effort you put into your UX will determine the quality, not the framework you use.
I love both Gatsby and Next, and I definitely agree with you that there are a time and place with both. Definitely depends on the type of website you are trying to build.