This review nails it. It takes the matrix.org gatsby website 20 minutes to build currently, which is excruciating when trying to do quick fixes for blog content - you just sit there wondering what the graphql is actually doing and what it’s giving you :/<p>edit: <a href="https://github.com/matrix-org/matrix.org/" rel="nofollow">https://github.com/matrix-org/matrix.org/</a> if any indignant gatsby fans want to tell us what we’re doing wrong
If a static site generator put my images in the wrong place and required a gigantic JSON file to be loaded by the client for no reason I would not think twice to get rid of it.<p>There are literally hundreds of static site generators: <a href="https://www.staticgen.com" rel="nofollow">https://www.staticgen.com</a><p>Most of them should get markdown right too!
I wonder why it seems nobody wants to use Hugo. Smashing Magazine appears to be happy with it and they tooted about their experience with Hugo multiple times.<p>Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
After building a site with Gatsby, it feels like a prank to make the process of getting a bit of html and css on the page as complex as possible.<p>It’s like you’re not a heroic enough a developer if you haven’t wrestled three build pipelines and ten layers of abstraction before breakfast.
I migrated a couple of sites I look after from react-static (which is a nice, simple library but unfortunately had some fundamental issues that it sounded like we’re unlikely to be solved and gave the impression that it was struggling for maintainers e.g. <a href="https://github.com/react-static/react-static/issues/1203" rel="nofollow">https://github.com/react-static/react-static/issues/1203</a>), one to Gatsby and the other to NextJS.<p>I agree largely with the findings described here - Gatsby felt quite slow and the GraphQL part feels like complexity overkill, for my use case I bypassed it using their createPage API but you lose out on eg the ability to reload a page’s data on the fly by doing so (from what I could work out - the documentation was a bit lacking in parts I found).<p>I was more impressed with NextJS, it feels generally more solid and easier to understand. It has a great preview feature where you can set a cookie and then the site will pull in data at request time rather than from the static site (perfect for CMS previews!) and build times seem alright - I haven’t had cause to look into speeding them up, which is a good sign.<p>Personally I’d go with NextJS in future based on my experience... that said, I’ve no idea if it would work well for their reasonably specialised use case!
Surprised they didn’t try Eleventy. I was just reading how a Mozilla team converted their extension documentation to it from Jekyll because it has support for Jekyll’s template language via a plugin.<p><a href="https://hacks.mozilla.org/2020/10/to-eleventy-and-beyond/" rel="nofollow">https://hacks.mozilla.org/2020/10/to-eleventy-and-beyond/</a>
Is it wrong to suggest and admit that I write on my blog in plain HTML? How often do people refactor their designs and links? In PyCharm, I can do Regex search/replace and it gets the job done if I ever need to change the template (which hasn't happened in last 4 years). Not a single minute spent on searching for the right framework, reading docs, setting it up, dockerizing the app, and perhaps even building CI/CD for automatic deployment.<p>Simple is better IMO. Just calculate the ROI and time spent on it and in next 10 years how often you'll be changing stuff in terms of template or links (Neither should change - Design is not fashion and links should be relative).<p>I also have complete 100% control over the page. I adapt it for a particular content if its got more pictures and less text for example. It's so easy and beautiful. There is a kind of zen-like aspect to it.
The first complaint in this is review is that markdown isn't rendered in custom MDX components, using this example:<p>```
<Alert level="warning" title="Note">
<i></i>PUT/DELETE<i></i> methods only apply to updating/deleting issues.
Events in sentry are immutable and can only be deleted by deleting the whole issue.
</Alert>
```<p>And goes on to shiw their ugly hack to make it work.<p>Well, markdown in custom MDX components is rendered. You only need to leave a line break to signal to the parser that this needs further processing. Like this:<p>```
<Alert level="warning" title="Note"><p><pre><code> **PUT/DELETE** methods only apply to updating/deleting issues.</code></pre>
Events in sentry are immutable and can only be deleted by deleting the whole issue.<p></Alert>
```<p>Which I really don't find to be a deal breaker.<p>I stopped reading after that because I was hoping for a somewhat more informed opinion.<p>From my experience, build time/build complexity is Gatsby's achilles heel. But I've built some stuff that looking back I don't think I could have done without Gatsby, as I came yo it being new to React.<p>It's simple enough on the surface and as you dif deeper, there's plenty of knobs to turn.<p>My one wish is if they'd let you bypass image processing in the development environment.
Apart from that, I can't recommend it enough.
Advice on the "A Broken DOM" section: it sounds exactly like a hydration mismatch. Hydration is the process of React correlating existing DOM nodes from server-rendered HTML (SSR) with the initial render of the React app on the browser-side. (As opposed to what happens without SSR, which is almost always the app being rendered into an empty DOM node – no content exists yet.)<p>Satisfying hydration constraints is by far the hardest part of doing React server-side rendering. The basic requirement is: whatever HTML you rendered on the server, the initial render of the browser app MUST output that exact same DOM structure. Otherwise, it won't be able to correlate them correctly, and will get confused about which DOM nodes to update. You can seriously mangle your entire page this way – but usually, it looks like nearby content stuck in the wrong place, or incorrect updates.<p>Some things that lead to hydration mismatches:<p>- Time-based rendering. Time passes between when the server rendered the HTML and the browser initializes the app. So any component using `new Date` to make decisions can potentially have a hydration mismatch.<p>- Randomization. Let's say you wanna choose a random promo image to show. The `Math.random()` result is going to be different on the server and client.<p>- Anything involving browser APIs, like the browser window size, or checking `typeof window`, etc. The server has no access to this info, so it either needs to skip rendering that content, or fallback to a default.<p>Once in the browser, here's the important part: you need the app's components to make all the same rendering decisions that they made on the server, <i>on the first pass</i> specifically (when hydration occurs). Then, using the component lifecycle, you can make them update to take the latest client-side info into account.<p>In other words, it's not enough to simply detect `typeof window` and render different content – you're only "allowed" to render that different content <i>after</i> the app has done its initial mount.<p>The somewhat-reassuring aspect of all this is that it's almost certainly your components at fault, not Gatsby or React, so it can always be fixed without too much effort. But it's an annoying foot-gun to have to worry about nonetheless.
Yeah, that's quite similar with my experience. The idea is really nice and when it works, it's great. But debugging those GraphQL queries without any intellisense and writing monstrous config files eg gatsby-node.js makes me wish for something better.<p>I understand that because the API gets so complicated it's better to use something flexible like GraphQL. But the magic breaks down too easily in places and then you end up trying to fix some really peculiar bug (I had one where you had to put blank .eslintrc to the root to prevent the linter from linting local linked npm libraries).<p>I think parts of Gatsby core should probably be rewritten or done in different language to make it faster. The compilation shouldn't take that long. But I'm not sure what are the remedies for the other problems. Maybe if they focused really hard to simplify the library into its very basics, following the Unix philosophy, it could help with the creeping complexity headache that Gatsby brings.
Gatsby is a mountain of unnecessary complexity. I've built a few Gatsby sites that I'm still maintaining and I will never use Gatsby for a new project again.
I think alot of folks share this view. When we switched our marketing site over to Gatsby it was a godsend, but once we hit over 400 static pages on our site, the build times were killing us.<p>Our devs complained that even on local, building took forever, and because it had to refetch all of our WordPress CMS media library each time, sometimes it would just crash during build.<p>Also we grew the need for good SEO support for dynamically generated pages (of which we have thousands), and we had to write our own prerendering lambda function to handle bots (and embed tools) that couldnt run js on their own<p>After Next announced their support for static site generation and the release of next-serverless, we took the next three weeks to get our site ported over and haven't looked back since.
The creator of Lektor (<a href="https://www.getlektor.com/" rel="nofollow">https://www.getlektor.com/</a>), aka @the_mitsuhiko, works for Sentry, and as I got from David Cramer himself over Twitter, Lektor is used for various secondary or internal websites at Sentry.<p>Has it been a contender for the rewrite of their documentation?<p>Shameless plug: I'm in the middle of a rewrite of my company's website (<a href="https://abilian.com/" rel="nofollow">https://abilian.com/</a>) using Lektor myself. So far so good, for someone used to Python and Flask it's the obvious choice for a static website generator.
Static site generators are a weird bunch. A vast majority of the projects never leave the beta phase and only a select few are relatively stable and regularly updated. That aside, the community aspect is even more vital in my experience. Unless you're an expert and understand the inner workings of the project, you're going to have to rely on documentation and community tutorials and starter projects.<p>I wouldn't for example know if something is even possible to achieve with a project unless someone had a repository showcasing how it is done, which has made me wary of betting on anything too immature. I just don't have the skills to bridge the gap myself.<p>Personally, I've stuck with Jekyll up to last year for these reasons, but right when COVID hit I started to delve into 11ty. I can say that it has been nothing short of a delight and the community is pretty stellar as well. I'm currently experiencing build times measured in milliseconds instead of minutes or so. I've been impressed and the project is developed actively and each update brings very concrete upgrades every time. Currently, I have the honor of sitting on top of the performance leaderboard for 11ty. Over half of the 400 sites there scores full marks in Google Lighthouse scores which should tell you something.
Gatsby is a great idea, with a questionable execution. Being able to build your entire site with React, make all of it statically rendered, and then opt into interactive/dynamic parts as needed is really great. Pulling in data sources at build time can be excellent. Overall I like the ideas behind Gatsby a lot.<p>But with real websites, I struggled to get Gatsby to be performant both at build and runtime. Gatsby really wants to preload other pages on your site in an attempt to speed things up, and you can't opt out of it. Whether this preloading is a benefit is a real mixed bag, and I have found myself spending a lot of time tweaking things to try and make it a net plus across the site. Mostly with bad results. gatsby-plugin-no-javascript can really improve things here a lot. It allows you to opt into JS only on pages that really need it, kill off the preloading entirely, and gain more control over the end result of your site. It's very strange that to get something like Gatsby in the ballpark you want you need to strip out JS, but well, it's true.<p>gatsby-plugin-no-javascript is not a perfect solution. It's too coarse. But I have found overall it can be a net positive. What I really want is the ability to say "this part of the page/site/whatever is truly static, please don't rehydrate it at runtime".<p>Gatsby's plugin system is nice. I like being able to handle things like robots.txt, sitemaps, favicons in a well defined, easily managed part of my app. The downside being you gotta accept what the plugin gives you. For example the favicon plugin generates favicons that are over 30kb. In my case, the favicon is often larger than the entire rest of the page combined. So I still find even here Gatsby is a good idea with questionable execution at times.<p>Gatsby has strict caching requirements -- <a href="https://www.gatsbyjs.com/docs/caching/" rel="nofollow">https://www.gatsbyjs.com/docs/caching/</a> -- and if you can't meet them, your site will have subtle bugs. This means Gatsby is not compatible with Github Pages, and is a major downside to Gatsby.<p>This article spent a long time complaining about MDX. I agree, I think MDX is quite bad. But of the 4 complex Gatsby sites I have built, none of them used MDX. I don't think it's fair to conflate MDX's short comings with Gatsby.<p>I'm currently playing with Svelte's Sapper. It might possibly become what I always wished Gatsby was.
When I found gatsby, I immediately stripped everything out and hooked into the dynamic createPages so I could just give it a list of components to turn into pages. (I thought the graphQL parts were horribly bloated boilerplate, so I didn’t want to even touch it.)<p>It also works well with async import for runtime loading of components.<p>Other then that, I don’t use any of it’s features. (I found a markdown react on npm and manually move the images to the public folder and use normal image tags.)<p>I’m quite happy with the runtime results, and develop re-render works pretty quickly. However, the production build takes about 30 secs which is pretty slow and I also ran into “out of heap memory“ on node during build and had to increase node’s heap size.<p>So I’m sure I’ll end up needing to build my own SSR eventually, but it should be easy to do.
I tend to agree with a lot of this article, having done a fair few Gatsby sites. I'd love to ditch GraphQL entirely and use proper SQL. But keep in mind this is all build-time complications, and at the end of the day you have static data sourcing all your pages.
Not mentioned here, and rarely mentioned anywhere is marko.js as a good alternative. Its not static site generation, but it's faster than most static site generated even though it processes templates on the server. The markup does not even need to learn: its pure JavaScript in the markup, it makes it so intuitive to create templates.
This mirrors my experience as well. Extremely slow build times, a lot of complexity that is hidden at first but is going to rear its head sooner or later, and GraphQL everywhere for very unclear reasons. Also, surprisingly easy to misconfigure something and get very poor TTI and other Lighthouse scores.
It's amazing to me that there's still not a super simple create react app option out there that builds a react app based on markdown sources for pages. You can get close to it with gatsby et al., but they're all twiddly or fragile in their own ways.
Elder.js for Svelte looks like a great "pure SSG" alternative for larger SEO sites:<p><a href="https://github.com/Elderjs/elderjs" rel="nofollow">https://github.com/Elderjs/elderjs</a>
I had a bad experience with Gatsby too. I am fond of the Gatsby-Image plugin for an image heavy website because it will generate all the images you need for responsive sizes, plus webp, plus a blurry preview.<p>The downside of this is that the lighthouse profiler currently does not score this setup properly and the blurry placeholder results in a lower score. There was an open bug to fix this last I checked.<p>The other major issue I faced was to setup netlify CMS for my own hosting. This ecosystem seems to very forcefully nudge you to use their infrastructure like Netlify or Gatsby cloud. I didn't want that for a number of reasons. The documentation to set it up for your own server is in an absolutely pathetic state. All the steps described are cryptic and I ran across multiple questions and issues filed by confused users. I finally found a blog post which covered a large number of gotchas and I was able to set it up.<p>My customer manages the content on their site on their own. They were happy with the performance upgrade but the prospect of waiting a few minutes for the site to recompile everytime they make an update felt like a big step back to them.<p>I was not happy with seeing enormous json files being generated for what is essentially a website with a homepage and multiple categories with large photo galleries in them.<p>The other thing I was not prepared for is the hardware required to build the site. Small servers were running out of memory to do the build so I had to setup CircleCI to do the builds for me and then copy everything back to my server.<p>Another weird scenario I ran into was that the development version and build version had different outputs. I eventually solved this by noticing an issue with the DOM which didn't get picked up by anything in the build tools. Took me a day or two to finally figure it out.<p>In hindsight I am now wondering if I should just roll my own image resizing scripts, switch to a crud web app and cache all the generated htmls on first load and delete the cache when a change is made and prime it. This has been my approach prior to Gatsby, but I was sold on their marketing about how I get all the speed benefits for free and not have to worry about sizing images, setting up webpack for performance and splitting for routes, setting up metatags for prefetching/preloading etc. Turns out you're better off doing all that on your own.<p>Broadly I probably wouldn't use this framework again unless it was for a simple blog or something. The experience has left me quite annoyed. I am probably not going to follow this JAM stack philosophy in the future either. I don't really see the benefit. Are people really that afraid of managing servers?<p>I am also considering redoing the entire site in Sinatra the next time I add features to it.
For those of us not familiar with these systems - can someone please link to something more introductory?<p>I literally thought this was an item about the Australian stand-up comic (but that's Gadsby with a D).
The last time I had to work on a Gatsby project, it had build times of approximately nine hours.<p>Last thing I heard from them, is that when faced with the need to update news on the site more quickly (not on realtime, but "sooner"), the development team had to make a separate mechanism to query the news from the backend when the site was running on the browser, instead of doing it at build time, using the builtin GraphQL database. This defeats the central idea that everything on Gatsby comes from a central data source.
Gatsby build times are getting slower especially for images. Just started using Gatsby using a starter theme ( <a href="https://www.bobbydreamer.com" rel="nofollow">https://www.bobbydreamer.com</a> ). I am just imagining, if I continue to use this theme and add more posts and pictures for next 10 years. How slower can it become. Gatsby is fast and site starters are really sleaky. If builds are faster/optimized, it can help.
"Modern" is a term that should be reserved for improvement and progress. Are Gatsby users experiencing net gains from the alleged modern tooling?
> gigabyte-sized Sentry frontend app<p>Mr. Nolan, please invert me, I have to fix an awful mistake called "frontend frameworks" back in time.
It's an interesting experiment in switching between various frameworks but honestly, looking at the docs, they could just use WordPress.. but regardless of backend, I'm not sure I see a need for a React frontend here <a href="https://docs.sentry.io/" rel="nofollow">https://docs.sentry.io/</a>
I just wonder how much time had to be spent trying to get a static site generator to build quickly and correctly, and how much time it would have taken to deploy a CMS and a caching layer, or wire up a UI over a headless CMS.
> approximately 0% of the engineering team knows Ruby<p>I found this surprising. I once worked somewhere that used Sentry heavily (liked it a great deal, it was pretty important to us). We had about a hundred projects and were encountering quota problems, the worst of which were usually from misbehaving queue workers on staging or perf the would consume our entire event budget if left unchecked. If we didn't shut it off in time we'd end up losing meaningful prod events.<p>Our solution was to switch to a YAML based config for rate limits and per project quotas. This would ensure every project was capped, central prod services were allocated more events like they deserved, etc. Sentry staff sent us a helpful starter script for utilizing their project configuration REST API. It was written in Ruby.
Wes Bos released his 'Master Gatsby' course a few days ago: <a href="https://mastergatsby.com/" rel="nofollow">https://mastergatsby.com/</a>
Gatsby was amazing for getting a landing page with a blog off the ground. It's much less compelling as we expand what we want our landing page to do .
Serious question: Why generate a static site at all instead of running next.js behind a CDN? Now a publish is really just a publish instead of a rebuild.
Using gatsby is the worst choice I ever made, the build times are infuriatingly slow and GraphQL really is not a good fit for it.<p>The amount of time that you have to spend just fiddling with Gatsby is insane and then in the end it only barely works.<p>Their marketing keeps touting fast but I doubt there is something slower when you actually use it for something of consequence.
Argh, I thought this was a (potential) new take on "The Great Gatsby" but it turns out to be some web framework I haven't heard of. Could we maybe name things so that tech things sound like they are tech?
All that useless effort for just some static pages. Can't believe how much money, time and resources are wasted by these hipsters. Why don't they solve actual problems that could help our race, instead of resume driven hipsterness.