4 ms·
Hugo can be that simple if you don't have a complex frontend template. As soon as you want to make a SPA (or SPA-like experience), use a framework like React/V
by qbasic_forever 5y ago
Hugo can be that simple if you don't have a complex frontend template. As soon as you want to make a SPA (or SPA-like experience), use a framework like React/Vue/Svelte/etc., or even try out stuff like TailwindCSS you're going to get sucked into the deep rabbit hole of bundling frontend assets, webpack/esbuild/etc.
So you kind of have to decide, are just static templates and static assets all you need? Stick with Hugo and enjoy the speed, simplicity, etc. There are some even simpler alternatives you might enjoy too, like mdbook or mkdocs. Both are more oriented towards technical docs but are similar to hugo at their core--send in some markdown (in the case of these tools you don't even need frontmatter or other schema) and get out some HTML.
If you're building something fancier or using more complex frontend setups then... there's no perfect answer right now. It's all about balancing complexity of the build system with what it gives you in the output. IMHO webpack and gnarly dependencies can be tamed pretty well with a simple docker container. Spend some time getting your perfect workflow setup, chuck it in a container that a CI system can run all day, every day without fail, and you'll be pretty well setup.
- earthboundkid 5y agoI use Hugo with a modern front end, and it’s extremely easy to get setup, especially now that it has built in ESBuild support.
- mtlynch 5y agoCan you share more about this? I like Hugo for its speed and simplicity, but I find it hard to create elements within components the way I can in Vue. I haven't found any good resources for combining Hugo with frontend frameworks, so I'm curious what you do.
- earthboundkid 5y agoI've switched away from Vue to using Alpine.js, which makes it easier to combine backend templates with frontend ones, but here's the repo back when I was using Vue: https://github.com/spotlightpa/poor-richard/tree/eb816cac8079fd982e7d8cd437a7d1f28aa767f0 https://github.com/spotlightpa/poor-richard/tree/eb816cac807... src/entrypoints/donate.js defined a custom element, which was included on layouts/donate-page/single.html and layouts/partials/get-src.html conditionally included the Vue component either with Parcel's dev server in testing or precompiled files in production. It's not very different from what you'd do in any not-JS web framework.
- mtlynch 5y agoCool, thank you!
- perardi 5y agoSo you kind of have to decide, are just static templates and static assets all you need? In my particular instance: yup. I’m at the “loop through an array of things in a folder” level, not “deploy at scale” level.
- cholantesh 5y agoI would think that if you wanted a SPA-like experience, you wouldn't be choosing a static site generator, no?
- qbasic_forever 5y agoEverything is kind of converging. In the SPA world they realized the SEO sucks and they need static server rendered content, so there's a whole realm of SSR (server side rendering) built around it with Next.js, Vuepress, Sveltekit, etc. And on the static site side folks realized static sites can kinda suck and feel clunky, so loading some JS to add smoothness is nice. Check out Docusaurus for an example of a static site generator that actually uses React internally to build a SSR friendly SPA with fluid page loads. You don't have to choose one or the other anymore, you can get both a smooth SPA experience with full server rendered and SEO friendly content.