Live data from Hacker News

An Honest Review of Gatsby

cra.mr

111–120 of 120 posts

Re: An Honest Review of Gatsby

#111
post #80

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.

As many other comments are saying, because it's Go. The majority of developers who use static-site generators professionally are frontend developers. Their language of choice is javascript or typescript. And if many are complaining about the inconvenience of writing graphql plugins — in javascript! — for Gatsby, imagine the annoyance of having to write the logic for your build step in an entirely different language.…

Hugo is a single executable - it doesn't require any knowledge of Go itself. Granted, you have to be familiar with the templating syntax to add build-time logic to the website, but I believe that syntax is common across many other static site generators as well.

Yes, if you want to add logic in addition to the templating primitives provided by default, then being able to write code into the source pages will be of great help. However I think that when such a level of dynamism is required, then one can start debating the utility of a static generator in the first place.

Re: An Honest Review of Gatsby

#112

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 like Hugo. I've been using it since 0.17. I've forgotten if I found getting started with it easy or hard. But since then it has been a relatively smooth ride. No node or javascript baggage, fast build times, single executable - what is not to like?

Re: An Honest Review of Gatsby

#113

Earlier quoted context omitted.

I use createPages and I get hot reloading when running gatsby develop. I also just figured out how to trigger hot reloading for sources that normally don’t trigger it (markdown files which I was manually processing). Basically, I discovered that gatsby will hot-reload when it sees a change in code files (.tsx). So I created an essentially empty _rebuild-trigger.tsx file and imported that in my main page template. Now…

Please do share!

This commit has the important pieces. Look for the createPage call and rebuild-trigger.

I’ll try to put together a blog post when I can.

https://github.com/ricklove/rick-love-master/commit/8eebd4f9...

Re: An Honest Review of Gatsby

#114
post #110
post #94

Earlier quoted context omitted.

You're extremely limited in what you can compile as a GraphQL query, so while yes I agree with you that likely there is some stuff we're simply doing wrong.. good luck doing it right. After all, its a database query language trying to create a giant cache of its results. For example, we have what roughly amounts to an component. It uses some contextual information to include language-specific code. That include compo…

Have you tried using page queries? Page queries can accept arguments passed in via the createPage API. Here's some (admittedly hard to find) documentation about it: https://www.gatsbyjs.com/docs/page-query/#how-to-add-query-v... The basic idea is your page context just contains identifiers for the content you need to display on the page and then the page query uses those identifiers to query for just those objects an…

That only helps when it’s coupled to the page. Doesn’t make a ton of sense in our use case as it’s just an arbitrary component. It would have to support queries based on component props, but that’s even more complexity in an existing nightmare.

Re: An Honest Review of Gatsby

#115

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. https://github.com/react-static/react-static/issues/1203 ), one to Gatsby and the other to NextJS. I agree largely with the findings described here - Gatsby felt qu…

I use createPages and I get hot reloading when running gatsby develop. I also just figured out how to trigger hot reloading for sources that normally don’t trigger it (markdown files which I was manually processing). Basically, I discovered that gatsby will hot-reload when it sees a change in code files (.tsx). So I created an essentially empty _rebuild-trigger.tsx file and imported that in my main page template. Now…

Hmmm, I seem to recall that hot reload didn’t reload the content, but I’ll check again! In any case it’s not as smooth for allowing content editors to preview content as NextJS’s preview unless I’ve missed something - with Next it will reload the content on every page load if you have the preview cookie set

Re: An Honest Review of Gatsby

#116

Earlier quoted context omitted.

Please do share!

This commit has the important pieces. Look for the createPage call and rebuild-trigger. I’ll try to put together a blog post when I can. https://github.com/ricklove/rick-love-master/commit/8eebd4f9...

This looks very promising. I've given it a like, will take a deeper look when I get on the laptop. :)

Thanks a lot for sharing Rick!

Re: An Honest Review of Gatsby

#117

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 use Hugo a lot. I'll admit it does have a learning curve. Once you figure out how to really effectivity use it you can be productive and build out some huge websites and it's fast as hell.

> Once you figure out how to really effectivity use it you can be productive and build out some huge websites and it's fast as hell.

I don't doubt that, but a site that is a) huge, and b) doesn't require interactivity seems rather niche to me. SSG's really shine to me on small sites, and to some degree mid-sized ones. Code documentation is a good example, where I made some new library at work and now I want to dump some nice documentation somewhere. It's only a few pages, all I need is a way to convert Markdown to HTML in a semi-pleasing format, and have the SSG handle creating an index or ToC sidebar so people can navigate.

Hugo sucks for this. The templating language is Go's, which I don't care for much, and doesn't seem to be very widely used outside of Hugo. So now I have to learn a DSL just to use Hugo, which is unlikely to be useful for anything else, ever.

The templating language also seems to change constantly. I feel like every time I update Hugo, I have to go find a new theme, because now I get 10,000 warnings that they're going to redo the whole template API, and like 7 things my theme is doing aren't compatible with their new API. Of course, someone will say that I can build my own theme. And you're right! If I want to go become an expert in this esoteric DSL so I can figure out how to iterate over pages to build my ToC. Plus now that I'm building a theme, part of me starts wondering if it wouldn't be easier to just hand-write the HTML.

These NodeJS site generators are at least an order of magnitude easier to work with. I get code completion, so I don't have to try to remember all the various built-in and custom macros. I get unit tests, so when I change something in my theme, I can test it. I find that it's easier to genericize things from tutorials as well. If I want to add a navigation sidebar to all my pages, I just need a tutorial that shows me where I hook into the base page template (i.e. add a customizePageTemplate() call when you instantiate the renderer or something). From there I can use code completion and docs to figure out what I have access to to do the things I want. Again, that's because it's a familiar domain. If I want to do the same thing in Hugo, I pretty much need a tutorial specifically dedicated to customizing the base page templates. Even if someone tells me where to customize it, I end up having issues because the things you can access inside Hugo depend on where you are in the rendering pipeline, and Hugo's templating language doesn't make it easy to tell what you have access to at the moment.

I do admire their speed, but I have had effectively no situations where I have a site that is both large enough to be worth learning the DSL, and simultaneously doesn't require anything that Hugo makes difficult.

Re: An Honest Review of Gatsby

#118
Gatsby build times are getting slower especially for images. Just started using Gatsby using a starter theme ( https://www.bobbydreamer.com ). 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.

Re: An Honest Review of Gatsby

#120
post #94
post #90

Earlier quoted context omitted.

> 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. Incorrect DOM-output is likely caused by common mistakes (e.g. conditional rendering based on `typeof window !== 'undefined'`) which screw up rehydration. Dealt with it in the past and seen a lot of developers struggle with it. This article…

You're extremely limited in what you can compile as a GraphQL query, so while yes I agree with you that likely there is some stuff we're simply doing wrong.. good luck doing it right. After all, its a database query language trying to create a giant cache of its results. For example, we have what roughly amounts to an component. It uses some contextual information to include language-specific code. That include compo…

You are basically complaining that the client is loading too much data because you are sending them too much data.

You could publish the different languages in different folders/path, thus, using the static queries to build static pages.

If you want them on the same path while loading different language content dynamically, that migh not be the best use case for gatsby. In that case you probably need to load every translation for each of the included paths, but not every path with every language for all of the different pages.

Post reply on HN