Hacker News Reader

Comment by stavros | Hacker News Reader

I'd like to second Hugo. Static sites with Netlify are a joy, since they can handle however much traffic you want, there are no scaling headaches or updates or stuff for bots to randomly hack.

I'm currently trying to decide between Lektor and Hugo, Lektor's data model seems more powerful, Hugo seems harder to learn (worse-quality docs) but Lektor doesn't seem very actively maintained, and Hugo has a larger community around it.

View on HN

Co-founder of https://forestry.io here.

As an interesting speed comparison, one of our users has a site with 2,000 blog posts that takes Jekyll 10 mins to build. We migrated it to Hugo and the build time went down to 900 ms.

We're big fans of Jekyll, but Hugo certainly beats it when it comes to speed.

That's awesome. I'll have to check this out. I wonder what type of speed improvements one could get rewriting this with crystal-lang (https://crystal-lang.org).

I'm also trying to decide between Hugo and Lektor (Note: I'm having some flask experience). At first view Hugo seemed superior but I looked at some important specifics for me like e.g. thumbnail generation, Plugin System (important for developers) or CMS like editing. All this stuff is not available in Hugo core but it's already built into Lektor. It seems the biggest weakness of Hugo is that it is statically built and not easy to extend (only easier to deploy). If you build your own Makefile/gulp etc. around it it may also work for you but Lektor is more flexible when looking at this. From a developers perspective Lektor seems more customizable... unless you are a die hard Go developer. I think Lektor community can outgrow Hugo's one because of the plugin system. Building a toolset around a binary to extend a page generator does not seem the right way @hugo team. But at the end it all depends on your requirements. Hugo is much much easier to deploy and many people do not want to extend their page generator.

I agree, but someone on the Hugo forums pointed me to this issue:

https://github.com/lektor/lektor/issues/180

The fact that it's such an egregious issue (85 minutes for 2000 posts?!) that has been open for 9 months doesn't give me much hope in the development speed of Lektor. This also matches my experience, as I see trivial issues and PRs open for months in Lektor's repo...

The Lektor dev (it wasn't Armin) told me on Gitter that development has stalled a bit, but will hopefully pick up in 2017. I certainly hope so, becaue it's a well-designed site generator.

maybe when community and development speed and extensibility are the main requirements it all leads back to Jekyll :/ if I would be a ruby guy it would be definitely my first choice. Hugo is the speedy gonzales with easy deployment but lacks good extensibility when you want to go into the code level :(

I think you're right... Bah, just when I was convinced by Hugo, you convinced me to use Lektor again :P

sorry :D it really depends on your requirements. If Hugo in its current state covers you or if you can live with a light toolchain around Hugo go Hugo (I think many people do not need to touch the go code). There is nobody saying that you cannot write a little python code which is run before/after hugo (actually some people are doing that!). But if you want total control/extensibility with your python code in the page generator the Lektor plugin system will give you more power.

I decided to go with Lektor in the end, since it's much easier to work with and good enough for my purposes for now. Plus, since I'm a Python dev, I can extend it much more easily.

I am bep, the lead maintainer of Hugo. A plugin system will happen in Hugo, and I don't think it will take too long to get there -- we have been thinking about it for some time, and it feels natural to have that before we call it 1.0. CMS like editing is something that could live well outside of Hugo, me thinks.

Thanks bep. I'm really looking forward to that. With a plugin system the Hugo community will also grow IMHO. Looking forward to it. I agree that CMS like editing should not necessarily be inside of Hugo.

Oh that's exciting. Will be a great addition to a really good system.

Looking forward to it!

Yeah, the lack of thumbnail generation is an issue. It's definitely something which should be built in.

Agree.

bep (Hugo maintainer)

Reply on news.ycombinator.com