I’ve been using Hugo for my blog. For the most part, I really like it. One of my favorite features is running it as a local HTTP server and having it watch all my content. When I save a change to my post, the server notices it, refreshes the content and then refreshes the actual browser page too, which I think is pretty nifty (web sockets?). It essentially replicates my workflow when writing LaTeX and having a PDF viewer that auto-refreshes the content open. It’s nice.
One of my biggest complaints is that it is clearly fickle about how to render syntax highlighted code. If you use the default Markdown syntax (triple backticks), then AFAIK, you’re forced into relying on a Javascript library to do highlighting for you (blech). You can instead opt to have pygments do syntax highlighting when generating content, but you end up needing to use non-Markdown syntax for it.
Note that Hugo is the first and only static site generator I’ve ever used, so don’t take my praise as if I were claiming the feature was novel to Hugo. :-)
I use hugo and I like it but despite having a lot of documentation, I found it pretty hard to figure out the stuff I care about. Like, how do I get the infomation I put into the frontmatter? What variables are available where?
I’ve been using it quite a while so things may have improved on that front. On the whole I’m quite happy with it. It does everything I want and does it quickly.
I started using hugo for my personal site a few months ago, and don’t have any complaints. It’s fast and works. I’m not a power-user by any means, so I probably haven’t run into any of the dark corners. But when paired with S3 + Cloudfront it makes for a pleasant static site experience.
Functionally? Practically none: it takes markdown files as input, munges them together with some template files that mostly look like HTML and outputs a directory suitable for uploading to a web server.
The only reason difference is that, being written in Go, it is compiled to (by default) a single static binary which can be copied around wherever you like. By comparison Jekyll requires that you have a working ruby installation plus all of its dependencies.
An example of a real-world difference for me is that I have the hugo binary on my server, along with a git repo for my site. The repo has a post-receive hook which runs hugo whenever I push changes. I could do the same thing with Jekyll & ruby of course, but I have no other reason to have ruby on that server.
You really care in both cases, just for different reasons. With dynamic generation it’s visitors who are affected. With static generation it’s you (the site author). Most static site generators don’t do any kind of freshness or dependency checking so they have to regenerate the whole site every time you run them. And if it takes half a second to generate each page, then once you’re past a couple dozen articles, that starts to really hurt your edit/regenerate/refresh/edit cycle.
I’ve been pretty happy with it, although I’ve been tempted to rewrite it in Myrddin, mostly as a proof of concept rather than out of any pressing need.
Do people simply not care about search? None of these static generators seem to support it (fine) but nobody ever mentions it either. Seems like a pretty basic feature for a blog to have.
I even search my own blog quite frequently to find old posts. It’s very handy.
I assume many people running static sites just wait for google to index everything, and use “site:” queries if they are looking for something in particular. Or they just use grep/ack/ag on the markdown source files.
Yeah, I guess that too, but seems like a fault. Off the top of my head…
“Don’t depend on third party dependencies.”
Nobody includes a search box, limiting discoverability. I can remember to manually go to google and search (and spell your domain right). Or I can forget.
Google’s search results are obviously styled quite differently. For all the effort that people spend on styling their themes, they’d care about the appearance of search results too, no?
Search results don’t contain metadata you want, but only what Google decides is your page’s summary.
Difficult to execute advanced queries, since Google can’t access your own metadata (tags, author, date).
Can’t control relevance or order. Google may decide to “juice” a popular post, but it may not be the newest or best.
Forgets that companies or groups may have internal sites, not accessible via google.
I think for a blog, most casual bloggers simply don’t care much about search or “stickiness”. They have a link to an archive or index of all posts, and consider that “good enough”. Most people come in organically via search engines, or directly via reddit/HN/lobsters/etc. Few people probably stick around after reading the individual article.
Obviously people who are trying to derive money from their blogging efforts likely feel differently.
Nobody includes a search box, limiting discoverability. I can remember to manually go to google and search (and spell your domain right). Or I can forget.
I have seen a few people include a textbox that simply builds a google search string and sends you there. Personally, not my cup of tea. I fully agree with not wanting to rely on Google. I personally use duckduckgo whenever I can for my own searches. For my own dumb blog that nobody reads, I just don’t provide search at all. Just an “all articles” index.
Maybe something like what Sphinx does as far as search (an pre-built index file that javascript just loads and queries), would be a great fit for a static blog.
Most people come in organically via search engines, or directly via reddit/HN/lobsters/etc. Few people probably stick around after reading the individual article.
And even for those who do stick around, tags seem to solve the major use-case, which is browsing for other posts on a similar subject.
Well, that’s kind of my point. Every week somebody announces “I switched to a static site and lost ten pounds!” but there’s no discussion, not even a mention, of what functionality has been traded away. Certainly, people don’t need all of wordpress, but I consider integrated search a major feature. What I find more surprising is not that some people can get by without search, but that there is no discussion of it.
I never use on-site search on other people’s weblogs. Or more truthfully, only as a very last resort. Either I search them with Google, or else I’m subscribed and I search my feed reader’s database, which lets me formulate queries as complex as I want. (Which doesn’t work in your case because you don’t have a fulltext feed, grrr.)
And my own weblog I just search locally. It wouldn’t really occur to me to bring up my own site in my browser and then type into my own search box.
So it would in fact not really occur to me to mention the lack of search as a lost feature. Considering your experience that no one does, it’s in fact quite possible that your use of people’s on-site search is a personal peculiarity of yours, not a widely shared habit. :-)
I’ve been using Hugo for my blog. For the most part, I really like it. One of my favorite features is running it as a local HTTP server and having it watch all my content. When I save a change to my post, the server notices it, refreshes the content and then refreshes the actual browser page too, which I think is pretty nifty (web sockets?). It essentially replicates my workflow when writing LaTeX and having a PDF viewer that auto-refreshes the content open. It’s nice.
One of my biggest complaints is that it is clearly fickle about how to render syntax highlighted code. If you use the default Markdown syntax (triple backticks), then AFAIK, you’re forced into relying on a Javascript library to do highlighting for you (blech). You can instead opt to have pygments do syntax highlighting when generating content, but you end up needing to use non-Markdown syntax for it.
Note that Hugo is the first and only static site generator I’ve ever used, so don’t take my praise as if I were claiming the feature was novel to Hugo. :-)
See showcase for example sites running hugo here; http://gohugo.io/showcase/
I use hugo and I like it but despite having a lot of documentation, I found it pretty hard to figure out the stuff I care about. Like, how do I get the infomation I put into the frontmatter? What variables are available where?
I’ve been using it quite a while so things may have improved on that front. On the whole I’m quite happy with it. It does everything I want and does it quickly.
I started using hugo for my personal site a few months ago, and don’t have any complaints. It’s fast and works. I’m not a power-user by any means, so I probably haven’t run into any of the dark corners. But when paired with S3 + Cloudfront it makes for a pleasant static site experience.
How is this versus Jekyll? Jekyll is my go-to for static sites.
Functionally? Practically none: it takes markdown files as input, munges them together with some template files that mostly look like HTML and outputs a directory suitable for uploading to a web server.
The only reason difference is that, being written in Go, it is compiled to (by default) a single static binary which can be copied around wherever you like. By comparison Jekyll requires that you have a working ruby installation plus all of its dependencies.
An example of a real-world difference for me is that I have the hugo binary on my server, along with a git repo for my site. The repo has a
post-receivehook which runs hugo whenever I push changes. I could do the same thing with Jekyll & ruby of course, but I have no other reason to have ruby on that server.It’s written in a compiled language so it’s FASTER. If there’s one place you want performance it’s in a static site generator.
I would think I’d care much more about performance with dynamic generation since it has to do all the work every time.
You really care in both cases, just for different reasons. With dynamic generation it’s visitors who are affected. With static generation it’s you (the site author). Most static site generators don’t do any kind of freshness or dependency checking so they have to regenerate the whole site every time you run them. And if it takes half a second to generate each page, then once you’re past a couple dozen articles, that starts to really hurt your edit/regenerate/refresh/edit cycle.
My go-to so far has been USSM: http://loup-vaillant.fr/projects/ussm/
I’ve been pretty happy with it, although I’ve been tempted to rewrite it in Myrddin, mostly as a proof of concept rather than out of any pressing need.
Do people simply not care about search? None of these static generators seem to support it (fine) but nobody ever mentions it either. Seems like a pretty basic feature for a blog to have.
I even search my own blog quite frequently to find old posts. It’s very handy.
I assume many people running static sites just wait for google to index everything, and use “site:” queries if they are looking for something in particular. Or they just use grep/ack/ag on the markdown source files.
Yeah, I guess that too, but seems like a fault. Off the top of my head…
“Don’t depend on third party dependencies.”
Nobody includes a search box, limiting discoverability. I can remember to manually go to google and search (and spell your domain right). Or I can forget.
Google’s search results are obviously styled quite differently. For all the effort that people spend on styling their themes, they’d care about the appearance of search results too, no?
Search results don’t contain metadata you want, but only what Google decides is your page’s summary.
Difficult to execute advanced queries, since Google can’t access your own metadata (tags, author, date).
Can’t control relevance or order. Google may decide to “juice” a popular post, but it may not be the newest or best.
Forgets that companies or groups may have internal sites, not accessible via google.
I think for a blog, most casual bloggers simply don’t care much about search or “stickiness”. They have a link to an archive or index of all posts, and consider that “good enough”. Most people come in organically via search engines, or directly via reddit/HN/lobsters/etc. Few people probably stick around after reading the individual article.
Obviously people who are trying to derive money from their blogging efforts likely feel differently.
I have seen a few people include a textbox that simply builds a google search string and sends you there. Personally, not my cup of tea. I fully agree with not wanting to rely on Google. I personally use duckduckgo whenever I can for my own searches. For my own dumb blog that nobody reads, I just don’t provide search at all. Just an “all articles” index.
Maybe something like what Sphinx does as far as search (an pre-built index file that javascript just loads and queries), would be a great fit for a static blog.
And even for those who do stick around, tags seem to solve the major use-case, which is browsing for other posts on a similar subject.
How would search work, if it’s generating static files intended for serving on anything that can serve an HTML file?
Well, that’s kind of my point. Every week somebody announces “I switched to a static site and lost ten pounds!” but there’s no discussion, not even a mention, of what functionality has been traded away. Certainly, people don’t need all of wordpress, but I consider integrated search a major feature. What I find more surprising is not that some people can get by without search, but that there is no discussion of it.
You could use Google Search feature it works very well.
I never use on-site search on other people’s weblogs. Or more truthfully, only as a very last resort. Either I search them with Google, or else I’m subscribed and I search my feed reader’s database, which lets me formulate queries as complex as I want. (Which doesn’t work in your case because you don’t have a fulltext feed, grrr.)
And my own weblog I just search locally. It wouldn’t really occur to me to bring up my own site in my browser and then type into my own search box.
So it would in fact not really occur to me to mention the lack of search as a lost feature. Considering your experience that no one does, it’s in fact quite possible that your use of people’s on-site search is a personal peculiarity of yours, not a widely shared habit. :-)