
Next.js or Gatsby – for the end user and SEO - travltalk
Hey everyone....so on one hand developers love build speed. But once deployed, it&#x27;s really about the end user right, and how easy it is for them to discover the content. Does Gatsby offer SEO value. I&#x27;m trying to research but seem to arrive at the same place each time. We have initially decided to use Next.js for our shift from Wordpress to our own server rendered sites (also moving from Vercel to AWS this week for security reasons). But Gatsby keeps popping up. Sure Next.js is good for routing, and again favours developers. But is the web built for development ease or user happiness &#x2F; interaction and discoverability. 90% of people (UX &#x2F; marketers &#x2F; investors and non developers would say the latter). Therefore are the wins you get with Next.js when setting up routing, which should be a one time only thing anyway, little benefit when compared to Gatsby and the ease of updating content and the part I still don&#x27;t get enough info on - does the SSR from Next.js overall help with SEO or can the same be obtained from Gatsby? If I&#x27;ve overlooked anything here - shout out and tell me, I&#x27;m by no means right or wrong, but very interested to hear all opinions on the matter.
======
WnZ39p0Dgydaz1
I recently built a project in both Gatsby and NextJS. Or rather, I built it in
Gatsby due to the hype and then threw away everything to do it again in
NextJS. I would highly recommend going with NextJS.

Fundamentally, they are both very similar if you use them for static site
generation (NextJS also supports SSR, but that's a different story). The main
difference is Gatsby's data layer, which allows GraphQL queries to integrate
all kinds of sources. Gatsby's data model is quite complex, with all kinds of
GraphQL node creation callbacks, schema inference, non-determinism when it
comes to ordering, etc. If you do something custom you're going to spend most
of your time learning the ins and outs of (ugly) Gatsby internals and
debugging edge cases as opposed to working on your application-specific logic.
It's like crawling through 4 layers of abstractions to get a simple job done,
over and over again. Look at how large the docs are - it's not only because
the documentation is good - it's because there are so many complexities to
consider. And most of the issues are not even discussed in the docs.

NextJS is on the opposite end. It's incredibly simple and straightforward.
Yes, it does less out of the box, and I had to re-implement some of the logic
that Gatsby already provides, but that amounted to a few hundred lines of
application-specific code, like sourcing files from a local folder. I would
rather maintain these few hundred lines than being locked into some overly
complex framework that constantly changes.

Any new developer would immediately understand the Next.js code, perhaps after
walking through the hour-long NextJS tutorial. A new developer would need days
to understand the multiple Gatsby layers and their integrations and
idiosyncrasies. I'd pick simplicity.

One use case where Gatsby would shine if there is a plugin or data sources
that already does __exactly __what you need. But I found the plugin ecosystem
isn 't that great either - it's mostly small stuff from the developers behind
gatsby, not contributed by the community.

I really don't understand the hype behind Gatsby. To me NextJS seemed superior
in almost every way.

------
ShaneCurran
I think it really depends on what specifically you're building.

If your app has a lot of user interaction, needs some kind of state and has a
lot of bespoke functionality then I'd lean towards Next.js.

I've worked with Gatsby in the past and have great experiences, especially for
things like developer documentation, blogs and anything with a lot of static
content. If that's what you're optimizing for then Gatsby is your best bet
IMO.

Re: security — if your app is stateless, I think the attack surface is
reasonably small assuming your production codebase and host is secured. The
headless CMS you pick is going to be the most important thing to protect. Data
breaches, CSRF and session hijacking are going to be less significant in this
case.

I think the most important thing to keep in mind is that the experience your
users enjoy and see is almost certainly not going to be _just_ as a result of
the framework you pick. No matter which framework you use, the way you craft
designs, layouts and experiences is the most important thing.

------
samblr
>> also moving from Vercel to AWS this week for security reasons

Could you share the issues with Vercel ?

