5 ms·

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, ha

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

Jestar342 6y ago
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.
nobody0 6y ago
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.
- leetrout 6y ago
  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.
  - tnolet 6y ago
    We run a Hugo site on Vercel. Works fine
  - richeyryan 6y ago
    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 :)
naavis 6y ago
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 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.
- talolard 6y ago
  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
- chrisweekly 6y ago
  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.
  - 6y ago
tootie 6y ago
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.
- madeofpalk 6y ago
  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.
  - tootie 6y ago
    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.
    - thesandlord 6y ago
      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-regeneration https://nextjs.org/blog/next-9-5#stable-incremental-static-r... (edit: whoops this was for the parent comment)
      - madeofpalk 6y ago
        "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.
DrFell 6y ago
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.

Jestar342 6y ago

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.

nobody0 6y ago

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.

leetrout 6y ago
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.
- tnolet 6y ago
  We run a Hugo site on Vercel. Works fine
- richeyryan 6y ago
  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 :)

naavis 6y ago

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 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.

talolard 6y ago
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
chrisweekly 6y ago
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.
- 6y ago

tootie 6y ago

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.

madeofpalk 6y ago
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.
- tootie 6y ago
  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.
  - thesandlord 6y ago
    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-regeneration https://nextjs.org/blog/next-9-5#stable-incremental-static-r... (edit: whoops this was for the parent comment)
    - madeofpalk 6y ago
      "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.

DrFell 6y ago

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.