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.
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.
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.
Non tech people often know about Gatsby and compare it to WordPress.
I have to warn decision makers that it promises a lot but adds complexity that wastes developer time.
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.
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.
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.
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.
Microsoft owns github, npm, vscode, typescript...
I mean...
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.
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.
There's lots of other SSGs that do the same thing, so Gatsby does not have any exclusivity on creating a performant static website.
Can't you do that much more simply with a simple static site and a service worker?
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.
Edit: + cloud infrastructure probably
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.
Do you want to display markdon files?? Oh that would be plugin.
Ok I got the plugin. Can I display a Markdown now?
Not yet you must write a GraphQL!!! query to read the contents of your file.
Lol, talk about damning them with faint praise.
I think you might be on to something; I don't even bother with projects without good docs or a readme.
Edit: Not sarcasm. I value my time.
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.
If I’ve understood your comment I don’t think this is still a problem as of Next 9.3. There have been some pretty big improvements since Next hit v9
https://nextjs.org/blog/next-9-3#next-gen-static-site-genera...
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
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.
All of the CSS is loaded from the webpack runtime though.
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".
Yeah, I know now.
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.
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.
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).
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.)
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.
I thought it was the combination of React plus a nice GraphQL interface. I would think that's a nice combination for your average startup.
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?