AFAIK, the thing that sets Gatsby apart is the integration of the built static site and React to do pre-fetching. The output from Gatsby is not just HTML, it's HTML + React javascript, with data loaded from JSON files. That means that once the site has loaded, Gatsby can pre-emptively fetch all the linked pages, both React components and data, to give instantaneous second click page loads. That's a pretty impressive feature in the wild, the second click is neck snappingly fast. I'm not sure if this is an option in other things like nuxtjs or not.
But, you're right that Gatsby requires a lot of code. To get a simple static site setup, it's a lot of work. Plus it changes very fast. We stopped paying attention for a few months, and things broke on the next upgrade.
But, if web performance is the goal, Gatsby is hard to beat. In addition to pre-fetching, it also inlines every resource, images, CSS, the whole thing. So a single HTML fetch should be enough for a full first paint. That's a lot faster than a usual static site, which in turn loads all the additional resources before it can show the site to the user.
> Nextjs does the same thing. That's not a business model.
A business model doesn't need to be unique in order to be successful. Also Gatsby is open source, so I wouldn't expect to find profits falling out of the core library. They make their money through consulting and cloud ops.
> adds complexity that wastes developer time
Every framework comes with its own flavor of complexity. To blanket say that Gatsby wastes time ignores the real benefits it provides and the opportunity cost of getting those benefits through some other library (or even more daunting, writing and maintaining a homegrown framework).
If web performance matters to you or your business then effort focused in that direction is not a waste. The complexity of learning/developing with Gatsby/Next is significantly lower than getting those benefits without them.
It's also just plain fun to use, IMO. I built a site using Gatsby for a product I'm helping with (https://greeter.ai/) and it was a really fun and enjoyable experience. The site is blazing fast. The ease of React integration, Node modules, Gatsby plugins, etc., further add to developer productivity and enjoyment.
I see a really bright future for slick, fast, well-documented solutions that significantly depart from the Wordpress/massive CMS model and rely on highly-modern technologies that developers enjoy working with. Couple something like Gatsby with a framework that makes design a lot easier too (e.g. Tailwind + Tailwind UI) and suddenly, as a developer, you're so much more capable than previously.
I dunno. This old Rails programmer is loving it. And if I can learn to love it, I think they've got a market.
It’s funny, because I did just as your post suggests and built my latest personal site using Gatsby and Tailwind and it was an overall positive experience. I loved that I didn't have to do any design (although, sure, you could argue that might be a negative in terms of the result) and the build/deploy process was really simple with Netlify.
My previous sites were built with Wordpress and before that I used AMFPHP and Flash (over 10 years ago!). This was a breeze compared to those sites.
Yeah, I was reading that and thinking that you can replace every instance of Gatsby with Next.js and the text would still hold.*
I noticed that IDEO uses Gatsby for their site, so I'm starting to think that the main difference is PR/marketing.
* I've worked with Next, 11ty, jekyll, hugo, but not Gatsby, hence the interpretation. Gatsby feels like less boilerplate than Next. I'll check it out once I find an excuse to use it.
NextJS might be open source but it's from a company (recently renamed do) Vercel, before known as Zeit.co, which has also a lot of VC dollars behind it's belt.
Web performance doesn't need any of that. Browsers are very good at parsing HTML and CDNs are a commodity now. A directory of HTML files is about as fast as it gets, no preloading necessary (and you avoid all that JS payload too).
It really depends on your network connection. If it is fast fetching a small HTML page is nearly instant, if it
s not then it will be noticeable compared to locally cached data.
Now you don't need to do it as complex as Gatsby does, you could literally just GET the HTML file and throw away the result so that it is in the cache.
What if you want to make a site-wide change (e.g. GDPR mandates a cookie banner)?
With Gatsby's approach, you only modify the js that renders the template. Then, if a site-wide change needs to be made, you make a single change in the js template.
With the static-HTML-served-from-directories approach, you would have to rebuild all the HTML for your entire site if you wanted a template change and a database to store all the articles/posts for you to rebuild the HTML.
That's great but isn't a site that must be statically built and deployed to add a new page a niche use case for todays web? You can't use it for a site like HN, a content hub, a social media site, so many use cases that rely heavily on dynamic content from a database. And yes technically you can use it for those things but you're building the static front end with lots of page building logic and complex graphQL queries and ALSO a database backend with your content or CMS as a service like maybe contentful? That's a lot of complexity and unique architecture to maximize for the time to first paint metric. It seems like the Gatsby use case is agencies, branding, advertising campaigns. Which definitely is a sizable market, but sizable enough for what kind of returns on a $28M round?
Gatsby has a lot of optional functionality built with plugins. Server-side rendering is among them. I built a product on top of Gatsby, so far it works fantastic.
What do you mean by SSR with Gatsby? Dynamic rendering at the time of page request, or rendering static HTML at build time? If the former, can you share some links?
> Gatsby can pre-emptively fetch all the linked pages, both React components and data, to give instantaneous second click page loads. That's a pretty impressive feature in the wild, the second click is neck snappingly fast.
Can't you do that much more simply with a simple static site and a service worker?
You don't even need the service worker: just use preload hints for the related content and, if you're really convinced you need to, fetch the content so you can replace the page on a click.
That's usually a waste of time, however, compared to making sure your site is cache-friendly. As most projects have discovered, there are a lot of edge cases for making a JavaScript solution as fast or robust as the built-in browser behaviour.
But, you're right that Gatsby requires a lot of code. To get a simple static site setup, it's a lot of work. Plus it changes very fast. We stopped paying attention for a few months, and things broke on the next upgrade.
But, if web performance is the goal, Gatsby is hard to beat. In addition to pre-fetching, it also inlines every resource, images, CSS, the whole thing. So a single HTML fetch should be enough for a full first paint. That's a lot faster than a usual static site, which in turn loads all the additional resources before it can show the site to the user.