3 ms·

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js. We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.

akerl_ 8y ago
Why would I spend a huge amount of time writing JS for the front-end?
- sandGorgon 8y ago
  You have the choice to. If you use reactjs based frameworks, you get the same amount of upfront effort as Hugo. It's not harder. However build times are slower. But as your website complexity increases, you can leverage the reactjs ecosystem (both people and libraries). In Hugo, you get locked to their templating system. Which is nice...but very non standard and relatively non-Googleable.
gschier 8y ago
I went this way too. If your site has a dynamic/interactive frontend, Gatsby makes it super easy to build a static-but-interactive site. Another huge plus with Gatsby is that it uses React's server-side-rendering to ensure that the site is still seo-friendly. If you have more than a few snippets of JS on your site, Hugo comes up way short. It's great for simple things though.
slathrop 8y ago
I ended up with a hybrid approach where Hugo and Golang templates are only for building the data (TOML files) into the required JSON for a read-only REST API. The remainder of the solution is all JavaScript (in my case Vue and Nuxt instead of React and Next). I came very close to switching to Gatsby early on, and I am very curious to know how my project[1] would have gone with Gatsby instead of Hugo. I get the impression that for the data manipulation (avoiding complex Golang templates that generate HTML) and for build speed, Hugo takes it. Certainly if you are working in React the simplicity of a single framework is the way to go, as you did. I also kind of felt a little more weird about mixing Gatsby and React with my preferred front-end framework, Vue, than I did about having to combine Golang template logic in one layer (API) with JavaScript in another layer (App). [1] https://github.com/railroadpm/site https://github.com/railroadpm/site
- sandGorgon 8y ago
  If you are NOT using React, then Gatsby and Hugo will be roughly equivalent. Because you lose the built in DSL which is very react-esque. In fact, I think there is value for a Gatsby built in vuejs as well .
bobwaycott 8y ago
> Since you are going to spend a huge amount of time writing js code for the front-end anyways... My general goal in using an SSG is to have a static site. HTML and CSS. Maybe some images, of course. But I typically don’t reach for an SSG if I’m building something that requires a huge amount of time writing JS code. The goal is to have zero JS and zero backend. I know others may not care to create the smallest, fastest pages they can, but if I need a bunch of JS, that strikes me as the opposite of a static site.
- sandGorgon 8y ago
  I think you are reading too much into what "JS based" means. You will end up writing the exact same amount of mark-up in Gatsby or Hugo - except that one is in JS (ES6) versus Golang based templates. The amount of JavaScript is not "huger" and Hugo does not make it zero markup. The only difference is that you get to leverage the react ecosystem which is far far bigger ... And it is easier for a dev (who probably already knows React) to pickup Gatsby versus Hugo. You are in the exact same webpack, js, npm ecosystem as a vanilla react site. If you have a fundamental distaste for js..that is a whole different matter altogether.
  - bobwaycott 8y ago
    Yeah, everything you’re saying just invokes my fundamental distaste for the JS ecosystem. Hugo is fantastic for its utter lack of any sort of environment requirements. Requiring webpack, npm, React, and any dependencies else at all is a complete turnoff. Hugo’s Go-based templating isn’t difficult to pick up (I use it and extend it and I’ve never actually read any of the docs outside of one place I wanted to check on loop-based variables). Of course, I’ve been using various templating languages for over a decade, so I can pretty much see some examples and relatively immediately intuit how it works with little effort. For me, having to invoke npm is a non-starter for SSG work. I reach for an SSG because I don’t want any JS at all—or a very minor, controlled amount of it. To be fair, I feel the same toward just about any other SSG—if a person must setup an environment to use the tool, the SSG is doing it wrong.

akerl_ 8y ago

Why would I spend a huge amount of time writing JS for the front-end?

sandGorgon 8y ago
You have the choice to. If you use reactjs based frameworks, you get the same amount of upfront effort as Hugo. It's not harder. However build times are slower. But as your website complexity increases, you can leverage the reactjs ecosystem (both people and libraries). In Hugo, you get locked to their templating system. Which is nice...but very non standard and relatively non-Googleable.

gschier 8y ago

I went this way too. If your site has a dynamic/interactive frontend, Gatsby makes it super easy to build a static-but-interactive site. Another huge plus with Gatsby is that it uses React's server-side-rendering to ensure that the site is still seo-friendly. If you have more than a few snippets of JS on your site, Hugo comes up way short. It's great for simple things though.

slathrop 8y ago

I ended up with a hybrid approach where Hugo and Golang templates are only for building the data (TOML files) into the required JSON for a read-only REST API. The remainder of the solution is all JavaScript (in my case Vue and Nuxt instead of React and Next). I came very close to switching to Gatsby early on, and I am very curious to know how my project[1] would have gone with Gatsby instead of Hugo. I get the impression that for the data manipulation (avoiding complex Golang templates that generate HTML) and for build speed, Hugo takes it. Certainly if you are working in React the simplicity of a single framework is the way to go, as you did. I also kind of felt a little more weird about mixing Gatsby and React with my preferred front-end framework, Vue, than I did about having to combine Golang template logic in one layer (API) with JavaScript in another layer (App). [1] https://github.com/railroadpm/site https://github.com/railroadpm/site

sandGorgon 8y ago
If you are NOT using React, then Gatsby and Hugo will be roughly equivalent. Because you lose the built in DSL which is very react-esque. In fact, I think there is value for a Gatsby built in vuejs as well .

bobwaycott 8y ago

> Since you are going to spend a huge amount of time writing js code for the front-end anyways... My general goal in using an SSG is to have a static site. HTML and CSS. Maybe some images, of course. But I typically don’t reach for an SSG if I’m building something that requires a huge amount of time writing JS code. The goal is to have zero JS and zero backend. I know others may not care to create the smallest, fastest pages they can, but if I need a bunch of JS, that strikes me as the opposite of a static site.

sandGorgon 8y ago
I think you are reading too much into what "JS based" means. You will end up writing the exact same amount of mark-up in Gatsby or Hugo - except that one is in JS (ES6) versus Golang based templates. The amount of JavaScript is not "huger" and Hugo does not make it zero markup. The only difference is that you get to leverage the react ecosystem which is far far bigger ... And it is easier for a dev (who probably already knows React) to pickup Gatsby versus Hugo. You are in the exact same webpack, js, npm ecosystem as a vanilla react site. If you have a fundamental distaste for js..that is a whole different matter altogether.
- bobwaycott 8y ago
  Yeah, everything you’re saying just invokes my fundamental distaste for the JS ecosystem. Hugo is fantastic for its utter lack of any sort of environment requirements. Requiring webpack, npm, React, and any dependencies else at all is a complete turnoff. Hugo’s Go-based templating isn’t difficult to pick up (I use it and extend it and I’ve never actually read any of the docs outside of one place I wanted to check on loop-based variables). Of course, I’ve been using various templating languages for over a decade, so I can pretty much see some examples and relatively immediately intuit how it works with little effort. For me, having to invoke npm is a non-starter for SSG work. I reach for an SSG because I don’t want any JS at all—or a very minor, controlled amount of it. To be fair, I feel the same toward just about any other SSG—if a person must setup an environment to use the tool, the SSG is doing it wrong.