|
|
|
|
|
by webdelv
2214 days ago
|
|
I Initially thought Gatsby was great. As someone who enjoys using React, being able to use it for web sites in a way that’s well optimized and SEO friendly was appealing. However… after using Gatsby for a fairly simple site it didn’t take me long to realise that this approach add’s a fair bit of complexity and limitations. Prepare for long build times for simple changes, which becomes a bit silly once you hook up a CMS that triggers builds for each change. As a content editor having to wait 5 minutes for your change to be deployed kinda sucks. GraphQL for loading data often felt overkill and a lot of hassle. If you want to add something like a simple contact form you are encouraged to use external services which just get’s out of hand for what I want to be a simple self-contained site. The end result doesn't even feel that fast due to the React re-hydration that takes place. I ended up switching back to a traditional server-side solution which provided a much faster experience (in both tests and perceived speed) and more flexibility. It turn’s out the browser is pretty good at caching static assets and you can achieve the same SSG benefits with Caching and a CDN without the restrictions. I’m sure there are cases where Gatsby performs well, and it’s the best tool I’m aware of for bundling React pages in an SEO friendly, optimised way. But I think for the kind of project’s it’s useful for, something like Jekyll or Hugo may be more suitable. For more complex site’s that would actually benefit from React, it seems like the SSR alternative (Next) would be easier to scale. |
|