I just don't get Gatsby. It feels over-engineered for the small static site use cases it is the best tool for and definitely not a good alternative to dynamically generated pages from other frameworks like Next.js, Rails, Django, etc. Maybe the engineers that preceded me on the Gatsby project I worked on took a wrong turn but we ended up with long build times and ever growing complexity around the create pages function. I just couldn't figure out what value Gatsby was supposed to be delivering that was better than any of its competitors.
Gatsby has slick looking docs and a lot of VC money and as far as I can tell a painful development experience. For most use cases you'll still have to write a backend API to handle form submissions, 3rd party calls and other Ajax. What does Gatsby actually do other than package together a bunch of trendy web technologies with Wieden Kennedy designed documentation?
We use Gatsby with Contentful for our marketing site and blog. It's been a nightmare.
We publish content multiple times a week. It's taken a huge amount of effort and paying Gatsby a lot of money for their SaaS products to get a setup that any serious publisher (like a newspaper) would laugh at.
The whole product being built around static site generation is a huge limitation. Things like republishing at a reasonable cadence and previewing changes require massive kludges and huge amounts of infrastructure to make work.
Static site generation is a niche product. Gatsby are trying to replace dynamic server side rendering, and in the short term will win people over with the upsides. But long term people are going to hate the limitations.
I've been involved in a site that has over 10k pages and it worked fine. Sanity has a preview feature and Gatsby incremental builds are available now (which I haven't used yet) but should bring your build times down significantly.
We use Gatsby preview. It frustrates me that we are paying a lot of money for a substandard solution to a problem that shouldn't exist.
The same goes for Gatsby incremental builds. We don't want to run a web server, so instead we should pay to run a build server 24/7 so we can have a warm cache available when we need to build!?
The annoying part is that there is not reason a static site generator should have these limitations. Gatsby's entire revenue model is based on solving problems that only exist because of the bad architectural decisions in their open source product.
Our problems stem from the fact that Gatsby's architecture is based around assembling an in-memory model and GraphQL schema for all possible data nodes, and then generating pages by querying from that store.
These operations are dependent on each other, so Gatsby can't do things like fetch just the data needed for a single page. It's also error prone because it adds a whole bunch of complexity to everything they do: https://www.gatsbyjs.org/docs/gatsby-internals/
That kind of complexity is not needed for something that is inherently a pretty simple problem.
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.
Congratulations on the cash, but after trying it out recently, Gatsby feels like it was made as a dare to make the process of displaying a bit of HTML and CSS on the page as complicated as possible.
> Gatsby has slick looking docs and a lot of VC money and as far as I can tell a painful development experience.
I have used Gatsby only for small projects, but developer-experience-wise, it's been fantastic, on par with Next.js and better than developer experience of Jekyll or Eleventy, I would say. No pain at all, if you know your way around javascript and react.
But of course the price you pay for that is that a hello world Gatsby app starts at around 60 kB of javascript. Also, service workers, which are nice in principle, but in inexperienced hands might result in stale content or even broken site. I sometimes visit the site of Kent C. Dodds. It's built with Gatsby. It's also using service workers, so every time I visit the site after a couple of weeks or so, the page greets me with the old content; and I have to refresh the page to get the new one. Occasionally, his service workers that have cached the entrypoint webpack file fail to fetch css or js files from previous builds listed there, and the site just shows blank nothingness. It's ironic, really.
Gatsby still has a pretty good UX compared to Java though. You probably do not want to use Enterprise Java with its dependency injection and inversion of control systems even on a good day.
I agree, I tried Gatsby to set up a simple static site and it just felt massively overengineered, and despite loving GraphQL I found their GraphQL layer to be more of a hindrance than a help. Moved to NextJS and it's a breath of fresh air, there's no looking back now. Their new getStaticProps interface is so simple yet very powerful.
Can't tell if that's sarcasm or not. I've 100% seen startups lose prospects and deals because the docs weren't great.
If anyone who's selling software thinks their docs are only for users, and don't get read by prospective customers, they're missing out on customer prospects without even realizing. Many people even skip the homepage and everything else and jump straight to the docs to figure out what the product does, whom it's for, how it works, what it integrates with, and so on.
Good documentation is immensely valuable. Likely an absolute must have to be a huge ecosystem like node, rails, etc. But extensive documentation certainly can't replace being a simple, well organized and elegant tool for the job. Last I checked the Gatsby docs felt more complete than the Next.js docs. Writing this out makes me want to head over to to the Next.js repo and start contributing.
If I recall correctly that’s what Patrick Collison said about one of the reasons why Stripe grew so quick as they had such useful docs. Good, robust documentation is crucial for any software project or business.
I can totally see why. Stripe’s docs are really the best I’ve seen. Not only are the docs good but the API is very logical and well made, definitely much better than their competitors like Authorize.Net.
We use Gatsby for our landing[0] (and are also in the process of moving the main SaaS dashboard to it) and the experience has been nothing but amazing. Page loads almost instantly with little manual optimization required and compile time rendering makes deployment really simple - unlike Next.js you do not have to fiddle with production SSR using serverless functions or a separate node server. The only issue with Gatsby is that compile-time SSR errors are not exposed during normal development live reload so everything needs to be compiled twice, once for development and once to test that the production build can be generated without error.
used gatsby for my portfolio website and recently wanted to add a p5 sketch into it and went round the houses for about 2 hours as i did an update which broke everything.
ended up sacking it off, creating a static html/css/vanilla site text right in tag and boom done in about 20 mins.
ridiculously over-engineered. use react if you want the madness, plain if you want to just do something normal
Currently working on a project using gatsby, have had some big wins but other things have been a pain. The single biggest feature you get is SSR rendering for an application built in react. There are lots of little goodies like Gatsby Image and Gatsby Link that are actually really awesome.
I personally am not that huge of a fan of the graphQl layer, we have been using it with basic use cases and still have run into issues with it.
Definitely not a revolutionary framework or tech, but for its use cases it does work.
Technically it doesn't. Unless developers add a bunch of logic to run in JS after the page loads (e.g. React's useEffect), everything it needs to render should work just fine without JS enabled.
This is my biggest complaint with these supposedly static site generators.
The resulting sites are anything but static.
My biggest regret of 2020 so far is agreeing to use Gridsome for a site, promised by the docs and a dev that it was a static site with "only as much VueJS as was desired for additional functionality".
I think you have got it right. I own dozens of static websites from 100 pages to 1M pages. I am the ideal customer for a company like Gatsby.
I had all the content in my mysql and accessible through a REST api. I had python scripts that would pull data from REST and generate .MD files which then Jekyll would convert to static sites. Everything worked fairly well except long build times for the 1M pages site which was expected.
I decided to try porting things to Gatsby because I thought I can get rid of the python script. Then I realized how useless Gatsby suddenly is.
It will take hours to call the REST APIs and create nodes. It would take huge amount of memory too often causing the process to crash even for sites that had just 10,000 nodes. The create pages step was even more horrible. If there is some error like a special char in the url it would just crash the whole process forcing me to build from scratch again which again took lot of time. I had to then try to figure out how to cache the data. Even then, memory crashes were frequent and Netlify free plan would not support the long build times.
I then decided not to use Gatsby for my use case and instead just use Google Cloud Run and PHP for the super large site and continue using Jekyll for all the < 1M pages sites with free Netlify plan.
Now, if you are going to raise lot of money from VC I would like to see you making products that make your customers happy and not engaging in some of engineering porn where you try to solve problems like using "react components" which in itself has no meaning to me.
Have you tried testing other generators for sites with 1M pages? How about Hugo?
I'm confused about Gatsby as well to be honest. It has a lot of buzz but Hugo does everything I need. It can download data from URLs too and, worst case, just write a short script that does this before triggering the static site generation.
Part of the appeal of static site generation for me is simplicity. I've already hit enough issues with Jekyll having versioning issues when I return to a site I've let sit for a while. I don't want to have to deal with versions and upgrading issues that'll be involved with using Node, Webpack, React etc.
A million statically generated pages seems to be an interesting use case (also your use of cloud run suggests it's not high traffic). Is this common at all though?
> other frameworks like Next.js, Rails, Django, etc.
I think that's the biggest difference. Gatsby spits out a bunch of html and js files that can be served anywhere. No database migrations, impossible for someone to install malware on your site, no server costs (static site hosts are multiple and free).
That's the big value prop to me. Hosting is simple, dev tools are familiar (npm and react), plus I don't have to mess with webpack.
(I agree that I have no clue how they'll make money, but I do really like their existing ecosystem).
It helps if you think of Gatsby as part of the "Headless" architecture, which presupposes that your app/website is just a veneer on top of other 3rd party tools/SaaS.
So if you're an e-commerce business using Shopify, Contentful, and Algolia, then Gatsby is actually a very nice fit. You could do all of this in Next.js, but you'd be dealing with server-side proxying to the SaaS tools and all that goes with that (e.g. service downtime, adding 100ms+ latency to each request, caching etc.)
I’m a Gatsby fan and have built several sites with it. But I do recognize it’s a dead end at its core. Its main use case is data driven static sites, and it does that case very well. But when it tries to extend beyond that, the results are mixed.
But with that said, I give Gatsby a lot of credit in pushing forward the idea of a cohesive React framework. I just think Next.js, Remix and other newcomers are ultimately going to achieve that way better than Gatsby.
This was my experience as well. I thought it might be aimed at news sites with content in WordPress as a faster alternative front-end. It certainly positions itself as "for everyone", but it felt wildly over engineered when I used it for a small static site.
Gatsby has slick looking docs and a lot of VC money and as far as I can tell a painful development experience. For most use cases you'll still have to write a backend API to handle form submissions, 3rd party calls and other Ajax. What does Gatsby actually do other than package together a bunch of trendy web technologies with Wieden Kennedy designed documentation?