Hacker News Reader

Comment by talolard | Hacker News Reader

Poor Gatsby. We run a Gatsby site, it was great to setup fast fast fast and has been a pain in the butt ever since.

Next, from our limited experimentation, has much better ergonomics and it looks like the company has a stronger grasp on go to market.

Crazy how fast that happened

View on HN

Could you describe what kind of pain points have you had? I've been building a photo-intensive static personal website lately. I started off with Next.js, but later switched to Gatsby, because so many things just worked out-of-the-box with it. This was especially the case with optimizing and resizing images.

For Gatsby there is gatsby-image, which works super well. For Next.js there is next-optimized-images which is not very mature. The latest version of Next.js also provides next/image, but as far as I have understood, it requires you to run the Next.js backend server, so it is not an option for 100% static websites.

https://nextjs.org/docs/basic-features/image-optimization

> Instead of optimizing images at build time, Next.js optimizes images on-demand, as users request them. Unlike static site generators and static-only solutions, your build times aren't increased, whether shipping 10 images or 10 million images.

Sometimes I also bumped into issues with Next.js where the framework was trying to send some code to run on the client browser instead of running it during page generation. The division between server and client seemed a bit too hazy for my taste and felt magical in the wrong ways.

Yeah, Gatsby-image was what drew us into the platform to begin with. That's what made it fast to get started.

I found the plugin system confusing, and poorly documented so it was hard to know how to get the most out of a plugin and adjust it to whatever our own funny use case was.

The graphql thing was annoying, we don't use graphql and don't know it and didn't find any advantage in having it around.

It's been a while since I touched it, but every time I need to a put it off because it's not a nice env to work in compared to our "from scratch" react apps

NextJS supports export for 100% static site generation (like Gatsby). Unlike Gatsby, it _also_ supports a server runtime and SSR, and everything in between. Its magic is the good kind that decomposes into sane primitives. Respectfully, it sounds like you might have needed to spend a little more time with the docs.

It does support static site generation, which I was using it for, but for example next/image requires the backend API server. The case I was referring to was such that defining the exact same function in a component file behaved differently than in a page file, I think. In one case the build failed if I remember correctly, because it was trying to build client-side code but the code referred Node.js stuff.

No need to be aggressive. I don't have anything against Next, I just felt much more comfortable with Gatsby.

Parent explicitly mentioned next/image, which is not supported by next export static site generation.

The common complaint about Gatsby is that it's slow. Once you reach a certain scale of records you're ingesting from Contentful or wherever, Gatsby really starts to chug down trying to infer all their types for GraphQL (I believe this is what causes the slow down).

Gatsby is a weird platform. It's gotten absolutely humongous for a product that is designed to only solve the simplest problems. Netlify has taken it to it's limit by adding redirects and lambdas. But it's still a platform for fancy brochures and blogs.

I agree with this weird mismatch of overcomplexity for the problem it's trying to solve. I did really like though the Gatsby model of ingesting all your source data into GraphQL and then having a standardised way to query and build pages from this. I wish Next.js would learn something from this.

I was using Next.js to build a staticly-generated website (so within the remit of Gatsby) but eventually i outgrew the limitations of static site generation (23k pages and counting...) it was so easy to switch to a traditional server-generated model with Next.js. I'm incredibly greatful for picking up and sticking with Next.js for this.

I think for any commercial site, it's likely cheaper to use a platform like next or nuxt and a CDN rather than choking your build pipeline with static generation. You still get static performance and just offload it to an edge network and CDN costs are racing downwards.

No need to do static generation at build time or fully server-side rendering with Next.js either, you can build static pages at runtime with ISR

https://nextjs.org/blog/next-9-5#stable-incremental-static-r...

(edit: whoops this was for the parent comment)

"incremental static rendering" is... server-side rendering, at least that's what I meant. Rendering pages on demand for users as they request them, with (optional) invalidation to render it again later.

That feels like the React community in a nutshell.

Seems like any developer who isn't able to think critically about the decisions they make.

Can relate, next.js is more progressive while Gatsby get things done so quick at first, but you find yourself in a dark room of settings, let along GraphQL.

This happened to me. And the graphql proponents that know gql love it but it’s so slow to build.

I love Hugo and I wish there was a middle ground that was more approachable. I might have to try next.

We run a Hugo site on Vercel. Works fine

I setup my personal blog recently. Tried Gatsby and decided I didn't want to spend the time tweaking it so just used Hugo. Ended up deploying it on Vercel and its been so easy. I have less excuses for not writing blog posts now :)

Vercel also supports Gatsby deployments. Well, they have an option when setting up the repo integration at least.

My team has just started a Next.js app. I chose Next.js over Gatsby because on the face of it, Gatsby looked like a lot more configuration. I fully expect we'll "disagree" with Next.js at some point but for now I am really liking that it is opinionated, as it it letting us build really quickly.

The whole JavaScript SSR/SSG/hybrid app scene is changing too fast to be driven by anything more substantive than trendiness. Reminds me of dot com hysteria.

Reply on news.ycombinator.com