11–20 of 120 posts
edit: https://github.com/matrix-org/matrix.org/ if any indignant gatsby fans want to tell us what we’re doing wrong
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. Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
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. Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
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. Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
For the content (not done yet), I want humans to write it, but haven't found a scalable approach.
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 https://docs.sentry.io/
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.
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. Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
Hugo is really, really good at what it does. I run a number of static blogs on it, including that of my startup [0] and my personal blog [1]. However, for many purposes, a completely static setup like the one that Hugo offers is surpassed by the reactive capabilities of Next.js/Gatsby/Nuxt, etc. For larger, more complex sites, javascript frameworks make more sense, and offer far more functionality for building a web-…
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.