Next.js or Gatsby – for the end user and SEO | Hacker News Reader

Next.js or Gatsby – for the end user and SEO

9 pointstravltalk3 comments

Hey everyone....so on one hand developers love build speed. But once deployed, it's really about the end user right, and how easy it is for them to discover the content. Does Gatsby offer SEO value. I'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 / interaction and discoverability. 90% of people (UX / marketers / 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'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've overlooked anything here - shout out and tell me, I'm by no means right or wrong, but very interested to hear all opinions on the matter.

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.

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.

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

Could you share the issues with Vercel ?

Reply on news.ycombinator.com