3 ms·

Thank you, that comment is very enlightening... I know hugo pretty well, so this might have been not as obvious to me. One of the things, I did not like so much

Thank you, that comment is very enlightening... I know hugo pretty well, so this might have been not as obvious to me. One of the things, I did not like so much about hugo (although I think it's awesome), is documentation. It is pretty well documented but as you said the sheer amount of options is overwhelming. What I was missing, is a list of quickstart best practise scenarios along with a well designed template for exactly this use case, like: - A small blog - A companies homepage - A photographers website - A technical documentation with search index - An image gallery Since all this IS possible with hugo, you just have to find your way to do it, I think ;)

qbasic_forever 5y ago
Yeah hugo kind of suffers from being one of the first popular tools in the SSG space. It's been around for a while and feature creep has definitely added to the complexity. Being written in Go is both a huge advantage, and an unfortunate disadvantage too these days. It's great because the speed and ease of use is unrivaled, but nowadays a jamstack site is much, much more than just a pile of markdown turned into HTML. People are building complex SPA, SSR, hybrid, etc. architectures and using fancy webpack-based workflows with all kind of transpilation, code generation, etc. at every level. You have to jam all of that into hugo's workflow and it just adds to the complexity--now you need a full node/JS frontend setup (with webpack/babel/postcss/etc.) and hugo's setup on top of that. Hugo tries to do some of this itself with esbuild but it still is hard to get away from bolting on webpack with hugo and getting the best... and worst... of both worlds.
- chrisweekly 5y ago
  +1 insightful Along these lines, the case for exporting a static site from NextJS (leaving the door open to all the options) is a lot stronger than trying to bolt on dynamic functionality to Hugo. IMHO it's not even close.

qbasic_forever 5y ago

Yeah hugo kind of suffers from being one of the first popular tools in the SSG space. It's been around for a while and feature creep has definitely added to the complexity. Being written in Go is both a huge advantage, and an unfortunate disadvantage too these days. It's great because the speed and ease of use is unrivaled, but nowadays a jamstack site is much, much more than just a pile of markdown turned into HTML. People are building complex SPA, SSR, hybrid, etc. architectures and using fancy webpack-based workflows with all kind of transpilation, code generation, etc. at every level. You have to jam all of that into hugo's workflow and it just adds to the complexity--now you need a full node/JS frontend setup (with webpack/babel/postcss/etc.) and hugo's setup on top of that. Hugo tries to do some of this itself with esbuild but it still is hard to get away from bolting on webpack with hugo and getting the best... and worst... of both worlds.

chrisweekly 5y ago
+1 insightful Along these lines, the case for exporting a static site from NextJS (leaving the door open to all the options) is a lot stronger than trying to bolt on dynamic functionality to Hugo. IMHO it's not even close.