by ehfeng on 10/3/20, 7:18 AM with 118 comments
by Arathorn on 10/3/20, 8:26 AM
edit: https://github.com/matrix-org/matrix.org/ if any indignant gatsby fans want to tell us what we’re doing wrong
by brabel on 10/3/20, 8:12 AM
There are literally hundreds of static site generators: https://www.staticgen.com
Most of them should get markdown right too!
by pkalinowski on 10/3/20, 8:08 AM
Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
by mattkevan on 10/3/20, 9:44 AM
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.
by tomduncalf on 10/3/20, 8:10 AM
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).
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.
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!
by jmisavage on 10/3/20, 8:53 AM
by fermienrico on 10/3/20, 9:05 AM
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).
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.
by joostdecock on 10/3/20, 9:44 AM
``` <Alert level="warning" title="Note"> PUT/DELETE methods only apply to updating/deleting issues. Events in sentry are immutable and can only be deleted by deleting the whole issue. </Alert> ```
And goes on to shiw their ugly hack to make it work.
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:
``` <Alert level="warning" title="Note">
**PUT/DELETE** methods only apply to updating/deleting issues.</Alert> ```
Which I really don't find to be a deal breaker.
I stopped reading after that because I was hoping for a somewhat more informed opinion.
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.
It's simple enough on the surface and as you dif deeper, there's plenty of knobs to turn.
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.
by exogen on 10/3/20, 8:20 PM
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.
Some things that lead to hydration mismatches:
- 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.
- 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.
- 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.
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, on the first pass specifically (when hydration occurs). Then, using the component lifecycle, you can make them update to take the latest client-side info into account.
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 after the app has done its initial mount.
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.
by tekkk on 10/3/20, 8:43 AM
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).
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.
by baobabKoodaa on 10/3/20, 11:58 AM
by himynameistimli on 10/3/20, 9:42 AM
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.
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
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.
by fermigier on 10/3/20, 6:20 PM
Has it been a contender for the rewrite of their documentation?
Shameless plug: I'm in the middle of a rewrite of my company's website (https://abilian.com/) using Lektor myself. So far so good, for someone used to Python and Flask it's the obvious choice for a static website generator.
by httpsterio on 10/3/20, 8:14 PM
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.
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.
by city41 on 10/3/20, 12:53 PM
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.
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".
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.
Gatsby has strict caching requirements -- https://www.gatsbyjs.com/docs/caching/ -- 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.
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.
I'm currently playing with Svelte's Sapper. It might possibly become what I always wished Gatsby was.
by ricksharp on 10/3/20, 10:33 AM
It also works well with async import for runtime loading of components.
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.)
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.
So I’m sure I’ll end up needing to build my own SSR eventually, but it should be easy to do.
by deanclatworthy on 10/3/20, 8:26 AM
by tvphan on 10/3/20, 10:36 AM
by hirako2000 on 10/3/20, 10:56 AM
by gherkinnn on 10/3/20, 7:59 AM
I wish the article mentioned that.
by tobr on 10/3/20, 9:58 AM
by chadlavi on 10/3/20, 12:38 PM
by deltron3030 on 10/3/20, 10:26 AM
by fareesh on 10/3/20, 8:36 AM
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.
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.
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.
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.
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.
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.
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.
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?
I am also considering redoing the entire site in Sinatra the next time I add features to it.
by einpoklum on 10/3/20, 10:57 AM
I literally thought this was an item about the Australian stand-up comic (but that's Gadsby with a D).
by c0ffe on 10/3/20, 8:16 PM
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.
by bobbydreamer on 10/4/20, 7:34 PM
by say_it_as_it_is on 10/3/20, 10:28 AM
by znpy on 10/3/20, 10:19 AM
by SergeAx on 10/3/20, 2:54 PM
Mr. Nolan, please invert me, I have to fix an awful mistake called "frontend frameworks" back in time.
by firasd on 10/3/20, 8:12 AM
by ljm on 10/3/20, 1:09 PM
by np_tedious on 10/3/20, 9:39 AM
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.
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.
by rahimnathwani on 10/3/20, 9:39 AM
by talolard on 10/5/20, 12:54 PM
by tootie on 10/3/20, 7:12 PM
by cutler on 10/3/20, 1:37 PM
by adamzapasnik on 10/3/20, 12:29 PM
by Exuma on 10/3/20, 7:12 PM
by cheph on 10/3/20, 10:28 AM
The amount of time that you have to spend just fiddling with Gatsby is insane and then in the end it only barely works.
Their marketing keeps touting fast but I doubt there is something slower when you actually use it for something of consequence.
by prewett on 10/3/20, 5:53 PM
by jandeboevrie on 10/3/20, 8:42 AM