7 ms·

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 an

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?

angusp 10y ago
Jekyll also has the (perhaps unfair) advantage of being baked into GitHub pages, making it's workflow super easy
- pmoriarty 10y ago
  Could you elaborate on this? As someone unfamiliar with Jekyll, I don't know what you mean.
  - detaro 10y ago
    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.
    - amenghra 10y ago
      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.
- 0xCMP 10y ago
  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.
  - endisukaj 10y ago
    > 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.
- bobfunk 10y ago
  We do this for hugo (and any other build tool) at Netlify (https://www.netlify.com https://www.netlify.com) together with a whole bunch of extra features to make the workflow even easier.
andmarios 10y ago
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.
- harlanlewis 10y ago
  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.
- Xeoncross 10y ago
  This is the reason I wrote http://github.com/xeoncross/jr http://github.com/xeoncross/jr - the static, static website generator.
  - glaberficken 10y ago
    I really like the minimalism here. Is SEO a concern for this though?
    - endisukaj 10y ago
      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.
adiabatty 10y ago
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.
- rocky1138 10y ago
  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.
  - headmelted 10y ago
    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!
NeutronBoy 10y ago
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.
- sfifs 10y ago
  Oh interesting! Care to share a small write-up about how you set it up?
  - NeutronBoy 10y ago
    The key stuff is from this project (not mine) https://github.com/ryansb/hugo-lambda 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.
- jambulance 10y ago
  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.
  - NeutronBoy 10y ago
    See my reply here https://news.ycombinator.com/item?id=12675780 https://news.ycombinator.com/item?id=12675780
bjornerik 10y ago
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.
- justajot 10y ago
  I saw that speed was greatly improved in Hugo 0.17 as well. Thanks for all your hard work!
- type0 10y ago
  > 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.
jvns 10y ago
I wrote a blog post yesterday about switching to Hugo from Jekyll: http://jvns.ca/blog/2016/10/09/switching-to-hugo/ 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.
tunaoftheland 10y ago
Decent-looking, free themes to get started with: http://themes.gohugo.io/ 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.
deleted 10y ago
[deleted]
bootload 10y ago
one reason, Hugo is written by @spf13, a HN reader, and is easier to contact directly. [0] https://news.ycombinator.com/user?id=spf13 https://news.ycombinator.com/user?id=spf13
jacquesm 10y ago
Fast, reliable, extremely responsive dev team, very clean codebase what's not to like?
mrmondo 10y ago
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.
kowdermeister 10y ago
> 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.
hypertexthero 10y ago
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 https://github.com/hypertexthero/sgg

angusp 10y ago

Jekyll also has the (perhaps unfair) advantage of being baked into GitHub pages, making it's workflow super easy

pmoriarty 10y ago
Could you elaborate on this? As someone unfamiliar with Jekyll, I don't know what you mean.
- detaro 10y ago
  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.
  - amenghra 10y ago
    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.
0xCMP 10y ago
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.
- endisukaj 10y ago
  > 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.
bobfunk 10y ago
We do this for hugo (and any other build tool) at Netlify (https://www.netlify.com https://www.netlify.com) together with a whole bunch of extra features to make the workflow even easier.

andmarios 10y ago

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.

harlanlewis 10y ago
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.
Xeoncross 10y ago
This is the reason I wrote http://github.com/xeoncross/jr http://github.com/xeoncross/jr - the static, static website generator.
- glaberficken 10y ago
  I really like the minimalism here. Is SEO a concern for this though?
  - endisukaj 10y ago
    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.

adiabatty 10y ago

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.

rocky1138 10y ago
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.
- headmelted 10y ago
  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!

NeutronBoy 10y ago

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.

sfifs 10y ago
Oh interesting! Care to share a small write-up about how you set it up?
- NeutronBoy 10y ago
  The key stuff is from this project (not mine) https://github.com/ryansb/hugo-lambda 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.
jambulance 10y ago
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.
- NeutronBoy 10y ago
  See my reply here https://news.ycombinator.com/item?id=12675780 https://news.ycombinator.com/item?id=12675780

bjornerik 10y ago

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.

justajot 10y ago
I saw that speed was greatly improved in Hugo 0.17 as well. Thanks for all your hard work!
type0 10y ago
> 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.

jvns 10y ago

I wrote a blog post yesterday about switching to Hugo from Jekyll: http://jvns.ca/blog/2016/10/09/switching-to-hugo/ 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.

tunaoftheland 10y ago

Decent-looking, free themes to get started with: http://themes.gohugo.io/ 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.

deleted 10y ago

[deleted]

bootload 10y ago

one reason, Hugo is written by @spf13, a HN reader, and is easier to contact directly. [0] https://news.ycombinator.com/user?id=spf13 https://news.ycombinator.com/user?id=spf13

jacquesm 10y ago

Fast, reliable, extremely responsive dev team, very clean codebase what's not to like?

mrmondo 10y ago

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.

kowdermeister 10y ago

> 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.

hypertexthero 10y ago

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 https://github.com/hypertexthero/sgg