Hugo: A fast and modern static website engine(gohugo.io)
gohugo.io
Hugo: A fast and modern static website engine
https://gohugo.io/
160 comments
The main reason I like Hugo is almost all other engines require me to install an entire Ruby or JavaScript ecosystem of packages on machine just to be able to preview my blog post. I don't want to manage the dependency hell when I don't have to.
I have never succeeded at installing any Ruby software in one go.
Ruby is terrible in this regard. Even Rails was a pain to setup last time I tried it (some years ago).
Me too :-(
I don't know about Ruby, but most sufficiently advanced ecosystems have package managers to help with dependency hell.
That still doesn't beat a single binary. :)
Why should I switch to this from Jekyll. There are dozens of site generators and when I go to their websites they all hash over the same set of features. Can anyone has used both or any other site generators please let me know what you found the differences to be?
My main reason, as funny as it may sound, is that it has one static binary.
I do use Jekyll, but given that a site will live for a few years at least, babysitting a ruby app isn't something I look forward to. Maybe my server has a different ruby version from my desktop, maybe some ruby gems are installed by my distribution and some others I have to install manually via gem leading to an inconsistent system state, every now and then something breaks, some functionality is provided by a gem I have to install manually and oops, I forgot to ssh to my server and install it there too. Oh, some gems can't be build because my server is hardened. Maybe jekyll got a new version and this leads to new ruby adventures.
Hugo has some other niceties too, like a built-in server with live reload and some clever link translating while testing on localhost.
I do use Jekyll, but given that a site will live for a few years at least, babysitting a ruby app isn't something I look forward to. Maybe my server has a different ruby version from my desktop, maybe some ruby gems are installed by my distribution and some others I have to install manually via gem leading to an inconsistent system state, every now and then something breaks, some functionality is provided by a gem I have to install manually and oops, I forgot to ssh to my server and install it there too. Oh, some gems can't be build because my server is hardened. Maybe jekyll got a new version and this leads to new ruby adventures.
Hugo has some other niceties too, like a built-in server with live reload and some clever link translating while testing on localhost.
I just last weekend revived a Jekyll site that had sat dormant for 3+ years and experienced exactly what you're describing. Not a fun afternoon. I do feel fortunate it was only _an_ afternoon, though.
I've been using the official Docker image for Jekyll (https://hub.docker.com/r/jekyll/jekyll/), which makes it fairly easy to avoid this particular problem. Assuming you're willing/able to have a dependency on Docker.
I am all for docker, we use it on production and I maintain a couple docker github repos.
But docker also has its own complexities. A user that can run docker, is almost as good as a user with sudo rights. Would you give your CI system root access on your server? There are of course workarounds, like permit the CI system to run only the jekyll image by adjusting the sudoers file but, at some point you have to think about the scope of configuration needed for deploying your site.
Also docker on hardened servers can be challenging, for example I had to disable most of grsecurity's chroot protections to have docker run.
But docker also has its own complexities. A user that can run docker, is almost as good as a user with sudo rights. Would you give your CI system root access on your server? There are of course workarounds, like permit the CI system to run only the jekyll image by adjusting the sudoers file but, at some point you have to think about the scope of configuration needed for deploying your site.
Also docker on hardened servers can be challenging, for example I had to disable most of grsecurity's chroot protections to have docker run.
This is the reason I wrote http://github.com/xeoncross/jr - the static, static website generator.
I really like the minimalism here. Is SEO a concern for this though?
From the example in the Github repo I understand that the JS only compiles the Markdown to HTML. All the content is still being served on the server-side and the client only handles the way it's presented. If I'm correct, I see no reason why it should hurt SEO. All the content is still being crawled.
Gotcha, thanks!
It's actually the most SEO friendly engine there is because there is nothing but content with Jr.
Actually, you will be missing things like the meta tags for an image preview when sharing the post on facebook and other sites. This still needs to be added.
Actually, you will be missing things like the meta tags for an image preview when sharing the post on facebook and other sites. This still needs to be added.
Aren't static site generators supposed to umm, generate a static site, so one wouldn't have to maintain any binaries?
Something has to generate that static site if it isn't being hand written, no?
Having a single binary that does that is easier to maintain than a script plus a stack of ever-changing dependencies.
Having a single binary that does that is easier to maintain than a script plus a stack of ever-changing dependencies.
Comment I replied to was describing the troubles caused by dev machine and server going out-of-sync.
I think many have a setup where the server grabs your website repo and creates your site. It's generally good to create your static files directly from your actual repo, whether that's on the host server or an artifact builder, etc.
The obvious thing that jumps to mind is CI/CD systems like Travis and Gitlab CI. The workflow for a lot of folks is to push to a git endpoint and then have the site picked up and then compiled automatically, rather than building on the dev machine then pushing.
Oh, I see.
I initially thought the comment was just about dependency hell, but now upon re-reading I find myself wondering what sort of (static site) setup requires both server and dev machine to share dependency state.
Maybe in the case of off-line testing before a push to remote?
Thanks for clarifying for me.
I initially thought the comment was just about dependency hell, but now upon re-reading I find myself wondering what sort of (static site) setup requires both server and dev machine to share dependency state.
Maybe in the case of off-line testing before a push to remote?
Thanks for clarifying for me.
Yes, my workflow is localhost development and testing, then pushing to a git repo and call via a hook a CI system which is used for both deployment and validation that the code works in a vanilla/reproducable environment.
Deployment via CI is important, because you may don't want all your devs to have ssh/ftp credentials to the server, or maybe you want to be able to work from many computers, yet prefer to keep your server ssh keys in only one.
Another issue is that multiple developers can use different operating systems. To be honest I have no idea how to setup jekyll on OS X or Windows. For hugo I just say to my devs “download and run this file”.
Deployment via CI is important, because you may don't want all your devs to have ssh/ftp credentials to the server, or maybe you want to be able to work from many computers, yet prefer to keep your server ssh keys in only one.
Another issue is that multiple developers can use different operating systems. To be honest I have no idea how to setup jekyll on OS X or Windows. For hugo I just say to my devs “download and run this file”.
Yes. When I write for my github pages blog, my edit-compile-debug cycle includes pushing to github and seeing how my post is rendered. I often get several minor edit pushes in a row.
If I had jekyll set up on my home environment, I could avoid that - but if the environment was different from github's, then I'd only be able to avoid it most of the time.
If I had jekyll set up on my home environment, I could avoid that - but if the environment was different from github's, then I'd only be able to avoid it most of the time.
GitHub provides a gem that does a decent job of replicating their Pages environment. It's not well advertised, but does work well [1].
[1] https://github.com/github/pages-gem
[1] https://github.com/github/pages-gem
This. I just can't seem to get a Ruby app to work in the first try.
I use Jekyll for my main site and Hugo for a couple one-off sites that maybe ten people will ever see. From what I've seen:
- Jekyll is a Ruby thing and requires you to have pretty much all the Ruby stack, including some kind of version manager like RVM. - Hugo is a binary that you can download and stick in ~/bin/. - Jekyll comes with Sass; Hugo comes with LiveReload. - You can extend Jekyll in Ruby. I wrote a thingy for Jekyll to generate breadcrumbs and color them based on a SHA hash of the page title; I don't think I could do this in Hugo without adding this sort of functionality to it myself and possibly submitting it upstream.
If I gave up my beloved auto-colorized breadcrumbs and moved to Hugo I'd still have to find a way to get Sass to execute on every Hugo rebuild, and there's still all the things I have Gulp do for production builds (autoprefix my CSS and minify the HTML). Seems like all programs in this space helpfully offer to be file-monitoring task runners, but I'd rather not have too many for what I think are simple sites.
- Jekyll is a Ruby thing and requires you to have pretty much all the Ruby stack, including some kind of version manager like RVM. - Hugo is a binary that you can download and stick in ~/bin/. - Jekyll comes with Sass; Hugo comes with LiveReload. - You can extend Jekyll in Ruby. I wrote a thingy for Jekyll to generate breadcrumbs and color them based on a SHA hash of the page title; I don't think I could do this in Hugo without adding this sort of functionality to it myself and possibly submitting it upstream.
If I gave up my beloved auto-colorized breadcrumbs and moved to Hugo I'd still have to find a way to get Sass to execute on every Hugo rebuild, and there's still all the things I have Gulp do for production builds (autoprefix my CSS and minify the HTML). Seems like all programs in this space helpfully offer to be file-monitoring task runners, but I'd rather not have too many for what I think are simple sites.
Your `/bin` technique works for Windows as well. I run Hugo for a couple of simple sites from a Windows machine. To do this, simply copy hugo.exe to C:\Windows and call it a day.
You'd be better having it out of the OS directory and a path reference surely, no?
In any case I'd think the drawback to this is the manual updating everytime, although overwriting a single file with curl/wget is probably not much more laborious than updating gems. And less likely to break. And wouldn't have dependency problems during the update.
.. you win this round rocky1138, but don't think this is over!
In any case I'd think the drawback to this is the manual updating everytime, although overwriting a single file with curl/wget is probably not much more laborious than updating gems. And less likely to break. And wouldn't have dependency problems during the update.
.. you win this round rocky1138, but don't think this is over!
I have moved from Jekyll to Hugo. Functionally it's the same for my use case, but in a single binary, meaning I don't have to maintain a full Ruby stack.
I've now moved it into Lambda, so to post a new page to my blog, I drop the markdown file in an S3 bucket, and literally a few seconds later my blog is updated, Cloudfront and all.
I've now moved it into Lambda, so to post a new page to my blog, I drop the markdown file in an S3 bucket, and literally a few seconds later my blog is updated, Cloudfront and all.
I too would love to read a write up. I've just recently moved a lot of things over to AWS (from a traditional VPS) and having hugo in Lambda would be the last piece of the S3+Cloudfront cake.
See my reply here https://news.ycombinator.com/item?id=12675780
Oh interesting! Care to share a small write-up about how you set it up?
The key stuff is from this project (not mine) https://github.com/ryansb/hugo-lambda
I couldn't get to CloudFormation template deploy working, so set it all up by hand, using the scripts in that repo as a base.
Once you figure out how it works, it becomes easy to start adding other commends to run (for example, I added some lines to invalidate CloudFront when I uploaded a blog post).
If I get a change over the next week or so I'll update a repo with the scripts I use, but as I said it's based on the above anyway.
I couldn't get to CloudFormation template deploy working, so set it all up by hand, using the scripts in that repo as a base.
Once you figure out how it works, it becomes easy to start adding other commends to run (for example, I added some lines to invalidate CloudFront when I uploaded a blog post).
If I get a change over the next week or so I'll update a repo with the scripts I use, but as I said it's based on the above anyway.
Use what makes you happy/gets the job done. I'm bep and one of the Hugo core devs, so I'm biased.
But I'm also a heavy Hugo user.
For me speed is very important. And with Hugo's great live reload, the editing of content and styles while getting instant feedback in the browser, it doesn't get much better than that.
Hugo 0.17 was released two days ago with native multilingual support. Important for some bloggers, but a pretty huge thing for documentation sites.
But I'm also a heavy Hugo user.
For me speed is very important. And with Hugo's great live reload, the editing of content and styles while getting instant feedback in the browser, it doesn't get much better than that.
Hugo 0.17 was released two days ago with native multilingual support. Important for some bloggers, but a pretty huge thing for documentation sites.
> Hugo 0.17 was released two days ago with native multilingual support. Important for some bloggers, but a pretty huge thing for documentation sites.
Thanks, didn't know that, I might take another look at it then.
Thanks, didn't know that, I might take another look at it then.
I saw that speed was greatly improved in Hugo 0.17 as well. Thanks for all your hard work!
I wrote a blog post yesterday about switching to Hugo from Jekyll: http://jvns.ca/blog/2016/10/09/switching-to-hugo/
I mostly did it because it's faster and sometimes I like to waste time microoptimizing my website, but I don't there's any really good reason to switch your static site generator if you're happy.
I mostly did it because it's faster and sometimes I like to waste time microoptimizing my website, but I don't there's any really good reason to switch your static site generator if you're happy.
I used Jekyll to run my website for a few years, and recently changed to Hugo because:
1. Speed. Hugo generates my site in seconds instead of minutes.
2. Less dependency issues with Ruby.
I plan to clean up and package the code into a theme soon. In the meantime you can see it at https://github.com/hypertexthero/sgg
1. Speed. Hugo generates my site in seconds instead of minutes.
2. Less dependency issues with Ruby.
I plan to clean up and package the code into a theme soon. In the meantime you can see it at https://github.com/hypertexthero/sgg
> Why should I switch to this from Jekyll?
I keep seeing this question when a new technology pops up when in a crowded field there are already usual suspects out there. You shouldn't switch if all your problems are solved. Why would you?
My rule of thumb is that new technologies are for fresh projects to evaluate whether they are good fit or not. I haven't used any static site generators before so I'm open to this but if I had already invested in an ecosystem I wouldn't give it up for a similar feature set unless it's massively better.
I keep seeing this question when a new technology pops up when in a crowded field there are already usual suspects out there. You shouldn't switch if all your problems are solved. Why would you?
My rule of thumb is that new technologies are for fresh projects to evaluate whether they are good fit or not. I haven't used any static site generators before so I'm open to this but if I had already invested in an ecosystem I wouldn't give it up for a similar feature set unless it's massively better.
one reason, Hugo is written by @spf13, a HN reader, and is easier to contact directly.
[0] https://news.ycombinator.com/user?id=spf13
[0] https://news.ycombinator.com/user?id=spf13
Decent-looking, free themes to get started with: http://themes.gohugo.io/. This probably doesn't make a big difference for you, since you already have sites made with Jekyll.
I haven't used Jekyll, but I know of a very vibrant community that exists around it. I didn't go with it as I also read about the challenge of installing it on Windows. Although I prefer other OS's for myself, I feel that having Window support as well tends to result in fewer surprise down the road.
EDIT: Some grammar stuff.
I haven't used Jekyll, but I know of a very vibrant community that exists around it. I didn't go with it as I also read about the challenge of installing it on Windows. Although I prefer other OS's for myself, I feel that having Window support as well tends to result in fewer surprise down the road.
EDIT: Some grammar stuff.
Jekyll also has the (perhaps unfair) advantage of being baked into GitHub pages, making it's workflow super easy
Jekyll's workflow is horrible compared to Hugo. A single binary that explains mostly whats going wrong vs a crazy mix of ruby gems that need to be installed with a meta-package that is hard to find in the Github support docs.
I currently use it in place of Jekyll on github. I fought jekyll enough trying to get it to do what I wanted. Now I don't need to worry about it.
Another awesome feature: Since this is mostly used for personal sites and a lot of those are portfolio + blogs you have multiple "content type"s made by different folders. So you can show all your posts easily by iterating over the posts and then show all your projects by doing the same. They each can have separate default templates.
I currently use it in place of Jekyll on github. I fought jekyll enough trying to get it to do what I wanted. Now I don't need to worry about it.
Another awesome feature: Since this is mostly used for personal sites and a lot of those are portfolio + blogs you have multiple "content type"s made by different folders. So you can show all your posts easily by iterating over the posts and then show all your projects by doing the same. They each can have separate default templates.
> Jekyll's workflow is horrible compared to Hugo.
Odd. I found the exact same opposite. Granted, I have been using Jekyll for some time now and only tried Hugo for one afternoon. But I found Hugo very opinionated in how the site should be structured and it felt more like working with a CMS than with a static site.
Odd. I found the exact same opposite. Granted, I have been using Jekyll for some time now and only tried Hugo for one afternoon. But I found Hugo very opinionated in how the site should be structured and it felt more like working with a CMS than with a static site.
We do this for hugo (and any other build tool) at Netlify (https://www.netlify.com) together with a whole bunch of extra features to make the workflow even easier.
Could you elaborate on this? As someone unfamiliar with Jekyll, I don't know what you mean.
On GitHub Pages, GitHub will run a basic Jekyll for you -> you don't have to install or run it locally, just edit the source files in the repo and it builds and publishes the page for you.
You could get the same result with Hugo + Travis (+ Travis' encrypted file thing). You don't get it out of the box, but it's do-able.
Fast, reliable, extremely responsive dev team, very clean codebase what's not to like?
I tried, but for some reason I just kept going back to Jekyll, the community is so good, it's so simple, it just works. I think Hugo probably is as good but it's likely what you start with.
[deleted]
I've built two client sites with Hugo recently with great success: https://www.halorestorationservices.com/ and http://www.laviagelaw.com/. Both are fairly extensive in their use of templates and Hugo's features.
That said, I typically grab from site templates and don't do a lot of css/js manipulation myself. Though, if I did, I'd just set-up Grunt or Gulp to handle automatic regeneration of the final asset files.
For those asking why should you switch? Well, exactly, why should you? If you are happy with your current toolset and are productive using it, isn't it all about the final product anyway? Who cares what you use. But if you aren't happy with your toolset, or are just keeping an eye out for something that might be better ...
Hugo is known most for its speed. If you have a site with many, many pages that needs to be built quickly, strongly consider Hugo. It really is super fast. I'm actually considering building out a very large sample site with various engines to demonstrate just how fast it is. I'll try to find this post on Hacker News again and post if I ever get around to it.
Layout of content is extremely nice in Hugo. Basically, you just organize everything in directories how you want it to be rendered in the end. This can be overridden if necessary.
Documentation is also really nice. I'm actually about to build another client site and considered using Jekyll (you know, just to see), but found the documentation lacking compared to Hugo. It also seems to needlessly complicate things, but that's probably just personal opinion based on prior experience with Hugo.
There are a few downsides obviously. You get what you get, unless you want to add functionality and recompile. But now you have to maintain your own version.
As parent5446 mentioned, variables can be a bit confusing. They are not as idiot proof as I'd like them to be.
That said, I typically grab from site templates and don't do a lot of css/js manipulation myself. Though, if I did, I'd just set-up Grunt or Gulp to handle automatic regeneration of the final asset files.
For those asking why should you switch? Well, exactly, why should you? If you are happy with your current toolset and are productive using it, isn't it all about the final product anyway? Who cares what you use. But if you aren't happy with your toolset, or are just keeping an eye out for something that might be better ...
Hugo is known most for its speed. If you have a site with many, many pages that needs to be built quickly, strongly consider Hugo. It really is super fast. I'm actually considering building out a very large sample site with various engines to demonstrate just how fast it is. I'll try to find this post on Hacker News again and post if I ever get around to it.
Layout of content is extremely nice in Hugo. Basically, you just organize everything in directories how you want it to be rendered in the end. This can be overridden if necessary.
Documentation is also really nice. I'm actually about to build another client site and considered using Jekyll (you know, just to see), but found the documentation lacking compared to Hugo. It also seems to needlessly complicate things, but that's probably just personal opinion based on prior experience with Hugo.
There are a few downsides obviously. You get what you get, unless you want to add functionality and recompile. But now you have to maintain your own version.
As parent5446 mentioned, variables can be a bit confusing. They are not as idiot proof as I'd like them to be.
I agree with you about everything except the documentation being very nice. I was stuck on somewhat of an edge case, and the tutorial style documentation doesn't help for that. I ended up wading through the forum, which is cool to have, but not the same as authoritative docs.
I too am curious about your edge case. I have had to wade through the forums, or even check out blogs for a few things myself. Though, I'd be surprised if this wasn't the case with another tool.
> I'm actually considering building out a very large sample site with various engines to demonstrate just how fast it is. I'll try to find this post on Hacker News again and post if I ever get around to it.
That would be fantastic. Do you have any shortlist of engines you are going to test?
Also, I have a question about the two website you've built. Did you also write the copy (content) yourself or was it sourced from the client/a third-party?
That would be fantastic. Do you have any shortlist of engines you are going to test?
Also, I have a question about the two website you've built. Did you also write the copy (content) yourself or was it sourced from the client/a third-party?
Can I ask you, what libs do you use for the layout and theme?
The Halo site was built with a modified version of the Assan template available on WrapBootstrap.com - so Bootstrap, jQuery and the like. It's not perfect, but I strip out unnecessary plugins and combine most of the assets to minimize resource loading. Ideally most of the unused CSS and JS would be stripped out too to further reduce load times, but this becomes a lot more complicated and is usually not worth it for a variety of reasons.
The lawyer site was done with the Elevation theme from Templated.co. Less manipulation here, other than a few changes of tags for SEO purposes. No CSS framework (that I know of anyway), skel.js and jQuery.
The lawyer site was done with the Elevation theme from Templated.co. Less manipulation here, other than a few changes of tags for SEO purposes. No CSS framework (that I know of anyway), skel.js and jQuery.
Thank you.
Is Hugo very blog-oriented, like Jekyll? I started using Lektor and quite like its data-agnostic model, but I would like something more actively developed.
Hugo is not blog oriented and works well with any site structure.
A good way to a lot of different ways of how people are using Hugo is with the site showcase.
http://gohugo.io/showcase/
A good way to a lot of different ways of how people are using Hugo is with the site showcase.
http://gohugo.io/showcase/
That looks great, thank you! It also looks pretty actively developed, so I'm going to have to give it a look!
I love Hugo! I have been hosting https://hidekisaito.com/ and its .onion counterpart http://hideki24bd6yof6s.onion/ using Hugo, it's very easy way to get the page up and running. I use Visual Studio Code to write the contents in markdown, and I got task runner that configured to run Hugo and then rsync them to the servers.
Is using Hugo suitable even for non-tech people?
I have worked with several systems during last years (Wordpress, Drupal, custom apps, several wikis), but I am still not happy with them, because of missing combination "easy to maintain" and "easy to use by non-tech people (when installed)". In my experience, non-tech people can use markdown (if properly motivated) at most and can log in into a system, but that is.
Is Hugo going to help here?
In my experience as a not-very-technical person who has worked with WordPress extensively and dabbled in static site generators, WordPress is an order of magnitude easier to deal with.
Further thoughts on this: https://poststatus.com/static-site-generators-versus-wordpre...
Further thoughts on this: https://poststatus.com/static-site-generators-versus-wordpre...
There are content-as-an-API services (e.g. Contentful, Prismic.io, CloudCMS) and some editors (e.g potion, Content Editor) to make managing markdown on GitHub easier. Either should help with non-tech people creating content.
Full disclosure: I work for Contentful.
Full disclosure: I work for Contentful.
There are some hurdles yet to be had for the non-tech person. But I would claim that when he/she gets the split panel up and running with the markdown editor on the left and the live-reloading browser on the right, it is no way going back to whatever Wordpress feeds you.
There are initiatives writing some nice clients on top of static site generators such as Hugo and Jekyll, but in my head you then lose out some of the most valuable features of Hugo, speed and simplicity.
There are initiatives writing some nice clients on top of static site generators such as Hugo and Jekyll, but in my head you then lose out some of the most valuable features of Hugo, speed and simplicity.
I don't think most genuinely non-technical people would prefer Markdown over real WYSIWYG.
Try Lektor for running locally or Hubpress if you look for github based online generator.
you can use prose or netlify which has web-ui, or desktop Typora wysiwyg
For those wondering what to do with an asset pipeline, check out Victor Hugo (https://github.com/netlify/victor-hugo), a boilerplate for using gulp and webpack too manage the asset pipeline around a hugo based project.
There is a growing trend of static websites.
My favorite tool for static websites is Middleman (https://middlemanapp.com/), but competition is always good.
My favorite tool for static websites is Middleman (https://middlemanapp.com/), but competition is always good.
But why this over another site generator? Metalsmith has total flexability, Lektor has a web UI for those who dislike writing in plain text, Jekyll has simplicity... Hugo doesn't really seem to have any advantages.
> But why this over another site generator? Metalsmith has total flexability, Lektor has a web UI for those who dislike writing in plain text
Hugo predates those two. It got its first tagged release almost a year before Metalsmith and two years before Lektor.
Hugo predates those two. It got its first tagged release almost a year before Metalsmith and two years before Lektor.
That doesn't mean I should use it now.
there are at least 10+ good static site engines, why is Hugo better? I tried many of them and Hugo definitely has nothing to stand out in my experience.
Disclaimer: I am the creator of Hugo. Trying to provide an impartial perspective here for the readers.
Everyone has different needs and tastes so no tool works for everyone. Here's how I see Hugo's strengths and weaknesses. I'd love to know what other people see are Hugo's strengths and weaknesses.
Hugo's key differentiators: 1. Ease of install 2. Speed (critical for large sites) 3. Integrated live-reload while editing in near realtime 4. Multilingual capabilities 5. Flexible 6. Very strong community 7. Very good & comprehensive documentation (but not perfect...yet)
Hugo struggles with: 1. Not integrated with Github like Jekyll (though webhooks solve this to a large degree) 2. No plugin support 3. Media & Asset processing not tightly integrated
There are many solutions that work around Hugo's limitations, some which are quite elegant, but at the end of the day they are workarounds and require external tooling.
We would love to address these weaknesses in upcoming releases as best we can. If you are interested in helping we would love to have help.
Everyone has different needs and tastes so no tool works for everyone. Here's how I see Hugo's strengths and weaknesses. I'd love to know what other people see are Hugo's strengths and weaknesses.
Hugo's key differentiators: 1. Ease of install 2. Speed (critical for large sites) 3. Integrated live-reload while editing in near realtime 4. Multilingual capabilities 5. Flexible 6. Very strong community 7. Very good & comprehensive documentation (but not perfect...yet)
Hugo struggles with: 1. Not integrated with Github like Jekyll (though webhooks solve this to a large degree) 2. No plugin support 3. Media & Asset processing not tightly integrated
There are many solutions that work around Hugo's limitations, some which are quite elegant, but at the end of the day they are workarounds and require external tooling.
We would love to address these weaknesses in upcoming releases as best we can. If you are interested in helping we would love to have help.
Just wanna say thanks for having RSS support!
Thank you for the summation. Speed is definitely an adantage.
It might sound strange saying this in 2016 but during development markup generation speed can be an issue for projects of certain sizes...
That might be a reason.
Speed and portability for me.
I feel most comfortable with pelican but with huge sites it gets kind of slow.
I feel most comfortable with pelican but with huge sites it gets kind of slow.
I think one the biggest draws of something like Hugo would be that it's amazingly fast. You can check out the video [0] here that shows a benchmark. It generates 5,000 pages in around 6-7.
Another is that it's a single file to deal with. This may be different when you get into making your own themes, but to get going you just need to download the single file for your platform.
[0]: https://gohugo.io/overview/introduction/
Another is that it's a single file to deal with. This may be different when you get into making your own themes, but to get going you just need to download the single file for your platform.
[0]: https://gohugo.io/overview/introduction/
The video showing two benchmarks, one on a SSD and one on a HD, is kind of pointless and possibly misleading. The files are already in memory cache, and the disk is not being read from. There is no way 5000 files can be loaded off a HD in less than 6 seconds, especially on NTFS.
That doesn't make the benchmark totally uninteresting, though, because dealing with 5000 posts in 5 to 7s is still good, and would be what you'd get from several rendering iterations, which you'd get for subsequent edits of your text, or tweaks of your templates.
The point I'm trying to make is that he should not care about showing more than one measurement.
That doesn't make the benchmark totally uninteresting, though, because dealing with 5000 posts in 5 to 7s is still good, and would be what you'd get from several rendering iterations, which you'd get for subsequent edits of your text, or tweaks of your templates.
The point I'm trying to make is that he should not care about showing more than one measurement.
I tried out, Jekyll, Hugo and neither one met my needs.
I found middleman to be the most powerful static site generator.
I found middleman to be the most powerful static site generator.
Ditto, but I settled on Pelican because Python, which makes it far more hackable IMO.
Hugo's speed is overrated (and overstated). Anything with caching (like Pelican) makes this somewhat of a non-issue IMO. Incidentally, the longest part of generation for me is thumbnails and other asset bundling, which is essentially imagemagick.
Having said that, Hugo does many things right and is pretty fully featured, so it's hard not to recommend. It would be nice if all static site generators used the same format (front matter?) so switching engines could be more seamless.
Hugo's speed is overrated (and overstated). Anything with caching (like Pelican) makes this somewhat of a non-issue IMO. Incidentally, the longest part of generation for me is thumbnails and other asset bundling, which is essentially imagemagick.
Having said that, Hugo does many things right and is pretty fully featured, so it's hard not to recommend. It would be nice if all static site generators used the same format (front matter?) so switching engines could be more seamless.
Out of interest, which needs of yours weren't met by Jekyll and Hugo?
For a bizzare reason you cant combine pagination and categories in Jekyll?
I had to try to hack add ons like jekll paginate.
Hugo actually had all the features I wanted but It was something to do with the locations of templates for custom collections were in a very opinionated yet weird place and the docs werent super clear about how it worked? And theres literally only a handful of tutorials.
Theres a lot of good about Hugo though and Im not denigrating it all.
Middleman was just perfect on every level. Elegant, customizable, feature rich, with great docs.
Its also Ruby so its like an evolved Jekyll pokemon.
But then again all this is just my opinion. :)
I had to try to hack add ons like jekll paginate.
Hugo actually had all the features I wanted but It was something to do with the locations of templates for custom collections were in a very opinionated yet weird place and the docs werent super clear about how it worked? And theres literally only a handful of tutorials.
Theres a lot of good about Hugo though and Im not denigrating it all.
Middleman was just perfect on every level. Elegant, customizable, feature rich, with great docs.
Its also Ruby so its like an evolved Jekyll pokemon.
But then again all this is just my opinion. :)
I tried Hugo on a quick prototype for a API documentation site, but quickly ran into limitations in the go template engine and how Hugo handles variables.
It's great for a simple static site, but without a way to extend the template engine easily, there was no way to do what we wanted (which was to style a yaml file of service metadata into a swagger like UI).
It's great for a simple static site, but without a way to extend the template engine easily, there was no way to do what we wanted (which was to style a yaml file of service metadata into a swagger like UI).
I switched from Jekyll -> own rolled Node.js generator -> Hugo.
For me it is better because of simplicity and speed. I use it to power a 400 page blog (https://shapeshed.com/) with this source code (https://github.com/shapeshed/shapeshed.com).
I used Jekyll in a small organisation and it meant everyone needed a working Ruby environment This caused much pain across platforms. Hugo ships a single binary for multiple platforms so setup is far simpler. It is also amazingly fast and there have been major performance improvements in 0.17 too (https://gohugo.io/meta/release-notes/).
I love it!
For me it is better because of simplicity and speed. I use it to power a 400 page blog (https://shapeshed.com/) with this source code (https://github.com/shapeshed/shapeshed.com).
I used Jekyll in a small organisation and it meant everyone needed a working Ruby environment This caused much pain across platforms. Hugo ships a single binary for multiple platforms so setup is far simpler. It is also amazingly fast and there have been major performance improvements in 0.17 too (https://gohugo.io/meta/release-notes/).
I love it!
Maybe Hugo has improved, but when I switched our static website from Jekyll over to Hugo, there was a lot to be wished for.
One of the problems is that it's not easy to integrate Hugo into any other build process. For better or worse, many website build tools right now are in JavaScript (npm, bower, gulp, grunt, yo, etc.). And on the flip side, Hugo does not do any static resource processing. So for our site, we needed to have Grunt tasks fetch third-party libraries, compile the JS and CSS, perform lint checks, and finally put files into the correct location so that Hugo could then be called to build the final site. Now, to be fair, Jekyll core does not do any of this for you either, but at least there are plugins in Jekyll [0], and integration of custom build scripts becomes a bit smoother.
This brings me to my second pain, which is shortcodes [1]. It is the closest Hugo has to plugins. Hugo completely disallows writing raw HTML in Markdown content (the cited reason is it "is in complete opposition to the intent of using a bare-bones format for our content and utilizing templates to apply styling for display"). It makes sense, and I'd use a system that separates raw content from more complicated code. But when you start needing to put dynamic content in your site, shortcodes in Hugo specifically are extremely unflexible. You're stuck using the Go template library that underlies Hugo, which gives you very limited information about the page being rendered.
Local variables, for example, are not scoped the way you think they are, and you are stuck with a "scratchpad" hack that Hugo put in [2]. To see this in action, here is code I had to write to make a shortcode for responsive images [3]. The entire process involved starting with a JSON file containing the shared configuration, having Grunt read this config to generate the images, and then using the code in [3] to also read from that file and find where the images would be. This is all without syntax highlighting or any useful debugging tools.
There are also just some times you really need HTML in your Markdown, and it doesn't make sense to use a shortcode. For example, a web page that contains very specific formatting that cannot be expressed in Markdown, but is also specific enough to that page to not be separated from the page's content.
All in all, we switched to Hugo for a reason: it had many features that Jekyll was missing at the time (although many it has since added). We wanted to express our website in a well-structured format that also allowed Markdown so not-especially-tech-savvy people could edit content. In the end, we got it working (here's the site, a good example of how a Hugo site can come out pretty great IMO [4]), but it caused a whole lot of pain and misery for me.
[0] https://jekyllrb.com/docs/plugins/ [1] https://gohugo.io/extras/shortcodes/ [2] https://discuss.gohugo.io/t/counter-variables-and-template-s... [3] http://pastebin.com/ZjiWpDHc [4] https://www.castlepointanime.com/
One of the problems is that it's not easy to integrate Hugo into any other build process. For better or worse, many website build tools right now are in JavaScript (npm, bower, gulp, grunt, yo, etc.). And on the flip side, Hugo does not do any static resource processing. So for our site, we needed to have Grunt tasks fetch third-party libraries, compile the JS and CSS, perform lint checks, and finally put files into the correct location so that Hugo could then be called to build the final site. Now, to be fair, Jekyll core does not do any of this for you either, but at least there are plugins in Jekyll [0], and integration of custom build scripts becomes a bit smoother.
This brings me to my second pain, which is shortcodes [1]. It is the closest Hugo has to plugins. Hugo completely disallows writing raw HTML in Markdown content (the cited reason is it "is in complete opposition to the intent of using a bare-bones format for our content and utilizing templates to apply styling for display"). It makes sense, and I'd use a system that separates raw content from more complicated code. But when you start needing to put dynamic content in your site, shortcodes in Hugo specifically are extremely unflexible. You're stuck using the Go template library that underlies Hugo, which gives you very limited information about the page being rendered.
Local variables, for example, are not scoped the way you think they are, and you are stuck with a "scratchpad" hack that Hugo put in [2]. To see this in action, here is code I had to write to make a shortcode for responsive images [3]. The entire process involved starting with a JSON file containing the shared configuration, having Grunt read this config to generate the images, and then using the code in [3] to also read from that file and find where the images would be. This is all without syntax highlighting or any useful debugging tools.
There are also just some times you really need HTML in your Markdown, and it doesn't make sense to use a shortcode. For example, a web page that contains very specific formatting that cannot be expressed in Markdown, but is also specific enough to that page to not be separated from the page's content.
All in all, we switched to Hugo for a reason: it had many features that Jekyll was missing at the time (although many it has since added). We wanted to express our website in a well-structured format that also allowed Markdown so not-especially-tech-savvy people could edit content. In the end, we got it working (here's the site, a good example of how a Hugo site can come out pretty great IMO [4]), but it caused a whole lot of pain and misery for me.
[0] https://jekyllrb.com/docs/plugins/ [1] https://gohugo.io/extras/shortcodes/ [2] https://discuss.gohugo.io/t/counter-variables-and-template-s... [3] http://pastebin.com/ZjiWpDHc [4] https://www.castlepointanime.com/
I have also done websites in Hugo; the inflexibility of golang's template processor was extremely limiting to the point that I would never use Hugo again.
I've been using html within my markdown files and hugo without issue. Admittedly, I'm only inserting simple html like h2 elements, or simple links to other sites...but its still html in a markdown file, and hugo does not mind, and in fact processes it all just fine.
I came over from lektor to hugo. As much as I liked lektor's UI (via local website), hugo's binary is far better for me since I'm constantly jumping to different machines (windows, linux, OS X), and didn't want the hassle of set up on each.
That being said, the one thing that is annoying with hugo - and I DID see this with lektor as well though not as annoying as hugo - was wiring up your first template. Ugh, configuring templates - or perhaps more specifically variables - is a big time sink. Other than that, hugo is my generator of choice.
I came over from lektor to hugo. As much as I liked lektor's UI (via local website), hugo's binary is far better for me since I'm constantly jumping to different machines (windows, linux, OS X), and didn't want the hassle of set up on each.
That being said, the one thing that is annoying with hugo - and I DID see this with lektor as well though not as annoying as hugo - was wiring up your first template. Ugh, configuring templates - or perhaps more specifically variables - is a big time sink. Other than that, hugo is my generator of choice.
Seconding this -- I use HTML inside hugo all the time. The problem hugo has is that you cannot include _partials_ in your markdown, like you can with Jekyll.
And as parent5446 said, the shortcodes don't give you enough information in some cases.
I also think that people who aren't very technical will have a hard time getting started with the Go templating language, whereas Jekyll is dead obvious (super loose scoping, it looks like any other scripting language, etc.)
And as parent5446 said, the shortcodes don't give you enough information in some cases.
I also think that people who aren't very technical will have a hard time getting started with the Go templating language, whereas Jekyll is dead obvious (super loose scoping, it looks like any other scripting language, etc.)
I doubt this opinion is fashionable, but I prefer simple. HTML or bust.
But aren't static site generators essentially agreeing with you? Obviously they are easier to scale up, too - manual find-n-replace across a site with hundreds of pages is a lot more risky than letting automation take care of the details.
I started developing my blog using Octropress (Jekyll derivative) many years back. I painfully installed it the first time (Ruby dependencies). I tried upgrading to Octopress 2.0 probably 2 years back, but I was never successfully able to install all the dependencies on my work machine. More than that, I never got it working on multiple platforms. I wished to be able to post to my blog from both home (Windows) and work (RHEL6.6), but that just wasn't possible.
Hugo was a breath of fresh air:
- Easy to install (auto-installs all the dependent go packages without a hitch, and results in a single static binary!)
- Easy to set up a web page (hardly took 10 minutes)
Having the basic web site building going, I can now tinker as I like with the layouts, config.toml, etc. Hugo has allowed me to focus more on my web site content and design than burning time figuring out how to successfully install (and keep upgraded) the web site building. (All I need to do to update hugo to the latest and greatest is: "go get -u -v github.com/spf13/hugo").
Hugo was a breath of fresh air:
- Easy to install (auto-installs all the dependent go packages without a hitch, and results in a single static binary!)
- Easy to set up a web page (hardly took 10 minutes)
Having the basic web site building going, I can now tinker as I like with the layouts, config.toml, etc. Hugo has allowed me to focus more on my web site content and design than burning time figuring out how to successfully install (and keep upgraded) the web site building. (All I need to do to update hugo to the latest and greatest is: "go get -u -v github.com/spf13/hugo").
I was surprised that I had a already-visited link on HN. This weekend I was trying to migrate my wordpress blog to Hugo... to no avail. The plugins mentioned all killed my Wordpress, so now I'm stuck transcribing my posts one by one by hand. Anyone knows of a good exporter for WP that keeps the footnotes/ref and doesn't kill WP?
Perhaps give WP-CLI a try? [0]
[0] https://wp-cli.org/commands/export/
[0] https://wp-cli.org/commands/export/
Docker documentation recently moved away from Hugo in favor of Jekyll.
https://blog.docker.com/2016/09/announcing-new-docs-repo-git...
In the blog article above, they mentioned a problem they faced.
> The docs were built around Hugo, which is not natively supported by GitHub, and took minutes to build, and even longer for us to deploy.
I've been using Middleman for static site for a couple of years. I'm thinking about moving to Hugo because I read HN comments Hugo is much faster than other alternatives. But reading the official Docker blog, I'm thinking twice.
Could anyone tell me the reason why Docker blog took too much time to build with Hugo that is supposed to build really fast?
https://blog.docker.com/2016/09/announcing-new-docs-repo-git...
In the blog article above, they mentioned a problem they faced.
> The docs were built around Hugo, which is not natively supported by GitHub, and took minutes to build, and even longer for us to deploy.
I've been using Middleman for static site for a couple of years. I'm thinking about moving to Hugo because I read HN comments Hugo is much faster than other alternatives. But reading the official Docker blog, I'm thinking twice.
Could anyone tell me the reason why Docker blog took too much time to build with Hugo that is supposed to build really fast?
> Docker documentation recently moved
> the reason why Docker blog took too much time to build
Not the blog, but documentation. And it takes so much time because it's just so huge. Just by itself it would be pretty big, but consider that they maintain a clone for each release version. You end up with lots of documents very fast.
What I'm not sure about is why it would have to be completely rebuilt every time since the build results would have to be committed. Maybe they had two repositories? Or Hugo can't do "incremental" builds well?
> the reason why Docker blog took too much time to build
Not the blog, but documentation. And it takes so much time because it's just so huge. Just by itself it would be pretty big, but consider that they maintain a clone for each release version. You end up with lots of documents very fast.
What I'm not sure about is why it would have to be completely rebuilt every time since the build results would have to be committed. Maybe they had two repositories? Or Hugo can't do "incremental" builds well?
Disclaimer. I am the author of Hugo and former exec at Docker. I don't speak for Docker and I've been gone for over a year so the following is at best a guess.
From my reading of their blog post I see that their primary motivation for the change was first to consolidate all of their documentation into a single repo, instead of spread across all of their various projects. As they have grown as an organization and now have a large number of projects this approach has a lot of strengths and makes a lot of sense. Any SSG could work in this new formation, but the change gave them an opportunity to make a change. Additionally Github provides a lot of Jekyll features out of the box that help with managing these documentation sites.
I believe it is not a question of performance between Hugo and Jekyll, but a question of Docker's specific workflow. As Github already runs Jekyll server side all the contributors need to do is upload the source file and then Github does the rest. In contrast, Hugo based docs would have to be built locally and then uploaded as completed html. There are easy ways to set up services through github hooks that do the exact same thing as Jekyll already does but that requires additional setting up.
Since Github is doing all the work it is easier on the contributors since all they need to do is `git push`. This also enables people to edit right in the github edit screen and not bother with setting up anything client side. The total time to process the site is likely much longer on Jekyll but the time that their contributors spend is much less as they aren't building the site locally.
From my reading of their blog post I see that their primary motivation for the change was first to consolidate all of their documentation into a single repo, instead of spread across all of their various projects. As they have grown as an organization and now have a large number of projects this approach has a lot of strengths and makes a lot of sense. Any SSG could work in this new formation, but the change gave them an opportunity to make a change. Additionally Github provides a lot of Jekyll features out of the box that help with managing these documentation sites.
I believe it is not a question of performance between Hugo and Jekyll, but a question of Docker's specific workflow. As Github already runs Jekyll server side all the contributors need to do is upload the source file and then Github does the rest. In contrast, Hugo based docs would have to be built locally and then uploaded as completed html. There are easy ways to set up services through github hooks that do the exact same thing as Jekyll already does but that requires additional setting up.
Since Github is doing all the work it is easier on the contributors since all they need to do is `git push`. This also enables people to edit right in the github edit screen and not bother with setting up anything client side. The total time to process the site is likely much longer on Jekyll but the time that their contributors spend is much less as they aren't building the site locally.
I tried out dozens of generators; for plain, simple, mostly text blogs, Hugo is fine. And Pelican, and Jekyll, and nearly all.
Hugo falls short when it comes to custom needs, like EXIF handling, or intermediate image downsizing for responsive images, because adding features to Hugo is painful.
Hugo falls short when it comes to custom needs, like EXIF handling, or intermediate image downsizing for responsive images, because adding features to Hugo is painful.
If you want custom features the only option I found is Nikola : get Nikola.com
The plugin system let's you do nearly anything you can think of,and if not the devs are will consider updates to make it possible
The plugin system let's you do nearly anything you can think of,and if not the devs are will consider updates to make it possible
Obviously not true; a quick search shows the two options the op mentioned, Jekyll [0] and Pelican [1] have plugins.
I'm familiar with Pelican. Apart from writing plugins (with excellent signals to hook into), you can replace the main class with a custom class and get basically any behaviour you want.
[0] https://jekyllrb.com/docs/plugins/ [1] http://docs.getpelican.com/en/3.6.3/plugins.html
I'm familiar with Pelican. Apart from writing plugins (with excellent signals to hook into), you can replace the main class with a custom class and get basically any behaviour you want.
[0] https://jekyllrb.com/docs/plugins/ [1] http://docs.getpelican.com/en/3.6.3/plugins.html
[deleted]
Do you agree that pelican is the best when it comes to adding features and plugins?
I do like Hugo because of the speed and portability.
I do like Hugo because of the speed and portability.
Steve Francia has written a nice blog article about the recent Hugo 0.17 release: http://spf13.com/post/hugo-goes-global/
Great update and a nice blog. I wonder if he knows about the distasteful ads that are shown by Disqus, right underneath his own writing.
I didn't. I'm shocked how awful these ads are. I've turned it off completely.
The Taxonomy section of Hugo sounds interesting [1]. I've been putting up my personal comments and reviews of stories in book anthologies and magazines via Goodreads. I also put up reviews of individual books on Goodreads. I would love to be able to organise what I've written in a static website via categories like story title, author, magazine/anthology appearances, etc. and this looks like the way to do it.
- [1] https://gohugo.io/taxonomies/overview/
- [1] https://gohugo.io/taxonomies/overview/
Is this a viable alternative to Hyde (the python static site generator) ?
I was using this instead of Jekyll for a hardly updated website and I can't get it running on Arch linux (without putting too much effort into it). The whole system looks pretty dated and dead too (I think the upstream URL doesn't even work any more).
I would be really happy to get a "set and forget" solution, so I can update the site 3 times in a year and don't have to worry about the system.
Is Hugo stable enough for something like that ? Is the Jekyll Docker image the better solution for this ?
I was using this instead of Jekyll for a hardly updated website and I can't get it running on Arch linux (without putting too much effort into it). The whole system looks pretty dated and dead too (I think the upstream URL doesn't even work any more).
I would be really happy to get a "set and forget" solution, so I can update the site 3 times in a year and don't have to worry about the system.
Is Hugo stable enough for something like that ? Is the Jekyll Docker image the better solution for this ?
I'm sure Hugo is fine, but if you want something in Python, try Pelican. And use a virtualenv, to avoid mixing up the system libraries with it. In my experience, it'll essentially work forever.
I don't really care if it is Python or any other language. Hyde looked okay when I've started with it (altough the lack of documentation should've been a warning sign).
Is it modern because it's written in Go, or am I missing something?
[deleted]
I use Hugo for a Deep learning blog I just started writing (http://navinpai.github.io/ga) as a self reference.
The main reasons I like hugo:
- The single binary (which others have mentioned)
- The theme support (Somehow, Hugo themes are well designed as opposed to Pelican themes which seem more thrown together)
- The folder structuring is very intuitive
All in all would definitely recommend
The main reasons I like hugo:
- The single binary (which others have mentioned)
- The theme support (Somehow, Hugo themes are well designed as opposed to Pelican themes which seem more thrown together)
- The folder structuring is very intuitive
All in all would definitely recommend
would you mind create a blog post how to create your blog using this tools.
Some previous discussion:
* https://news.ycombinator.com/item?id=10646508
* https://news.ycombinator.com/item?id=10627585
Strangely I can't find any posted story for the 0.16 release...
* https://news.ycombinator.com/item?id=10646508
* https://news.ycombinator.com/item?id=10627585
Strangely I can't find any posted story for the 0.16 release...
I am a hugo user, but I noticed that it has been slower and slower. I ran a --stepAnalysis, and it shows that the most expensive step is
Started building sites ... Go initialization: 5.722103073s (5.722526117s) 2.66 MB 22083 Allocs
The rest of the steps take 115ms. What is happening in go init, and why does it take so long?
Started building sites ... Go initialization: 5.722103073s (5.722526117s) 2.66 MB 22083 Allocs
The rest of the steps take 115ms. What is happening in go init, and why does it take so long?
This is surprising and counter to what most others are experiencing.
Many of the performance optimizations have tradeoffs and while they increase performance for the majority of cases, some cases will experience slight degradation.
This is also a surprisingly long time for initialization. My site with a few hundred pages on a rather old mac (with an SSD) has
Go initialization: 48.00164ms (48.842363ms) 2.14 MB 18299 Allocs
Do you have your site source available publicly so we can do more testing and benchmarking with it? We'd love to understand the places where it's not improving so we can address them further.
Many of the performance optimizations have tradeoffs and while they increase performance for the majority of cases, some cases will experience slight degradation.
This is also a surprisingly long time for initialization. My site with a few hundred pages on a rather old mac (with an SSD) has
Go initialization: 48.00164ms (48.842363ms) 2.14 MB 18299 Allocs
Do you have your site source available publicly so we can do more testing and benchmarking with it? We'd love to understand the places where it's not improving so we can address them further.
[deleted]
The only thing that is said to make Hugo better than other static site generators is that it compiles fast. This is probably because of Go. Now Go is so fast because it uses ALGOL's compiling methods...
I wonder how fast Hugo would be if it was written in Pascal instead.
I wonder how fast Hugo would be if it was written in Pascal instead.
One could also argue that developers also has some impact on speed in an app like Hugo. The measured speed increase from Hugo 0.16 was 40/60 Go vs Developer.
Weird that their header over 'Run Anywhere' reads 'S Q R.' Is it perhaps a mis-spelt allusion to the senate and people of Rome?
Wasn't that more like 'SPQR'?
https://en.wikipedia.org/wiki/SPQR
https://en.wikipedia.org/wiki/SPQR
Yes, that's why I wrote 'mis-spelt.' I was making a point about their use of JavaScript to load fonts to display glyphs, which of course fails miserably if one has JavaScript disabled (as anyone who cares about privacy and security does).
so after going to your landing page, I'm still unsure of what I get from Hugo? I use bootstrap to build my websites. How does Hugo work exactly?
Let me sum it up for you: it is yet website generator that allows you to spend an entire weekend making something that almost works while reading reams of boring documentation.
The next weekend you will already have forgotten how to work it and you think "fuck it" and either install Jekyll (which is also a piece of shit, but it is a piece of shit that has a bigger community) or you think "screw this" and sign up for some website generation service your slightly odd uncle uses.
Wake me up when someone makes a website generator for people who really aren't interested in website generators.
The next weekend you will already have forgotten how to work it and you think "fuck it" and either install Jekyll (which is also a piece of shit, but it is a piece of shit that has a bigger community) or you think "screw this" and sign up for some website generation service your slightly odd uncle uses.
Wake me up when someone makes a website generator for people who really aren't interested in website generators.
That would be me. I found Hugo and Jekyll because I wanted a simple but powerful way to build websites.
After using Drupal and Wordpress for years they're a total breath of fresh air.
I can put together a site in a fraction of the time it would normally take, host it for free, and through services like Snipcart, Typeform and Forestry.io, add some surprisingly sophisticated functionality.
For what they do, Hugo and Jekyll are excellent.
After using Drupal and Wordpress for years they're a total breath of fresh air.
I can put together a site in a fraction of the time it would normally take, host it for free, and through services like Snipcart, Typeform and Forestry.io, add some surprisingly sophisticated functionality.
For what they do, Hugo and Jekyll are excellent.
That mostly says something about Drupal and Wordpress.
> Wake me up when someone makes a website generator for people who really aren't interested in website generators.
Been thinking about doing exactly that as a side project.
Main features:
* Free as in Beer & Source
* Available as Chrome Extension and Desktop (Electron) App
* You add posts / pages using a UI
* Select themes like you do in Wordpress
* Click to push to GitHub pages, Amazon etc.
* Save as JSON for portability and backup
* No Command Line. No dependencies.
Been thinking about doing exactly that as a side project.
Main features:
* Free as in Beer & Source
* Available as Chrome Extension and Desktop (Electron) App
* You add posts / pages using a UI
* Select themes like you do in Wordpress
* Click to push to GitHub pages, Amazon etc.
* Save as JSON for portability and backup
* No Command Line. No dependencies.
Why not make it as a command line program that requires only the barest minimum of depedencies? And be bold: make strong conventions so that the source structure is as identical as possible for each site -- so people can build on your project and provide tooling for it.
Focus on getting the basics right.
Focus on getting the basics right.
I think Hugo is that.
The itch I am scratching here is for:
1. Someone who knows the benefits of a self-hosted static site over say wordpress.com/.org. So probably some technical.
2. But doesn't want to learn another command line app, a new templating system etc. Just wants to write stuff and publish it in an intuitive way. They don't want to shave that Yak to write their blog. Hell they are so damn lazy they don't want to download and install anything! (hence a chrome app)
I currently solve this using Github pages, letting it generate the site for me so no local install. But that feels a bit locked in.
The itch I am scratching here is for:
1. Someone who knows the benefits of a self-hosted static site over say wordpress.com/.org. So probably some technical.
2. But doesn't want to learn another command line app, a new templating system etc. Just wants to write stuff and publish it in an intuitive way. They don't want to shave that Yak to write their blog. Hell they are so damn lazy they don't want to download and install anything! (hence a chrome app)
I currently solve this using Github pages, letting it generate the site for me so no local install. But that feels a bit locked in.
Yes, Hugo tries to be that, but it doesn't succeed in offering enough good conventions, so if you want to use one of the many setups available things are going to get messy.
Making something a website generator isn't easy. Not least because people who design and implement these things seem to love fiddling around with website generator tools. Which isn't necessarily what users like.
Making something a website generator isn't easy. Not least because people who design and implement these things seem to love fiddling around with website generator tools. Which isn't necessarily what users like.
What happens is that someone gets as angsty about it as you just displayed, but decides to do something about it, and starts a website generation service.
Y'know, that one your odd uncle is using.
Y'know, that one your odd uncle is using.
There's still a need to solve the basic problem: a command line site generation tool. Preferably one that doesn't try to solve everything else in the process and ends up being a poor something else. Build something that does one job well and design it with the intent that other people can build on it.
For instance so someone can use it to build a website generation service. (Yeah, you kinda do have to solve the basic problem of generating the HTML anyway, so one might as well focus on doing the core part of it well)
I'm not saying it is easy. In fact, it is hard because people tend to get too familiar with their own mess. Or they think it is easy.
(And no, that wasn't angst. That was realism conveyed in a honest manner)
For instance so someone can use it to build a website generation service. (Yeah, you kinda do have to solve the basic problem of generating the HTML anyway, so one might as well focus on doing the core part of it well)
I'm not saying it is easy. In fact, it is hard because people tend to get too familiar with their own mess. Or they think it is easy.
(And no, that wasn't angst. That was realism conveyed in a honest manner)
Maybe a bit over the top, but you definitively said it like it is. This stuff can get us all pumped up here on hacker news, but good luck doing this for clients who want simple websites "i can update myself".
Which in 2016 is like 90% of clients.
Therefore, the one and only piece of software everybody here loves to despise: wordpress.
Just wondering, have you tried Lektor[1]? I heard it is non-engineer friendly, although, I haven't tried it myself yet.
[1] - https://www.getlektor.com/
[1] - https://www.getlektor.com/
Nope. I'll have a look. Thanks.
It is a static site generator. You get a lot out of hugo when you start writing blogposts or content with markdown and let hugo do is work to generate content. At my company we build our website with it and now all the team can contribute with blogpost just by writing normal markdown files. http://tengio.com/blog/company-website-using-hugo/
Bootstrap is a CSS3 framework, hugo is static content generator written in Go.