3 ms·

Gatsby vs. NextJS

11 points by tomduncalf 6y ago

eyelidlessness 6y ago
I’ve been a full stack dev for about a decade. Well, kinda. I started primarily on the frontend, then gradually took on more and more backend responsibilities (and interests), until I hadn’t done any frontend work for several years. That transition began right around the time that React (and similar libraries) really started to take off. I came to very much like the general philosophy of React, but very seldom worked with it. Until earlier this year, when I decided to build a documentation site for a library I had built. So I looked around to see what the state of the art was. I knew I wanted to build a static site. After eliminating a variety of other options that didn’t suit my needs or preferences, the two technologies that stood out were Gatsby and Next.js. Gatsby, at the time, seemed to have a bit more momentum, so I tried it out first. It’s been several months, so I don’t recall many of the particulars, but the DX was awful. It took me very little time to determine that I would not enjoy working with Gatsby, particularly over the long term. So I tried Next.js. And my experience was pretty much the opposite! The defaults were sane, I was able to get productive immediately, and overriding defaults to support a fairly unusual set of requirements and preferences was almost always trivial. Where I had to interact with some of the more complex underlying technologies (why even is webpack???), I was always able to find examples of what I wanted to achieve... and they were always clear and correct! Since that time, I’ve followed Next.js releases, and while I haven’t yet had another web project this year, I’ve continually been impressed with its progress. I likely have another web project coming up pretty soon, and I have no doubt that I can skip the “pick a technology” research phase.
- eyelidlessness 6y ago
  Somewhat tangentially, if you’re starting a new project with either, and you intend to use TypeScript, and you suspect you may want to swap out React for something roughly API compatible (e.g. Preact), I highly recommend exploring that early on in the project. While Preact is largely API compatible, their respective static types are much less compatible than I would have expected.
  - tomduncalf 6y ago
    Out of interest, what was your reason for doing so? I’ve done a lot of React projects and only once tried Preact, several years ago when we hit some performance issues IIRC (it didn’t help).
    - eyelidlessness 6y ago
      Out of sheer morbid curiosity about how far I could go with optimization. Preact was to be the first step, but the eventual goal was to try to use static analysis to only mount dynamic runtime code that had potential for state change, and make the rest truly static. For the site in question, everything except a hamburger menu could have been reduced to HTML and never touched by any DOM code, and it felt bonkers to ship the same content as JSX. It’s been a while so I don’t remember if Preact was part of that effort or just a separate optimization step that seemed like it should be low hanging fruit.
- tomduncalf 6y ago
  Yep, agreed. NextJS would be my go to for any new site. I found it very logical and pleasant to work with. As you say, Gatsby felt much more fiddly and I feel the end result with Next is better

11 points by tomduncalf 6y ago

I’ve been a full stack dev for about a decade. Well, kinda. I started primarily on the frontend, then gradually took on more and more backend responsibilities (and interests), until I hadn’t done any frontend work for several years. That transition began right around the time that React (and similar libraries) really started to take off. I came to very much like the general philosophy of React, but very seldom worked with it. Until earlier this year, when I decided to build a documentation site for a library I had built. So I looked around to see what the state of the art was. I knew I wanted to build a static site. After eliminating a variety of other options that didn’t suit my needs or preferences, the two technologies that stood out were Gatsby and Next.js. Gatsby, at the time, seemed to have a bit more momentum, so I tried it out first. It’s been several months, so I don’t recall many of the particulars, but the DX was awful. It took me very little time to determine that I would not enjoy working with Gatsby, particularly over the long term. So I tried Next.js. And my experience was pretty much the opposite! The defaults were sane, I was able to get productive immediately, and overriding defaults to support a fairly unusual set of requirements and preferences was almost always trivial. Where I had to interact with some of the more complex underlying technologies (why even is webpack???), I was always able to find examples of what I wanted to achieve... and they were always clear and correct! Since that time, I’ve followed Next.js releases, and while I haven’t yet had another web project this year, I’ve continually been impressed with its progress. I likely have another web project coming up pretty soon, and I have no doubt that I can skip the “pick a technology” research phase.

eyelidlessness 6y ago
Somewhat tangentially, if you’re starting a new project with either, and you intend to use TypeScript, and you suspect you may want to swap out React for something roughly API compatible (e.g. Preact), I highly recommend exploring that early on in the project. While Preact is largely API compatible, their respective static types are much less compatible than I would have expected.
- tomduncalf 6y ago
  Out of interest, what was your reason for doing so? I’ve done a lot of React projects and only once tried Preact, several years ago when we hit some performance issues IIRC (it didn’t help).
  - eyelidlessness 6y ago
    Out of sheer morbid curiosity about how far I could go with optimization. Preact was to be the first step, but the eventual goal was to try to use static analysis to only mount dynamic runtime code that had potential for state change, and make the rest truly static. For the site in question, everything except a hamburger menu could have been reduced to HTML and never touched by any DOM code, and it felt bonkers to ship the same content as JSX. It’s been a while so I don’t remember if Preact was part of that effort or just a separate optimization step that seemed like it should be low hanging fruit.
tomduncalf 6y ago
Yep, agreed. NextJS would be my go to for any new site. I found it very logical and pleasant to work with. As you say, Gatsby felt much more fiddly and I feel the end result with Next is better