The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing? Maybe, but I know how much time I spend on rendering when I am working with Flask + Jinja and how it's 10x worse with Hugo.
Sadly, moving my blog way from Hugo would be too much work and I have to bear with it.
I ended up writing my own static site generator which has a good chunk of the features of Hugo but focusing on ease of use rather than increasing the feature count.
> The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway.
I have to disagree on that. My Pelican blog a few years back was taking several seconds to render vs milliseconds now and live reload is instant.
On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
> On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
It is going to change name this week or next week though, gutenberg was not original enough :(
And I liked that name.
I find it hard to understand what's so awful about Go Templates. Can you paste few examples of Go templating that you didn't like?
I have been following Hugo development, and I see that a lot of new features are getting added. But if it's something that I don't care about (i18n, SASS support, archetypes update, etc) I just ignore and don't use the new features.
I'm interested in knowing the overhead you are facing in keeping up. I just read the Release notes, and often find something I really wanted in the next update (if not everything in that update).
Overall Hugo development is quite conservative about introducing backward incompatible changes. They do happen, but very rarely (sign of progress). I remember the last time that happened about a year back when Page Bundles got introduced.
Because in my opinion, it starts to make sense if you understand what's going on behind the scenes with Go.
Hugo always struck me as an SSG for developers who want something in between the super-easy to use, with zero experience and, well, starting from scratch with every site.
Admittedly, even with a Golang background, I find there is quite a learning curve, so I wouldn't recommend it for anyone who is just trying to get their blog online.
This is not directed to me but I'd like to chime in and say that one doesn't need to know Go language to write Hugo templates. I appreciate Go Templates even without knowing Go.
It's quite simple:
- If you don't want to learn the templating for a static site generator, use one of the readymade themes.
- If you want to tinker with the themes or create your own themes, learn the templating language. There's no magic potion.
I actually wrote an article about why I choose Hugo, on the site I made using Hugo: https://verummeum.com/blog/2018/09/02/how-verummeum-is-build...
I’m looking into Jekyll, but can’t find any themes as minimalistic as my current Hugo theme. Any recommendations for a simple theme that doesn’t look like the default?
Edit: I found one (https://chesterhow.github.io/tale/). Beginning the switch soon.
You can use netlify but there's more setup to that than github imo.
with github you can also have as many sites as you want, little unknown fact just make 100 organizations and you have 100 sites. Content is open to anyone though. But the option is still nice to have
Plus you can actually look at the files on the server without modification or piping them to gzip to check the files.
You can also elect not to gzip files smaller than MTU (1500 bytes) and stop wasting your and your client's time. Realistically it's often wasteful to gzip small files (below 5KB).
If you're worried about squeezing maximum compression out of your text files, then you're serving up too much stuff to clients anyway. You probably don't care about your users... just about your bloated page loading fast. Get rid of some ad garbage.
That is what GitLab Pages expects, and because I can control my own pipeline with GitLab I am able to support multiple file formats that GitHub would not be able to support. It doesn't get any simpler than the example I provided.
If you just gzip from nginx, have content caching enabled (why don't you with static content?), and set a minimum size for gzipping, you have the best possible scenario and take a small hit on first requests of files until server-restart/cache-expiration.
Could you help me understand the value of this? It doesn't seem too hard for an SSG to provide documentation on what to put in a `.travis.yml` file.
In my experience, Netlify.com is 1000x better.
HTTPS, smooth integration with any SSG (including Hugo), any of the big git repos (GitHub, Gitlab, Bitbucket), great customer service, all for free.
That's a very surprising comment, without any detail. Can you elaborate on what you found surprising and magical?
> How variables work is impossible to understand. So is creating new layouts.
Again, some details would help understand the real problem.
[ It's agreed that you need to learn any new thing you'd like to use. ]
I have used Hugo for more than a year now, and I don't see any reason to move away from it, as it is awesome! Once you understand Go Templates (this is awesome too. Coming from Emacs-Lisp, I can associate the Go Template syntax with it in some ways :D).
I publish/update my site about a dozen times on days when I am updating my notes (which I publish to my site). It's a real boon to be able to save the content file, glance to the browser, and see it updated within that time. There is no exaggeration; it's that fast!
It's difficult to take your complaints seriously if you update your site "only once"!
> It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing?
Which weird design choice? Which easy solution?
I agree that doing new layouts is quite hit and miss. An extensive example using all possible variables would be quite welcome.
If your trying to do some form of email list, or e-commerce I would stick with Wordpress
Maybe we have different criteria for how a theme should be constructed.
I'm wanting to learn from our predecessors and avoid their mistakes.
Also the lack of flexibility in content organization, although this seems like a common feature of static site generators, so I won't hold it (too much) against it.
I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least.
This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive.
I'm looking into Gutenberg now, at least the template engine looks familiar enough.
What's wrong with the template engine? Also, before you switch to a different SSG, bring up the pain points in the documentation on the Hugo Discourse forum or as an issue in the HugoDocs GitHub repo. Please.
> Also the lack of flexibility in content organization
An example would help. What part of the content organization is inflexible. Of course there are some rules, else how will the SSG find the content consistently? But an example would help. (Atleast all the files don't have to be prefixed with date stamps.)
> I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least.
Examples please. What part is inaccessible? I have been using Hugo for 1+ year, and I am still going string on not learning Go (learning Nim instead, it's awesome!)
> This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive.
Typically when deploying SSG for a team, most of the team just contributes to the content (Markdown, for example), and few few folks handle the design of the site layout. So everyone doesnt even need to learn Go templates.