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.
An Honest Review of Gatsby
21–30 of 120 posts
Re: An Honest Review of Gatsby
#22Earlier quoted context omitted.
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-…
Plus, you can generally take the the dynamic generators and dial them down to a purely static build for sites that genuinely aren't using client-side features, but you can't go in the opposite direction.
Each time I've looked into the react based static site generators, even late last year this seems not to be true, at least not easy, they always seem to bundle client side js for rehydration, turning that off seemed impossible and wasn't a priority seemingly for many generators because the site would work without js enabled, but for cases where I don't want my sites payload to include a huge bundle of needless js then I was out of luck.
Re: An Honest Review of Gatsby
#23Earlier quoted context omitted.
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-…
Plus, you can generally take the the dynamic generators and dial them down to a purely static build for sites that genuinely aren't using client-side features, but you can't go in the opposite direction.
This is a good point. I've been very impressed with how well Nuxt works for static builds: https://nuxtjs.org/blog/going-full-static.
I think for a startup with the liberty to choose a new tech stack, Nuxt.js is a great choice. It allows you to start with simple S3 bucket hosting, and move up to Vercel/Docker on ECS/etc. as you grow.
Hugo is a fantastic choice for blogs, but not for much else.
Re: An Honest Review of Gatsby
#24Earlier quoted context omitted.
Plus, you can generally take the the dynamic generators and dial them down to a purely static build for sites that genuinely aren't using client-side features, but you can't go in the opposite direction.
Each time I've looked into the react based static site generators, even late last year this seems not to be true, at least not easy, they always seem to bundle client side js for rehydration, turning that off seemed impossible and wasn't a priority seemingly for many generators because the site would work without js enabled, but for cases where I don't want my sites payload to include a huge bundle of needless js the…
The React SSGs are not very good at this, but as mentioned in my reply to the parent comment, Nuxt.js (based on Vue), is a great option. See https://nuxtjs.org/blog/going-full-static.
Re: An Honest Review of Gatsby
#25I 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 those who want to like Hugo, but can't stand the templating language: there's also Zola ( https://github.com/getzola/zola ), a superb static site generator, with built-in Sass compilation, written in Rust.
There is a shit tonne of static site generators that ain't hugo though.
Re: An Honest Review of Gatsby
#26Is 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.
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.
Re: An Honest Review of Gatsby
#27I 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.
Gatsby did feel way too much engineered and I went with Hugo. It's not perfect but it works well and I understand it.
Re: An Honest Review of Gatsby
#28I 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 built a data intensive website with Hugo and it’s horrible. Template engine is very bad. Hard to write reusable small functions (string manipulation, array manipulation, data extraction, mapping one form of data to other, filtering etc.). The fact that statements can’t be multiline is ridiculous.
Coming from Hakyll which just gives you all the power of Pandoc and a programming language, it was really a chore to work with Hugo. I’ll never use it again.
Re: An Honest Review of Gatsby
#29This 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 :/ edit: https://github.com/matrix-org/matrix.org/ if any indignant gatsby fans want to tell us what we’re doing wrong
Yeah, SSG build times are certainly an issue in my experience, even for smallish sites. I quite like the incremental regeneration idea in NextJS: https://nextjs.org/blog/next-9-5#stable-incremental-static-r... - sounds like it will rerender pages in the background as traffic comes in to them, while serving a stale version to the original request. I guess there are times when this might not be acceptable though... in which case really you just want to be able to rerender the subset of pages a given change affects, but this isn’t always easy to work out.
Re: An Honest Review of Gatsby
#30I 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.
Because Hugo doesn’t solve the dynamic problem. It also is not flexible enough for composing content. If you look at the Sentry docs you can see that it depends on the flexibility of the graphql system to feed shared content to different parts of the documentation.
Maybe a static site engine shouldn't be solving any 'dynamic problem'
That has a strong smell of losing focus on your core principles and obsessing over adoption stats at any cost