Gatsby raises $15M Series A for its modern web development platform

We also integrate with Gatsby if you want the best of both worlds :) https://ghost.org/docs/api/v2/

Don't search engine crawlers render React properly?

I'm one of the use cases that Sam mentions - B2C website. Replatforming our site with Gatsby, Netlify (hosting and more) and Contentful (headless CMS) has saved us hundreds of dollars a month in hosting - our site which receives 20,000 - 30,000 visitors a month now costs $0 to host. Additionally it is radically faster and more secure than it previously was. Being able to use React as needed has enabled us to manage some relatively complicated form handling/routing, get really creative around how we handle 'sites within the site' for a large sales team that we support, and easily create calculators and other tools for our customers.

And bonus - I'm a graphic designer by trade. For one reason or another a web team of 7+ people left my company over the course of 6months and I stepped in to fill the void. Just me, one person who had prior experience building the odd site (maybe one a year) with HTML, CSS. I literally learned javascript and React through Gatsby (I'd say I'm junior developer level at this point - which is actually a good fit for my company).

Gatsby is a great product (for many use cases), run by a generous team, surrounded by an equally generous community. I owe my career to Gatsby. My company is saving hundreds of thousands of dollars a year thanks to Gatsby. Stoked to see Gatsby's continued growth and success.

TLDR: I just completed a large project built with Gatsby, and wouldn't recommend it to anyone. The technology is extremely complicated, and the end result quite inflexible.

Here's an idea of how the whole thing works when you have non-technical users:

1. You need some sort of Content Management System for non-technical users to be able to create content.

2. That CMS stores the content however it sees fit (db/files/whatnot) and provides an API to fetch it.

3. In gatsby, you build "source plugins" that fetch the content and fill it in an in-memory GraphQL sever.

4. Building the site entails fetching all content, feeding it to GraphQL, making a webpack build to run in nodejs, making a webpack build to run on the final site, and finally generating the HTML files.

If this doesn't sound so bad, here are some complaints in no particular order:

- There are no incremental builds. You must rebuild everything every time you want to publish a change. Our builds currently clock in at ~8min.

They've been saying they want incremental builds since 2 years ago. They are "just around the corner" since ~6 months ago. They "already did the hard part" ~4 months ago. They "will offer incremental builds sometime in the future but only in the cloud paid-for version" as of ~1 month ago.

- Users hate not being able to immediately see how their content will look like (especially if every time they publish there's a ~10min. delay to actually being able to see it). We had to setup a "preview" environment that is running gatsby in development mode. Gatsby the company just recently started selling this as a paid cloud service (we built it ourselves).

- Development mode does not serve html files like production builds do. The site behaves differently in that mode, and some issues only happen in actual builds. When you encounter one such issue, the feedback loop becomes "full build for every change" == ~10min of waiting to try every single change. This is a HUGE productivity killer.

- Gatsby generates html files. Then it hydrates that html in the client, using ReactDOM.hydrate. Sounds cool, but the React devs explicitly stated that prerendered content must match exactly what the client-side would render, and if it doesn't your site may completely break and it won't be considered a rehydration bug.

Now consider what happens if you try to use a component that changes appearance by doing size detection, or if you have some area that changes between "Hello " or "log in" depending on whether the client is logged in, etc. BTW, these bugs only happen when you test actual builds, not in development mode of course (massive waste of time as per the point above).

- Gatsby hijacks NODE_ENV (setting it to "production" for actual builds and "development" for the development mode). This leaks into the many tools involved in the many things that happen while building (babel, webpack and all of their plugins, times two compilations, plus the rendering phase, etc). For instance, I've lost many hours trying to get a full, tree-shaken but unmangled build to no avail.

- Gatsby infers GraphQL types from the data you feed into it. It usually works, but when it doesn't it is painful to discover why (your queries return weird results) and fixing it means specifying your data types manually (something you already did once when you defined the database, again to define the models in the CMS, and yet again when you specified the API Gatsby uses to fetch the contents)

- Many months ago we went with CSS Modules because Gatsby sold it as a way to get the CSS required for each page inlined in the HTML itself. Fast-forward a bit, people where having issues with specificity (because of ordering) ... and now Gatsby inlines ALL of the site's css in each and every page. Our html's usually have more inlined CSS than actual HTML!

I can assure you I'm going the next.js route if I ever have to build a site with similar technology.