Earlier quoted context omitted.
> 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, faste…
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 alre…
Re: Migrating from Jekyll to Hugo
#91Yeah, 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.